On this page · 10 sections
Summary. On 21 August 2026 Cloudflare began rolling out measurement of client-side route changes in Web Analytics using Chrome's native Soft Navigation API, marked the rollout complete on 4 September 2026, and says in its changelog that reported pageviews and visits in the dashboard and GraphQL API may change, with LCP also liable to fluctuate. 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. Cloudflare has announced no backfill and no flag to restore the old counting. On 16 October 2026 it shipped a beacon fix that ignores same-page soft navigations when the URL does not change, so sites that fire such navigations may see counts dip from that date, and it has not said whether earlier data will be restated. 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 updated on 13 October 2026 and now names Largest Contentful Paint, Interaction to Next Paint and Cumulative Layout Shift, with First Input Delay gone.
If you run a React, Angular, Vue or Svelte front end behind Cloudflare, your traffic chart for late August and early September 2026 probably shows a step that has nothing to do with traffic, and some sites will see a second, downward step on 16 October.
What changed, precisely
Cloudflare's changelog entry of 21 August 2026 describes an accuracy improvement to Real User Monitoring for client-side soft navigations, rolled out gradually and marked complete on 4 September 2026. 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. |
Cloudflare has since adjusted the counting once. Its release notes for the beacon.min.js script list a fix dated 16 October 2026 that makes the beacon ignore same-page soft navigations when the URL does not change, alongside an upgrade of Google's web-vitals library to version 6.2.3. Client-side navigations that left the address unchanged could add soft-navigation events before that date and are dropped after it. Chrome's own definition of a soft navigation also requires a visible URL change. The note says nothing about restating data collected between 21 August and 16 October.
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, first published on 1 February 2023, now states that the feature is enabled by default from Chrome 151, so every site can use it without a flag.
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."
When this article was first published, that sentence contradicted Cloudflare's own Core Web Vitals page, then dated 16 April 2026, which said Core Web Vitals were collected only in Chromium browsers and still listed First Input Delay. Cloudflare updated the page on 13 October 2026. It now names Largest Contentful Paint, Interaction to Next Paint and Cumulative Layout Shift, and notes that Cumulative Layout Shift is only supported in Chromium browsers because Firefox and Safari have not implemented the Layout Instability API. That narrows the changelog's statement that the other Core Web Vitals are present on the routing-apis path: on Safari and Firefox, expect no CLS either.
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 has started to, but not in the numbers Search Console uses. On 13 October 2026 the Chrome team published experimental versions of LCP, INP and CLS that include soft navigations, available from the October 2026 CrUX release in the BigQuery dataset, the CrUX API and the CrUX History API, while the stable Core Web Vitals scores stay unchanged. Google says it aims to graduate these metrics in May 2027, subject to feedback, and that Search Console will then switch to the new data. The soft navigations documentation by Barry Pollard and Michal Mocny now points to the same plan.
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, and will keep doing so until Search Console moves to the soft-navigation data, which Google currently targets for May 2027. A slow route transition that now drags your Cloudflare LCP distribution downward may not appear in the field data Search Console uses, though it can now show up in the experimental CrUX metrics. The reverse is equally possible once Search Console switches.
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 dates in your analytics annotations first, before anyone builds a narrative on the step change. Cloudflare has not said any of this is retroactive, so treat 21 August to 4 September 2026, while the rollout ran, as one seam in the series and 16 October 2026, when the beacon stopped counting same-URL soft navigations, as a second. Pageview totals either side of each seam are not directly 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 Search Console moves to soft-navigation data.
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 to 4 September 2026 seam and the 16 October correction 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 it depends on your front-end architecture and visitor traffic patterns, and it has not said how much the 16 October fix takes back. Google now publishes experimental soft-navigation metrics in CrUX, but Search Console will not use them until they graduate, which Google targets for May 2027. Cloudflare has not said whether historical data will be reprocessed for either change, and the absence of any backfill language points to no. Until those gaps close, the honest position is that your Web Analytics pageview series has two eras, with a correction on 16 October inside the second, 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: 11 November 2026.
