Core Web Vitals: reproducible protocol, evidence and counter-tests

LCP, INP and CLS are three different distributions, not one speed score. A field assessment describes the 75th percentile of eligible experiences. A lab run describes a device, network, page state and scenario. When CrUX, RUM, Lighthouse and a trace disagree, do not average them. Name the population, isolate the metric, locate the responsible element or interaction, correct one cause and counter-test under comparable conditions.

This guide publishes the complete decision contract, an open bilingual dataset and a browser instrument that records this session locally. It deliberately refuses three shortcuts: TBT is not renamed INP; missing CrUX data is not treated as a pass; a faster laboratory run is not presented as ranking or revenue causality.

The stable Core Web Vitals are Largest Contentful Paint, Interaction to Next Paint and Cumulative Layout Shift. Google’s public thresholds classify a page or origin as “good” when at least 75% of eligible experiences meet the threshold. That sentence carries the essential information: the value is a distribution, not the best run, not the average and not the desktop score displayed in a report.

A disagreement is not a data-quality failure by default. Lighthouse may expose a cold-load problem that is diluted among returning field users. CrUX may reveal slow interactions that a load-only test never exercises. RUM may expose a checkout template hidden by an origin-wide aggregate. The method therefore preserves every layer and its timestamp instead of electing a single “true score”.

If CrUX has insufficient data, record “not measured”. Low traffic, a new URL or insufficient eligible Chrome visits can explain the absence. None proves a good experience. This distinction is especially important for a young B2B site: a green lab test is useful operational evidence, but it cannot stand in for a field population that does not exist yet.

The gates are ordered. They prevent the most frequent category errors before optimisation begins: changing an image because “performance is red”, replacing a library because TBT is high, or announcing a Core Web Vitals pass after one Lighthouse run. A release may continue with an open field status; it may not silently turn that unknown into success.

LCP is not synonymous with image weight. Start with the element reported by the trace. It may be a hero image, a poster, a text block or a background. Then break its timestamp into four parts: time to first byte, delay before the resource starts, resource-load duration and delay between resource completion and rendering.

High TTFB points towards origin work, cache misses, redirects or network distance. High resource-load delay points towards late discovery, CSS backgrounds, client rendering or priority competition. High load duration points towards bytes, compression, connection and origin delivery. High render delay points towards hidden content, fonts, main-thread work or a resource that loaded before the element could be painted.

This decomposition avoids contradictory fixes. Preloading cannot repair a slow origin. Re-encoding a 20 KB image cannot repair a one-second render delay. A faster image may even leave LCP unchanged when the text baseline remains the largest candidate.

INP begins with a real interaction. Its latency contains the wait before handlers run, the time spent executing them and the delay until the next frame is presented. A slow click can therefore come from earlier work blocking the main thread, expensive application logic, synchronous layout, a large render or several causes at once.

Exercise the critical journeys: open navigation, expand the FAQ, submit invalid and valid form states, play media, use search and trigger the main CTA. Record the interaction target and page state. Long Animation Frames can connect the slow interval to long frames and scripts when the browser supports the API. Unsupported attribution remains unsupported; it is not converted into a pass.

The local lab below reports the worst interaction observed in the session. It does not claim the official INP of a field population. The official metric applies interaction selection and aggregation rules across real visits; the local value is a diagnostic candidate for a controlled replay.

CLS accumulates unexpected layout shifts in session windows. The useful evidence is not only the total: it includes the moment, value, shifted nodes and preceding action. Shifts caused within the recent-input exclusion window are treated differently, which is why clicking an accordion and seeing content move does not automatically create a CLS defect.

Frequent causes include media without reserved geometry, ads or embeds injected above content, fonts that alter metrics, notices inserted after first paint and animations that change layout properties. Reserve the final space, keep responsive aspect ratios truthful, choose compatible font fallbacks and animate transforms rather than layout where appropriate.

Test the entire lifecycle. A page may be stable during loading and shift when a consent message, audio player, validation summary or lazy component appears. A screenshot cannot prove stability; the sequence and sources can.

Arm the next navigation. The page reloads from the top and starts observing automatically, before you open the table of contents, expand FAQ items, activate an article action or play the audio when available. Freeze the proof only after the scenario is complete. The export records the capture mode, environment, supported APIs, candidates, timing parts, element geometry, visibility changes and explicit limitations. It excludes form values and the proof never leaves the browser.

The first visit remains opt-in and starts no observer. Only the explicit arming action triggers one page reload; the versioned module then reads buffered navigation entries and begins the session without a second user input. The URL marker is immediately removed without another request. This prevents a late click or restored scroll position from being mistaken for a clean navigation measurement.

The run used Lighthouse 9.6.8 with a mobile Moto G (4) emulation and Headless Chrome 155. It transferred 158,995 bytes over 16 requests. These values are published because they are reproducible context, not because they prove current field quality. The run predates this rewritten edition, and a future counter-test must keep that chronology visible.

The SEO subscore was 93 because that Lighthouse version did not recognise Edikka’s Content-signal directive. The performance observation and the SEO parser warning are separate findings; neither should be hidden inside the overall score. No PageSpeed API field result is claimed because a valid CrUX response was not obtained during this review.

The four v1.1 files were useful evidence, not valid before/after pairs. Their filenames claimed “load-only” or “interactive”, but the proof itself encoded neither the scenario nor its completion. Each same-browser pair also mixed one network transfer with one zero-transfer navigation. One supposed load-only Safari export even contained a pointer interaction after navigation.

This failure produced version 1.2: scenario, completion, page-input count and navigation transfer state are now machine-verifiable comparison gates. Only derived counts are published here; raw user-agent strings are not republished.

CI should protect deterministic properties: asset budgets, missing image dimensions, unexpected third-party requests, duplicate preloads, long tasks in a named journey and lab deltas beyond an agreed tolerance. Store the trace and environment when a gate fails. Do not make an origin-wide CrUX percentile a per-commit gate: the 28-day field window cannot identify one commit in real time.

A useful release record therefore has two clocks. The fast loop runs trace and laboratory counter-tests before deployment. The slow loop watches RUM or CrUX after deployment and waits for an adequate population and window. If traffic is low, report raw eligible counts and retain “insufficient data” rather than optimising the threshold until it turns green.

Use the web-image optimisation protocol for codecs, responsive sources, perceptual quality and delivery. Use the technical SEO audit protocol for crawling, canonicals, rendering and broader technical controls. Use the business-impact analysis to frame commercial risk without turning a lab delta into attributed revenue.

This division prevents cannibalisation and keeps every claim with the evidence it needs. Core Web Vitals are the measurement and diagnostic interface between those territories, not a synonym for all front-end quality.