How We Got Our Own Homepage to 97/95/100/100 — And Logged Every Mistake That Got Us There
We almost shipped a homepage section that printed our own PageSpeed score next to a button inviting visitors to check it live. Good thing we didn't — the number changed before we hit publish. Here's the actual, unglamorous story of what it took to get the real score up, including the parts where we were wrong.
Those are the numbers as they stood when this post was first written, mobile, Slow 4G — not rounded up. Accessibility wasn't a 100 yet, and we weren't going to pretend otherwise on our own page about not pretending otherwise. Here's how we got from a homepage that looked finished to one that's actually been checked.
Two more rounds of testing after this post went up found a second white-on-orange contrast failure we'd missed — the EN/Vietnamese language toggle on one of our client samples, same root problem as the buttons above, just a different CSS rule. We'd been searching by component name (.btn-primary) instead of by the actual failing color combination, so a second instance of the same pair hid in plain sight. Fixed the same way. Final confirmed run: Performance 99, Accessibility 100, Best Practices 100, SEO 100. We're leaving the numbers in the headline and scorebar above exactly as they were when this was first published — that's the whole point of an incident log. This update is the same discipline applied to this post about the discipline.
Eleven days later: the homepage — and every page and domain this studio operates or maintains — measures a verified 100/100/100/100 on mobile PageSpeed. The remaining points came from the v2 build standard that this post's mistakes helped write: analytics deferred until 1.5 seconds after the page loads, a hero video that downloads nothing until the page is fully interactive, and every color pair checked by computation instead of by eye. The full accounting, receipts and new mistakes included, is in Four Domains, Twenty 100s. The headline and scorebar above stay exactly as published, per the same policy as the first update.
It started with a link, not a number
The original idea was simple: put a PageSpeed Insights link on the homepage and dare visitors to test us. The pitch was solid. The execution almost wasn't — the first draft wanted to print a fixed score (96/93/100/100) next to that link. We ran the test again twenty minutes later. Performance had moved to 85. Then 78. Then back up to 99.
A page that says "don't take our word for it, check it yourself" cannot also print a number the live check might immediately contradict. We pulled the fixed numbers and kept only the ones that never moved — Best Practices and SEO, both a clean 100 every single run.
The font request was the whole problem
There's not a single image on this homepage. Every byte of the page is markup, CSS, and type. So when Largest Contentful Paint kept landing north of 3.5 seconds on a throttled connection, the culprit wasn't hard to find: three font families, loaded from Google's CDN, with display:swap.
We fixed it in three passes, each one smaller than the last:
- Swap → optional. One parameter change. Stopped the late font-swap reflow that was producing a Cumulative Layout Shift of 0.104 — over the "good" threshold.
- Self-hosted the fonts. Pulled all twelve weight files onto our own server, cutting two cross-origin round trips out of the critical path entirely. CLS dropped to a flat 0.
- Removed the custom fonts altogether. Once every other metric was already high, font loading — even self-hosted — was the only thing left holding Performance back from triple digits. We made a deliberate call: trade the brand's distinctive serif headlines for zero font network requests, on this one performance-critical page. Not a new default. Just an honest trade, logged as one.
The lesson that stuck: on a text-only landing page, check font-loading strategy before chasing anything else. It's usually the entire story.
Two contrast bugs, same root cause, found a week apart
Our own accessibility checklist has said "verify orange-on-bone and orange-on-ink text meets WCAG AA" since the day this design system existed. It took an actual failing Lighthouse run to discover that nobody had ever calculated the ratio. Plain brand orange on our bone background measures roughly 2.75:1 — nowhere near the 4.5:1 floor for normal text. It had been sitting on the process-step number badges and the FAQ expand icon the entire time.
A separate, unrelated contrast bug turned up earlier in the same week: a muted gray comparison column, deliberately styled to look washed-out, that turned out to actually fail at roughly 3.7:1. Different bug, same underlying mistake — a checklist item existing is not the same thing as a checklist item being followed.
A heading level nobody could see by looking
Lighthouse's accessibility audit flagged a heading order violation in two places: a nonprofit section and the entire footer, both jumping from an <h2> straight to an <h4> with no <h3> in between. Visually, nothing was wrong — the text sizes looked exactly like they were supposed to. Heading order isn't a visual property. It's a document-structure property a sighted reviewer has no reason to ever notice, and a screen-reader user immediately does.
Why we stopped trusting a single Lighthouse run
Across roughly an hour of repeated testing on one completely unchanged page, Performance returned 96, 85, 78, 99, 91, and 97. That's not six different bugs. That's normal lab variance — simulated network conditions and device emulation noise that Google's own documentation explicitly warns about. The fix wasn't a code change at all; it was breaking each run down with the Lighthouse Scoring Calculator to check whether the underlying metrics (FCP, LCP, TBT, CLS) had actually moved, instead of reacting to one composite number.
The actual secret sauce
There isn't a single clever trick in any of this. The methodology is just: test against the real tool, fix what it actually finds, write down exactly what broke and why the moment it's fixed, and don't let a later page contradict what an earlier page already proved was true. Every fix above is now a numbered entry in our internal design system document — not so we can say we did it once, but so the same mistake has a much harder time happening twice, on this site or a client's.
We hold our own site to the exact same checklist we use on every audit — published and not retouched after the fact.
See how we audit other sites →