Render-Blocking Resource
A CSS or JavaScript file that the browser must fully download and process before it can render any content to the screen. The most common performance bottleneck on the web.
§ 1 Definition
Render-blocking resources prevent the browser from painting pixels until they are fully fetched and processed. CSS is render-blocking by default: the browser blocks rendering until the CSS Object Model (CSSOM) is constructed. JavaScript is both render-blocking (if inline or external before CSS) and parser-blocking (it pauses HTML parsing). The browser must wait for all blocking resources before performing the first paint.
§ 2 Types of Blocking Resources
CSS: Every external stylesheet in the <head> is render-blocking by default. JS: Every <script> (inline or external) without defer or async blocks HTML parsing. Scripts that appear after CSS also block CSSOM construction. The browser's preload scanner can discover some resources early, but it cannot overcome blocking behavior.
§ 3 Common Misunderstandings
Async does NOT eliminate render blocking. Async scripts still execute as soon as they load, which can block rendering if they load early. Defer is safer for scripts that are not needed before the page renders. Also, render-blocking is not just about CSS/JS: @font-face declarations that are in external stylesheets add additional blocking time because the font download delays text rendering.
§ 4 Optimization
Inline critical CSS (above-the-fold styles) in a <style> tag in the <head>. Defer non-critical CSS with media=print or by dynamically loading it. Use defer for non-critical scripts. Use async for scripts that don't depend on DOM or other scripts. Remove unused CSS and JS. Preload key resources like fonts and LCP images.
§ 5 Note
§ 6 In code
<!-- Inline critical CSS, defer non-critical -->
<style>header{display:flex}.hero{width:100%}</style>
<link rel="stylesheet" href="non-critical.css" media="print" onload="this.media='all'">
<!-- Defer non-critical JS -->
<script src="app.js" defer></script>§ 7 Common questions
- Q. Are all CSS files render-blocking?
- A. Yes, by default. But CSS with media=print or other media queries that don't match the current device are marked as non-render-blocking by the browser.
- CSS is render-blocking by default.
- JS blocks HTML parsing.
- Inline critical CSS; defer non-critical.
- Use defer/async for scripts.
- Critical bottleneck for FCP and LCP.
Atomic Glue identifies render-blocking resources through Lighthouse and field data, then implements inline critical CSS, deferred scripts, and preload strategies. Web Development services.
Get in touchA CSS or JavaScript file that the browser must fully download and process before it can render any content to the screen. The most common performance bottleneck on the web.
Category: Performance (also: Front End)
Author: Atomic Glue Performance Team
## Definition
Render-blocking resources prevent the browser from painting pixels until they are fully fetched and processed. CSS is render-blocking by default: the browser blocks rendering until the CSS Object Model (CSSOM) is constructed. JavaScript is both render-blocking (if inline or external before CSS) and parser-blocking (it pauses HTML parsing). The browser must wait for all blocking resources before performing the first paint.
## Types of Blocking Resources
CSS: Every external stylesheet in the <head> is render-blocking by default. JS: Every <script> (inline or external) without defer or async blocks HTML parsing. Scripts that appear after CSS also block CSSOM construction. The browser's preload scanner can discover some resources early, but it cannot overcome blocking behavior.
## Common Misunderstandings
Async does NOT eliminate render blocking. Async scripts still execute as soon as they load, which can block rendering if they load early. Defer is safer for scripts that are not needed before the page renders. Also, render-blocking is not just about CSS/JS: @font-face declarations that are in external stylesheets add additional blocking time because the font download delays text rendering.
## Optimization
Inline critical CSS (above-the-fold styles) in a <style> tag in the <head>. Defer non-critical CSS with media=print or by dynamically loading it. Use defer for non-critical scripts. Use async for scripts that don't depend on DOM or other scripts. Remove unused CSS and JS. Preload key resources like fonts and LCP images.
## Note
Lighthouse flags render-blocking resources in its 'Eliminate render-blocking resources' audit. The fix: inline what is critical, defer what is not.
## In code
<!-- Inline critical CSS, defer non-critical -->
<style>header{display:flex}.hero{width:100%}</style>
<link rel="stylesheet" href="non-critical.css" media="print" onload="this.media='all'">
<!-- Defer non-critical JS -->
<script src="app.js" defer></script>## Common questions
Q: Are all CSS files render-blocking?
A: Yes, by default. But CSS with media=print or other media queries that don't match the current device are marked as non-render-blocking by the browser.
## Key takeaways
- CSS is render-blocking by default.
- JS blocks HTML parsing.
- Inline critical CSS; defer non-critical.
- Use defer/async for scripts.
- Critical bottleneck for FCP and LCP.
## Related entries
- [Critical Rendering Path](atomicglue.co/glossary/critical-rendering-path)
- [FCP (First Contentful Paint)](atomicglue.co/glossary/fcp-first-contentful-paint)
- [LCP (Largest Contentful Paint)](atomicglue.co/glossary/lcp-largest-contentful-paint)
- [Preload / Prefetch / Preconnect](atomicglue.co/glossary/preload-prefetch-preconnect)
Last updated July 2026. Permalink: atomicglue.co/glossary/render-blocking-resource