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.

Client
APPLEPIE
Year
2026
Scope
Performance, accessibility, German localisation
Stack
Static HTML, no build step at deploy
Standard
WCAG 2.1 AA via EN 301 549
01Numbers

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

−75%. Requests in the critical path went from 9 to 4.

Logo
133 KB, two PNGs6.1 KB, one SVG

Traced to vector; one file serves both themes through currentColor.

Fallback font
102 KB18 KB

Subset to the 124 glyphs the site actually uses.

axe-core violations
—0

Across every page, both language branches, on every deploy.

Worst contrast found
1.81:15.10:1

Required: 4.5:1. The failure was in our own navigation.

02The problem

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.

03What we did

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.

04Accessibility

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.

05What it cost

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.

06Next

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.