Core Web Vitals and the Critical Rendering Path

1. First screen: one fast run is not a field distribution

A content page opens quickly on a developer laptop. The hero appears without an obvious pause, the search button responds, and nothing visibly jumps during the short test. It is tempting to conclude that performance is solved. That conclusion is too large for the evidence. A local run can expose useful causes, but Core Web Vitals are designed around user experience at scale. The current set is Largest Contentful Paint (LCP) for loading, Interaction to Next Paint (INP) for responsiveness, and Cumulative Layout Shift (CLS) for visual stability. Current good-experience guidance uses LCP at or below 2.5 seconds, INP at or below 200 milliseconds, and CLS at or below 0.1, evaluated at the 75th percentile and segmented for mobile and desktop. [S-WEBDEV-VITALS]

The engineering problem in this lesson is deliberately bounded. You will inspect a deterministic page fixture with three separate failure modes: a delayed hero path, a long interaction task, and missing reserved dimensions. You will connect each symptom to a plausible rendering, interaction, or layout cause, repair the cause without assuming the other metrics improved, and record what your lab evidence does not establish about real users.

Your evidence artifact is Core Web Vitals Diagnosis & Rendering-Path Record v1. It must separate observation from inference. A passing local audit proves that the fixture and your reasoning satisfy the lesson contract. It does not prove a production page passes CrUX, and it does not turn one synthetic trace into a 75th-percentile field result.

2. Route orientation: reduce scaffolding, not the evidence bar

Foundation route: use the supplied matrix and work one metric at a time. For each row, identify the observed symptom, the trace fields that changed, the cause hypothesis, the smallest repair, and the residual evidence you still need. Keep the current thresholds visible so you do not replace measurement with intuition.

Repair route: if you already know the metric names, start from one broken mutation. Predict the first evidence row that should fail, run the audit, explain why the trace changed, repair only that cause, and rerun. Do not optimize the entire page before you have isolated a failing boundary.

Experienced route: skip basic definitions and review the fixture as a performance change request. Ask whether the diagnosis distinguishes metric symptom from cause, whether a repair is supported by trace evidence, and whether the conclusion stays inside the lab-versus-field boundary. Then complete the transfer case without copying the first solution.

All routes preserve five critical dimensions: current_metrics, thresholds, lab_field_boundary, critical_path, and measure_before_claim. Experience can compress exposition, but it cannot remove mutation evidence, changed-context transfer, or the residual-limitation statement.

3. Mental model: metric symptom is not the same thing as root cause

Use a simple chain:

navigation → document response → render-critical resources → content paint → interaction task → next paint / layout stability → lab evidence ↔ field evidence boundary

LCP tells you when the largest eligible content element in the viewport was rendered relative to navigation. The metric does not tell you, by itself, why that rendering happened late. The cause may be server or document delay, late resource discovery, slow resource transfer, render-blocking work, or element render delay. The lesson fixture exposes several of those stages so that you can trace the delay rather than say “LCP is slow because the image is large.” [S-WEBDEV-LCP]

INP is a responsiveness metric. It observes interaction latency across click, tap, and keyboard interactions and reports a value representing the slow end of the page’s interaction experience, with outlier handling for pages that receive many interactions. A long main-thread task can delay processing or the next paint, but the correct diagnosis comes from the interaction evidence, not from seeing JavaScript in the stack and assuming it is the cause. [S-WEBDEV-INP]

CLS measures visual instability. Missing dimensions for images or embeds are common causes because content can be laid out without space and then displaced when the resource arrives. But not every visual change counts the same way, and a local page-load trace can miss shifts that happen later in a long-lived session. [S-WEBDEV-CLS]

The arrows matter: a metric is an observation surface. The rendering path is where you investigate causes. Your evidence record keeps those two layers separate.

4. Foundation layer: current metrics, thresholds, and percentile meaning

The current Core Web Vitals set is LCP, INP, and CLS. FID is not the current responsiveness Core Web Vital. The metric set can evolve, so this statement is freshness-bound rather than timeless. [S-WEBDEV-VITALS]

