A Lighthouse score of 100 does not mean your site is fast. How to measure performance in 2026

A Lighthouse score of 100 can make website performance look like a finished job. The page is green, the report is clean and there appears to be nothing left to measure.

That score only tells part of the story.

Lighthouse answers: how did this page perform in one controlled test? Core Web Vitals answer a different question: what did real people experience on their own phones, computers and connections?

Both measurements matter, but they have different jobs.

What a Lighthouse score of 100 actually means

Lighthouse loads a page in a laboratory environment. It uses a defined device profile, network conditions and an empty cache, then calculates a score from several performance metrics.

According to the Chrome documentation, the Performance score is a weighted average. Metrics including Largest Contentful Paint, Total Blocking Time and Cumulative Layout Shift have the greatest influence.

This makes Lighthouse useful while a site is being built:

• the test can be repeated after every change,
• it identifies heavy scripts and images,
• it highlights render-blocking resources,
• it allows two versions of the same page to be compared.

It is not a record of every visit. A single run does not know which phone a visitor owns, how reliable their connection is or what they do after the initial load. The score itself may fluctuate because of computer load, network routing or third-party scripts.

A score of 100 therefore means: this version of the page performed very well in this test. It does not mean: every visitor will always experience the same speed.

Laboratory data and real-user data

Google separates performance measurements into two groups.

Lab data comes from Lighthouse and similar tools. The conditions are controlled, which makes a problem easier to reproduce and a fix easier to verify.

Field data comes from real visits. Google collects it through the Chrome User Experience Report, or CrUX. It includes different devices, networks, locations, cache states and user behaviour.

Google’s explanation of lab and field data is clear: laboratory testing is valuable for diagnosis, but it does not replace field data. CrUX covers a rolling 28-day period and describes a distribution of experiences rather than one ideal visit.

A small or recently launched site may not yet have CrUX data for every URL. CrUX requires sufficient traffic, and Google does not publish the exact threshold. PageSpeed Insights may then show data for the whole origin or only a laboratory result.

Three numbers that matter more than the headline score

The current Core Web Vitals consist of three metrics. A page passes when it reaches the good threshold for at least 75% of visits:

• LCP of 2.5 seconds or less — when the largest visible element, often a heading or image, appears,
• INP of 200 milliseconds or less — how quickly the page responds to a click, tap or keyboard input,
• CLS of 0.1 or less — whether the layout remains stable instead of shifting unexpectedly.

These thresholds come from the official Web Vitals guidance.

Lighthouse can help investigate LCP and CLS. INP is more difficult because it requires a real interaction. A laboratory test uses Total Blocking Time as a diagnostic proxy, but it cannot predict when a visitor will interact or which control they will use.

This is one reason a page can score 100 and still hesitate when someone opens a menu, uses search or completes a complex form.

Why a fast test and a slow experience can both be true

The tool is not necessarily wrong. The test and the visitor are simply seeing different conditions.

A slower phone executes JavaScript less quickly. Work that is invisible on a new laptop may delay an interaction on a device that is several years old.

Third-party services change the page after load. Analytics, maps, chat widgets, advertising, video and booking systems can request more resources after the initial test has settled.

Cache state changes the result. A first visit may need to download fonts and images, while a returning visitor already has those files available.

Interactions reveal problems later. Expanding navigation, filtering a list or validating a form may look fine during load but respond slowly after a click.

Different screens can have different largest elements. Text may be the LCP element on a phone, while a large image takes its place on a wide display. One viewport cannot represent every layout.

How I measure website performance

I do not make decisions from one green circle. I use a simple order:

1. PageSpeed Insights and Search Console show whether real-user data is available.
2. Lighthouse helps reproduce a problem and identify its technical cause.
3. Testing on a phone and a slower connection checks whether the site remains comfortable away from fast Wi-Fi.
4. Post-launch measurement confirms whether the improvement remains visible across the next 28 days.
5. Real User Monitoring on higher-traffic sites identifies the exact pages, devices and interactions that need work.

I look at the section labelled field data first. I then use the laboratory report to find out why a metric is poor.

Technology helps, but it is not an automatic guarantee

Astro limits the JavaScript sent to the browser and works well for statically generated websites. This removes several common causes of poor INP and slow loading.

It is still possible to build a slow Astro site: use oversized photographs, several font families, a map, a chat widget, three analytics systems and an autoplaying video. Choosing a framework does not replace control over what reaches the browser.

In practice, I pay particular attention to:

• image dimensions and formats,
• the number of web fonts,
• reserved space for images and embedded content,
• client-side JavaScript,
• when third-party services start,
• behaviour on a real phone.

What score is good enough?

Spending hours moving a score from 99 to 100 just to complete the number is rarely useful. Lighthouse classifies 90–100 as good, and its scoring curve means that the final point can require a disproportionate amount of work.

A better target is:

• Core Web Vitals remain green for real visitors,
• the main content appears quickly,
• controls and forms respond without a noticeable pause,
• the layout stays stable while someone reads,
• new features do not undo earlier performance work.

A Lighthouse score of 100 is still a positive signal. It is simply not the end of measurement. A fast website is not one that achieved a perfect score once; it is one that remains fast for the people who actually use it.