Our own
site
The first case study is ours, for a plain reason: we can publish every number in it without asking anyone. Everything here is verifiable on the live site right now.
What changed, measured
Every figure below was taken on the production site, before and after. None of them are projections.
- Critical path
334 KB80 KB- Logo
133 KB, two PNGs6.1 KB, one SVG- Fallback font
102 KB18 KB- axe-core violations
—0- Worst contrast found
1.81:15.10:1
−75%. Requests in the critical path went from 9 to 4.
Traced to vector; one file serves both themes through currentColor.
Subset to the 124 glyphs the site actually uses.
Across every page, both language branches, on every deploy.
Required: 4.5:1. The failure was in our own navigation.
A site that sold engineering without showing any
The site loaded 334 KB before it could paint. Two versions of the logo shipped as PNGs because the mark had to work on both a light and a dark background. A fallback font shipped whole, all 102 KB of it, to cover eight characters the display face was missing.
None of that was visible to a visitor on a good connection, which is exactly why it survived. It became a problem the moment we started selling technical quality: the argument is not credible from a slow site.
Three changes did most of the work
The logo became one vector. Traced from the PNG, then reduced to a single file that inherits its colour from currentColor — so one asset serves both themes instead of two bitmaps. 133 KB became 6.1 KB.
The fallback font was subset. Not to the eight missing glyphs, which was the obvious move and the wrong one — the same face is the body font on the imprint, privacy and 404 pages. Subsetting to the union of everything actually used across the site gave 124 glyphs and 18 KB.
Fonts are preloaded per page. The home page and the interior pages use different faces, so preloading the same pair everywhere would have cost more than it saved.
One thing we tried and rejected: Brotli compression. The module is not present in nginx and not in apt on this server, and installing it through a PPA would have upgraded nginx for all eighteen domains that share the machine. The gain was 3–4 KB. That is not a trade worth making with other people's sites.
The failure we found in our own navigation
Running the audit against ourselves turned up a contrast ratio of 1.81:1 where 4.5 is required — beige text on an olive background, a combination the brand guidelines explicitly allowed. It was not a mistake anyone would catch by eye. Two stacked opacity values produced it, and it sat in the navigation on every page.
Fixing it meant changing where one colour was permitted to appear, not adjusting a single component. Later the same audit caught the secondary text colour at 4.52:1 — passing, but by 0.02. That is not a margin; it is a coincidence. It is now 5.10.
The full result, including what is still open, is published in our accessibility statement. Publishing the open items was not a marketing decision — it is the only honest way to sell audits.
Time, plainly
The performance work took roughly six hours across three days. The accessibility work is not a fixed number because it is not finished: the audit runs on every deploy, and the statement is updated when something changes. That is the shape of this kind of work, and any agency quoting you a one-off number for accessibility is quoting you the wrong thing.
Want this measured on your site?
The same method applies to any site: measure first, publish the numbers, fix what the numbers show. Start free with the self-check, or read the study behind our accessibility work.