I aim for Lighthouse 100. But the score does not decide the project

100 is not a badge to put on a website

I like scores because they force us beyond generic claims. “Fast”, “accessible” and “optimised” are easy words to write. A test run on a real page, on a specific date and with a declared profile produces a result that can be verified.

That is why I publish evidence and keep measuring it. I do not treat Lighthouse as a marketing decoration or a test reserved for the homepage. A change to a shared component can affect many pages; a language, form or feature can behave differently from the rest of the website.

An isolated number, however, says little unless I know which page was tested, under which conditions, on what device and before or after which changes. A 100 can be genuine while still describing only the most convenient part of the project.

I am not interested in collecting perfect scores. I want to know why a page reaches them and notice when it stops doing so.

The method starts at the maximum

Every project begins with the same technical target. I do not build the website first and then try to recover the remaining points: image weight, font loading, code structure, contrast, keyboard navigation, metadata and scripts shape decisions while the website is taking form.

My verification standard is simple to state and more demanding to apply.

A 98 or 99 therefore does not become the new target. It is a tolerance that requires a cause. If a value falls below the threshold, the check fails and the problem must be addressed. If it fluctuates, I repeat the test under the same conditions before deciding what the result means.

This rigour is not a contractual promise of four perfect scores in every possible situation. It prevents “fast enough” and “technically fine” from remaining opinions without a measurement.

The difference between a constraint and an excuse

A score can fall for many reasons: a code regression, an oversized image, a script loaded without need, a slow server response or an external dependency. They do not all mean the same thing.

The first questions are always technical. Can I remove the cause? Can I achieve the same result with less weight, fewer requests or less JavaScript? Can I load a resource only when it is needed? Can I prevent it from blocking the main part of the page?

While a correction exists that does not harm the project, the score is not a compromise: it is unfinished work. Client requirements cannot become a generic formula for justifying neglected assets, unnecessary libraries or uncontrolled integrations.

A genuine constraint begins only after identifying the cause, testing alternatives and measuring the result. Before then, it is too early to say that a 98 is unavoidable.

A hero is not automatically a mistake

A large opening image can be one of the most important elements in a project. It can present a product, make photographic work recognisable or give the page the character that distinguishes one business from another. It can also become the heaviest resource in the first viewport.

The professional response is not to remove it immediately. I first choose the format, compress it, prepare appropriate sizes for different screens, declare the space it will occupy and verify when it should load. If it is a video, I consider whether it should really start, whether a cover image is enough or whether it can wait for a user action.

After that work, the hero may still affect the result. The question is no longer “how do I gain another point?”, but “how much value would the project lose if this element were removed or diminished?”.

The opposite also applies. A huge photograph chosen by habit, an autoplaying decorative video or five variants downloaded for no reason are not an identity choice: they are a problem to fix.

Third parties are part of the result

Booking, maps, payments, video, chat and other external services may be necessary. They also bring code, connections and response times that I do not control entirely. Even when the local integration is clean, a provider can change a script or respond more slowly.

In many cases I can reduce the impact: load a map after consent or a click, show a cover before a video, limit scripts to the pages that need them, or link to a service instead of embedding it everywhere. In other cases, the feature must be immediately available because it is central to the page’s task.

A demonstration website stripped of every dependency may achieve 100. The same project with a genuinely working booking function may stop at 99. The first score does not automatically make the first website better.

What matters is being able to demonstrate that the function is useful, the integration has been reduced to what is necessary and the remaining cost is known. “It is the external service’s fault” is not a sufficient diagnosis.

Four perfect scores do not certify everything

Even a perfect result has precise boundaries. Lighthouse runs a laboratory test. It is extremely useful for finding regressions and reproducible problems, but it does not observe every network, device and interaction of the people who will use the website.

The Accessibility category finds many automated issues; it does not replace manual checks, keyboard navigation or a complete conformance assessment. Best Practices is not a penetration test. SEO verifies a technical foundation; it does not promise rankings, visits or citations in AI answers.

The Google Search Central documentation (opens in a new tab) explains that strong technical-report results do not guarantee top rankings and that page experience includes more than one or two indicators. The web.dev guide to Core Web Vitals (opens in a new tab) also distinguishes Lighthouse laboratory data from data collected over time from real users.

That is why I combine scores with checks on routing, forms and email, responsive behaviour, light and dark themes, keyboard use, content, metadata, structured data, privacy, security and feature behaviour. When sufficient real-world data exists, I also examine field Core Web Vitals.

The real evidence is the process

A screenshot captures one moment. A method must keep working when the website changes, the browser is updated, an external provider modifies its code or a new page enters the architecture.

That is why I record the page, environment, date, profile and results. I check what changed and what may have been affected by it. If a live test reveals a regression, the work is not finished merely because everything looked fine locally.

It is also the most honest way to present numbers to a client: not as an abstract guarantee, but as the consequence of a verifiable process that continues after the first test.

In my website services and delivery standards I do not promise an immutable score or automatic rankings. I design, measure, correct and document everything that is genuinely within my control.

What someone commissioning a website should ask

Asking for Lighthouse results is useful. Stopping at the number is much less so. A serious test should at least identify the URL, date, environment and profile used.

Then come the questions the chart does not contain: do forms actually send email? Can the page still be used with a keyboard? Do important images retain their quality? Do external functions serve the goal? Does the website protect data and routes? Are content and actions understandable to the people it was built for?

A professional should not be afraid to show four perfect scores. Nor should those scores be used to avoid these questions.

I aim for Lighthouse 100 because technical work should be measurable. The project comes first because the website has to be useful.