What blocks the parser and the first paint.

Copperpot, the kitchenware shop we follow through this card, has a product page for an enamel casserole. Open it on a mid-range phone over 4G and the server has sent every byte of HTML by 0.42 s. The screen stays white until 1.22 s, and even then the name, the price and the details are missing for another 0.3 s: the boxes are laid out, the bullets are there, the words are not. Nothing was slow to draw. The browser spent most of that second waiting, because the page told it to.

Each wait exists for a good reason. Painting before the stylesheet arrives would show raw, unstyled HTML and then jump, so the browser holds the first paint until the stylesheets it has seen in the head are ready: they are render-blocking. A plain script tag may call document.write or read a style and expect the page as it stands at that line, so the parser stops, fetches the script, waits for any pending stylesheet the script might read, runs it, and only then reads on: the script is parser-blocking. A heading set in a web font could flash from one typeface to another, so by default the browser draws that text invisibly for up to a few seconds while the font downloads.

Most pages do not need all of those protections for all of their resources. A print stylesheet cannot affect the screen. An analytics script does not care where the parser is. The app's own bundle only needs the finished DOM. Attributes such as media, async and defer tell the browser which waits it may skip, and a second, speculative parser starts downloads early even while the main one is stuck. This topic is about who waits for whom, and how to change it.

The HTML Standard keeps a list on every document: the elements it is waiting for before it may render. A stylesheet link or a style element that the parser creates joins that list if its media attribute matches the current screen, and leaves it once the sheet and the resources it needs to be applied have loaded. While the list has anything in it, or while the document has no body element yet, the document is render-blocked: rendering opportunities come and go and the browser skips them. Browsers also keep a safety timeout of their own choosing, so a stylesheet that never finishes cannot hold the page back for ever.

Two details follow from that wording. First, elements can only join the list while there is no body yet, so it is the head's stylesheets that gate the first paint. Second, the media check is made against the environment right now: media=print, or a min-width the phone does not reach, means the sheet is still downloaded, at a low priority, but it blocks nothing.

The same matching, parser-created stylesheets also block scripts. Any plain or deferred script waits until no such sheet is still loading, because the script might read a computed style or a box size, and an answer based on half the CSS would be wrong. That is why a tiny inline script placed after a stylesheet link is not free: it cannot run, and the parser cannot move past it, until the stylesheet has arrived. Moving the inline snippet above the link, when it does not read styles, removes that wait.

A script tag with a src and no async or defer is parser-blocking. When the parser reaches it, it stops building the DOM, waits for the file to download, waits for any stylesheet that blocks scripts, runs the script, and only then reads the next tag. An inline script skips the download but not the rest. In the head this also means no body exists yet, so nothing can paint while the parser is stopped there.

Two attributes change the deal for external scripts. async says: download alongside the parser and run the moment you arrive, whenever that is. The parser is only paused while the script actually runs, but the order between async scripts is whatever order the downloads finish in, and an async script does not wait for stylesheets. defer says: download alongside the parser, then run after parsing has finished, in the order the tags appear, before DOMContentLoaded. A deferred script does wait for script-blocking stylesheets, so it always sees the page's styles.

Module scripts (type=module) are deferred without being asked, and the defer attribute does nothing on them; add async to make a module run as soon as it and its imports are ready. Inline classic scripts ignore both attributes. Scripts that other scripts insert with createElement are async by default; setting script.async = false on them makes a group of injected scripts run in the order they were inserted, which is how loaders keep dependencies in line without blocking the parser.

If a stopped parser were the whole story, every file after a plain script would start downloading only once that script had run, and a head with three scripts would cost three round trips in a row. Browsers avoid that with a speculative parser, usually called the preload scanner. While the real parser is stuck, it reads on through the raw HTML that has already arrived, recognises URLs in tags it knows (img src and srcset, stylesheet links, script src, preload links) and starts those downloads. It builds nothing and runs nothing; it only gets the bytes moving.

That is why vendor.js, product.js and Copperpot's hero photo were all requested at about 320 ms in the sequence above, even though the parser did not reach them until much later. The scanner can only see what is written in the HTML, though. Anything that a script adds, anything named only inside CSS, and anything hidden in a data attribute for a lazy loader is invisible to it, and waits for the stage that does see it.

A web font is not render-blocking in the stylesheet sense. Its @font-face rule only says where the file is; the browser downloads it once styles show that text on the page actually uses it, which means after the CSS has been parsed and usually around the first layout. That makes fonts late by design, and the preload scanner cannot help, because the URL lives in CSS.

What happens to the text meanwhile is set by a timeline in CSS Fonts Level 4. During the block period, text that wants the font is laid out and drawn with an invisible fallback, so the space is there but the words are not. During the swap period it is drawn in a visible fallback and swapped when the font lands. After that comes the failure period: the fallback stays. Chromium-based browsers and Firefox use a block period of up to 3 s by default (font-display: auto behaves like block there). The font-display descriptor sets the two periods: block keeps that short block (about 3 s) and an unlimited swap period; swap has almost no block period and an unlimited swap period; fallback a block of about 100 ms and a swap of about 3 s; optional the tiny block and no swap period at all, so a font that misses it is not used on this page view. Which one to choose, and how to get the file earlier, are covered in Resource hints, priorities and fonts.

Sometimes the default is too lenient. A deferred or module script that sets a theme class, or picks the variant of an experiment, would cause a visible flash if the page painted before it ran. The blocking attribute with the value render, on a script, link or style element in the head, puts that element on the render-blocking list without making it parser-blocking. The parser keeps going; only the paint waits. It is supported in Chrome and Edge 105 and later and Safari 18.2 and later, and not in Firefox as of September 2026, where the page simply paints without waiting, so it must stay an improvement rather than a requirement.