Your Lighthouse Score Is Green. Why Does Your Website Still Feel Slow?

A Lighthouse Score Is a Signal, Not the Entire User Experience

Lighthouse is an automated tool for auditing web pages, including performance, accessibility, SEO, and other quality checks. Its Performance score combines several measured metrics into a weighted score. Scores from 90 to 100 are displayed as green and considered good.

That makes the score useful for quickly identifying whether something is obviously wrong.

But consider what a real user actually does. They do not:

1. Open your website.
2. Read your Lighthouse score.
3. Decide the website is fast.

Every delay inside that sequence affects how fast the product feels. And some of those delays are not well represented by a single performance score.

PageSpeed Insights Already Shows Why One Number Is Not Enough

One of the most useful things to understand about PageSpeed Insights is that it separates lab data from field data.

A lab test gives you something repeatable. A user gives you reality.

A real visitor might be:

• using an older phone with limited CPU cycles,
• connected through a weaker mobile network with packet loss,
• returning with cached assets and service workers,
• navigating between routes on a Single Page Application,
• clicking buttons while JavaScript is busy parsing or hydrating,
• opening your application after it has been running for several minutes,
• or following a flow your initial page-load test never exercised.

Neither view makes the other useless. They answer different questions. You need both perspectives when performance matters.

Users Experience a Sequence, Not a Performance Score

When I think about frontend performance now, I find it more useful to break the experience into moments.

Core Web Vitals Help Measure Important Parts of This Experience

Google's current Core Web Vitals focus on three major parts of the user experience:

These are valuable metrics. They move performance measurement much closer to what users actually experience. But there is another critical observation:

Your product may contain important moments that no standard metric completely describes.

Those are product questions, not only browser questions. And sometimes you need to measure them yourself.

The Slow Feeling Often Starts After the Initial Page Load

This is where a website with good performance numbers can still disappoint. The HTML arrives quickly, the primary content paints, Lighthouse finishes its test, and everything looks green.

Then the visitor clicks navigation or toggles a filter. That journey looks like:

The waiting happened after the initial page load. This is especially prevalent in modern React and Next.js applications where most interactions bypass full-page reloads.

The Framework I Use: Measure Four Moments, Not One Score

Instead of asking only "How fast is this page?", I evaluate four product moments:

It is not a replacement for Core Web Vitals—it is a product-level layer on top of them.

I’m Testing This on heyzain.dev

My own portfolio, heyzain.dev, is a prime example because it features an animated entrance. I like the animation. The critical question is whether liking the effect is enough justification for the time it takes.

The key discipline is changing one meaningful variable at a time so that any improvement is directly attributable.

Measure When the Product Becomes Useful

For heyzain.dev, I define a custom state: Hero usable (headline readable, CTA active, navigation live). Here is how I instrument it with the User Timing API:

performance.mark("hero-usable");

performance.measure("time-to-hero-usable", {
  start: 0,
  end: "hero-usable",
});

const measurement = performance.getEntriesByName(
  "time-to-hero-usable"
)[0];

console.log(
  `Hero usable after ${measurement.duration}ms`
);

This is a product-specific measurement. It answers what standardized browser metrics were never designed to answer: When does my specific interface become usable?

Test the Experience, Not Just the Page

A practical audit should go beyond clicking "Analyze". Here is the workflow I follow:

Performance Is Also a Product Decision

Performance is frequently treated as though it belongs purely to backend queries and bundle sizes. Those matter. But many sluggish moments stem from product design choices:

• Should the animation block interaction?
• Should this data load before the rest?
• Should navigation wait for the request to resolve?
• Should the interface acknowledge clicks immediately with optimistic UI?
• Should returning visitors see the same splash introduction again?

These are architectural decisions. That is why an audit must not stop when Lighthouse turns green.