Core Web Vitals in plain language, with thresholds

Core Web Vitals is a set of three measurements Google uses to describe whether a page feels acceptable to use. They are usually introduced as acronyms, which is why they are widely quoted and rarely understood. Underneath, each one corresponds to a specific irritation a real visitor experiences, and the acronyms are easier to hold onto once the irritation is named first.

The first is waiting: you tap a link and stare at a mostly empty screen wondering whether anything is coming. The second is unresponsiveness: the page looks ready, you tap a button, and nothing happens for long enough that you tap again. The third is movement: you go to tap something and the layout shifts under your thumb, so you tap an advert instead of the thing you wanted. Everyone reading this has experienced all three, usually on a phone, usually on a shaky connection. That is the entire subject. The metrics exist to put a number on those three feelings so they can be tracked rather than argued about.

Largest Contentful Paint measures the time from the start of loading until the largest piece of content in the visible area has rendered — usually a hero image, a video poster or a substantial block of text. It is a proxy for the moment the visitor stops looking at an empty screen and starts looking at your page. It deliberately ignores small early elements, because a logo appearing does not make anyone feel the page has arrived.

The threshold for a good score is 2.5 seconds or less. Between 2.5 and 4 seconds needs improvement, and above 4 seconds is poor. The causes are usually unglamorous and fixable: an enormous unoptimised hero image, a slow server response before any rendering can begin, render-blocking resources in the head, or a font that delays text appearing. For an Indian audience the connection matters more than a developer's own testing suggests, because the phone on a patchy mobile connection in the market is the real visitor, not the laptop on office fibre where the page loads instantly and nobody thinks about it again.

Interaction to Next Paint measures how long the page takes to visibly respond after a visitor interacts with it — a tap, a click, a key press. It replaced First Input Delay, which measured only the delay before processing started on the very first interaction. INP is a harder and more honest measurement because it considers interactions throughout the visit and it measures all the way through to the visible response, which is the part the visitor actually perceives.

Good is 200 milliseconds or less. Up to 500 milliseconds needs improvement, and beyond that is poor. The usual cause is JavaScript occupying the main thread: a large bundle still being parsed, a heavy handler doing work synchronously, third-party scripts for analytics, chat widgets and advertising all competing for the same thread. This is the metric most likely to be poor on a page that scores well on the other two, because a page can paint quickly and still be busy behind the scenes — and it is the metric a business is most likely to have made worse by adding one more well-intentioned widget.

Cumulative Layout Shift measures how much visible content moves around unexpectedly during the life of the page. It is not a time measurement, which is why the numbers look unfamiliar: it is a unitless score combining how much of the viewport was affected by a shift with how far things moved. Good is 0.1 or less, up to 0.25 needs improvement, and above that is poor.

The causes are almost always the same short list. Images and videos without width and height attributes, so the browser cannot reserve space and the text jumps once the file arrives. Adverts and embeds injected into a container with no reserved height. Web fonts that swap and reflow the text around them. A banner or notification bar inserted at the top of the document after the rest has rendered, pushing everything down. What makes this metric worth caring about beyond the score is that it maps directly to a real cost: a layout shift at the moment of a tap makes a customer press the wrong thing, and on a checkout page that is a lost order rather than a poor grade.

Run a page through a testing tool and you often get two sets of numbers that do not match, which reasonably makes people wonder which is the real one. They are measuring different things. Lab data is a single simulated load in a controlled environment with a defined device and connection speed — reproducible, immediately available, and useful for diagnosis because you can change something and re-run it.

Field data is aggregated from actual visits by real people on real devices and connections, reported at the 75th percentile, which means a quarter of visits were worse than the figure shown. That percentile choice is deliberate: it describes the experience of the tail rather than flattering the average. Field data is what Google uses when Core Web Vitals inform how a page is assessed, and it lags, because it is a rolling window of collected visits rather than a live reading. The practical consequence is that both have a job. Use lab data to find and fix causes, since it responds immediately. Judge whether you have actually improved anything by field data, and expect to wait weeks after a fix before the field numbers move — a fix that shows instantly in lab data and not yet in the field is normal, not a failed fix.

Some of this you can inspect directly from your own page with no account anywhere. Whether images carry width and height attributes, whether the hero image is a sensible size and a modern format, how many third-party scripts the page loads, whether fonts are preloaded, whether anything blocks rendering in the head — all of that is readable from the page's own markup, and all of it is causal rather than symptomatic. Fixing those addresses the common causes of poor scores directly.

The measurements themselves are a different matter. Field data for your pages is free but not automatic: it needs an API key that somebody with the right access has to create and configure, and Search Console shows the same underlying data grouped by URL for a property whose owner has verified it. Neither costs money, and neither arrives just because a checker looked at your HTML. So the honest division is that the causes are inspectable today for nothing, the scores need a credential somebody has to set up, and no page's markup will ever tell you what real visitors experienced. Start with the causes, because they are actionable immediately and they are what the scores are reacting to.