How Chromium's Preload Scanner Discovers External Resources

This article provides a complete overview of how Chromium's preload scanner operates to accelerate web page loading. It explains why the main HTML parser frequently gets blocked, how the preload scanner activates during these pauses, the lightweight tokenization method it uses to read raw HTML ahead of time, and how it triggers speculative network requests for critical external resources like scripts, stylesheets, and images before the main parser ever reaches them.

The Bottleneck of the Main HTML Parser

When Chromium loads a webpage, the main HTML parser reads the markup from top to bottom to construct the Document Object Model (DOM). However, this process is frequently interrupted. When the main parser encounters a synchronous <script> tag, it must halt DOM construction, wait for the resource to download, and execute the code. This pause is required because the script might use document.write() or otherwise alter the HTML structure. While the main parser waits, it is completely blind to any HTML that follows the blocking script, which would normally leave the network idle.

Activation of the Preload Scanner

To eliminate this idle network time, Chromium utilizes a secondary, speculative parser called the preload scanner (implemented as HTMLPreloadScanner in Chromium's Blink rendering engine). The exact moment the main HTML parser is blocked by a script, the preload scanner steps in. It takes the raw, unparsed chunks of HTML bytes that have already arrived from the network and begins scanning the markup ahead of the paused main parser.

Fast, Lightweight Tokenization

The preload scanner can read ahead quickly because it performs only the bare minimum work required to find URLs. Unlike the main parser, the preload scanner does not build a DOM tree, does not execute JavaScript, and does not construct the CSS Object Model (CSSOM).

Instead, it runs a stripped-down HTML tokenizer over the raw text. This tokenizer breaks the HTML into basic chunks, looking almost exclusively at start tags and their attributes. By ignoring tree construction, layout rules, and deep syntax validation, the preload scanner can process thousands of lines of HTML in a fraction of a millisecond.

Identifying and Fetching Resources

As the tokenizer moves through the raw HTML, the preload scanner inspects the generated tokens for specific tags that reference external files. It specifically hunts for:

  • <script> tags with a src attribute.
  • <link> tags with rel="stylesheet" or rel="preload".
  • <img> tags with src or srcset attributes.
  • <video> tags with a poster attribute.
  • CSS @import rules within inline <style> blocks.

When the scanner identifies one of these tokens, it extracts the URL and immediately hands it off to Chromium's ResourceFetcher. The browser's network stack then initiates a speculative background download for the file, prioritizing the requests based on resource type (for example, fetching CSS and scripts at a higher priority than images).

Context-Aware Scanning

Although the preload scanner does not build a DOM tree, it is not entirely blind to document context. If it were completely stateless, it might download the wrong files. To prevent wasted bandwidth, the scanner maintains a lightweight internal state to track specific tags that affect how URLs are resolved:

  • <base> tags: The scanner notes the href attribute of base tags so it can accurately resolve relative URLs found later in the document.
  • <meta name="viewport">: It reads viewport configurations to understand the intended screen dimensions.
  • <picture> and srcset: By combining its knowledge of the viewport with <source> media queries, the scanner accurately selects and preloads the correct responsive image size for the user's device.
  • <template> tags: The scanner tracks when it enters and exits a template tag so it does not accidentally preload inert resources that are not meant to be rendered immediately.

Handoff to the Main Parser

Once the blocking script finishes downloading and executing, the preload scanner pauses, and the main HTML parser resumes building the DOM. As the main parser moves down the document and finally reaches the <script>, <link>, or <img> tags that the preload scanner discovered earlier, it requests those files. Because the preload scanner already initiated the network requests, the files are either already sitting in the browser's memory cache or are currently in flight, drastically reducing the overall page load time.