Metrics

What a measurement carries

One page view produces one measurement:

Field	Unit	Meaning
lcp	ms	Largest Contentful Paint
cls	—	Cumulative Layout Shift
ttfb	ms	Time to First Byte
fcp	ms	First Contentful Paint
longTaskCount	count	Tasks over 50 ms on the main thread
longTaskDuration	ms	Their total duration
resourceCount	count	Resources the page fetched
transferSize	bytes	Bytes over the wire

Plus the context every one of them is sliced by: route, release, device type, connection type, country and browser.

INP is a separate event, sharing the page view’s measurementId. It travels in the page view’s request when the visitor interacted early, and in a request of its own when a worse interaction turns up later — an interaction that happens twenty seconds in cannot be waited for without losing the page view entirely.

The interaction event also names the element: its id, or its tag name when it has no id.

Not every measurement has every metric

A metric the browser never reported is absent, not zero. A page the visitor leaves before the largest paint has no LCP; a page nobody touches has no INP; Safari reports a narrower set than Chrome does.

This matters when you read an aggregate: the p75 of LCP is over the page views that had an LCP. The dashboard shows the sample count behind every aggregate for exactly this reason — a p75 is a claim about a population, and you should be able to see how big that population was.

Bands

Good / needs improvement / poor, per metric. These are the field’s own thresholds, not ours:

Metric	Good	Poor
LCP	≤ 2500ms	> 4000ms
INP	≤ 200ms	> 500ms
CLS	≤ 0.1	> 0.25
TTFB	≤ 800ms	> 1800ms

Anything between the two edges is “needs improvement”. These are what the dashboard colours against.

The performance score

A single 0–100 number, so a release can be compared to the one before it without reading four charts. It is computed from the p75 of each metric, never from individual measurements.

Weights:

Metric	Weight
LCP	35%
INP	35%
CLS	20%
TTFB	10%

LCP and INP dominate because they are what a visitor experiences as “slow” — one is how long until the page is there, the other is how long until it answers. TTFB is weighted lightest: it is a component of LCP rather than an independent experience, and weighting it heavily would count the same delay twice.

Each metric is scored on a decay curve rather than a step: a metric at its “excellent” value scores ~100, and at its half-score value scores ~50, falling off faster above that. A continuous curve is what makes an improvement from “poor” to “slightly less poor” visible at all, which a banded score would hide.

The bands and the curve are different things

The table above answers is this number acceptable — external constants nobody here gets to move. The score’s curve answers how good is this number, on a continuum, and is ours to tune against real field data. They will not always agree at the edges, and that is expected.

A metric that was never observed is skipped, and the remaining weights are renormalised. A page with no interactions is not a page with a bad INP.

Every stored score carries the formula version it was computed with, so a change to the weights relabels old numbers rather than silently restating history.

Percentiles do not merge

A daily p75 cannot be derived from twenty-four hourly p75s — the median of medians is not the median. Every percentile you see is computed from the raw measurements in its own window. This is why changing the time range recomputes rather than re-adds, and why two adjacent windows can each look fine while their union does not.