Render-blocking resources are CSS and JavaScript files that the browser must download and process before it can paint any pixels on screen. They delay First Contentful Paint and Largest Contentful Paint, drag down Core Web Vitals, and make a site feel slow. You eliminate them by deferring non-critical scripts, inlining critical CSS, and loading the rest asynchronously.
What Render-Blocking Resources Are
When a browser parses an HTML document, it builds the page from top to bottom. The moment it encounters a stylesheet link or a synchronous script tag in the head, it stops constructing the page and waits. CSS blocks rendering because the browser refuses to paint content it cannot style correctly. JavaScript blocks rendering because a script could modify the document structure, so the parser pauses until the script downloads and executes.
The result is a blank screen while the browser works through these blocking resources. On a fast connection the delay might be small, but on mobile networks, where most traffic now originates, every blocking request adds round trips that visitors feel as lag. The goal is not to remove CSS and JavaScript, but to control when and how they load so the critical content paints first.
Why Render-Blocking Resources Hurt Core Web Vitals and Conversions
First Contentful Paint and Largest Contentful Paint are both delayed by render-blocking resources, and both feed directly into how Google evaluates your page. A page that holds a blank screen for two seconds while a stylesheet loads will score poorly no matter how good the content is. Since Core Web Vitals influence rankings, blocking resources cost you visibility as well as speed.
The conversion impact is immediate. Visitors form an impression of speed in the first few hundred milliseconds, and a blank or unstyled flash erodes trust before they read a word. For lead generation and e-commerce sites the math is unforgiving, where slower paint times correlate with higher bounce rates and lower form completions. Our guide on Largest Contentful Paint goes deeper on how paint timing maps to the metrics Google reports.
CSS Versus JavaScript Blocking
The two block differently. All external CSS is render-blocking by default, because the browser builds the render tree from styles before painting. JavaScript in the head is parser-blocking unless you add async or defer. Understanding which type you are dealing with determines the fix.
How to Diagnose Render-Blocking Resources
Both Google’s free tools call these out explicitly, so diagnosis is straightforward.
- Lighthouse: Run an audit and look for the “Eliminate render-blocking resources” opportunity. Lighthouse lists every blocking file and estimates the milliseconds you would save by deferring it.
- PageSpeed Insights: The same audit appears with field data attached, so you can confirm whether real visitors experience the delay or whether it is only showing in a lab run.
- DevTools Network panel: Reload with the network tab open and watch the waterfall. Resources that load before the first paint marker and sit on the critical path are your blockers.
- Coverage tab: Chrome’s Coverage panel shows how much of each blocking CSS or JavaScript file is actually used on the page, which helps you decide what to inline versus defer.
Concrete Fixes for Render-Blocking Resources
1. Defer Non-Critical JavaScript
Add the defer attribute to script tags so they download in parallel but execute only after the HTML is parsed. Use async for independent scripts like analytics that do not depend on the document or each other. The difference: defer preserves execution order and waits for parsing to finish, while async runs as soon as each script arrives.
<script src="/app.js" defer></script>
2. Inline Critical CSS
Extract the minimal CSS needed to style above-the-fold content and place it directly in the head as an inline style block. The browser can then paint the visible portion immediately without waiting for an external stylesheet. Load the full stylesheet asynchronously afterward. Our deep dive on critical CSS walks through how to identify and extract that critical subset.
3. Load Remaining CSS Asynchronously
For stylesheets beyond the critical set, use a pattern that loads the file without blocking. The common approach swaps the media attribute on load:
<link rel="stylesheet" href="/full.css" media="print" onload="this.media='all'">
This tricks the browser into treating the file as non-blocking print styles until it loads, then applies it to all media.
4. Minify and Compress
Minify CSS and JavaScript to strip whitespace and comments, and serve everything with Brotli or Gzip compression. Smaller files spend less time on the critical path even when they cannot be deferred.
5. Self-Host or Preconnect to Fonts
Web fonts loaded from a third-party domain add render-blocking requests and connection setup time. Self-host fonts where possible, or add a preconnect hint to warm the connection early. Pair this with font-display: swap so text renders in a fallback font immediately rather than blocking on the web font.
Render-Blocking Fix Checklist
- Add
deferorasyncto every script in the head - Inline the critical CSS for above-the-fold content
- Load the remaining CSS asynchronously
- Minify and compress all CSS and JavaScript
- Preconnect to font and asset domains, use
font-display: swap - Re-run Lighthouse and confirm the render-blocking warning is gone
How Modern Stacks Handle Render-Blocking Resources
Next.js
Next.js optimizes the critical path automatically. Its font system inlines font CSS and preloads files to avoid layout-shifting and blocking. The script component lets you set loading strategies so third-party scripts load after the page is interactive rather than blocking it. Server-rendered HTML means the meaningful content paints before any client JavaScript runs.
Framer
Framer ships sites that are already engineered against render-blocking by default. Critical styles are handled at the platform level, scripts are loaded with sensible strategies, fonts are optimized, and everything is served from a global CDN. You do not edit head tags or wire up async loading patterns by hand, which removes an entire category of performance regressions. This is a core reason Framer sites tend to clear Core Web Vitals thresholds without a dedicated performance engineer. For the broader picture, see our website speed optimization guide.
| Technique | Manual stack | Framer |
|---|---|---|
| Critical CSS | Extract and inline by hand | Handled automatically |
| Script deferral | Add attributes manually | Optimized defaults |
| Font loading | Configure preconnect and swap | Built in |
| CDN delivery | Set up separately | Included |
A Step-by-Step Workflow to Unblock Rendering
Knowing the techniques is one thing; applying them in the right order on a live site is another. Here is the sequence that produces the fastest visible improvement with the least risk of breaking the page.
Begin with a baseline measurement. Run Lighthouse and PageSpeed Insights on your key pages and write down First Contentful Paint, Largest Contentful Paint, and the list of flagged render-blocking resources. The flagged list is your work queue, ordered roughly by potential time saved.
Tackle JavaScript first, because it is the lowest-risk change. Add defer to application scripts and async to independent third-party scripts in the head. This rarely breaks anything when scripts are well written, and it immediately removes parser-blocking delays. Test interactivity afterward to confirm nothing depended on synchronous execution order.
Move to CSS next, which is more delicate because mishandling it causes a flash of unstyled content. Extract the critical CSS for above-the-fold content, inline it in the head, and load the full stylesheet asynchronously. Verify visually on both mobile and desktop that the above-the-fold view paints correctly before the full stylesheet arrives. Our dedicated critical CSS guide covers the extraction step in depth.
Then address fonts, a frequently overlooked blocker. Self-host where you can, preconnect to font origins you cannot, and apply font-display: swap so text appears in a fallback immediately. This prevents the invisible-text delay that hurts both First Contentful Paint and perceived speed.
Finish by minifying, compressing, and re-testing. Confirm the render-blocking audit is clear and, more importantly, that field data improves over the following weeks. A clean lab score that does not reach real users means the work is not done. Treat the Chrome User Experience Report as the source of truth, since it reflects the devices and networks your actual audience uses.
Eliminating render-blocking resources is one of the fastest ways to lift First Contentful Paint and improve rankings. If you would rather start from a platform that handles this automatically than chase Lighthouse warnings on a legacy build, take a look at our recent work or reach out through our contact page.
Frequently Asked Questions
What is the difference between async and defer?
Both let a script download without blocking HTML parsing. The async attribute runs each script as soon as it finishes downloading, in no guaranteed order, which suits independent scripts like analytics. The defer attribute waits until the HTML is fully parsed and runs scripts in document order, which suits application code that depends on the page or on other scripts.
Is all CSS render-blocking?
External CSS loaded with a standard stylesheet link is render-blocking by default because the browser needs styles before it paints. You can make non-critical CSS non-blocking by inlining the critical subset and loading the rest asynchronously, or by scoping a stylesheet to a media query that does not match the current device.
Does Framer have render-blocking resources?
Framer is built to minimize render-blocking out of the box. Critical styles, script loading strategies, font optimization, and CDN delivery are handled at the platform level, so a standard Framer site typically passes the Lighthouse render-blocking audit without manual intervention.