# What is Render-blocking resources? > Render-blocking resources are CSS and JavaScript files the browser must download and process before it can display any content on the page. URL: https://yes-seo.com/glossary/render-blocking **Render-blocking resources** are files the browser has to fetch and process before it can paint anything on screen. While they load, the visitor stares at a blank page — even though the HTML has already arrived. ## Which resources block rendering - **Stylesheets** linked in the head. By default, the browser won’t paint until it has the CSS, to avoid showing unstyled content. - **Classic scripts** without `async`, `defer` or `type="module"`. These block the HTML parser itself: the browser stops building the page, downloads the script, runs it, then carries on. - **Web fonts**, indirectly. Text styled with a font that hasn’t loaded can stay invisible for up to three seconds in most browsers. Every blocking file adds at least one network round trip before the first paint, and on mobile networks round trips are expensive. That delay feeds straight into [Largest Contentful Paint](https://yes-seo.com/glossary/lcp). ## Before and after ``` - /* critical above-the-fold CSS, a few KB */ ``` What changed: `defer` downloads the script in parallel and runs it after parsing, in document order — the safe default for your own scripts ([MDN: the script element](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/script)). - `async` runs a script as soon as it arrives, in no particular order — fine for independent third-party tags. - Inlining the critical CSS lets the first screen paint immediately. A stylesheet whose `media` doesn’t match, like `print`, downloads without blocking; the `onload` switch then applies it to the screen. ## Common mistakes - **Deferring a library that inline code depends on**, which produces errors such as “jQuery is not defined”. - **Using async for scripts that depend on each other.** Execution order isn’t guaranteed. - **Deferring all CSS**, which causes a flash of unstyled content and layout shifts. Something has to style the first screen. - **Third-party fonts without `preconnect`**, adding DNS and TLS time to the critical path. - **Polishing your own files** while a consent banner or A/B testing script in the head blocks everything. Some testing tools block on purpose to prevent flicker; weigh that cost honestly. ## How to prioritize Start with whatever sits in the `` and is not needed for the first screen. Third-party tags are often the easiest wins: many don’t need to run before the visitor sees anything. Then shrink the CSS that remains blocking — unused rules from a theme or framework are common — so the critical path carries only what the first view needs. ## Find them on your page The [page speed test](https://yes-seo.com/page-speed-test) lists the render-blocking scripts and stylesheets on your page together with the number and weight of scripts and styles, so you know exactly which tags to defer, inline or remove. For the bigger picture, see [page speed](https://yes-seo.com/glossary/page-speed). ## Frequently asked questions ### Is all CSS render-blocking? Stylesheets linked in the head with a media type that matches the screen are render-blocking by default. Stylesheets for non-matching media, such as print, are downloaded with low priority and don’t block the first paint. ### What is the difference between defer and async? Both download scripts without blocking the parser. Deferred scripts run after the HTML is parsed, in the order they appear; async scripts run as soon as they finish downloading, in any order. ### Do render-blocking resources affect SEO? Indirectly. They delay the first paint and LCP, which are part of Core Web Vitals and page experience. Fixing them mostly helps users, which is where the business value lies.