For the current guidance, “good” is:

These thresholds are evaluated at the 75th percentile of page loads, with mobile and desktop considered separately. The percentile condition changes how you reason. If one local run produces a 1.4-second LCP model value, you have evidence about that run or fixture state, not evidence that 75% of production visits are at or below 2.5 seconds. [S-WEBDEV-VITALS]

The fixture therefore has two evidence types. deterministic_fixture_trace is generated from known local inputs so that a mutation has a repeatable observable consequence. supplied_field_sample is a static sample that represents an already-collected distribution for comparison practice. Neither is falsely labelled as live CrUX. The audit rejects any record that says lab_equals_field=true.

This boundary is central to correctness. Lab measurement is excellent for diagnosis, reproduction, and regression prevention. Field data tells you how real visits are distributed across devices, networks, page states, and user behaviors. One informs the other, but they are not interchangeable.

5. Deep explanation: connect each metric to an evidence path

LCP: decompose the late paint

When LCP is late, first identify the LCP candidate and then trace the path that had to complete before it could render. In the fixture, the hero row records document response time, resource discovery delay, resource duration, and element render delay. The model LCP is the combination of those controlled stages. If the hero-discovery mutation adds 1,400 ms before the hero request can start, the evidence should show the discovery stage expanding. The correct repair targets discovery or the render-critical dependency that caused it. Merely compressing the image would not address the observed bottleneck.

The current LCP guidance also explains why field LCP can differ from a narrow lab run: navigation setup, redirects, connection work, and Time to First Byte are part of what users experience. [S-WEBDEV-LCP] Therefore a record that says “image decoded in 300 ms, so LCP is fixed” is incomplete unless the rest of the path was measured.

INP: follow the interaction through the next paint

The fixture breaks interaction latency into input delay, processing duration, and presentation delay. The long-task mutation raises processing duration and therefore pushes the interaction model above the current 200 ms good threshold. The diagnosis is not “JavaScript is bad.” It is “this observed long main-thread task extends the processing segment for this interaction.” The repair can then split or reduce the blocking work and rerun the interaction trace.

INP is specifically meant to assess responsiveness across user interactions over the page lifecycle, not only the first input. [S-WEBDEV-INP] This is why substituting FID in the plan is a contract failure.

CLS: reserve layout before the resource arrives

The layout fixture includes an image slot with explicit width and height. Removing those dimensions creates a deterministic layout-shift model row above 0.1. The repair reserves the geometry before the image arrives. This does not claim every production CLS problem is caused by images: ads, embeds, dynamically injected content, fonts, and other late changes can also affect layout stability. [S-WEBDEV-CLS]

Across all three metrics, the workflow stays the same: observe the symptom, inspect the trace, form the smallest cause hypothesis, change the mechanism, rerun, and state what remains unmeasured.

6. Worked example: diagnose three failures without merging them

Start from the baseline fixture. Its deterministic trace is intentionally “good” for all three model thresholds:

{
  "lcp_model_ms": 1430,
  "inp_model_ms": 120,
  "cls_model_score": 0.04,
  "measurement_kind": "deterministic_fixture_trace"
}

That baseline is not a field pass. It only gives you a stable starting point.

Hero-delay mutation. The mutation increases resource-discovery delay. The LCP model rises above 2.5 seconds while INP and CLS remain unchanged. Record: observed trace stage changed; inferred cause is delayed hero discovery in this fixture; repair restores early discovery; not observed is production p75 LCP.

Long-task mutation. A controlled 260 ms processing segment pushes the interaction model above the 200 ms good threshold. LCP and CLS remain at their baseline values. Record the interaction segment that changed and avoid claiming “the whole page is slow.” Repair the long task and rerun.

Missing-dimensions mutation. The image slot no longer reserves geometry and the deterministic shift model exceeds 0.1. LCP and INP do not automatically regress. Repair the geometry and rerun.

Finally compare the baseline lab model with the supplied field sample. The sample has p75_lcp_ms=3100, p75_inp_ms=240, and p75_cls=0.07. The correct conclusion is not that the lab is wrong. The conclusion is that a controlled local reproduction and a field distribution answer different questions. You now have a reason to investigate which production contexts are absent from the local fixture.

