We have shipped a lot of Lighthouse 100s. Desktop performance scores of 100 are routine across our builds for AAS, Creative Maintenance Solutions, IMS, Kwaan Bear Technology, Salyers Construction, and SearchRadar. Our accessibility, best practices, and SEO scores sit at 100 on every page we check, not a sampled handful.
So take this as testimony from inside the badge: a Lighthouse score is a more complicated object than the marketing around it suggests. Some of what moves the number is real engineering. Some of it is the measurement itself. Knowing which is which is most of the job.
The score moves when nothing changed
Run Lighthouse against the same page twice and you can get two different numbers. Lab metrics have run variance, and the conditions around the test leak into the result. We have measured first contentful paint at around 400 milliseconds in the afternoon and over 2 seconds in the evening on identical code, purely from home-network congestion. A score taken under those conditions describes the Wi-Fi, not the site.
The default mobile test adds a subtler layer. Lighthouse simulates a slow device and network with a mathematical model, and that model assumes a client-rendered page cannot paint until its JavaScript finishes hydrating. On an animated site, that assumption penalizes exactly the motion you designed in. Re-run the same page with real device throttling instead of the simulation and the score often lands around 99.
So our protocol before any performance refactor is to figure out whether we would be fixing the page or fixing the measurement. We verify on a local production build, on Google's own test servers, and against real-user field data before we believe a bad number.
Chrome's LCP heuristics have trapdoors
Largest contentful paint sounds simple: when did the biggest thing show up. In practice, Chrome applies heuristics that quietly change what gets measured.
- A full-viewport hero image can be excluded from LCP as wallpaper, so the paint you care about most may not be the one being scored.
- An element that starts at opacity zero for a fade-in entrance never generates an LCP entry at all.
- An image compressed below roughly 0.05 bits per pixel is discarded as low-entropy, and the metric silently shifts to something smaller, often the nav logo.
We hit that last trap on AAS. The hero image had been compressed to about 5KB, small enough that Chrome stopped counting it as the LCP element. The fix was raising its quality setting from 40 to 60: a slightly larger file that made the measurement honest again. Optimization folklore says smaller is always faster. Past a point, smaller is just blurrier.
Animated pages trade points for character
Here is a trade we made with open eyes. One of our richly animated pages topped out around 95 to 97 on the synthetic mobile test, because the remaining render delay was the entrance animation itself. Real-world measurement of the same page read 99.
We kept every animation and accepted the 96. The alternative was stripping the motion that gives the site its character to satisfy a simulation no real visitor experiences. That is a bad trade, and we would rather explain the number than quietly gut the design.
This is standing policy, not a one-off. We never strip imagery or motion for a score. We use quality-neutral levers only, and we prove visual parity with before and after screenshots so the design survives the optimization intact.
What a real 100 actually takes
None of this means the 100s are fake. It means the honest ones are engineering, not a trick. A perfect accessibility, best practices, and SEO score across an entire site requires holding every page to the bar, including the ones nobody screenshots for the case study.
On Creative Maintenance Solutions, that meant 346 Lighthouse runs: 173 pages, each tested on mobile and desktop, every one scoring 100 for accessibility, best practices, and SEO. On Polymer Nation, Google's PageSpeed test reads 100 in all four categories on desktop, and 98 on performance with straight 100s everywhere else on mobile.
Numbers like that come from structural decisions, not from a plugin installed the week before launch:
- Metadata generated by shared factories, so every title and description lands within budget on every route.
- Structured data built from the same typed content that renders the page, so the two can never drift apart.
- Contrast ratios engineered into the design tokens themselves, with the math documented next to the values.
- Heading order enforced where the content is generated, so hundreds of pages cannot ship a broken outline.
The number is a tool, not the verdict
We treat performance as a feature and we keep the receipts. But a score is a communication tool. The verdict is whether a visitor on a mid-range phone gets a fast, legible, usable page that still looks like somebody designed it on purpose.
So when you see a 96 on one of our animated pages, it is not a compromise we failed to notice. It is a decision we made deliberately, with the real-world number at 99 and every pixel of the design intact.
