Open a slow website and there is often a moment of blank white before anything appears. That gap is rarely the server being slow; more often it is the browser being told to wait. Certain resources — some scripts and stylesheets — block the browser from painting the page until they are downloaded and processed. They are called render-blocking resources, and taming them is one of the highest-impact performance wins available.
The browser is not being lazy. It is following the rules of how HTML, CSS and JavaScript interact, and those rules force it to pause.
Why the browser waits
When the browser parses your HTML and hits a stylesheet, it generally waits for that CSS before rendering, because painting content and then restyling it would cause an ugly flash of unstyled and then re-styled content. When it hits a plain script tag, it stops parsing entirely to download and run the script, because that script might rewrite the very HTML being parsed.
So a few large stylesheets in the head, or a pile of ordinary scripts before your content, can hold the whole page hostage. The user stares at white while the browser dutifully waits for resources that often have nothing to do with the first thing they need to see.
The fixes for scripts
Scripts have two magic attributes. Marking a script "defer" lets the browser keep parsing the page and run the script after the HTML is ready, in order — ideal for most application scripts. Marking it "async" lets it download in parallel and run whenever it arrives, good for independent third-party scripts like analytics. Either one stops the script from blocking the initial render.
The broader move is to ship less script up front and load non-critical code later, only when needed. Every kilobyte of JavaScript in the critical path is time the user spends looking at nothing.
The fixes for CSS
CSS is trickier because you genuinely need styles before painting, or the page flashes unstyled. The professional approach is to inline the small amount of "critical CSS" needed to render what is first visible, and load the rest of the stylesheet in a non-blocking way. Splitting giant global stylesheets and removing unused rules shrinks the blocking payload directly.
Measure before and after with your browser's performance tools, which flag render-blocking resources explicitly. Deferring scripts, trimming and inlining critical CSS, and shipping less up front routinely turn that second of blank white into an instant paint — and first impressions of speed drive whether people stay.
Why the browser blocks on CSS specifically, and why that is a deliberate choice
A stylesheet blocks rendering because the browser cannot safely paint any content without first knowing how it should look — rendering unstyled content and then immediately restyling it once CSS arrives would produce a visible, jarring flash as the page's appearance changes right in front of the user, which browsers deliberately avoid by holding off on the first paint until CSS in the current render path has been fully parsed and applied, treating a blank screen as a better experience than an ugly, briefly-unstyled flash.
Why scripts without async or defer block HTML parsing entirely, not just rendering
A plain `<script>` tag with no attribute at all does something more disruptive than blocking rendering: it pauses the HTML parser itself at the exact point the script tag appears, fetches the script if it is external, executes it fully, and only then resumes parsing the rest of the document — this happens because a script can call `document.write()` or otherwise modify the page in ways that would invalidate whatever the parser has already built if it kept going, so the specification requires this synchronous pause as a safety guarantee, which is exactly what `async` and `defer` exist to opt out of when a script does not actually need it.
Async versus defer: same non-blocking parse, different execution timing
Both attributes let the HTML parser continue without pausing while the script downloads in the background, but they differ in exactly when the downloaded script actually runs: an `async` script executes the moment it finishes downloading, whenever that happens to be relative to the rest of parsing, which can interrupt parsing at an arbitrary, unpredictable point; a `defer` script always waits until the entire HTML document has finished parsing before running, in the exact order the defer scripts appear in the markup — which is why `defer` is generally the safer default for scripts with dependencies on the DOM or on each other's execution order, while `async` suits independent scripts, like analytics snippets, that do not care when exactly they run relative to anything else.
Critical CSS: shipping only what the very first paint actually needs
A large, comprehensive stylesheet covering every page on a site blocks the very first render on styles that may not even apply to anything currently visible above the fold — the critical CSS technique extracts specifically the styles needed for the initial visible viewport, inlines that small subset directly into the page's `<head>` so it needs no separate network request at all, and loads the remaining, larger stylesheet asynchronously afterward for everything below the fold, trading a small amount of build-time tooling complexity for a first paint that is no longer gated on downloading and parsing styles the very first screen does not actually need.
Why `<link rel="preload">` exists alongside async and defer
Preloading tells the browser to start fetching a specific resource immediately, at a high priority, well before the parser would otherwise discover it — useful specifically for a resource the browser would not find until relatively late in parsing, like a font referenced only inside a stylesheet that has not finished downloading yet, or a hero image referenced via CSS `background-image` rather than an `<img>` tag the parser can see directly. This is a different tool from async or defer, which control when a discovered script executes; preload controls when the fetch itself begins, and the two concerns are frequently combined for the same resource in a well-tuned page.
Why third-party scripts are disproportionately likely to be the actual blocking culprit
An analytics tag, a chat widget, an ad script — none of these are usually written with the same performance discipline a team applies to its own first-party code, and a third-party script loaded without async or defer can block rendering just as thoroughly as any first-party script would, while being considerably harder to fix, since the actual source code is not under the site's own control at all; auditing exactly which third-party scripts are marked async or defer, and whether any of them are genuinely necessary to load before first paint at all, is frequently the single highest-leverage fix available on a page dominated by third-party embeds.
Why font loading has its own distinct blocking behavior worth knowing separately
A custom web font referenced in CSS does not block the initial render the way a render-blocking stylesheet does, but it can cause its own distinct problem — invisible text while the font downloads, or a visible flash as fallback text is replaced once the real font arrives — and the `font-display` CSS property controls exactly how this trade-off is handled, letting a page choose between showing fallback text immediately (`swap`) or holding text invisible briefly to avoid any visible font-swap flash (`block`), a choice worth making deliberately rather than accepting whichever a browser's own unconfigured default happens to be.
Why inlining small stylesheets entirely can sometimes beat even the critical-CSS technique
For a small site with a genuinely small total CSS footprint, inlining the entire stylesheet directly into the HTML document removes the separate network request for it altogether, which can be simpler and just as fast as extracting a critical subset the more elaborate technique described earlier requires — critical CSS extraction earns its added build complexity specifically once a stylesheet has grown too large to inline in full without itself becoming a meaningful part of the initial HTML payload's size.
Why the order of stylesheet and script tags in the head still matters even with async and defer
Even once scripts are correctly marked async or defer, render-blocking stylesheets still execute in the order they appear, and placing a large, rarely-needed stylesheet before a small, critical one delays the critical one's application for no good reason — ordering resource tags deliberately, smallest and most critical first, is a nearly free optimization that costs nothing but rearranging existing markup.
Why removing an unused stylesheet entirely beats optimizing its loading
Before reaching for async loading, critical CSS extraction, or careful tag ordering, it is worth confirming a given stylesheet is actually still needed at all — tools that detect unused CSS selectors across a site's actual pages routinely reveal that a meaningful fraction of a large stylesheet is dead weight from a redesign or feature nobody removed, and deleting that unused portion outright is both simpler and more effective than any technique for loading the same bloated file more cleverly.
Why a single build tool setting sometimes ships render-blocking code by accident
Modern bundlers can inadvertently produce a single, large combined CSS or JavaScript file spanning every route in an application rather than splitting per-page, which means visiting even the simplest page on a site can still block on downloading and parsing code needed only by an entirely different, unrelated page — checking a build's actual output for this kind of accidental over-bundling is worth doing explicitly, since it is a common, silent source of render blocking that has nothing to do with any of the markup-level techniques covered elsewhere in this article.
Why HTTP/2 server push was tried and largely abandoned for this exact problem
Server push, an HTTP/2 feature letting a server proactively send resources it expects a client will need before the client has even requested them, was proposed partly as a solution to render-blocking resource delays, but it was largely deprecated in major browsers after real-world use revealed it frequently pushed resources the browser's own cache already had, wasting bandwidth rather than saving time — the preload technique discussed earlier in this article achieves a similar goal more reliably, since it lets the client itself decide, with full knowledge of its own cache state, whether a fetch is actually needed.
Why a render-blocking audit should be part of every major redesign, not a one-time cleanup
A page carefully tuned to minimize render-blocking resources can quietly regress the very next time a redesign adds a new third-party widget or a new stylesheet without anyone revisiting the original optimization work — building a render-blocking check into a standard pre-launch checklist for every major page change, rather than treating the original optimization as a one-time project now considered finished, is what keeps the gains from eroding silently over subsequent redesigns.