7. Failure modes: shortcuts the audit must reject

Failure A — FID as the current metric. A plan lists LCP, FID, and CLS. The audit rejects the metric set because current Core Web Vitals use INP for responsiveness. [S-WEBDEV-VITALS]

Failure B — altered thresholds. A local dashboard labels INP 240 ms as “good” by silently setting the threshold to 250 ms. The lesson contract rejects the threshold table. Local teams may define additional budgets, but they must not relabel the current official threshold.

Failure C — lab equals field. A record says “Lighthouse/local trace passed, therefore real-user Core Web Vitals pass.” The audit rejects the inference. Lab evidence can explain and prevent known regressions; field evidence is required for a field-distribution claim.

Failure D — one fix repairs everything. Compressing the hero is reported as a fix for LCP, INP, and CLS without rerunning interaction and layout evidence. The repair is unsupported for the metrics that were not measured.

Failure E — architecture guarantee. A static-first page is declared fast because of the architecture label. The audit rejects the claim. Static generation can change some delivery characteristics, but it does not prove LCP, INP, or CLS outcomes by itself.

A mutation is useful only when it can change your conclusion. If your evidence record still passes after the fixture uses the wrong metric set or claims lab equals field, the validator is too weak.

8. Experienced bridge: performance review as causal change control

On a mature site, performance regressions often cross team boundaries. A design change can alter the LCP candidate. A CMS template can delay resource discovery. A third-party widget can add long tasks. A font policy can affect text rendering and layout. A personalization layer can insert content after the initial layout. The valuable review object is therefore not “the Lighthouse score”; it is a causal performance diff.

For each release, capture the affected route, candidate elements, trace environment, relevant metric symptom, changed resource or task, and the field signal you will watch after deployment. The lesson artifact is a small version of that review record. It teaches you to keep implementation evidence, mutation evidence, repair evidence, and residual uncertainty in the same place.

There is one current SPA nuance worth keeping freshness-bound. As of the August 2026 web.dev update, Chrome 151 introduced APIs that allow Core Web Vitals measurement across SPA soft navigations. At that time, the guidance said those APIs were beginning to appear in measurement libraries and tooling, while CrUX integration timing was not yet published and other browser engines did not yet support the new APIs. [S-WEBDEV-SPA-2026] Do not generalize that Chrome-specific state into a universal cross-browser field claim.

9. Alternatives and tradeoffs: optimize the measured bottleneck

Preloading or prioritizing a hero can help when discovery or priority is the observed LCP bottleneck. It can waste bandwidth when the resource is not actually critical. Inlining critical CSS can remove a request but can also increase document bytes and reduce cache reuse. Splitting a long interaction task can improve responsiveness, but careless scheduling can introduce complexity or move work into another user-critical window. Reserving layout space improves stability, but the reserved geometry still needs to match the intended responsive design.

The decision rule is not “use the fastest technique.” It is “choose the smallest mechanism that addresses the observed bottleneck and preserves the page contract.” Then measure again.

Do not optimize a metric label in isolation. An LCP repair can shift work onto the main thread; an interaction optimization can defer work that later affects layout; a layout stabilization change can alter loading priority. The lesson does not assume such tradeoffs happen every time. It requires you to rerun the relevant evidence instead of inferring that one metric moved because another one did.

The same discipline applies to tools. Lighthouse, DevTools, web-vitals, RUM systems, and CrUX expose different kinds of evidence. The correct tool is the one that answers the claim you are making. A diagnostic lab trace and a p75 field distribution are complementary, not substitutes.

10. Guided and independent practice

Run node --test test/public-contract.test.mjs inside the learner fixture. Then run node src/audit-vitals.mjs to regenerate the deterministic audit output.

Work in this order:

