Core Web Vitals for Client-Side Apps

Core Web Vitals were designed around documents that arrive mostly complete from the server. A client-side rendered application inverts that assumption: the server sends a near-empty shell, and JavaScript paints the meaningful content only after it downloads, parses, and hydrates. Every one of the three metrics — Largest Contentful Paint (LCP), Cumulative Layout Shift (CLS), and Interaction to Next Paint (INP) — is measured against that deferred timeline, which is why a SPA that feels fast to its author routinely fails the assessment on real devices. This guide explains how each metric behaves differently under client rendering, why those differences also threaten indexing, and how to diagnose each one. It sits under crawling and rendering fundamentals.

Problem Statement

The gap between a document site and a SPA is not a matter of degree; it is a matter of when the content exists. On a server-rendered page, the largest element is usually present in the first response and painted during the initial layout. In a client-rendered app, that same element does not exist in the DOM until a component tree resolves, data fetches settle, and the framework commits its first render. The browser cannot measure a paint that has not happened, so the clock keeps running.

That single fact cascades into all three metrics:

  • LCP waits for JavaScript to construct and paint the hero, so the largest paint is bound to bundle download, execution, and often a data round-trip.
  • CLS accrues when that late content injects itself into a layout the browser had already settled, pushing existing elements down.
  • INP suffers because the main thread is saturated with parsing and hydration exactly when an eager user first taps.

There is a crawling dimension too. Googlebot renders JavaScript in a deferred second wave, and that render has an execution budget. A page slow enough to score poorly on Core Web Vitals is also a page more likely to have its render abandoned before the DOM is complete — so the metric problem and the indexing problem share a root cause, as covered in understanding Googlebot’s rendering pipeline.

Where each Core Web Vital is decided on a client-rendered timeline A left-to-right SPA load timeline — shell, bundle execution, hydration, then interactive — with LCP, CLS, and INP each anchored to the deferred phase that determines it. SPA load timeline (JavaScript decides when content exists) Empty shell div id="root" Bundle executes parse + build tree Hydration attach handlers Interactive content painted LCP hero painted late CLS late content shifts INP main thread busy All three metrics are decided by the deferred phases, not the first response
Each vital is anchored to the phase of the client-render timeline that determines it — which is why they degrade together.

The three metrics, translated to client rendering

A metric definition tells you what is measured; it does not tell you what to look for in a SPA. The table below maps each vital to the specific client-rendering behavior that causes it to fail and the direction the fix takes. The three deep-dive guides expand each row into a step-by-step workflow.

Slide the amount of main-thread JavaScript and watch LCP and INP cross their “good” thresholds — the client-rendering failure mode for Core Web Vitals.
Metric What it measures SPA-specific cause Direction of the fix
LCP Time to paint the largest above-the-fold element The hero is constructed by JavaScript after hydration, often behind a client-side data fetch Serve or stream the hero in the first response; preload its image; never gate it on client-only state
CLS Unexpected movement of visible content Async content is injected into a settled layout, skeletons omit real dimensions, and web fonts swap after paint Reserve exact space before data arrives; size media and skeletons; stabilize font loading
INP Latency from interaction to the next paint Long hydration tasks and heavy event handlers block the main thread when the user first interacts Break work into yield points; defer non-critical hydration; schedule with the browser’s cooperative APIs

Two properties of this table are worth stating explicitly. First, every SPA-specific cause traces back to deferred JavaScript — the same property that makes client rendering attractive is the one that endangers the vitals. Second, every fix direction moves work earlier or off the critical path: paint sooner, reserve space sooner, or unblock the thread sooner. Keeping that framing in mind makes the individual fixes feel less like a checklist and more like one consistent strategy.

In this guide

Each metric earns its own workflow because the diagnostics and fixes differ substantially:

  • Fixing layout shift during SPA route transitions — why client-side navigations inject content into a settled layout, how to reserve space with correctly dimensioned skeletons, and how to use the View Transitions API to keep CLS near zero across soft navigations.
  • Reducing LCP for client-rendered hero content — why a hero painted by JavaScript after hydration is the single most common LCP failure in SPAs, and how preloading, server rendering, and streaming move that paint into the first response.
  • Improving INP on JavaScript-heavy SPA pages — why long hydration tasks make a page feel unresponsive exactly when users first tap, and how yielding, deferral, and scheduler.yield restore snappy interaction.

