In web performance, what does the Speed Index metric measure about a page load, how does it differ from a milestone metric like First Contentful Paint, and when does it disagree with them?
answer
- a curve, not a timestamp
- measures how the viewport fills
- progressive beats all-at-once
- needs frame capture, so lab only
- placeholders can flatter it
basics
~20 sSpeed Index scores how quickly the visible viewport fills in during load, computed from frame-by-frame visual progress rather than from a single event. Unlike milestone metrics it rewards steady progressive rendering and penalizes a page that stays blank and then appears all at once.
solid answer
~50 sSpeed Index is derived from a video capture of the load: the tool samples frames, estimates what percentage of the final above-the-fold view each frame shows, and produces a single number where lower is better. That makes it fundamentally different from FCP or LCP, which are **milestone** metrics — each marks one instant when one specific thing happened. Speed Index instead integrates the *whole* filling-in process, so a page that reveals content gradually scores better than one that stays blank for the same total duration and then paints everything in one frame, even when both finish at the same moment. Its two big caveats are that it is lab-only — it needs frame capture, so there is no field equivalent — and that it cannot distinguish useful content from a placeholder, so a full-viewport skeleton screen flatters it considerably. It is a supporting metric, not a Core Web Vital.
go deeper
Know that Speed Index scores how fast the visible part of the page fills in during load, that lower is better, and that it comes from a lab tool rather than from real users.
Explain that it integrates visual completeness over the whole load instead of marking one instant, and give the concrete case where two pages finishing at the same time score very differently.
Show judgment about when the metric is worth consulting at all — the milestone metrics look fine but the load feels empty — and be candid that being lab-only and viewport-relative limits what it can prove.
Be ready to argue against making a lab-only, easily-flattered metric part of a release gate, and to explain which measurements should carry that authority instead.
## Milestone metrics versus a progress metric Most loading metrics are *milestones*. First Contentful Paint says: at time T, something first appeared. LCP says: at time T, the largest element appeared. Each is a single timestamp, and each is blind to everything happening between timestamps. Speed Index is a different species. It describes the **shape of the load**, not a point on it. The tool captures frames of the viewport during loading, compares each frame to the final rendered view, and assigns each frame a visual completeness percentage. It then integrates over time — informally, it measures the area *above* the completeness curve. A page that reaches 100% quickly leaves very little area above the curve and scores low; a page that sits at 0% for three seconds and jumps to 100% leaves a large rectangle of unfilled area and scores high. Lower is better, and the value is expressed in milliseconds. ## The consequence: two loads that finish together can score very differently Consider two pages that both reach a fully painted viewport at exactly 3.0 seconds. - Page one renders its header at 0.6s, its body text at 1.2s, its images progressively through to 3.0s. - Page two shows a blank viewport until 2.9s and then paints everything in a single frame. Every milestone metric that fires on the *final* state treats these as equal. Speed Index does not: the first page accumulated visual completeness throughout, the second accumulated none until the end, and the scores separate accordingly. This matches how the loads actually feel — steady progress reassures, a long blank does not — and it is the entire reason the metric exists. ## Where Speed Index and the milestone metrics disagree The interesting cases are the disagreements, because they are diagnostic: - **Good FCP, poor Speed Index.** Something painted early, but the viewport then filled in very slowly — a small header rendered promptly while the bulk of the page trickled in behind it. The milestone hid the slow middle. - **Good Speed Index, poor LCP.** Most of the viewport filled in fast, but the single largest element landed late. Common when a hero image is late while all the surrounding chrome and text are quick. - **Good Speed Index, unhappy users.** The viewport filled with a skeleton or placeholder graphic. Visual completeness is measured against the *final* frame, so a placeholder that is later replaced by real content produces frames that differ from the final view — but a full-bleed splash or an above-the-fold layout that changes little between placeholder and content can still score well while the user waits for anything meaningful. ## The structural limitations Three limits are worth stating explicitly, because they explain why the metric is a supporting one: 1. **It is lab-only.** Computing it requires capturing and comparing frames during load, which no real-user measurement can do on a visitor's device at acceptable cost. There is no field Speed Index, so it can never tell you what real users experienced — only what a synthetic run experienced under chosen conditions. 2. **It is viewport-relative.** It measures the visible area at the emulated screen size. The same page measured at phone and desktop dimensions describes different content, and results are only comparable within a fixed configuration. 3. **It says nothing about interactivity or stability.** A page can fill in beautifully and then ignore every tap, or fill in beautifully by shifting content around as it goes. Current lab guidance treats Speed Index under roughly 3.4s as good and over roughly 5.8s as poor on a simulated mobile run, where it carries a relatively small share of the composite performance score. Treat the exact figures as version-dependent; the durable idea is that it is a secondary check, not a target to optimize directly. ## When to actually reach for it Speed Index earns its place in one situation: when the milestone metrics look acceptable and users still report that the page feels slow to come up. That is the signature of a load whose *shape* is bad — a long empty stretch that no single timestamp captured. In that case the filmstrip behind the metric is more useful than the number, because seeing the actual frames tells you which stretch of the load is empty and roughly what was pending during it.
- Why is there no field equivalent of Speed Index, when LCP and CLS are both collected from real users?Because it requires capturing and comparing frames of the viewport during the load. LCP and CLS are computed from rendering events the browser already tracks internally at negligible cost, so they can be reported from a real session. Continuous frame capture on a visitor's device would cost far more than the measurement is worth, so the metric stays in synthetic runs.
- Two pages both complete their above-the-fold rendering at 3.0s, but one has a much better Speed Index. What is different about them?The shape of the load. The better-scoring page accumulated visual completeness steadily — header, then text, then images — while the other stayed blank and painted everything in one late frame. Milestone metrics tied to the final state score them the same; Speed Index integrates the whole interval, so the long empty stretch is penalized.
- When would you reach for Speed Index rather than FCP or LCP?When the milestone metrics look acceptable but users still say the page feels slow to appear. That is the signature of a load with a bad shape — a long empty stretch between milestones that no single timestamp captured. In practice the filmstrip behind the number is the more useful artifact, since it shows exactly which stretch was empty.
saying these in an interview costs you the question
- Thinks Speed Index is a single paint timestamp
- Believes it can be collected from real users
- Treats it as a Core Web Vital
- Compares Speed Index across different emulated viewport sizes
- Assumes a good Speed Index means useful content appeared