Core Web Vitals 2026: Measuring SPA Performance Right

Why SPAs Were a Blind Spot in CWV Measurement

On a classic multi-page website, every click loads a new document from the server. The browser fires a real navigation event, and Core Web Vitals are captured cleanly for each of these pages. In a single-page app, that happens only once: on the initial load. After that, JavaScript takes over. Frameworks like React, Vue or Angular change the view via the History API with pushState and replaceState, swap content in the DOM and update the URL - but without triggering a full navigation event (web.dev).

The result was a systematic blind spot. Core Web Vitals were only captured during the initial page load, and all further in-app transitions were grouped under the entry-point URL (web.dev). Audit tools and the Chrome User Experience Report therefore could not distinguish between the first load and the later view changes. A perceptibly slow detail page, a sluggish filter or a laggy checkout step appeared in no field-data statistic - even though that is exactly where users wait.

The tricky part: the initial-load metric could look excellent while actual usage suffered. Anyone running an SPA was therefore often optimising the wrong place - the initial bundle download - and overlooking the in-app transitions that make up the bulk of a session in practice. A pure lab measurement on the developer laptop makes this worse, because it reflects neither the visitors' real devices nor the actual click sequence. This difference between lab and field is not a detail but the core of the problem: field data is considered the authoritative benchmark, because it reflects the actual user experience across all devices, networks and locations, whereas a lab test remains just a controlled assumption (Core Web Vitals Benchmarks 2026). In a single-page app, where most interactions take place after the initial load, this difference carries particular weight.

What Soft Navigations Are

A soft navigation is a JavaScript-triggered view change that feels like a real navigation to the user, without a new document being loaded from the server. Chrome defines it through three conditions: the change is initiated by a user interaction, it results in a visible URL change, and it produces a visible paint of new content (Chrome for Developers). Only when all three criteria apply does the browser treat the action as a navigation in its own right.

Technically, the Soft Navigations API introduces new entry types in the performance timeline. Each detected change produces a soft-navigation entry with its own navigationId, the new URL and the interactionId of the initiating interaction (Chrome for Developers). The new interaction-contentful-paint entry type measures the largest contentful paint after an interaction and serves as the LCP for that soft navigation. Existing timing entries additionally receive a navigationId, so every measurement can be attributed unambiguously to a single view.

What the 2026 Core Web Vitals Update Changes

The 2026 update brings three substantive adjustments: the INP measurement methodology was refined to better capture sustained interaction latency on input-heavy pages, soft-navigation coverage in CrUX was expanded for single-page apps, and the server response time TTFB is highlighted more strongly as a diagnostic in field-data analysis - not as a ranking signal in its own right (WebVitals.tools). The three thresholds themselves remain unchanged.

These thresholds apply under the familiar rule: a page passes a metric only when 75% of real user visits meet the value at the 75th percentile over a rolling 28-day window - and all three metrics must pass at once (Core Web Vitals Benchmarks 2026). A single missed metric fails the overall assessment. That is exactly why the soft-navigation expansion matters so much: once in-app transitions feed into the field data, they assess real usage instead of just the initial load.

Current data shows where the weak spots are. In the CrUX dataset from May 2026, over 18.4 million origins were evaluated (Core Web Vitals Benchmarks 2026). Of these, 68.6% achieved a good LCP, 81.3% a good CLS and 86.6% a good INP (Core Web Vitals Benchmarks 2026). LCP is therefore the hardest hurdle - and it is precisely the perceptible paint time that remained invisible during slow in-app transitions.

Why Slow In-App Transitions Cost Conversions

Perceived speed is directly linked to business metrics. As load time grows from one to three seconds, the probability of bounce rises by 32%; from one to five seconds it climbs by 90% (Google/SOASTA). That analysis is based on a neural network with around 90% prediction accuracy (Google/SOASTA). The longer a visitor waits, the more likely they abandon - and in an SPA that wait arises mainly during the in-app transitions after the initial load.

In single-page apps, this problem shifts from the initial load to the transitions. Progress indicators and skeleton screens mask the slowness visually, but they do not change the fact that the user is waiting (MindK 2025). Worse still: people often remember a delay as longer than it actually was (eBay Tech Blog). Anyone who does not measure slow in-app transitions sees good values in their field data - and still loses visitors at exactly the points between entry and conversion.