Why the render queue makes this a crawling issue, not just a UX one

It is tempting to treat Core Web Vitals as a pure user-experience concern that happens to influence ranking at the margins. For a client-rendered app that framing is incomplete. The rendering pipeline that indexes your JavaScript has a finite execution budget, and that budget is spent on exactly the work that inflates your vitals: downloading bundles, executing them, fetching data, and committing paints.

Drag the render-queue backlog: server-rendered pages still index on the first wave while the client-rendered page slides days into the future.

When a real device is slow to reach a stable, interactive state, the crawler’s headless render — running under its own constraints and competing for shared resources — is at risk of being cut short before the meaningful DOM exists. The consequence is not merely a lower ranking for content that is indexed; it is content that is never captured at all. This is the same failure mode behind blank-page indexing, and it is governed by the JavaScript execution limits and crawl budget that constrain the second wave. Improving the vitals — painting sooner, shifting less, blocking the thread less — directly increases the probability that the render completes and the DOM is indexed.

The practical upshot: optimizing Core Web Vitals in a SPA is doing double duty. The same changes that lift the field scores also harden the page against render timeouts. That makes vitals work one of the highest-leverage investments available to a team shipping a client-rendered site.

Lab data and field data disagree — and both are right

A recurring source of confusion is that a SPA can score well in Lighthouse and still fail Core Web Vitals in the field. The disagreement is structural, not a measurement error.

A lab tool runs a single cold load in a controlled environment. It captures the initial LCP and the layout shifts of that first paint, but it never performs a soft navigation, so it misses the route-transition shifts that dominate CLS on a SPA. It also simulates a limited set of interactions, so it underreports the INP that a real user encounters when they tap during hydration.

What a lab load captures versus what field data captures A matrix showing that a single cold lab load captures initial paint and first-load shift but misses route-transition shift, real interaction latency and soft navigations, all of which field data captures. Which vitals each measurement source actually sees Lab (cold load) Field (CrUX) Initial (cold) LCP captured captured First-paint CLS captured captured Route-transition CLS missed captured Real-user INP partial captured Soft navigations missed captured
A green lab score with red field data is expected: the lab never performs the soft navigations where a SPA's real vitals diverge.

Field data from the Chrome User Experience Report reflects real devices, real networks, and real interaction patterns, including the soft navigations the browser now attributes to the page. For a client-rendered app the two views are complementary: use lab tests to gate deploys and catch regressions deterministically, and use field data to understand the vitals your users actually experience. Wiring a lab check into your pipeline is covered in catching SEO regressions with Lighthouse CI; treat its number as a floor, not a verdict.

A shared measurement harness

Before optimizing any single metric, instrument all three from one place so improvements and regressions are visible together. The web-vitals library attributes each metric — including soft navigations for CLS and INP — and lets you forward the values to your own endpoint.

One web-vitals harness reporting all three metrics to an endpoint The browser fires onLCP, onCLS, and onINP into a single report function that beacons each value — tagged with its navigation type — to a vitals endpoint, capturing soft navigations a one-shot report would miss. Instrument all three vitals from one place Browser onLCP onCLS onINP report(metric) name · value · rating sendBeacon keepalive on unload /vitals endpoint navigationType = soft-navigation → a client route change
A single reporter attributes LCP, CLS, and INP — tagging each with its navigation type so soft navigations, where a SPA's real vitals diverge, are never dropped.
import { onLCP, onCLS, onINP, type Metric } from "web-vitals";

function report(metric: Metric): void {
  // Send to your analytics endpoint; keepalive survives the unload.
  const body = JSON.stringify({
    name: metric.name,
    value: metric.value,
    rating: metric.rating, // "good" | "needs-improvement" | "poor"
    navigationType: metric.navigationType, // "navigate" | "soft-navigation" | ...
    id: metric.id,
  });
  navigator.sendBeacon("/vitals", body);
}

// reportAllChanges surfaces soft-navigation updates as the user moves
// between client-side routes, which a one-shot report would miss.
onLCP(report, { reportAllChanges: true });
onCLS(report, { reportAllChanges: true });
onINP(report, { reportAllChanges: true });

