Prerender pages without firing your analytics

The reason most marketing teams reject prerendering has nothing to do with speed. It is that a prerendered page runs its scripts before the user arrives, so analytics records sessions that never happened, and the person who owns the reporting says no.

The prerender-until-script mode solves exactly that. The browser builds the DOM, loads the CSS, fetches the fonts and downloads the images, then stops at the first blocking script and waits. Nothing executes until the user actually clicks.

Why this is the version to ship

Full prerendering gives you an instant navigation, and it also gives you a page that has already run every tag, timer, tracker, chat widget and personalisation script you have installed. That is where the mess comes from.

The damage is not limited to inflated pageviews. Session duration becomes meaningless, because the session started before the visit. Bounce logic breaks. Any script that writes on load, an A/B test assignment, a personalisation cookie, a lead-tracking identifier, fires against a visit that may never occur, so your experiment sample fills with people who never saw the variant.

The prerender-until-script mode draws the line in the right place. Everything expensive and script-free happens in advance. Everything with a side effect waits.

What you get and what you give up

You get the parse, the layout, the stylesheet, the web fonts and the images. On a typical marketing page that is the overwhelming majority of the time to first paint, because it is the network work, and network work is what a mobile connection is bad at.

You give up script execution time. When the user clicks, your JavaScript still has to run, so the navigation is fast rather than instantaneous. On a page with a light script payload the difference is barely perceptible. On a page shipping 800KB of JavaScript, you will feel it, and that is a signal about the JavaScript rather than about prerendering.

The honest summary: full prerender is faster, prerender-until-script is the one that survives contact with a marketing team.

The one thing that breaks it

If your hero image is inserted by JavaScript, or your above-the-fold content is client-side rendered, this mode gives you very little. The browser stopped before the script that builds your page, so it prerendered an empty shell.

That is worth checking before you implement anything. Disable JavaScript in DevTools and load your key landing pages. Whatever renders is roughly what gets prerendered. If you see a blank frame with a spinner, fix the rendering strategy first, because prerendering is not the lever that helps you.

Server rendered pages, static pages and pages built with a modern framework's default rendering will all prerender well. The pages that fail are usually the ones assembled entirely in the browser, and those pages have a bigger problem than speculation rules.

Configuration in practice

The rule sits alongside your other Speculation Rules and applies to whichever links you match. The usual shape is moderate eagerness against your primary navigation, so a hover of roughly 200ms starts the work, with the prerender-until-script mode set.

Three implementation notes that save time:

Order your head properly. Stylesheets and font preloads should be as early as possible, because they are what actually gets used during the prerender window. A stylesheet loaded by a script will not be picked up.

Watch for scripts that block earlier than you think. A synchronous script tag high in the head halts the prerender at that point, so everything below it, including your CSS, never loads. Move blocking scripts down, or make them async or defer.

Test with Chrome's Speculative Loads panel. DevTools shows every speculation, its status, and the reason for any that failed. The failure reasons are specific and readable, which is unusual for browser diagnostics, and they will tell you exactly which rule is being ignored.

What to measure afterwards

Do not report LCP alone. The interesting number is the gap between your prerendered navigations and your normal ones, segmented by device.

Compare conversion rate on sessions that arrived through a prerendered link against sessions that did not. If your analytics fires on activation, those sessions are cleanly separable, and that comparison is the business case. Speed work that cannot be tied to an outcome gets deprioritised at the next planning cycle, every time.

Also watch origin load. Prerendering means serving pages to people who may not visit, and while the volume is bounded, it is not zero. If your origin is already the constraint, fix that first.

The feature that lets you have the speed without the reporting damage has been sitting there, and the objection it removes is the one that has been killing the conversation.