What Prerendering Does to Your Core Web Vitals Data

A team ships a Speculation Rules script, and two months later the Core Web Vitals report in Search Console shows a large jump in "good" LCP URLs. Nothing about the server, the images, or the critical path changed. The pages are not faster. The measurement origin moved.

That is not a bug and it is not cheating — users genuinely experience an instant navigation. But if you cannot separate "the page got faster" from "the page got prerendered," you will make bad decisions about what performance work to fund next, and you will quietly corrupt your pageview and log data at the same time.

What the browser actually does when it prerenders

The Speculation Rules API lets a page tell Chrome to fetch and fully render a likely next URL in a hidden tab-like context:

<script type="speculationrules">
{
  "prerender": [{
    "where": { "href_matches": "/product/*" },
    "eagerness": "moderate"
  }]
}
</script>

The eagerness value decides when speculation fires. immediate and eager start early; moderate triggers on hover (Chrome documents roughly a short hover delay on desktop); conservative waits for pointerdown. Chrome caps how many prerenders can be in flight at once, and it discards them under memory pressure or when the page uses features that are unsafe to run pre-activation.

When the user clicks, the prerendered document is activated: it is swapped in, becomes visible, and fires a prerenderingchange event. HTML parsing, subresource fetching, layout, and JavaScript execution all already happened — possibly seconds earlier, on the previous page's dwell time.

Why a prerendered page reports an LCP near zero

Metrics like LCP, FCP, and TTFB are timestamps measured from navigation start. For a prerendered document, navigation start is when speculation began, not when the user clicked. Reporting raw timestamps would make prerendering look worse than it is in some cases and incoherent in others.

Chrome solves this with activationStart on the navigation timing entry. The convention is to subtract it and clamp at zero:

const nav = performance.getEntriesByType('navigation')[0];
const corrected = Math.max(0, rawTimestamp - nav.activationStart);

If the largest contentful paint happened 1.8s after speculation began, and activation happened 4s after speculation began, the user-perceived LCP is 0. Google's web-vitals library performs this correction automatically and exposes whether the page was prerendered, so RUM tools built on it inherit the behavior. Chrome's documented position is that these metrics should reflect post-activation, user-perceived time, so the reasonable inference is that CrUX — and therefore the Search Console Core Web Vitals report, which is CrUX-derived — records the corrected values.

The practical consequence: prerendering does not improve your page; it relocates the cost to a moment the user is not waiting. That is a legitimate user experience win. It is not a server, template, or asset win, and it will not help any of the following:

• Entry pages from search, social, or email — there is no referring page to host the speculation rules.
• Browsers that do not implement Speculation Rules.
• Navigations where speculation was never triggered or was discarded.
• Googlebot, which does not behave like a user hovering links.

Why prerendering does not add data, it shifts it

A prerender that is never activated produces no CWV sample at all — the document never becomes visible, so there is nothing user-perceived to report. That means prerendering cannot inflate your sample count; it moves a subset of existing samples from "slow" to "effectively instant."

This matters for interpretation. If 20% of your product-page navigations come from a listing page with moderate eagerness and a decent activation rate, you can move a meaningful share of samples to near-zero LCP while the 75th percentile for cold entries stays exactly where it was. Whether the overall 75th percentile crosses a threshold depends entirely on how much of your traffic is internal, repeat navigation — which varies enormously by site type.

How speculative requests distort logs and analytics

Speculative fetches hit your origin like real requests, but Chrome labels them. Filter on these:

If your log pipeline, CDN dashboard, or bot-filtering logic ignores Sec-Purpose, three things go wrong:

1. Traffic looks higher than it is. Requests for pages nobody visited count as pageviews in log-based reporting.
2. Origin load analysis is wrong. You may be provisioning for speculative traffic you could reduce by changing eagerness — relevant if you have already found that response time constrains your crawl rate.
3. Server-side experiments get polluted. A prerender that is never activated is an impression of your variant with no human attached.

Client-side analytics has the mirror problem. During prerendering, document.prerendering is true and the document's visibility state is hidden. Libraries that fire a pageview on script execution without checking for that can log phantom sessions. The correct pattern is to defer until activation:

if (document.prerendering) {
  document.addEventListener('prerenderingchange', sendPageview, { once: true });
} else {
  sendPageview();
}

Major analytics vendors have added prerender handling, but behavior differs by product and version, and any custom or tag-manager-fired event you wrote yourself almost certainly does not handle it. Test it rather than assuming.

What to do about it

1. Add a prerendered dimension to your RUM and segment every CWV metric by it. One number that mixes instant activations with cold loads tells you nothing about whether your templates improved.
2. Keep a cold-load baseline for every template — synthetic tests or the non-prerendered RUM segment. Fund performance work against that number, not against the blended CrUX figure.
3. Filter Sec-Purpose in your log pipeline before any traffic, crawl-budget, or capacity analysis, and before any server-side test assignment.
4. Measure activation rate (activated prerenders ÷ total prerenders). A low rate with immediate or eager eagerness means you are paying origin cost for nothing; tighten to moderate and scope href_matches to the links users actually click.
5. Verify your analytics defers pageviews by loading a prerendered page in Chrome DevTools' Speculative Loads panel and watching what fires before activation.
6. Do not expect ranking effects from prerendering beyond the CWV signal itself. Google documents page experience as a small factor; the honest framing is that prerendering buys real user speed on internal navigation, plus a field-data improvement that reflects it, and nothing more.