A Core Web Vitals field report shows each metric as three bars labelled good, needs improvement and poor. What is being counted in those bars, and where do the band boundaries come from?

## The bars are a distribution A field report for a URL is not one number per metric; it is a summary of many real page visits. Each visit contributes one value per metric — one LCP time, one CLS score, one INP duration if the user interacted. Those values spread out enormously, because real visits arrive on different devices, over different networks, with different cache states. The three bars are the compressed picture of that spread: the fraction of visits that came in fast, middling, and slow. ## Where the boundaries come from Each Core Web Vital defines exactly two boundaries. Below the first, a visit counts as **good**; above the second, it counts as **poor**; between them it is **needs improvement**. These numbers are published by the Chrome team and are identical for every website — they are absolute targets tied to what users perceive, not a curve fitted to your industry or your own past. That is what makes cross-site comparison meaningful, and it is also why some page types find the bar genuinely hard. The bands are per metric, with different units: a loading time in seconds, an interaction latency in milliseconds, and a unitless layout-shift score are not comparable numbers, so each carries its own pair of boundaries. ## The bars are not the verdict This is the part people get wrong. Reading "the good bar is the biggest, so we're good" is a mistake. The rating for the URL comes from the **75th percentile** of the distribution — the value below which three quarters of visits fall — checked against the good boundary. If exactly 74% of visits are in the good band, the 75th-percentile visit is above the good boundary, and the metric does not pass. The bars and the verdict come from the same data, but the verdict is a percentile read, not a majority vote. A compact way to hold it: the good bar must cover at least three quarters of visits for that metric to be good. ## Reading the shape Because the bars are a distribution, their shape carries diagnostic information a single number cannot: - **Mostly good with a thin poor sliver** — the site is fine for the bulk of visits; the tail is likely low-end devices or bad networks, and squeezing it out is a hard grind. - **Two clumps, a fat good bar and a fat poor bar** — a strong hint that two different populations are visiting, for example returning visitors with a warm cache versus first-time visitors, or two page templates sharing a URL pattern. - **A wide needs-improvement bar** — you are close everywhere, and a modest, broad improvement can flip many visits across the line at once. This is usually the cheapest situation to fix. ## Segments change the picture The same URL will show different bars for mobile and desktop, because they are different populations of visits. Looking at a blended picture hides the fact that one segment can be almost entirely good while the other is almost entirely poor. Always ask which form factor a set of bars describes. ## Common trap Do not confuse the band of a *measurement* with the rating of a *page*. Bands are assigned to individual visits; the page's assessment is a separate derivation that requires every metric to land in good at the percentile the assessment uses. "Two green bars and one amber bar" is not a partial pass — it is a fail with a clear next task.