What is the browser's preload scanner (also called the speculative or lookahead parser), and which resources on a page can it not discover?

## The problem it solves HTML parsing is not a smooth process. The main parser stops whenever it hits a classic synchronous script, because that script can modify the document it is being parsed into. In the early days of the web that stall meant the network went quiet too — the browser knew nothing about the twelve images and three stylesheets sitting further down the document, because it had not read that far. The preload scanner exists to remove that dead air. It is a second parser, deliberately dumb and fast, that runs over the raw bytes ahead of the main parser's position. ## What it actually does The scanner tokenizes markup looking only for attributes that name a resource — chiefly `src` on `<img>` and `<script>`, `href` on `<link>`, plus related ones like `srcset` and `poster`. When it finds one it starts the fetch immediately, so by the time the main parser reaches that element the bytes are already in flight or in the cache. What it explicitly does **not** do: - It does not construct DOM nodes. - It does not execute scripts or evaluate CSS. - It does not run the cascade, so it has no idea which elements will be visible. It is a speculative optimisation. If the main parse later diverges — a script rewrites part of the document — some of those fetches were simply wasted bandwidth, which is a trade the browser accepts. ## What it cannot see This is the interview-relevant half, because it explains a whole class of "why did my hero image start downloading so late" bugs. **Resources referenced from CSS.** A `background-image` URL lives inside a stylesheet, which the scanner does not parse. That image cannot even be discovered until the stylesheet has been downloaded and the CSSOM built, and the element that uses it has been matched. Two serialised round trips before the request starts. **Anything injected by JavaScript.** An image element created with `document.createElement('img')` and given a `src` in a bundle does not exist in the markup at all. The download begins after the bundle has downloaded, parsed and executed. For a client-rendered app, this is why the largest image on the screen is often the last request to start. **URLs assembled at runtime.** `img.src = base + '/' + id + '.jpg'` is not a URL in the source; it is string concatenation. There is nothing for a byte scanner to match. **Lazy-loading patterns that hide the address.** The classic library idiom writes `data-src="real.jpg"` and swaps it into `src` from script. That deliberately defeats the scanner, which is the point for below-the-fold images and a serious own-goal for above-the-fold ones. Note that the native `loading="lazy"` attribute is different — the real URL stays in `src`, and the browser itself decides when to fetch. **Imports inside CSS.** An `@import` in a stylesheet is invisible for the same reason `background-image` is: it lives in a file the scanner never reads. ## Putting the URL back where it can be seen The standard repair is a preload hint in the head: ```html <link rel="preload" as="image" href="/hero.jpg" fetchpriority="high"> <link rel="preload" as="font" href="/inter.woff2" type="font/woff2" crossorigin> ``` This is a real URL in the markup, so the scanner finds it in the first bytes of the document and starts the fetch immediately; the response is then waiting in the memory cache when CSS or JS finally asks for it. The `as` attribute is not optional cosmetics — it sets the request's destination, and therefore its priority and its CORS handling. Fonts always need `crossorigin` because font fetches are made in CORS mode, and a mismatch causes the resource to be downloaded twice. Preload hints are a scarce resource: every hint you add competes for bandwidth with the things the scanner would have found anyway. A handful of genuinely critical, otherwise-invisible resources is the right dose. ## How to observe it In a network waterfall, scanner-discovered requests all start very near the beginning of the document download, in a cluster, even when the elements they belong to are far down the page. A resource that starts only after a script or stylesheet has finished is one the scanner missed — and that gap is the cost you are being asked to explain.