1. Read performance-plan.json and confirm the current metric set and thresholds.
2. Inspect traces/baseline.json. Mark every value as observed fixture evidence, not production field evidence.
3. Read the hero-delay trace. Predict which stage should explain the LCP regression before looking at the diagnosis.
4. Read the long-task trace. Identify whether input delay, processing, or presentation changed.
5. Read the no-dimensions trace and connect the shift to the missing reserved geometry.
6. Compare the baseline with field-sample.json. Explain why a good lab state can coexist with a weaker field distribution.
7. Complete Core Web Vitals Diagnosis & Rendering-Path Record v1 with observation, inference, repair, and residual limitation separated.
8. Run each mutation probe only after writing a prediction.
9. Repair and rerun until all public checks pass.
10. Complete the changed-context transfer independently.

The transfer page uses a web font, a third-party widget, and a client-rendered search panel. Do not start by “optimizing all three.” Choose the measurements that can distinguish likely LCP, INP, and CLS effects. State what you would inspect in a lab and what you would need from field data before claiming a real-user improvement.

11. Verification and the evidence record

The record requires six evidence dimensions: implementation artifact, observable generated-output behavior, failure mutation result, repair result, changed-context transfer, and residual limitation.

A strong LCP row says: “Observed: hero discovery delay increased from 30 ms to 1430 ms and the fixture LCP model rose from 1430 ms to 2830 ms. Inference: this mutation makes late hero discovery the dominant fixture cause. Repair: restore early discovery. Not observed: production p75 LCP or a live browser trace.”

A weak row says: “LCP fixed by preload.” It names a technique but does not show the bottleneck, the before/after evidence, or the remaining uncertainty.

The same structure applies to INP and CLS. For INP, name the interaction and the latency segment that changed. For CLS, name the element or layout event and the shift evidence. Never write a cross-metric success claim unless you actually reran the corresponding evidence.

The lab uses deterministic trace records so that acceptance is reproducible without an external account. The values are teaching-fixture data. They are not secretly labelled as DevTools, Lighthouse, CrUX, or RUM measurements. If you choose to inspect the included HTML manually in a browser, that is additional exploratory evidence, not a requirement for the deterministic Macro-A acceptance gate.

Residual limitation is mandatory: passing the lab does not establish production p75 Core Web Vitals, device/network distributions, long-lived session behavior, CrUX eligibility, or cross-browser soft-navigation coverage.

12. Assessment and transfer

Retrieval: name the current Core Web Vitals and their good thresholds, then explain what the 75th percentile changes about the claim.

Application: complete the baseline diagnosis and Core Web Vitals Diagnosis & Rendering-Path Record v1 without merging the three metric causes.

Diagnosis: predict and explain one deliberate regression. The answer must identify an observed trace change, a cause hypothesis, and the repair boundary.

Decision: defend one optimization against a plausible alternative. The defense must use evidence from the affected path rather than a generic performance slogan.

Transfer: for the font/widget/client-search page, choose measurement points before optimization. Explain which symptom could plausibly affect LCP, INP, or CLS and what field evidence would be needed after the local repair.

A response fails if it treats FID as current, changes the official thresholds without labelling them as a separate local budget, claims a lab pass proves a field pass, or declares a metric repaired without rerunning its evidence.

13. References and freshness boundary

This lesson keeps external scope exactly to the five official sources frozen in the Bible. On 2026-09-13, web.dev still lists LCP, INP, and CLS as the current Core Web Vitals, with good thresholds of 2.5 seconds, 200 milliseconds, and 0.1 at the 75th percentile. [S-WEBDEV-VITALS] The current LCP, INP, and CLS pages remain consistent with those metric semantics and threshold boundaries. [S-WEBDEV-LCP] [S-WEBDEV-INP] [S-WEBDEV-CLS]

The August 2026 SPA guidance remains a volatile, narrow claim: Chrome 151 introduced soft-navigation measurement APIs, but at that publication state CrUX integration timing was not yet published and other browser engines did not yet support those APIs. [S-WEBDEV-SPA-2026]

Review these freshness-bound claims no later than 2026-12-31, or earlier if official guidance changes. The Bible remains immutable; a future change must use the governed freshness/change-request path rather than silently rewriting the frozen authority.