On this page · 10 sections
Summary. On 21 August 2026 Cloudflare began measuring client-side route changes in Web Analytics using Chrome's native Soft Navigation API, and its own changelog states the change "may alter the volume of pageviews reported in the dashboard and GraphQL API". Two values join the navigationType dimension: soft-navigation and routing-apis. The Largest Contentful Paint figure that makes this useful only exists on Chrome 151, which reached stable on 28 July 2026. There is no backfill, no announced flag to restore the old counting, and no dated cut-over. Cloudflare Web Analytics is available on all plans, from the $0/month Free plan up to Business at $200/mo billed annually. The Core Web Vitals page that explains how these metrics are collected was last updated on 16 April 2026 and still describes the pre-change model, including First Input Delay, a metric Google replaced with Interaction to Next Paint.
If you run a React, Angular, Vue or Svelte front end behind Cloudflare, your August traffic chart is about to develop a step that has nothing to do with traffic.
What changed, precisely
Cloudflare's changelog entry of 21 August 2026 describes an accuracy improvement to Real User Monitoring for client-side soft navigations. The mechanism has three tiers, set out in the Web Analytics SPA documentation as of 20 August 2026:
- The Soft Navigations API, where the browser supports it.
- The Navigation API, listening for
navigateevents.
- Patching the History API's
pushStatefunction and listening toonpopstate.
Before this change, Cloudflare says it used only the History API and bucketed every navigation into navigate. That claim is worth reading twice, because the Dimensions page, last updated the same day, documents eleven navigation types, nine of which predate this release and include Navigate Cache, Navigate Prefetch Cache, Prerender, Reload, Back-forward and Restore. The changelog's three-row summary table and the reference documentation's eleven-row table describe the same dimension and do not agree on what it contained yesterday.
The practical consequence is the same either way. Route changes that previously produced no beacon, or produced one indistinguishable from a hard navigation, now produce a distinctly-typed event. The FAQ page confirms the beacon behaviour: for a single-page application, "additional metrics are sent for every route change to capture the page load event."
| navigationType | Introduced 21 Aug 2026? | What it does to your pageview count |
|---|---|---|
| Navigate | No | Unchanged. Hard navigation, document fetched from the network. |
| Navigate Cache | No | Unchanged. Hard navigation served from the HTTP cache. |
| Navigate Prefetch Cache | No | Unchanged. Prefetched document, no network request. |
| Prerender | No | Unchanged. Browser had already rendered the page. |
| Reload / Reload Cache | No | Unchanged. Explicit reload, cached or not. |
| Back-forward / Back-forward Cache | No | Unchanged. Back and forward gestures. |
| Restore | No | Unchanged. Tab restored after inactivity. |
| Soft Navigation | Yes | New rows. Chrome 151 and later only. Carries LCP. |
| Routing APIs | Yes | New rows. Safari, Firefox, older Chromium. No LCP. |
Why the LCP arrives unevenly
The measurement that makes soft-navigation tracking worth having is Largest Contentful Paint on a route change, and that depends on Chrome, not on Cloudflare. Google's soft navigations documentation, published on 1 February 2023 and last updated on 21 July 2026, carries an explicit note: "The Chrome team is launching this feature from Chrome 151 at which point it will be available unflagged for all sites to use."
Chrome 151 reached stable on 28 July 2026. Its release notes list the entry "PerformanceSoftNavigation and InteractionContentfulPaint performance entries", tracked as bug #1338390, and describe the soft-navigation entry as reporting "same-document history state changes initiated by interactions, establishing a new time origin to attribute subsequent performance data to the active route rather than the initial document URL."
Cloudflare's changelog is candid about the gap. For the routing-apis fallback path, covering Safari, Firefox and older Chromium builds, it says: "We cannot collect LCP for these, but the other Core Web Vitals are present."
That single sentence contradicts Cloudflare's own Core Web Vitals page, last updated 16 April 2026, which states that "Core Web Vitals is currently only supported in Chromium browsers, with Safari and Firefox coming soon." The same page opens by naming the three measured metrics as Largest Contentful Paint, First Input Delay and Cumulative Layout Shift, then lists Interaction to Next Paint two paragraphs later. One reference page, three unresolved statements. Treat the changelog as current and the Core Web Vitals page as four months stale.
The gap nobody at either vendor has closed
Here is the part that matters if anyone in your organisation reports Core Web Vitals to a board or a client.
Cloudflare now measures soft navigations. Google does not yet report them in the dataset that feeds Search Console. Barry Pollard and Michal Mocny, the Chrome engineers credited as authors of Google's soft navigations documentation, write plainly: "How exactly soft navigations will be reported in CrUX, once the feature is launched, is also still to be determined." The same page states the intent, "the aim is to include these in Core Web Vitals measurements as exposed by all tools after the API is launched," without a date.
So from 21 August 2026 your Cloudflare dashboard and your Search Console Core Web Vitals report are measuring different populations of navigations on the same site, by design, with no published timetable for convergence. A slow route transition that now drags your Cloudflare LCP distribution downward may not appear in the field data Google uses. The reverse is equally possible once CrUX changes.
Anyone tracking Search Console reporting for AI-driven visibility alongside a Cloudflare RUM dashboard should stop treating the two numbers as the same measurement.
Who is affected, and how to tell if that is you
Check three things.
First, architecture. The changelog is explicit that this is not only an SPA problem: "a non-SPA website can have soft navigation activity if its implementation uses these APIs." Any site using the History API or the Navigation API for client-side routing qualifies, including a mostly-static site with a filtered product listing. Teams shipping Next.js instant navigations and partial prefetching or a TanStack Start front end are squarely in scope.
Second, browser mix. If your Chrome share sits well above your Safari and Firefox share, the new soft-navigation rows will dominate and you will get LCP. If you skew to Safari on iOS, most new rows land in routing-apis with no LCP, so your LCP sample becomes a Chrome-only subset of a now-larger pageview base. That is a denominator change hiding inside a metric.
Third, downstream consumers. Anything reading the GraphQL API on a saved filter of navigate will now silently exclude route changes it used to include. Alert thresholds, weekly reports and any conversion-rate calculation with pageviews in the denominator all inherit the shift.
What to do this week
Mark the date in your analytics annotations first, before anyone builds a narrative on the step change. Nothing here is retroactive, so 21 August 2026 is a hard seam in the series and pre-seam and post-seam pageview totals are not comparable.
Segment by navigationType rather than turning the feature off. Split hard navigations from Soft Navigation and Routing APIs, and keep reporting the hard-navigation series next to the combined one for at least one full reporting cycle.
If you must freeze the old behaviour, the SPA documentation gives an opt-out: add "spa": false to the data-cf-beacon attribute on the beacon script tag. Cloudflare notes this requires the manual embedding approach rather than automatic injection. Under Google Tag Manager, pass it on the query string as ?token=...&spa=false. Understand the trade-off before you do it. You lose route-level measurement entirely, and you will have to unwind the change when CrUX catches up.
Feature-detect before you trust a soft-navigation number in your own instrumentation. Google's documentation gives the test as PerformanceObserver.supportedEntryTypes.includes('soft-navigation'), with the caveat that supportedEntryTypes is frozen on first use.
One more operational limit worth knowing while you are re-baselining: Cloudflare's FAQ states a soft limit of ten sites per account for Web Analytics, adjustable through support, and confirms that RUM "operates exclusively on the initial client request and cannot collect metrics from Worker subrequests." If you were planning to instrument route changes at the edge instead, that path is closed.
India-specific considerations
Indian consumer traffic runs heavily on Android Chrome, so most Indian-market SPAs will see the soft-navigation path rather than the routing-apis fallback, and the pageview increase will be larger than for a comparable US or European property with a big iOS Safari share. Where a Cloudflare dashboard number is quoted in a client report or an agency retainer covering ₹ media spend, restate the 21 August 2026 seam in writing before the next invoice cycle. Beacon data collected here is behaviour data about identifiable visitors' devices, so a change in what the beacon emits is worth a line in your Digital Personal Data Protection Act 2023 processing record even though Cloudflare states the beacon uses no cookies or localStorage.
What is still unknown
Cloudflare has not published an expected magnitude for the pageview increase, saying only that "the extent depends on your front-end architecture and visitor traffic patterns". Google has not said how CrUX will treat soft navigations, or when. Cloudflare has not said whether historical data will be reprocessed, and the absence of any backfill language points to no. The Core Web Vitals reference page has not been reconciled with the changelog. Until those four gaps close, the honest position is that your Web Analytics pageview series has two eras and only one of them can be compared to Search Console.
The real cost here is not the instrumentation. It is every report and target that quietly assumed one definition of a pageview.
FAQ
How eCorpIT can help
Re-baselining an analytics series after a measurement change is dull, exacting work, and it is much cheaper before three months of reports have been built on the wrong denominator. Our engineering teams handle this as part of Core Web Vitals and web performance work, covering beacon configuration, GraphQL query review and the reconciliation between Cloudflare RUM and Search Console field data. If your August dashboard has developed a step you cannot explain, ask our web performance team to review your Web Analytics setup.
References
Last updated 23 August 2026.
