What is Render-Blocking Resources?
Render-blocking resources are CSS and JavaScript files that the browser must download and process before it can display a page. Reducing or deferring render-blocking resources speeds up first paint.
Why Render-Blocking Resources matters
A browser cannot paint anything until it has the CSS it needs, and by default a synchronous script tag in the head stops HTML parsing until the script has downloaded and run. Every such file in the critical path is a render-blocking resource, and each one adds its download and execution time to the moment the visitor sees a first pixel. On a slow mobile connection, four blocking files can mean seconds of white screen.
The remedies are well established: inline the small amount of CSS needed for the first screen and load the rest asynchronously, mark scripts defer or async unless they truly must run before render, self-host fonts and let text render with a fallback, and drop stylesheets that the first screen never uses.
Example
Loading scripts without blocking the parser:
<script src="/app.js" defer></script>
<script src="https://www.googletagmanager.com/gtag/js?id=G-XXXX" async></script>
<link rel="preload" href="/fonts/body.woff2" as="font" type="font/woff2" crossorigin>defer keeps execution order; async runs as soon as it arrives, which suits analytics.
Common mistakes
- •A synchronous jQuery plugin bundle in the head on every page.
- •Loading a 300 KB CSS framework when the page uses a fraction of it.
- •Font stylesheets from a third-party origin with no preconnect.
How Webmatik checks it
The Files blocking page display check reads Lighthouse's render-blocking resources audit and lists the CSS and JavaScript files that delay the first paint, with the estimated savings.
Check your own site
Free Website Speed Test
See your LCP, CLS and INP on mobile and desktop, with the fixes ranked by payoff.
Related Performance terms
See how your website scores across SEO, GEO, performance, and more
Run a free audit