[Atomic Glue](atomicglue.co)
PERFORMANCE
Home › Glossary › Performance· 340 ·

Render-Blocking Resource

/ˈrɛndər ˈblɒkɪŋ rɪˈzɔːrs/n.
Filed underPerformanceFront End
In brief · quick answer

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

Lighthouse flags render-blocking resources in its 'Eliminate render-blocking resources' audit. The fix: inline what is critical, defer what is not.

§ 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.
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.
How Atomic Glue helps

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 touch
# 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.

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

## Related entries


Last updated July 2026. Permalink: atomicglue.co/glossary/render-blocking-resource

Schedule a call

30 min · Video call

1
Date
2
Time
3
Details