Understanding Lighthouse: Speed Index

You run Lighthouse and it tells you your Speed Index is bad.

But the page looks like it loads fine. You see stuff on screen early. So why is Lighthouse acting like your site is a sloth?

Speed Index is a “how fast does this page visually fill in” metric. Not “when did the first pixel show up” (that’s FCP) and not “when did the main content show up” (That’s LCP). It’s the whole above-the-fold loading experience, averaged over time.

What Lighthouse Is Telling You

Lighthouse defines Speed Index like this:

Speed Index measures how quickly content is visually displayed during page load.

Under the hood, Lighthouse literally records a video of your page loading, compares frames to see how quickly the viewport becomes “visually complete,” and then computes a score from that visual progression. If you want the canonical explanation straight from Google, here’s the Lighthouse Speed Index audit docs.

That’s why it can feel weird. Speed Index is not watching your DOM or your network waterfall. It’s watching what a user would see.

Speed Index Thresholds

Lighthouse reports Speed Index in seconds, and it has different “good” ranges for mobile and desktop.

Why It Matters

Speed Index is trying to capture a thing your users actually care about: does the page feel like it’s showing up progressively, or does it sit blank and then pop in all at once?

It rewards pages that paint meaningful chunks quickly and steadily, and it punishes pages that “download the world first” before rendering much. (Hello, giant JS bundles and render-blocking CSS.)

Also, Speed Index is a lab metric. Lighthouse runs in a simulated environment, so treat it as a clue, not gospel. If you want to know what real humans are seeing, you need real user monitoring, not just hope-driven Lighthouse runs.

And yes, if you’re chasing “the page feels loaded,” you probably also care about Largest Contentful Paint and whether your layout is doing a chaotic little dance, aka Cumulative Layout Shift.

How to Fix It

If Speed Index is slow, the theme is almost always the same: the browser is stuck doing work before it can paint progressively.

Focus on the stuff that helps the page render earlier and more continuously:

• Kill render-blocking CSS. Inline the critical CSS for above-the-fold, and defer the rest so you can paint sooner.
• Stop shipping a dump truck of JavaScript up front. Code split, defer, and trim third-party scripts so the main thread can actually render.
• Prioritize above-the-fold images and text. If your hero is important, make it load like it’s important.
• Make fonts not sabotage first render. If text is invisible while fonts load, your page looks empty even if everything else is ready.
• Fix backend latency first. If your server is slow to respond, every visual metric is going to look bad.

Common Mistakes

• Optimizing only for LCP and ignoring everything else above the fold. Speed Index cares about the whole viewport filling in, not just the biggest element.
• Skeleton screens that never match the final layout. If your “loading UI” is visually busy and then swaps, Speed Index can still look bad because the final page takes forever to settle.
• A/B tests and tag managers injecting late changes. You think the page is “rendered,” but Lighthouse sees the viewport still changing frame after frame.
• Treating Speed Index like a Core Web Vital. It’s useful, but it’s not what Google puts on the scoreboard.

Keep Improving

Lighthouse is great at yelling at you in a controlled lab. Real users are where the money is.

Run Lighthouse to find obvious problems, then validate with real-user data:

Use Real User Monitoring to see what your visitors experience across devices, networks, and real pages, then keep an eye on the Core Web Vitals, especially LCP, CLS, and INP, because those are the metrics Google actually cares about. And if you want the easy button, Request Metrics gives you the real timeline from real sessions so you can stop guessing and start fixing.