Then there is the device gap. In the CrUX dataset from July 2025, only 48% of mobile pages passed all three Core Web Vitals compared to 56% on desktop (Core Web Vitals Benchmarks 2026) - a gap of eight percentage points. Since in-app transitions weigh especially heavily on lower-powered mobile devices, per-view field-data measurement is particularly important for mobile audiences. On top of that, mobile users typically go through their session on the move and with varying network quality - a detail-page transition that feels fluid on Wi-Fi can noticeably stutter on a mobile network. Only a measurement on the real device captures this variability, not a test on a stable office network. Anyone serious about mobile conversions therefore needs field data that measures the transition where the visitor experiences it.

Capturing Soft Navigations With Field Data

Lab data alone is not enough. A measurement in a controlled test says little about how an in-app transition runs on a visitor's real device with their network, browser and click sequence. What matters is field data - real-user measurement in the actual browser. With the Soft Navigations API, every view can now be captured individually, because the navigationId attributes each measurement to a single navigation (web.dev).

Classic measurement (initial load only):
  /                LCP 2.1 s   measured
  /products        -           blind
  /product/42      -           blind
  /cart            -           blind

Soft navigation measurement 2026 (per view):
  /                LCP 2.1 s   good
  /products        LCP 1.4 s   good
  /product/42      LCP 3.8 s   slow      <-- bottleneck
  /cart            LCP 1.9 s   good
  /checkout        INP 410 ms  slow      <-- bottleneck

=> Two slow transitions revealed that the initial load hid

XICTRAQ performance monitoring captures your pages' Web Vitals continuously with real field data - the tracker collects LCP, CLS and INP directly in visitors' browsers, without cookies and without third parties. This builds a field-data history that shows whether transitions stay within target across devices and regions, or whether a deploy slowed down a step. The core idea of continuously checking a target value against reality is something performance monitoring shares with SLO monitoring via error budget burn-rate alerts.

• Real field data - LCP, CLS and INP are measured in real visitors' browsers, not just in the lab on the developer device
• Per view instead of per session - the values can be attributed to individual views, making slow in-app transitions visible
• Device and region split - field data shows whether a transition only slows down on mobile devices or in certain regions
• Performance budgets - defined target values per metric trigger an alert as soon as a value exceeds them
• Cookieless and GDPR-oriented - the measurement works without cookies and without transmission to third parties

It is important here that the measurement itself does not create additional load. A modern field-data measurement uses the performance interfaces already present in the browser and sends the values in batches, without delaying the rendering of the transition. This produces a realistic picture of the user experience without the collection distorting the result. Especially in single-page apps, where every additional task on the main thread can increase interaction latency, this lean capture is decisive.

Monitor Slow Transitions Before They Get Noticed

A one-off performance check is a snapshot - by the next deploy it may be outdated. Just as with security or compliance topics, the degradation often creeps in gradually: a new image without fixed dimensions, an extra script in the checkout or a changed data fetch can noticeably slow down an in-app transition. Continuous monitoring with field data catches such regressions instead of stumbling on them at the next manual audit.

When a value exceeds its performance budget - a view's LCP gets slower or INP rises in the checkout - XICTRAQ triggers a notification via email, Slack, Discord or Telegram. So you learn about a performance regression while it is still a few hours old, instead of only when the quarterly figures slump. How important resilience is in interplay with the underlying infrastructure is shown by the article on resolver resilience after the .de zone DNS outage.

Performance Monitoring as Part of the Bigger Picture

Performance is not an isolated topic but a building block of a resilient operation. A fast, stable site pays into visibility, conversion and user trust - and it depends on factors that go beyond pure frontend optimisation. The following areas interlock.

The practical value lies in the time factor. Without per-view field data, a slow transition is typically only noticed when conversion figures drop or a user complains - long after the triggering deploy. With continuous field-data measurement, the same degradation becomes visible within hours, often before it measurably hits revenue. This shortening of the time window is the real lever.

Single-page apps will not disappear - quite the opposite. The fluid, app-like operation is a competitive advantage. What can change is the blind spot in measurement. With the Soft Navigations API and continuous field-data monitoring, the previously invisible in-app transition becomes a visible, alertable signal - and thus an optimisable quantity instead of a black box.

Frequently Asked Questions About Core Web Vitals in SPAs