Lighthouse 90+ isn't hard, it's just early
Nearly every performance problem we've inherited was a decision made in week one and discovered in week nine.
Performance has a reputation as a specialist discipline involving profiling tools, waterfall charts and difficult trade-offs. Occasionally that's true. Mostly it's a handful of decisions made early, and the specialist work only becomes necessary when those decisions went the other way and somebody now has to undo them.
Here's what actually matters on a content-led site, in rough order of impact.
Images, and then everything else
On a marketing site, images are usually most of the problem and nearly all of the easy wins. Four things, all decided at build time:
- Serve modern formats, with a fallback. This alone often halves the transferred bytes.
- Generate transforms at the sizes actually used, rather than serving one large original scaled down by the browser. A 2,400px image displayed at 400px is roughly thirty-six times more data than needed.
- Give every image explicit width and height attributes so the browser reserves the space. This is what stops the page jumping around as things load, which is both a metric and the most irritating thing a website can do.
- Lazy-load everything below the fold, and never lazy-load the one at the top. Lazy-loading your hero image delays the exact thing the page is measured on.
That's close to the whole of it, and it's about a day of work at the start of a build. Retrofitting it once a site is full of client-uploaded content is a different job with a different price, because now there are four hundred existing images to reprocess and template changes to make against a live site.
Fonts are the other half
Self-host them. Subset them to the characters you actually use — a full font file carries glyphs for languages the site will never serve. Preload the one used in the hero, because that's the one blocking your largest contentful paint. And make sure text is visible while the font loads rather than after it, so the page isn't blank for 300ms on a slow connection.
Two custom fonts loaded well cost almost nothing. Four loaded from a third-party host, unsubset, blocking render, will comfortably undo every other optimisation on the page. Fonts are the thing most likely to be the problem on an otherwise well-built site.
Third-party scripts are where scores go to die
A site can be immaculate at launch and score badly three months later because marketing added a chat widget, a heatmap tool and two tag managers, none of which anyone measured.
This isn't an argument for refusing them. Some of them earn their place. It's an argument for deciding who owns that decision, and for measuring after each one goes on rather than discovering the cumulative effect at the next audit.
The practical version we suggest: one person approves tags, and every addition gets a before-and-after measurement. It takes two minutes and it makes the cost visible at the moment somebody is choosing to pay it.
Layout shift is a design problem in disguise
Cumulative layout shift — things moving as the page loads — is measured as a performance metric and is very often caused by design decisions. Content injected above existing content. Banners that appear after load. Web fonts that change the height of a heading when they swap in. Images without reserved space.
All of those are fixable, and all of them are much easier to fix by not doing them than by compensating for them afterwards.
We treat a bad score as a bug, not a nice-to-have. Bugs get fixed before launch; nice-to-haves get discussed until the budget runs out.
Why it's so much cheaper at the start
In week one, performance is a set of defaults. How image transforms are configured. How fonts are loaded. What the base template includes. Nobody needs persuading, because there's nothing to undo and no visible cost.
In week nine it's a change to templates that already work, against content that's already loaded, with a launch date in the calendar and a client who's just seen a demo. Identical outcome, several times the cost, and now there's a conversation about whether it's strictly necessary — which is a conversation performance work usually loses.
What the number is actually for
We commit to 90 or better across all four Lighthouse categories on the templates that matter, and Core Web Vitals in the green on real-world data rather than lab conditions.
Not because the number itself is important. It's a proxy, it's imperfect, and it's possible to game it in ways that make a site no better to use. But a site that hits it honestly is almost always a site where these decisions were made deliberately at the start — and that's the thing we're actually promising.
The templates that matter, incidentally, means the ones people arrive on. A perfect homepage score and an unmeasured article template is a marketing exercise, not an engineering one.