In short and in plain language
Many online shops change pages without loading them again. This is called a soft navigation. Google now counts these changes in a new set of data.
The new values are still a test. From May 2027, Search Console is set to use them. Search Console is a Google tool for site owners.
Most websites will see little change. Shops with many page changes without reload will see other values. Often the values then look better. But the page is not faster.
Check the old and the new values now. Measure slow page changes in your shop yourself. We are happy to help you with this.
Since the October 2026 CrUX release, the Chrome UX Report has carried a second reading of Core Web Vitals (web.dev). Next to LCP, INP and CLS, there are now experimental variants that also count soft navigations: page changes in which a single-page app swaps content and URL with JavaScript instead of loading a new HTML document. For most websites, little changes. For headless shops, app-like customer portals and product configurators, the difference can be large, and it comes with a date: Chrome aims to graduate the metrics from experimental in May 2027, after which Search Console will switch to the new data (web.dev). This article continues our guide to measuring soft navigations, which in July still had to note that CrUX reporting was undecided. The data is now here. You will learn which shops are affected, how LCP, INP and CLS shift, how to compare stable and experimental values for your own domain and what to do before the switch.
Key takeaways
- Since the October 2026 release, CrUX has published experimental variants of LCP, INP and CLS that include soft navigations (web.dev). The stable Core Web Vitals values and Search Console remain unchanged for now.
- Around 70 percent of origins have hardly any soft page views, fewer than 5 percent (web.dev). The change mainly affects headless shops and portals that switch pages with JavaScript instead of reloading them.
- With soft navigations, the share of origins with good Core Web Vitals rises from 55.9 to 59.5 percent (CrUX release notes). For Android origins with 75 to 100 percent soft views, good LCP jumps from 26 to 87 percent (web.dev).
- The CrUX API shows your own gap: query the same origin and form factor with largest_contentful_paint and with experimental_largest_contentful_paint_with_softnavs, and record the result with its date.
- Chrome aims to graduate the metrics from experimental in May 2027, after which Search Console switches (web.dev). Until then, measure route changes in your own monitoring and cut long tasks during page transitions.
What CrUX adds since October 2026
The trigger was the launch of the Soft Navigations API in Chrome 151 (web.dev). Chrome detects a soft navigation when three conditions come together: a user action starts the change, the URL changes visibly, and the page visibly paints new content (Chrome for Developers). Until now, CrUX only recorded the first, hard page load in a single-page app. Every later click was counted as part of that first page, including its interactions and layout shifts. A customer who viewed several products entered the statistics as one single page load, and the slowest interaction of the entire session landed on the entry page.
There are three new experimental metrics that evaluate hard and soft navigations together. They carry the experimental label on purpose, to make clear that their definition may still change:
-
experimental_largest_contentful_paint_with_softnavsmeasures LCP across full page loads and soft navigations. -
experimental_interaction_to_next_paint_with_softnavsevaluates responsiveness per view instead of attributing every interaction of a session to the entry page. -
experimental_cumulative_layout_shift_with_softnavsevaluates layout shifts per view and URL instead of across the whole session.
One point matters for context: the stable Core Web Vitals values remain unchanged, and the experimental ones are being validated alongside them. Search Console also keeps showing the existing values until the switch, and most tools still report Core Web Vitals without the new soft navigation metrics (web.dev). For the next CrUX release in November, Chrome anticipates further experimental metrics for First Contentful Paint and for navigation types (web.dev). If you are building a report for management right now, you should know which reading each tool is currently showing.
Scope
Who is affected: headless shops, not the company blog
Most websites load a new HTML document from the server on every click. For them, almost nothing changes. Across all origins in the CrUX dataset, around 70 percent have little to no soft navigation traffic, with fewer than 5 percent of their page views being soft (web.dev). Only about 7 to 11 percent of origins use soft navigations for more than half of their page views (web.dev). A company website with a blog and a contact form will therefore usually show the same numbers in the experimental values as before.
The picture is different for large sites. Among the 1,000 most visited websites, 35 percent on Android and 42 percent on desktop rely on soft navigations for more than half of their page views (web.dev). The changes are concentrated on sites that are built as single-page apps and have many follow-up clicks. That is exactly the pattern of modern shops: a visitor who clicks from the category to the product, on to the cart and back again creates many follow-up navigations in one session.
Classic storefront or headless
For Shopware shops, the architecture decides. The classic storefront renders pages on the server with Twig templates; the browser does not call the Store API directly, the shop's controllers do that (Shopware documentation). Every change between category and product is a full page load there, and such shops see little movement in the experimental values. Headless projects are different: Shopware Frontends is the toolkit for custom storefronts, its demo store is based on Vue.js and Nuxt and fetches data at runtime through the Store API (Shopware documentation). Such a front end switches pages through its own router, and Chrome records these changes as soft navigations once the three criteria are met.
There is a gray area in the product listing. The classic storefront also writes the filter selection into the URL with history.pushState on click and reloads the product list in the background (Shopware source code). That can fulfill all three criteria of a soft navigation: user action, visible URL change, visible repaint. Whether Chrome actually counts a filter click as a navigation depends on its heuristic. You can check it in the DevTools Performance panel, which marks soft navigations in the live view and in the trace (Chrome for Developers). For Shopware projects, this check is part of our Shopware performance optimization.
There is also a quirk in the CrUX data: CrUX strips query parameters such as ?utm_medium=email from the URL so that all visits to a page are aggregated together (CrUX documentation). If filter clicks are recorded as soft navigations, they are therefore likely to flow into the values of the category URL without parameters. The category page then carries not only the experience of the first load but also that of the filter changes. These signs point to a high share of soft page changes:
- When a product is clicked, the header stays in place, only the content changes, and the browser's loading indicator does not move.
- The shop runs as a headless front end with its own router, for example based on Shopware Frontends.
- Cart, wish list or customer account open under their own URL without reloading the page.
- Filters, sorting and pagination change the URL through the History API.
- In the DevTools Performance panel, a click path through the shop shows markers for soft navigations.
How each metric shifts
Across the whole dataset, the effect is small but measurable. The CrUX dataset for September 2026 covers around 18.4 million origins (CrUX release notes). Of these, 55.9 percent had good Core Web Vitals (CrUX release notes). With soft navigations, it would be 59.5 percent (CrUX release notes). The table shows the individual metrics from the same release.
| Metric (source: CrUX release notes, September 2026 dataset) | Origins with good values, stable measurement | Origins with good values, with soft navigations |
|---|---|---|
| LCP | 68.3 % | 72.1 % |
| INP | 85.4 % | 87.4 % |
| CLS | 81.7 % | 85.1 % |
| All three Core Web Vitals | 55.9 % | 59.5 % |
These averages hide where the movement actually happens. According to Chrome, the experimental values look identical or nearly identical for the vast majority of websites, while for single-page apps they either improve or remain steady, depending on how often users navigate within the site (web.dev). Clear jumps occur in the small group with mostly soft page views. The three metrics react in different ways.
LCP: follow-up views reuse what is loaded
When visitors click through many follow-up views, LCP improves because soft navigations reuse code and files that were already downloaded on the first load. For Android origins with 75 to 100 percent soft navigations, the share with good LCP rises from 26 to 87 percent (web.dev). Chrome stresses that this does not make SPAs faster than classic websites overall: follow-up clicks are faster on any website, and SPAs with many follow-up clicks simply move in line with classic websites with many follow-up clicks (web.dev).
For debugging, the LCP element changes. The soft navigation measurement only considers newly painted content: if a large image stays in place between two views and only the text below it changes, the text becomes the LCP element of the soft navigation (Chrome for Developers). A header image or banner that is the LCP element on a direct entry therefore drops out after a click within the shop if it stays in place. How to break LCP down into its phases is shown in the article on LCP subpart analysis.
INP: per view instead of per session
INP is where the logic of the measurement changes most clearly. Until now, the slowest interaction of the entire session counted; now responsiveness is measured per page view. For sites with mostly soft navigations, this roughly doubles the Android pass rate (web.dev). That is no all-clear: even with this boost, sites with many soft navigations still trail classic websites in good INP, and heavy JavaScript work on the main thread during route changes can still cause INP issues (web.dev).
For shops, this means that a click on "Add to cart", opening the mini cart or moving to the next product page is assigned to the view in which it happens. Slow transitions can thus be traced to a route instead of disappearing in the session value. Approaches are described in Optimizing INP and Breaking up long tasks with scheduler.yield.
CLS: shifts per view
CLS usually improves as well, because layout shifts are no longer accumulated over a long session but evaluated per view. Sites with many soft navigations are thereby in line with classic websites on desktop and nearly in line on Android (web.dev). If the CLS of a route is still poor, the cause lies in that view itself: reviews loading late, banners without reserved space or images without dimensions. The article Avoiding cumulative layout shift helps with that.
Better number, same page
Compare your own values: stable versus experimental
Starting with the October 2026 release, the experimental metrics are available in the CrUX BigQuery dataset, the CrUX API and the CrUX History API (web.dev). The quickest way to see the difference is CrUX Vis, which shows the new values for any URL and origin in the dataset. For a documented comparison that you can repeat later, the API is the better route.
The CrUX API provides a rolling average over 28 days (CrUX documentation) and is updated daily around 04:00 UTC (CrUX documentation). Query both variants for the same origin and form factor in one request:
curl -s -X POST \
'https://chromeuxreport.googleapis.com/v1/records:queryRecord?key=API_KEY' \
-H 'Content-Type: application/json' \
-d '{
"origin": "https://www.your-shop.example",
"formFactor": "PHONE",
"metrics": [
"largest_contentful_paint",
"experimental_largest_contentful_paint_with_softnavs",
"interaction_to_next_paint",
"experimental_interaction_to_next_paint_with_softnavs",
"cumulative_layout_shift",
"experimental_cumulative_layout_shift_with_softnavs"
]
}'The response contains a histogram and the 75th percentile value for each metric. Compare both values per metric and note the collection period from the collectionPeriod field. Then repeat the query with DESKTOP and for the most important page types at URL level: home page, a heavily visited category, a typical product page. Which templates tip the balance is described in Template performance beyond the home page.
At URL level, there is an additional effect that matters for shops: in the CrUX API, the values of a soft navigation are reported under the URL the user navigated to, not under the landing page, provided the usual eligibility criteria are met (web.dev). Product pages that were reached almost only by clicking from a category may get their own data for the first time. Conversely, the landing page loses interactions and shifts that actually belonged to later views.
History and monthly data
The History API is updated every Monday and covers the previous 40 weeks, one collection period per week (CrUX documentation). How far back the experimental series go there is shown by the response itself: periods without eligible data appear as NaN or null in the time series (CrUX documentation). If you start observing now, you will have several months of history before the planned switch and can separate real trends from single outliers.
For analyses across many domains or countries, BigQuery is the right tool. The dataset is released monthly on the second Tuesday of the following month (CrUX documentation), and the new columns sit in the experimental record as largest_contentful_paint_with_softnavs, interaction_to_next_paint_with_softnavs and cumulative_layout_shift_with_softnavs. Chrome explicitly expects shifts from month to month while the measurement is being refined (web.dev). A single monthly value is therefore an interim status, not a verdict. This is how to run the comparison:
- Fetch origin values for mobile devices, with the stable and experimental metric side by side.
- Repeat the same query for desktop.
- Query the most important page types at URL level and check which URLs gain data for the first time.
- Document the gap per metric as a baseline together with its collection period.
- Re-measure monthly and separate changes in methodology from real improvements.
What the switch means for Search Console
The Core Web Vitals report in Search Console takes its data from CrUX. It groups similar URLs and shows, per group, the value that 75 percent of page views in the past 28 days reached or beat (Search Console Help). Once the experimental metrics graduate, Search Console will switch to the new data (web.dev). For most websites, the change will be barely noticeable.
For SPA shops, however, the report may change noticeably. Groups that stand out today because of poor INP may look better after the switch if the poor value came from interactions in later views. Conversely, new URLs may appear in the report because soft navigations are counted under the target URL. A group only appears if there is enough data for LCP and CLS (Search Console Help); that, too, may change with the new attribution.
It is still open how Google will handle ongoing validations and the history charts at the switch; the announcements so far say nothing about it. A validation monitors for 28 days whether an issue still occurs on any URL (Search Console Help). If you roll out fixes in spring 2027, plan validation so that its results are in before the switch, and note the date of the change in your own log. How to read groups, example URLs and statuses is described in Reading the Core Web Vitals report in Search Console.
The rule until the switch
Roadmap to May 2027
Chrome aims to graduate the metrics from experimental in May 2027, explicitly subject to feedback (web.dev). The date may therefore move. It is still good enough for planning, because the work falls into three stages that keep making sense in this order even if the switch comes later.
By the end of 2026: collect a baseline
Query stable and experimental values for the origin, both form factors and the most important page types, and record them. With the release in November, FCP and navigation types are expected to follow as experimental metrics (web.dev). If the comparison shows hardly any differences, your shop is probably built the classic way. A quarterly check is then enough, and the work focuses on the familiar levers of server, images and scripts.
By spring 2027: measure routes in your own monitoring
CrUX shows that something shifts, but not on which route. That takes real user monitoring with soft navigation support. The web-vitals JavaScript library supports soft navigations as of version 6.0.0 (Chrome for Developers). Chrome recommends sending the navigation type along so that LCP, INP and CLS can be analyzed separately for soft and hard navigations. For a transition period, measuring twice pays off: once in the existing reading and once per soft navigation. That keeps your history and the comparison with other browsers intact (Chrome for Developers).
There is one limit: browser engines other than Chromium do not yet support the new APIs, so Core Web Vitals can only be measured across full page loads there (web.dev). Visitors using Safari on the iPhone therefore stay in the existing reading. Which measurement data you may collect without consent is covered in the article on performance measurement without consent.
By May 2027: fix the transitions
The route data reveals which transitions are slow. Typical candidates in a shop are the change from category to product, opening the cart and the step into checkout. The following overview shows where we start in SPA shops.
Long tasks during route changes
Router, data fetching and re-rendering often run as one block on the main thread. Split into smaller steps, the page responds faster to the next click, and the INP of the view drops.
Main image of the new view
In a soft navigation, the newly painted largest element counts. If the product image only loads after the data request, it delays the LCP of the view. Requesting it early and serving it at the right size helps.
Placeholders with fixed dimensions
Placeholder areas that are smaller than the final content cause shifts in every view. Reserved heights for the price box, reviews and recommendations keep CLS per route low.
Filters and pagination
If filters change the URL through the History API, they can count as soft navigations. Fast Store API responses and a repaint without jumps then decide all three metrics.
Two more points help. A fast first load remains essential, because the hard entry still counts; the article on server-side rendering and hydration has pointers. And transitions between views can be made calmer with the View Transitions API when fixed areas and short animations work together.
How we prepare SPA shops for the switch
For headless shops and app-like portals, preparation starts with an honest assessment: how large is the share of soft page changes, and which metric shifts by how much? In our performance analysis, we compare stable and experimental CrUX values per form factor and page type and map the gaps to your templates. Where CrUX is not enough, we set up route measurement in your own monitoring, with separate analysis for Chromium and other browsers.
Then we tackle the causes. For good Core Web Vitals in single-page apps, these are mainly long tasks during route changes, late main images and placeholders without fixed dimensions. For applications with login and dashboard, the approaches from our page on PageSpeed for SaaS applications apply; for Shopware shops, the Store API and caching come into play. The goal is that your values at the time of the switch come from real improvements and not only from the new methodology.
Sources and documentation
Related Articles
Sale Launch at Midnight: Warm the Cache Instead of Waiting
At sale launch, prices change and the cache goes cold. Build a warm-up list from field data and the sitemap, plan the night and measure hits before release.
What Does PageSpeed Optimization Cost? Planning the Effort
PageSpeed optimization costs depend on templates, shop system, scripts, server and images. How to plan analysis, fixed price, monitoring and a 2027 budget.
How to Read the Core Web Vitals Report in Search Console
The Core Web Vitals report bundles URLs into groups. Learn to read status, group value and example URL, and turn them into a work order for the template.