How the tool decides what to fix first

The one decision the tool makes

Every speed tool measures the same things, because they all run Lighthouse or read the Chrome UX Report. What differs is the order. PageSpeed Insights leads with a score and lists audits by estimated savings; GTmetrix leads with a grade. This tool makes one decision on your behalf: of everything Lighthouse found, which single change should you make first? It then shows what that change is plausibly worth, and only afterwards the measurements the decision was made from.

The rule has to survive two things a plain “biggest saving” sort does not. First, a problem with no time unit — layout shift — can never win a race measured in milliseconds, however bad it is. Second, Lighthouse estimates each audit in isolation, so a “save 3.2 s by preloading your image” can appear on a page whose image download phase lasts 0.4 s. The ladder answers the first; the phase cap answers the second.

The ladder

The headline is the first rung that fires. Each rung is tested in this order, and a lower rung is never consulted once a higher one has matched.

1. Layout shift is poor. CLS above 0.25 — Google’s own “poor” line — makes the layout fix the headline, stated in the metric’s own units. The real-visitor value is used when Google has one for the page; otherwise the lab value. No seconds figure is attached, because none exists.
2. Real visitors wait after a tap. A field INP above 500 ms makes the interaction fix the headline. This rung reads field data only: the lab has no reliable INP, and a page can be slow to react in ways a single simulated load never triggers.
3. The server is slow to start. A lab server-response-time above 600 ms makes the server fix the headline. Nothing can render before the first byte, so this delay is added to every other metric, which is why it outranks any single saving further down the page.
4. The biggest fix that survives its phase cap. Every remaining opportunity is sorted by its capped saving (next section), and the largest one wins — provided it is worth at least 100 ms.
5. Nothing meaningful. If no fix clears 100 ms, the result says so plainly rather than leading with a marginal recommendation. A headline fix that recovers a tenth of a second is worse than no headline fix.

The phase cap

Lighthouse partitions Largest Contentful Paint into four phases — server response, discovery, download, render — and reports how long each took. Every audit the tool knows is mapped to the one phase it can actually shorten: an image format fix acts on download, a preload acts on discovery, a render-blocking script acts on render, a redirect acts on the server phase. Some fixes act on none: lazy loading offscreen images and removing unused JavaScript help other things, not LCP.

An audit’s saving is then capped at the size of its phase: min(estimate, phase duration). A 3.2 s estimate against a 0.4 s download phase is worth 0.4 s, and every consumer — the headline, the “est. faster” figure, the revenue model, the opportunity list — reads the capped number. A fix with no phase keeps its raw estimate, because there is no budget to cap it against. The timeline on the result shows exactly this: the phase the headline acts on, the projected saving, and a note when the cap applied.

Field data versus lab data: who decides what

The two sources answer different questions, so the ladder assigns each decision to the one that can answer it, rather than blending them into a weighted number.

• Field data (the 75th percentile of real Chrome visits over 28 days, from the Chrome UX Report) decides the two non-time rungs: whether layout shift is poor and whether interaction delay is poor. It is what your visitors experienced and what Google’s assessment uses. When Google has no data for the page, the tool falls back to origin-level data, and says which it used.
• Lab data (one Lighthouse run on a simulated mid-range phone over throttled 4G) decides everything that needs a cause: which audit, which file, which phase. Field data can tell you LCP is 4.1 s; only a lab run can tell you the hero image is a 2 MB JPEG discovered late. The server rung uses the lab value because it is the only source that isolates the server.

When the page has no field data at all, rungs one and two fall back to the lab values for CLS, and rung two is skipped — a missing INP is treated as unknown, never as good.

The diagnosis label

Beneath the headline, the result names the page’s problem as server, images, JavaScript, layout or mixed. Each opportunity’s capped saving is added to its category’s bucket; a poor CLS adds a fixed weight to the layout bucket so a shift-only page is not labelled “mixed”. A category is named only when it holds at least half the total weight. Below that, the honest word is mixed.

What the saving is worth

The revenue figure is conversions per month, never money. The tool never asks for an order value, so any currency figure would be invented. The model: each second the headline fix recovers is worth 2% of current conversions, capped at 20% however many seconds are saved, applied to the visitor count and conversion rate you enter or the defaults shown. The rate is in line with the published retail studies, and your site could easily sit at half or double it — which is why the assumption sentence renders under every figure, and why non-time headlines (layout shift, interaction delay) show no conversions figure at all.

Why there is no single score

A score compresses six measurements into one number and then tells you nothing about which of them to change. Watch what people do with one: they try to raise it, chasing whichever audit looks easiest, and come away believing performance work is arbitrary. The measurements were never the problem; the presentation was. So the Lighthouse score is still on every result — at the bottom, where a number that cannot be acted on belongs — and no decision on the page reads it.

Impact, not effort

The rule ranks by measured impact only. It does not weight by effort, because effort is the one input a URL does not reveal: the same fix is a checkbox on one stack and a rewrite on another. A guessed effort score would put false precision on the half of the decision the tool knows least about. Instead, every headline links the guide for that fix, which describes the work honestly — so you weigh effort with facts the tool does not have.

The product recommendation is derived, not decided

A result shows at most one product, and it is a pure function of the headline the ladder already chose. Server headline (which already requires a first byte over 600 ms) → a host. Scripts or CSS headline on a site Lighthouse identifies as WordPress → a plugin; the same headline on any other stack → nothing. Cache-lifetime headline on a healthy origin with at least 100 KB of re-downloaded weight → a CDN. Image conversion, compression or resizing headline → an image service. Layout shift, interaction delay, image discovery, or nothing → no product, ever. Product triggers are never evaluated on their own, so two recommendations cannot appear, and every one carries the free way to do the same thing at the same weight.

The AI visibility check uses the same shape

The AI visibility check answers a different question — can the crawlers behind ChatGPT, Claude and Perplexity reach and read this page? — with the same construction: a ladder of blockers, each of which makes everything below it irrelevant. A noindex directive, then a firewall or CDN refusing crawler user-agents, then robots.txt blocking the fetchers that cite pages (training-only crawlers are reported but never counted against you), then content that only exists after JavaScript runs, then a page with no title, heading or description. The first that fails is the headline. It reports whether a page can be read, never whether it is cited, because the second is unmeasurable from outside.

What is deliberately not measured

• Desktop. The lab run is mobile only, because that is what Google ranks on and where the problems are.
• Lab INP. Lighthouse has no reliable interaction metric; the tool shows Total Blocking Time as the lab proxy and never substitutes it for INP in a decision.
• Money. Conversions, never currency, for the reason above.
• Anything from the score. No decision reads it.
• Effort. Described in the guides, not scored.
• Whether AI products cite you. Only whether they can read you.
• History. Each check is a snapshot kept for 30 days under a random link; there are no accounts and no trend lines. Lighthouse is a single run, and it varies; test more than once before trusting a small difference.

Where the inputs come from

Lab data is one PageSpeed Insights API v5 run, mobile strategy, performance plus accessibility and best-practices categories (the latter two feed the mobile usability section). Field data is the Chrome UX Report API, queried separately, URL level first and origin level as a fallback. Opportunity savings are read from each audit’s overallSavingsMs, or for Lighthouse 13 insight audits from the largest entry in metricSavings — the largest, not the sum, so the claim stays “worth this much to one metric”. The LCP phases are Lighthouse’s own partition, never one of ours. Checks are limited to 20 an hour per person so one script cannot spend the API quota for everyone.

If a result disagrees with PageSpeed Insights, believe PageSpeed Insights and tell us: the measurements are theirs, and only the ordering is ours.

Common questions