SPA performance is no longer only an initial load story
Single-page applications often feel fast after the first load, but many teams still measure them like classic multi-page websites. A user clicks from a dashboard overview into a record detail, the URL changes, data is fetched, the view repaints and the user waits. Traditional page-load metrics can miss much of that route-change experience.
The Soft Navigations API work changes that conversation. Chrome 151 introduced new performance entries for soft navigations and interaction contentful paints, and the WICG draft explains how browsers can attribute same-document navigation work back to the user interaction that caused it. For product teams, the timely SEO and UX opportunity is clear: measure the journeys people actually use, not only the shell that loads first.
What soft navigations measure
A soft navigation is a same-document navigation that starts with a user action, changes the visible URL and results in a visible paint. That pattern is common in React, Next.js, Vue, Svelte, dashboard shells and customer portals where routing happens in JavaScript instead of through a full page reload.
The new entries help split the performance timeline by route-like user journeys. `soft-navigation` entries identify the navigation segment, while `interaction-contentful-paint` entries expose meaningful content updates triggered by an interaction. The goal is not to replace LCP, INP and CLS, but to make SPA route changes measurable enough for real user monitoring, analytics and release review.
- Track route transitions that users perceive as page changes.
- Attribute contentful paints to the interaction that caused them.
- Group resources, long tasks and layout shifts by navigation segment.
- Compare framework route changes against full document navigation expectations.
- Give product and SEO teams a cleaner view of post-load user experience.
Why this matters for SEO and product analytics
Core Web Vitals remain user-centric metrics, and web.dev continues to recommend evaluating them at the 75th percentile across mobile and desktop. The problem for SPAs has been attribution. A homepage might pass, while the authenticated search flow, pricing configurator or product detail route quietly feels slow after the first click.
The HTTP Archive Web Almanac 2025 performance chapter reported continued Core Web Vitals improvement across the web, but it also highlights the reality of JavaScript-heavy pages and modern application patterns. Soft navigation measurement gives teams a better way to connect field data, route names, page templates and business-critical journeys.
Design the route map before adding metrics
Instrumentation should start with product structure, not with a dashboard widget. List the routes that matter: landing page to signup, portal login to overview, dashboard overview to filtered table, table row to detail, checkout step to confirmation, admin queue to approval screen. Then decide which route changes need field measurement and which are internal UI state changes.
This prevents noisy data. A tab switch, accordion expansion or filter chip should not always be treated as a navigation. A product detail route, onboarding step or invoice detail view usually should. The distinction matters because performance budgets are only useful when they map to journeys people recognize.
Build a practical RUM pipeline
For a production SPA, the useful implementation is a small real user monitoring pipeline. Collect route identifier, navigation type, start time, interaction id where available, largest interaction contentful paint, relevant resource timing, long animation frames or long tasks, device class and whether the user was on mobile or desktop. Keep personal data out of the event payload.
Then aggregate by route group, release version and user segment. A route-change metric becomes actionable when a team can answer: which template regressed, which release introduced it, whether the issue is mobile-only and whether the slow path is rendering, network, third-party JavaScript or backend latency.
- Use stable route templates instead of raw user-specific URLs.
- Sample enough traffic to see regressions without over-collecting.
- Join RUM data to release versions and feature flags.
- Separate public SEO pages from authenticated product workflows.
- Show p75 and poor-experience share, not only averages.
Plan for support gaps and changing standards
The WICG specification is a Community Group draft, not a final W3C standard, and browser support will evolve. That makes progressive measurement important. Teams can collect the new entries where available, keep existing route timing marks as a fallback and avoid making business-critical reporting depend on one browser-only path.
The practical release rule is simple: use soft navigation data as a better signal, not as the only signal. Keep lab tests, framework-level route timings, CrUX or PageSpeed Insights checks for public pages, and manual QA for the workflows where users wait on data, charts or large UI updates.
How EDS Labs would turn this into product work
For a customer portal or dashboard project, EDS Labs would start with a route-performance inventory: the key user journeys, current measurement coverage, Core Web Vitals status for public pages, known heavy transitions and the product decisions that depend on fast feedback. From there, the team can add instrumentation, define budgets and connect regressions to release review.
The result is calmer performance work. Instead of arguing about a single Lighthouse score, the team can see which SPA transitions users actually wait for, where route changes paint late and which fixes improve both perceived speed and product confidence. Soft navigations make modern web apps easier to measure in the same shape users experience them.