New in the Report: LCP Subparts and bfcache Hit Rate from Real Visitors

A lab test loads a page once, from one location, on a simulated phone. It shows what can go wrong, but not what real visitors experience. The PerfDelta report now adds two views from real smartphone visits: the four LCP subparts, which show where the time to the largest image goes, and the bfcache hit rate, which shows how often the back button brings a page back instantly. Both come from the Chrome UX Report and are shown next to your competitors, so they point directly to the fix that matters most.

LCP subparts show which phase slows down real visitors

The Largest Contentful Paint measures when the largest element on the screen appears. If that element is an image, Chrome splits the time into four consecutive subparts and reports each one for real visitors:

1. Server response: the time until the first byte of the HTML arrives.
2. Load delay: the time between the HTML and the start of the image request.
3. Load duration: the download of the image itself.
4. Render delay: the time between the finished download and the moment the image is painted.

The report shows these four values for your domain and your competitors at the 75th percentile, which is the value Google uses for the Core Web Vitals. The longest subpart of each domain is highlighted, and a stacked bar makes the proportions visible at a glance. An additional column shows how often the LCP element is an image at all, because the subparts only apply to those page views.

The longest LCP subpart decides the first fix

The subparts turn a vague “LCP is too slow” into a concrete task. Our analysis of 893 websites with a slow LCP and subpart data shows how differently the causes are distributed: the server response was the longest subpart on 45.4 percent of them, the load delay on 43.4 percent, the render delay on 8.8 percent and the image download on only 2.4 percent (Chrome UX Report, smartphones, data period up to October 26, 2026). We described the background in detail in Slow LCP: load delay and server response cause 9 in 10 cases.

Depending on the longest subpart, a different guide is the right starting point:

• Server response: page caching, a content delivery network and fewer redirects. Details in the guide on Time to First Byte.
• Load delay: the image belongs in the HTML, without loading="lazy" and with fetchpriority="high". The guide on preconnect and preload shows when a preload hint is needed.
• Load duration: smaller files and modern formats, explained in improve image delivery.
• Render delay: fewer stylesheets and scripts that block painting, see render-blocking resources.

The lab part of the report still shows the LCP element of each tested page with its own breakdown. Together, both views show whether a problem found in the lab also affects real visitors.

The bfcache hit rate shows how fast the back button works

A second card in the report is called Navigation and network. It shows how real smartphone visitors reach your pages: the share of back and forward navigations, the share of reloads, the share of prerendered page views and the network round-trip time of your audience. The most important value in it is the bfcache hit rate.

The back/forward cache keeps a complete snapshot of a page in memory. When a visitor goes back, the browser restores the snapshot instantly instead of loading the page again. The hit rate shows what share of back and forward navigations were actually served this way. On the median website in our sample, 59 percent were, and one in four websites stayed below 25 percent. A low value almost always has a concrete cause, most often a Cache-Control: no-store header on the HTML or an open connection when the visitor leaves the page. Chrome DevTools names the exact reason for each page.

The weekly history shows whether a bfcache fix works

Lab tools can check whether a single page is eligible for the bfcache, but only field data shows whether visitors benefit. The report therefore shows the bfcache hit rate and the share of back and forward navigations of your domain week by week. Each point covers the 28 days up to that week. After a fix, the rate rises gradually over about four weeks, as new visits replace the older ones in the window.

The same applies to the LCP subparts: the general field data history in the report shows how the LCP of your domain develops after a change.

Competitor values put the LCP subparts and the bfcache rate into context

An absolute value alone is hard to judge. Is a server response of 900 milliseconds a problem? Is a bfcache hit rate of 40 percent normal? The report places your domain next to its competitors. If a competitor in the same market reaches a much higher bfcache rate, the cause is rarely the audience and usually the website. For the network round-trip time, the opposite applies: a higher value than a competitor's points to a slower audience, not necessarily to a slower website.

Where to find LCP subparts and bfcache data

Both cards appear in the chapter on real users in every report for which the Chrome UX Report has data for your domain. Start with a free page speed test. Without a test, the Core Web Vitals benchmark compares the same field values for up to five websites side by side.

Limits of the field data

• Enough traffic: the Chrome UX Report only contains domains with enough Chrome visits. Smaller websites may have no field data at all.
• Image LCP only: the subparts are only reported for page views where the LCP element is an image.
• 75th percentile per subpart: each subpart is measured at its own 75th percentile. The four values do not add up exactly to the LCP.
• Whole domain, 28 days: the values describe all pages of the domain over the last 28 days, not a single URL on a single day.
• Chrome only: visits from Safari and Firefox are not included.