Chromium Prerender Mechanism: Evolution, Prerender 2.0 Usage, Implementation Flow and Application Scenarios

Prerender (pre‑rendering) loads and parses page resources before the user opens the page, allowing near‑instant display when the navigation occurs.

Chromium previously supported Prerender 1.0 (2011‑2018) via the <link rel=\"prerender\" href=\"/next-page/\"> tag. Because this capability consumes considerable device resources, it was not widely adopted and was gradually deprecated. Its functionality was later incorporated into NoState Prefetch (NSP), which only pre‑loads critical resources without executing JavaScript or rendering the page.

Starting with Chromium M94, Prerender 2.0 was re‑introduced. This new version emphasizes higher accuracy and lower resource consumption, shortening load time, improving user experience and reducing power usage. Compared with Prerender 1.0, Prerender 2.0 is more flexible, intelligent and lightweight.

1. Multiple Page Architecture (MPArch) – MPArch uses a single WebContents model to manage multiple pages (visible or invisible). The WebContents and Page are not in a one‑to‑one relationship, which is ideal for features such as BFCache and Prerender that need to support several pages within the same tab. Prerender 1.0 created a new WebContents for each prerendered page (multi‑WebContents model), while Prerender 2.0 builds on MPArch and uses a single WebContents with multiple pages.

2. Speculation Rules API – The new API (https://github.com/WICG/nav-speculation/blob/main/triggers.md#speculation-rules) can trigger Prefetch, NSP and Prerender. To check browser support:

HTMLScriptElement.supports(
'speculationrules'
)

Example usage:

<script type=\"speculationrules\">
{
\"prerender\": [
{\"source\": \"list\", \"urls\": [\"next.html\", \"./PrefetchTestNew.html\"]}
],
\"prefetch\": [
{\"source\": \"list\", \"urls\": [\"next.html\"], \"requires\": [\"anonymous-client-ip-when-cross-origin\"]}
],
\"prefetch_with_subresources\": [
{\"source\": \"list\", \"urls\": [\"next.html\"], \"requires\": [\"anonymous-client-ip-when-cross-origin\"]}
]
}
</script>

The API defines the following parameters (see the original table):

prerender – use the prerender mechanism.

prefetch – preload only the main document.

prefetch_with_subresources – preload the main document plus key sub‑resources (similar to NSP).

requires – enables cross‑origin preloading when the client IP must remain anonymous; the value can only be \"anonymous-client-ip-when-cross-origin\" and is only valid for prefetch and prefetch_with_subresources .

Reasons for abandoning <link rel=prerender> :

The rule is already used by NoState Prefetch; forcing full prerender would increase resource consumption dramatically and may break sites.

The <link> rule has limited flexibility; it cannot express the requires parameter or handle multiple sites simultaneously.

The Speculation Rules API is more flexible and is expected to replace the <link> rule.

3. Detecting activation of a prerendered page

When activationStart > 0, the prerendered page was successfully activated.

Listen for the 'prerenderingchange' event.

// Method 1
let activationStart = performance.getEntriesByType('navigation')[0].activationStart;
// Method 2
let wasActivated = false;
document.addEventListener('prerenderingchange', (event) => {
wasActivated = true;
});

4. Implementation flow (based on Chromium M97)

Each prerendered page starts with PrerenderHost::StartPrerendering() , then proceeds to NavigationRequest::BeginNavigation . The subsequent logic follows the normal page‑load pipeline.

In the Browser thread, Chromium decides whether the navigation requires network handling. If so, a network request is issued to fetch the main document’s first packet. Regardless of network usage, the flow eventually reaches CommitNavigation , which transfers control to the Render thread.

On the Render thread, a Document and DocumentLoader are created. After the main document data arrives, parsing and rendering commence.

After prerendering completes, the page exists as a FrameTree owned by a PrerenderHost . The page is invisible to the user until a navigation matches the stored PrerenderHost (URL comparison). At that point, the stored page is activated, the previous page is moved to BFCache, and the prerendered page becomes visible.

5. Application scenarios

Prerender consumes significant device resources, so it should be used conservatively—only when the probability of navigation to a target page is high. Metrics such as the number of prerendered pages versus the number of actually activated pages can be used to calculate a hit‑rate and adjust the strategy.

Chromium combines prediction technology with Prerender 2.0. The chrome://predictors page shows confidence levels: >50 % triggers a pre‑fetch, >80 % triggers a prerender. Example screenshots illustrate how typing “b”, “ba”, “bai” leads Chromium to prerender https://www.baidu.com/ because of high confidence.

For search‑engine browsers, developers can build custom predictors and integrate them with Prerender 2.0 to improve search result page performance. For website owners, static <link rel=prerender> tags or dynamic insertion via JavaScript can be used for high‑traffic pages.

6. Conclusion

The article reviews the evolution of Chromium’s prerender mechanism, introduces Prerender 2.0, explains its usage, implementation flow and practical scenarios. While Chromium M97 (used by the Baidu app) still treats Prerender 2.0 as an early feature, ongoing work will continue to refine it. Developers are encouraged to monitor its development and apply it judiciously to improve page‑on‑screen performance.