How We Got a Perfect 100 Lighthouse Score
A perfect Lighthouse performance score is achievable, and the work required to get there is mostly unglamorous. What surprised us was where the last few points went. After the images were sized correctly, the fonts were trimmed, the render path was clean, and the server was answering immediately, the score still would not reach 100. The remaining deficit did not belong to our code at all. It belonged to Google Analytics.
Everything Before the Last Five Points Is Ordinary Work
There is no trick to the bulk of the score. It is the same list we walk through in What Actually Makes a Website Slow, applied without exceptions. Images sized to the largest dimension they are ever displayed at, in modern formats, with explicit width and height so nothing shifts as they arrive. Video re-encoded honestly and given a poster frame. Fonts reduced to the weights the design actually uses, set to render immediately in a fallback rather than hiding text while waiting. No render blocking scripts. No stylesheets loaded because something else brought them along. A server that answers from cache or from a file instead of assembling a page nobody has changed in weeks.
Do all of that and the score climbs into the high nineties on its own. It is genuinely not complicated. It is only tedious, and tedium is why most sites stop at seventy.
The Last Points Belong to Someone Else
The final stretch is where it becomes clear how little of a typical page is under your control. Every third party tag on the site contributes to the audits that make up the score: unused JavaScript, third party impact, main thread work, and the caching policy of assets you do not host and cannot configure.
We removed our third party code one item at a time and measured after each removal, which is the only way to attribute a change honestly. The pattern was consistent. Each external script cost something. One of them cost more than all the others combined.
Google Analytics Was the Difference
The single largest remaining penalty on our own site came from the Google Analytics tag. With it present, a perfect score was unreachable. With it absent, and nothing else changed, the score was 100.
The irony is difficult to overstate. Lighthouse is Google's auditing tool, built into Google's browser, and one of the most reliable ways to fail its performance audits is to install Google's own analytics script. The tag contributes JavaScript that the page does not use for rendering, occupies main thread time during load, and is served from Google's infrastructure with a cache lifetime short enough that Lighthouse's own efficient caching audit flags it. You cannot fix that last one, because you do not control the headers on a file you are not hosting.
How We Proved It Rather Than Assumed It
Attribution is the hard part of performance work, because scores move for reasons that have nothing to do with the change you just made. Network conditions vary, the throttling Lighthouse applies is simulated, and running the same audit twice on the same page produces different numbers.
To isolate the variable properly, we made the analytics tag conditional on the requesting user agent. Lighthouse identifies itself in its user agent string, so the page could be served with the tag present for ordinary visitors and absent for the audit, with every other byte identical. Running both versions back to back, repeatedly, removed the ambiguity: the analytics tag alone accounted for the gap between a high score and a perfect one. That is a diagnostic technique, and we want to be precise about what it is good for. Used to attribute a cost, it answers a question no amount of guessing will. Left in place permanently, it does something quite different, which is produce a number that describes a version of the site no human being ever receives.
What You Can Actually Do About It
Once you know the cost, the decision is a business one rather than a technical one, and there are only a few honest options.
Accept the score you get with analytics installed. A 96 with working measurement is a perfectly respectable outcome, and for most businesses the marketing data is worth more than the four points.
Load the tag after the page is interactive, or on first meaningful interaction, so it stops competing with rendering. This costs you a small number of very short sessions in the data and recovers most of the performance.
Replace client side analytics entirely. Server logs and server side event collection describe traffic without shipping any JavaScript to the visitor, do not require a consent banner in most configurations, and cannot be blocked by the substantial share of visitors already running content blockers. Those blocked visitors are missing from your current numbers regardless.
Or remove it, if the honest answer is that nobody has opened the dashboard in a year. That is more common than anyone admits.
Is a Perfect Score Worth Chasing
Not for its own sake, and we will say that plainly even in an article about achieving one. A synthetic score is a proxy for an experience, and optimizing the proxy while real visitors wait is a well established way to waste a quarter. A site that scores 100 in a simulated audit and takes five seconds on a mid range phone over a congested network has been tuned for the wrong audience.
What makes the exercise worthwhile is what it forces you to confront. You cannot reach 100 while carrying code you never audited, images nobody sized, fonts nobody counted, or a server that renders a page on every request. The score is not the goal. It is a strict examiner that refuses to let you skip the work, and the work is what the visitor actually feels.
The site you are reading was built to that standard, which is also why we treat speed and user experience as an architectural property rather than a task at the end of a project.
If your scores have stalled and nobody can say which change would move them, we can tell you exactly where the points are going. Contact us and we will take a look.