Web performance.

Web performance is a three-dimensional quality measure: how fast a page loads, how fast it responds, and how stable it stays while loading.

Most performance debates get reduced to a single number, and it is usually the wrong one: the score an audit tool prints. Yet performance is not one-dimensional. A page can open very fast and respond late to clicks; it can be fast and responsive and still slide from under you while loading. Google’s Core Web Vitals metrics were defined precisely to separate these three dimensions.

This guide does three things. It cleanly separates what the three metrics measure and their thresholds. It explains the difference between lab measurement and field data — the source of the most expensive misunderstandings. And it argues, with measured examples, that performance is a design constraint, not an optimization added later.

Three metrics, three separate questions

Core Web Vitals consists of three metrics, and none substitutes for another. For a page to count as “good,” all three must clear their thresholds — when one breaks, the other two being perfect does not save the day.

1. LCP — when was the page’s largest visible content painted? The good threshold is 2.5 seconds. It asks: when does the user say “the page is here”?
2. INP — how fast does the page respond visually to clicks, taps and key input? The good threshold is 200 milliseconds. It replaced FID in March 2024.
3. CLS — how much did content shift unexpectedly while the page loaded or was used? The good threshold is 0.1. It is unitless; computed from the size of the shifting area times the distance it moved.

Keeping the three separate is a design decision. LCP measures loading speed, INP measures interaction responsiveness, CLS measures visual stability. A page can be independently good or bad on all three dimensions, and each has its own treatment — the work that fixes LCP usually does not touch INP.

INP replacing FID mattered in particular because FID measured only the DELAY of the FIRST interaction. A page could respond quickly to the first click and freeze on every later one, and FID would still look good. INP looks at interactions across the whole session and measures not the delay but the FULL CYCLE — from input to the next paint. A much harder exam.

Field data versus lab measurement

The most expensive misunderstanding in performance debates lives here. An audit tool opens the page in its own controlled environment and prints a score; that is lab measurement. The data Google uses in ranking is collected from what real users experience on real devices and real networks; that is field data.

The two routinely diverge, and the direction is usually the same: lab good, field bad. The reason is simple — lab measurement assumes a fixed device and a fixed network, while a significant share of real users browse on low-powered phones over variable connections.

The practical consequence: the lab score is a diagnostic tool, not a target. It shows what is slow, and being repeatable it serves to measure a change’s effect. But the verdict “we are good” can only come from field data.

The lab score tells you what is slow; only field data tells you whether you are good.

On this site the field data is pulled into a cache file and shown in the strip — but when there is no data, the field is NOT RENDERED at all. The verification suite measures this separately: when no data arrives, the “measured LCP” label must not appear. An empty field is preferred over fabricated evidence.

Performance is a design constraint

The common working order is: the site is designed, built, then an audit runs and the resulting list is fixed. Done in that order, most fixes stay cosmetic, because the real costs were locked in at the design stage.

Concrete examples: how many font families to use is a design decision, and it directly affects LCP. Whether the hero holds a video or an image is a design decision. How many animation layers to build is a design decision, and it determines INP. These cannot be “optimized” later — only rolled back.

The healthy method is treating performance as a budget item. The budget is set up front, the design happens inside it, and every deployment is measured. On this site the budget is defined as non-negotiable: LCP under 1.8 seconds, CLS under 0.05, INP under 200 milliseconds, and total JavaScript under 150 kilobytes gzipped.

Whether the budget actually holds was measured: the vendor libraries are 55.7 kilobytes after gzip, the site’s own code 28 kilobytes — 83.7 kilobytes in total, well under the ceiling. The main stylesheet is 67.4 kilobytes of source, 12.4 kilobytes after gzip. The first-byte time measured from the live server is 0.302 seconds.

No “done” without measuring

The most insidious trap of performance work is assuming an improvement really is one. A change can look sensible, be a known best practice, and still change nothing on that site — or make it worse.

Exactly such a case happened on this site and is on record. The font loading behavior was suspected as a source of layout shift, and a fix was planned. The measurement did not fix a bug — it prevented a WRONG FIX: the shift came from somewhere else, and the planned change would have broken things.

The second case teaches more. The layout shift measured during page load was near zero; but during scrolling, as a pinned section was released, a shift occurred. Classic CLS measurement looks at the page-load window and never sees this shift — while the user experiences exactly that.

The shared lesson: a metric coming out good means the thing that metric measures is good; it says nothing about what it does not measure. That is why on this site the shift during scrolling is measured by a separate test with session-window logic, bound to a 0.08 threshold.

Where to start

For someone who wants to speed up an existing site, a starting list ordered by impact. The order matters: the items at the top affect more users and cost less.

1. Look at the field data — not the lab score. Which metric is broken for real users?
2. Count the render-blocking resources — how many stylesheets, how many synchronous scripts? Each one delays the paint.
3. Find the largest visible element — which is the LCP element? Usually the hero image or the headline. Everything can be done for that element.
4. Give images dimensions — declaring width and height closes the most common source of CLS in one line.
5. Reduce the font count — every family is an extra request and an extra swap risk.
6. Weigh the JavaScript — how much is truly needed? No cutting before measuring; after measuring, be ruthless.
7. Set a budget and bind it to a test — a one-off improvement is rolled back three deployments later.

The last item is the most skipped and the most expensive. Performance fixes decay silently: a new library lands, a new image arrives without dimensions, a new font family slips in. With the budget bound to a test, the decay shows at deployment time; without it, it is rediscovered at the next audit.

The rest of the cluster covers each of these steps separately — the three metrics’ own pages, the difference between measurement layers, and two blind spots learned by measurement on this site.