Understanding Pre‑rendering and Speculation Rules in Modern Web Development

Hello everyone, I am ConardLi. Today we discuss pre‑rendering technology.

Pre‑rendering Technology

What is pre‑rendering? It means rendering a page in advance before the user actually visits it, so the page can be displayed instantly without extra rendering time.

In today’s most important web performance metric Core Web Vitals , Largest Contentful Paint (LCP) occupies a crucial position. LCP measures the render time of the largest visible element in the viewport.

When a page is visited, the browser first requests HTML from the server. The HTML response tells the browser to request further resources such as CSS , JavaScript , etc. Only after these resources are received does the browser perform the actual rendering.

Historically, pre‑rendering could be achieved in two ways:

1. Prefetch the next page’s resources. Chrome statistics show that about 40% of perceived latency is spent waiting for the first byte from the server, so pre‑fetching resources can greatly improve render performance.

<link rel="prefetch" href="/next-page/">

2. Prefetch resources and also start rendering them:

<link rel="prerender" href="/next-page/">

However, apart from Chrome, this approach is not widely supported and is not a powerful API.

Later Chrome introduced NoState Prefetch , which is similar to <link rel="prefetch" href="/next-page/"> but does not execute JavaScript.

NoState Prefetch can improve resource loading but does not provide the instant page load capability of full pre‑rendering.

Recently Chrome added a brand‑new full‑page pre‑rendering capability. To avoid complexity and allow future evolution, the new mechanism no longer uses <link rel="prerender"...> or NoState Prefetch syntax, and these may be disabled in some contexts.

Next‑Generation Pre‑rendering

Chrome’s new pre‑rendering works in three ways:

When you type a URL in the address bar, Chrome may predict the page you will visit and pre‑render it automatically.

When you type a keyword, Chrome may use search engine hints to pre‑render the predicted page.

This means that even before you click, the browser has already started rendering the page.

You can view Chrome’s URL predictions at chrome://predictors . Green indicates Chrome predicts > 80% chance you will visit the page, so it starts rendering. Yellow indicates a > 50% chance, so Chrome only prefetches resources.

How can we actively control pre‑rendering in web development? The Speculation Rules API allows programmers to tell Chrome which pages to pre‑render, replacing the old <link rel="prerender"...> syntax. Rules can be static JSON or injected dynamically via JavaScript.

Speculation Rules API

Data Prefetch

Add the following JSON to a page to prefetch next.html and next17.html :

<script type="speculationrules">
  {
    "prefetch": [
      {
        "source": "list",
        "urls": ["next.html", "next17.html"]
      }
    ]
  }
</script>

Prefetch rules only fetch the HTML documents, not their sub‑resources.

Unlike the old <link rel="prefetch"> which stores data in the HTTP cache, Speculation Rules keep prefetched data in memory, allowing faster access when needed.

In the Network panel you can see requests made by Speculation Rules. They have the resource type prefetch and include the header Sec-Purpose: prefetch , which servers can use to identify these requests.

The Application panel now has a Preloading section that shows the configured speculation rules and which pages have been prefetched.

Opening a page that appears in the rules confirms it was successfully prefetched.

Full Page Pre‑render

To perform full page pre‑rendering, add similar JSON with a prerender key:

<script type="speculationrules">
  {
    "prerender": [
      {
        "source": "list",
        "urls": ["next.html", "next17.html"]
      }
    ]
  }
</script>

Currently browsers only support prerendering pages on the same origin, e.g., https://1.conardli.com can prerender https://17.conardli.com . Cross‑origin prerendering requires the target page to send a Supports-Loading-Mode: credentialed-prerender header.

Unlike prefetch, prerender requests are not visible in the Network panel because they are handled in a separate rendering process.

Debugging prerendered pages must be done via the Application → Preloading panel.

Combined Rules

A page can configure multiple speculation rules simultaneously:

<script type="speculationrules">
{
  "prefetch": [
    { "source": "list", "urls": ["data-prefetch17.html"] }
  ]
}
</script>
<script type="speculationrules">
{
  "prerender": [
    { "source": "list", "urls": ["prerender17.html"] }
  ]
}
</script>

Rules can also be expressed as arrays, allowing up to ten prerendered sub‑pages per page.

Note: Browsers currently limit a page to a maximum of 10 prerendered sub‑pages.

Dynamic JavaScript Injection

Static JSON works for pages with fixed content, but most sites are dynamic. You can add rules at runtime with JavaScript:

// Check if the browser supports speculationrules
if (HTMLScriptElement.supports && HTMLScriptElement.supports('speculationrules')) {
  const specScript = document.createElement('script');
  specScript.type = 'speculationrules';
  const specRules = {
    prerender: [
      {
        source: 'list',
        urls: ['/17.html']
      }
    ]
  };
  specScript.textContent = JSON.stringify(specRules);
  console.log('Adding prerender rule: 17.html');
  document.body.append(specScript);
}

Conclusion

What do you think of this technology? Feel free to leave comments.

References:

https://developer.chrome.com/blog/prerender-pages

https://developer.chrome.com/blog/debugging-speculation-rules/

https://developer.chrome.com/blog/nostate-prefetch/

https://github.com/jeremyroman/alternate-loading-modes/blob/main/triggers.md#speculation-rules

https://github.com/WICG/nav-speculation/