Lighthouse 90+ isn't hard, it's just early

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.

On a content-led site the list is short, and it runs roughly in 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 the templates use, instead of serving one large original for the browser to scale down. 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 the site uses; 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 undo every other optimisation on the page. On an otherwise well-built site, fonts are the most likely culprit.

Third-party scripts

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.

Some of them earn their place, so refusing them outright is the wrong response. What works is deciding who owns that decision, and measuring after each one goes on rather than discovering the cumulative effect at the next audit.

What 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. The usual causes are content injected above existing content, banners that appear after load, web fonts that change the height of a heading when they swap in, and images without reserved space.

All of those are fixable, and all of them are easier to prevent than to compensate for afterwards.

A bad score is a bug. 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. Same outcome, several times the cost, and now there's a conversation about whether it's strictly necessary, which performance work usually loses.

The thresholds, precisely

It's worth being exact, because "fast" is not a specification and Lighthouse scores are not what Google measures for ranking. The Core Web Vitals thresholds are:1

• Largest Contentful Paint: 2.5 seconds or under. How long until the main thing appears.
• Interaction to Next Paint: 200 milliseconds or under. How quickly the page responds when someone does something.
• Cumulative Layout Shift: 0.1 or under. How much the page moves about while loading.

The detail most people miss is how they're assessed: at the 75th percentile of real visits, and all three have to pass at once.1 A page that's quick for three quarters of users and slow for the rest doesn't pass, and lab conditions on a developer's machine tell you almost nothing about it.

That's why field data matters more than a Lighthouse run. Lighthouse is a useful proxy and a fast feedback loop. It isn't the exam.

What the number is 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.

The number itself isn't the point. 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 without gaming is almost always a site where these decisions were made properly at the start, and that's what we're 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.