CrUX Adds Soft Navigation FCP and Visit Types

Primary topic Mobile Web

The November 11, 2026 Chrome UX Report update adds two experimental measurements that count page changes inside single-page apps. One tracks First Contentful Paint (FCP), the time until visitors first see content after a navigation. The other reports the mix of navigation types. The fields are available through the CrUX APIs and CrUX Vis. The next monthly BigQuery release is scheduled to add them there.

Start with the navigation mix. If most visits to a page come from links inside your app, a paint time that includes those visits answers a different question from the first load alone. A shopper who taps a product card can reuse the app they already have open. Someone arriving at the same product from a search result may need to download and run the app first.

What the two fields measure

A soft navigation keeps the current HTML document and updates the visible URL and page content. A tap on a product card that changes both the address and the rendered view can qualify. A menu expanding in place usually has no new URL to attribute. Detection is enabled by default from Chrome 151 and requires a user interaction, a visible URL change and a content paint. The resulting soft-navigation entry exposes paintTime and presentationTime for its first contentful paint. When CrUX has enough data for the destination URL, experimental results can account for the route under that address.

The new FCP variant combines eligible document navigations and detected soft navigations. A contentful paint is the first eligible text, image or other content that gets drawn. The product name can appear well before the product image, so use FCP to investigate the first sign of content and LCP to investigate when the main content appears. FCP is a supporting metric. LCP, INP and CLS make up the Core Web Vitals.

Navigation Types reports how the sampled views are divided. The existing breakdown includes regular navigations, cached documents, reloads, history returns, back/forward cache and prerenders. The experimental version adds soft navigations to its mix. On Android, a restored tab is counted as reload, rather than the separate restore category. Read each fraction against its own series: adding soft navigations changes the denominator for the other categories too. If soft navigations account for a large share, the blended number can move even when the document-load experience stays steady. Subtracting the standard p75 from the blended p75 cannot recover a soft-navigation-only paint time: each percentile describes its whole distribution.

Read two reports for the same phone traffic

Open CrUX Vis, enter a URL, choose the phone view and open Loading Performance. Expand First Contentful Paint and Navigation Types. Each has an Include soft navigations control. Keep the same URL, device and collection dates while you toggle the feature. Note whether the tool is showing URL or origin data. An origin aggregates eligible pages, which can hide an expensive transition in a small part of the site.

The tool can display FCP even when the Navigation Types graph lacks a point for the same window. On the YouTube homepage report for phones, standard FCP was 3,940 ms at the 75th percentile for October 11 through November 7. The standard navigation chart displayed no value for that same window when checked. At 3.94 seconds, that standard FCP exceeds the poor threshold of 3 seconds; the good target is at most 1.8 seconds at p75. Investigate the document-navigation paint experience. Keep the navigation mix unknown for this window: the missing point gives no basis for choosing a route-heavy explanation or calculating an experimental improvement.

Request the new fields from the API

For a dashboard, send the following JSON body to the CrUX API’s queryRecord endpoint using a Google Cloud key enabled for the Chrome UX Report API. Send a POST to /v1/records:queryRecord on chromeuxreport.googleapis.com. Pass your key as the key query parameter and set Content-Type to application/json. Replace the sample URL with an eligible page. Start with a route that users reach both from outside the app and from within it.

{
  "url": "https://example.com/product",
  "formFactor": "PHONE",
  "metrics": [
    "first_contentful_paint",
    "experimental_first_contentful_paint_with_softnavs",
    "navigation_types",
    "experimental_navigation_types_with_softnavs"
  ]
}

Look under record.metrics. Each paint field can return a histogram and percentiles.p75 in milliseconds. A p75 of 3,940 ms places about three quarters of the sampled observations at or below that time. Each navigation-types field returns a fractions object. Read the soft-navigation share in the experimental breakdown and multiply a fraction by 100 for a percentage; use it to decide how much weight in-app views carry. Preserve the field names in stored data and retain a missing metric as missing. If the URL is too sparse, replace url with origin for a separate, clearly labeled rollup.

Save the firstDate and lastDate from the record’s collectionPeriod beside each result. The window rolls over 28 days and the latest data is about two days behind. A report appearing after a deploy can still contain mostly pre-deploy visits; for an initial trend, compare like-for-like weekly points, then wait for a window wholly after the change before judging the full effect. The History API groups overlapping windows at weekly intervals. Adjacent points therefore share three weeks of traffic. Use the documented queryRecord fields for the current comparison and confirm each field is returned in the historical periods your reporting needs.

A reporting change can move the number immediately

The October dataset release gives a real comparison covering 18,070,207 origins, down 1.7% from the preceding release. The share with good scores on all three Core Web Vitals was 56.3% with the existing calculation and 60.3% with soft navigations included. That is a 4.0 percentage point gap within the same dataset, or a 7.1% relative increase as the release reports it. Reporting it as a site improvement would compare two measurement definitions as if they were two dates.

The individual good-score shares were 68.8% versus 73.6% for LCP, 81.6% versus 85.0% for CLS, and 85.2% versus 87.0% for INP, standard versus experimental. Keep those same-month differences separate from the release’s month-over-month changes in the standard series: LCP +0.7%, CLS −0.1%, INP −0.2% and all three +0.7%, as reported in the release notes.

The October 13 launch analysis found 66–75% of origins had fewer than 5% soft navigations. More than half of views were soft on 7.0% of Android origins and 10.6% of desktop origins; among the top 1,000 sites, those shares were 35% and 42%. Its Android cohort with 75–100% soft navigations moved from 26% good LCP under the standard calculation to 87% under the experimental one. That earlier cohort comparison shows why a route-heavy app deserves attention; it is separate from November’s whole-dataset comparison.

Keep the series separate while the metrics are experimental

For a site that loads a document on most clicks, keep the standard series as the default report. For an app with frequent in-app views, add the experimental series alongside it and use URL-level results to choose a route to profile. The experimental LCP, INP and CLS fields arrived on October 13; November 11 adds FCP and navigation types. The new paint timing helps investigate a route that leaves visitors waiting for its first content.

CrUX includes eligible Chrome users on Android and desktop. Chrome on iOS and Android WebView are excluded; Android Chrome Custom Tabs can contribute. URLs must be publicly discoverable and sufficiently popular under the collection rules. A missing route therefore needs a coverage check before it becomes a performance conclusion. The same platform limits matter for US, UK and European audiences: a phone report is not a complete picture of iPhone or embedded-app traffic.

The stable Core Web Vitals remain unchanged during the experiment. Google targets May 2027 for graduation, subject to feedback, with Search Console switching after graduation. A faster experimental FCP today does not change a Search Console Core Web Vitals result: FCP is not one of those three metrics.

Test the route the report points to

Use the same destination in two recordings: first open its URL directly, then reach it by tapping a link from another view in the app. Start with Chrome 151 or later and the DevTools Performance panel’s soft-navigation support. Match the phone and network conditions to the audience you are investigating. Check that the transition produces a soft-navigation entry and that its destination URL is correct before interpreting its paint timing.

If the transition stalls, inspect the request, script and rendering work between the tap and the first content paint. If CrUX cannot cover the route, use real-user monitoring that supports soft navigations to find how often that stall affects visitors; confirm support with the provider before relying on its route metrics. Keep the direct landing and in-app arrival separate in that diagnosis. A blended percentile tells you where to look; the two recordings reveal which experience needs the fix.