Watching navigationType is the detail that matters for a SPA: a value of soft-navigation tells you the metric came from a client-side route change rather than a full document load, which is precisely where a SPA’s real-world vitals diverge from any lab number.

How to work through the three metrics

Order matters when you have all three failing at once. A pragmatic sequence:

  1. Fix CLS first. Layout stability is the cheapest win and the most jarring failure for users. Reserving space rarely requires architectural change, and a stable layout makes the other metrics easier to reason about. Start with fixing layout shift during SPA route transitions.

  2. Then attack LCP. Getting the largest element painted early usually means moving the hero out of the client-only path, which also reduces the blank-render risk. See reducing LCP for client-rendered hero content.

  3. Finish with INP. Responsiveness work — breaking up hydration, deferring non-critical scripts, yielding to the browser — is the most involved and benefits from a page whose paint and layout are already stable. Continue with improving INP on JavaScript-heavy SPA pages.

Recommended order to fix a SPA's three Core Web Vitals Fix layout shift first as the cheapest win, then the largest paint, then interaction latency as the most involved, with effort rising at each step. Fix in this order — effort rises left to right 1 CLS cheapest win, reserve space low effort 2 LCP move hero off client path medium 3 INP break up hydration work most involved A stable layout (step 1) makes the paint and interaction fixes easier to reason about.
Work the vitals in ascending order of effort: layout stability first, hero paint next, interaction latency last.

Several fixes overlap with rendering-architecture decisions. Choosing to server-render or stream the hero, for example, is both an LCP fix and a rendering-strategy choice; the trade-offs are laid out in hydration strategies compared. Treat the vitals as one of the inputs to that architecture, not a separate afterthought.

Common Pitfalls

  • Optimizing only the cold load. A single fast initial paint hides the route-transition shifts and interaction latency that dominate a SPA’s field vitals. Always measure soft navigations.
  • Trusting the Lighthouse number as final. A green lab score with red field data is the normal state for a client-rendered app, not a contradiction — the lab never navigates between client routes.
  • Treating vitals as UX-only. In a SPA the same slow render that fails the metric can fail the render queue, so poor vitals quietly raise the risk that content is never indexed.
  • Fixing metrics in isolation. LCP, CLS, and INP share a cause in deferred JavaScript; a change that paints the hero earlier often improves all three, while a naive per-metric patch can regress another.
  • Ignoring the third-party budget. Analytics, tag managers, and chat widgets execute on the same main thread as your hydration and are a frequent, overlooked source of INP failures; defer non-critical JavaScript.
Five Core Web Vitals pitfalls in a SPA and their corrections Each common mistake — measuring only the cold load, trusting the lab score, treating vitals as UX-only, fixing metrics in isolation, and ignoring third parties — pairs with the practice that fixes it. Turn each pitfall into the practice that fixes it Pitfall Correction Optimising only the cold load measure soft navigations too Trusting the Lighthouse number read it as a floor, not a verdict Treating vitals as UX-only poor vitals raise deindex risk Fixing each metric in isolation fix the shared deferred-JS cause Ignoring the third-party budget defer non-critical scripts
Each SPA vitals pitfall has a direct correction — and most trace back to measuring soft navigations and the shared deferred-JavaScript root cause.

Frequently Asked Questions

Why are Core Web Vitals worse in a client-side rendered app? In a client-rendered app the meaningful content is painted by JavaScript after the framework parses, executes, and hydrates. That pushes the largest paint later, injects late content that shifts layout, and floods the main thread with hydration work that delays input response. The three metrics degrade together because they all depend on the same deferred execution the browser and the crawler must wait for.

Do Core Web Vitals affect how Google crawls and indexes a SPA? Core Web Vitals are a ranking signal, but the deeper crawling risk is indirect: the same slow, JavaScript-heavy render that produces a poor score can time out during the rendering pipeline, so the content that would have earned the ranking is never indexed. A fast, stable render helps the score and improves the odds the DOM is captured at all.

Should I measure Core Web Vitals in the lab or with field data for a SPA? Use both. Lab tools such as Lighthouse give a repeatable score for CI gating and catch regressions before deploy, but they run a cold load and miss route-transition shifts and real input latency. Field data from the Chrome User Experience Report reflects actual devices and captures the soft-navigation vitals that a single lab load never sees.

← Back to Crawling & Rendering Fundamentals