Run a PageSpeed Insights test and you’ll likely see the warning: “Eliminate render-blocking resources”, usually followed by a long list of CSS and JavaScript files supposedly costing you seconds.
The warning is real, but the fix is widely misunderstood. Most people either ignore it or flip every toggle at once and break their site. This guide walks through the 2026 method: what render-blocking means, defer vs delay vs async, critical CSS, what each plugin actually does, and how to apply it all without breaking your layout.
The short version: make your critical CSS load first (inline it), defer or delay your JavaScript, and exclude anything that breaks. Do it in that order, testing after each step.
What “Render-Blocking” Actually Means
When a browser loads your page, it reads the HTML top to bottom and builds the visible page as it goes. The moment it hits a CSS file or a JavaScript file in the <head>, it stops rendering until that file is downloaded and processed. The browser can’t paint the page until it knows how the page should look (CSS), and it can’t safely continue if a script might change the page (JS).
Those files are “render-blocking”: nothing visible appears until they’re handled. A typical WordPress <head> holds stylesheets and scripts from the theme, page builder, plugins, fonts, and analytics, sometimes dozens of them, each one delaying the first paint.
There are two honest fixes: reduce what loads (fewer, smaller files) and reorder what loads (critical first, the rest later). Most guides only cover reordering, yet the biggest wins usually come from reducing first.
The Three Offenders
1. CSS files
Every stylesheet in your <head> blocks rendering. Themes, page builders (Elementor, Divi, WPBakery), and plugins pile them on. A page-builder site can easily load 10+ CSS files before the browser paints a single pixel.
2. JavaScript files
Scripts in the <head> (or without defer/async) block the HTML parser. jQuery, sliders, forms, chat widgets, analytics, all queue up. JS is usually the bigger problem, because scripts also take time to execute, blocking the main thread.
3. Web fonts
Fonts cause their own damage: invisible text while the font loads, or mid-load swaps that shift layout. (Our font preloading guide covers this in depth.)
Defer vs Delay vs Async: What Each One Does
These three terms get mixed up constantly. Here’s what each one actually does to a <script> tag:
| Technique | What happens | Best for |
|---|---|---|
| Async | Downloads in parallel, executes immediately when ready (order not guaranteed) | Independent scripts where order doesn’t matter, e.g. analytics |
| Defer | Downloads in parallel, executes after HTML parsing, in order | Scripts your page needs but not before first paint — most theme/plugin scripts |
| Delay | Doesn’t load or execute until user interaction (scroll, click, tap) | Heavy third-party scripts: chat widgets, trackers, social embeds |
Think of it as a spectrum: async < defer < delay.
- Async is the gentlest option. The script downloads without blocking parsing, but it still loads during the initial page load. Good for analytics.
- Defer is the sweet spot for most WordPress scripts. It downloads quietly and executes after parsing, in order. Most theme and plugin scripts handle it fine.
- Delay is the nuclear option. The script doesn’t even download until user interaction. Huge for mobile scores, but also the most likely to break menus, sliders, and cart buttons.
Golden rule: start with defer, escalate to delay only for heavy scripts you’ve identified, and exclude anything interactive from delay.
Critical CSS: The Missing Piece
Most tutorials skip this part. Even with all JavaScript deferred, CSS still blocks rendering, and you can’t defer all CSS without a flash of unstyled content.
The answer is critical CSS, the small subset needed to render the visible (“above the fold”) content. The method:
- Generate critical CSS for your key templates (homepage, single post, etc.).
- Inline it in the
<head>. A<style>block loads instantly with the HTML. - Defer the rest. Full stylesheets load asynchronously, applying after first paint.
Result: the visible page paints immediately, correctly styled, and the full stylesheet arrives moments later. When PageSpeed Insights stops flagging your CSS, critical CSS is usually the reason, and the plugins below generate it for you.
What Each Optimization Tool Actually Does
| Tool | Defer JS | Delay JS | Remove unused CSS | Critical CSS | Notes |
|---|---|---|---|---|---|
| WP Rocket | Yes | Yes | Yes | Yes (generates automatically) | Most beginner-friendly; excellent docs |
| FlyingPress | Yes | Yes (smart exclusions) | Yes | Yes | Lean; praised for its delay-JS handling |
| LiteSpeed Cache | Yes | Yes | Yes | Yes (via QUIC.cloud) | Free; best on LiteSpeed servers |
| Perfmatters | Yes | Yes (called “Script Manager”) | No | No | Lightweight; pairs with a caching plugin |
Two honest notes. “Remove unused CSS” is the riskiest feature here. Page builders generate CSS dynamically, so aggressive removal is the #1 cause of broken layouts. Use it cautiously, per page type. And Perfmatters is not a caching plugin but a companion for script management. Never run two page caches together.
The 2026 Method, Step by Step
Do these in order, and test after each step as a logged-out visitor (incognito window). Load the homepage, a post, and any page with forms or interactive elements. Click everything.
Step 1: Reduce before you reorder
Cut the fat before touching defer/delay. Deactivate unneeded plugins (each can add CSS/JS), disable unused theme features, and remove forgotten widgets. Chat bubbles, social feeds, and popups are classic render-blocking culprits. Our 20-step WordPress performance checklist covers the full audit.
Step 2: Defer JavaScript
Enable defer JavaScript (not delay, not yet). This safe default clears most of the JS warning without breaking interactivity. Test now: if a slider or menu breaks, exclude that script from deferring and continue.
Step 3: Generate critical CSS and defer the rest
Enable your plugin’s critical CSS / load CSS asynchronously feature. It generates above-the-fold CSS, inlines it, and loads full stylesheets after first paint. If the layout breaks (unstyled flash, broken mobile menu), add fallback critical CSS manually or exclude that stylesheet from async loading.
Step 4: Delay heavy third-party scripts
Now escalate. Add your heaviest third-party scripts (chat widgets, extra analytics, ad scripts, embeds) to delay JavaScript execution so they load on user interaction. Keep your theme’s interactive scripts (menus, forms, cart) OUT of the delay list. When in doubt, don’t delay it.
Step 5: Consider removing unused CSS (carefully)
Only once steps 1–4 are stable, try remove unused CSS, ideally on one page type first. Check every template; page builders are the usual victims. If Elementor or Divi layouts break, exclude the builder’s stylesheets and accept the slightly lower score.
Step 6: Handle fonts
Preload critical font files and use font-display: swap. Font issues are fixed at the font-loading level, not with the CSS/JS toggles. Self-hosted fonts plus browser caching headers cut the font delay significantly.
Step 7: Verify with a real test
Re-run PageSpeed Insights, but don’t worship the score. Check that the warning is reduced, Largest Contentful Paint improved (the metric visitors feel), and nothing is broken as a logged-out visitor on mobile and desktop. If a CDN serves these assets, verify it’s actually working. A misconfigured CDN silently undoes optimization work.
What Breaks (And How to Fix It)
| Symptom | Likely cause | Fix |
|---|---|---|
| Menu won’t open on mobile | Menu script delayed or deferred | Exclude the menu/theme script from delay |
| Slider shows all images stacked | Slider JS deferred, CSS async | Exclude slider files, or load slider CSS normally |
| Unstyled flash on load | Critical CSS missed rules | Add fallback critical CSS; exclude that stylesheet from async |
| Add-to-cart button dead | WooCommerce script delayed | Never delay cart/checkout scripts |
| Cookie banner missing | Consent script delayed | Exclude it — consent must load immediately anyway |
| Layout broken only on some pages | Unused-CSS removal too aggressive | Exclude the page builder’s CSS; use per-URL safelists |
The pattern is simple: exclusions are not failure, they are the method. A site with thoughtful exclusions and a 90 score beats a broken site with a 100 every time.
Frequently Asked Questions
Will eliminating render-blocking resources break my site?
Only if you enable everything at once. Done in the order above — defer, critical CSS, delay last, with exclusions for interactive elements — risk is low and every step is reversible. Test as a logged-out visitor after each change.
Defer vs delay JavaScript — which should I use?
Defer for scripts your page needs to function (theme scripts, menus, forms). Delay for heavy third-party scripts that can wait for user interaction (chat widgets, extra trackers, embeds). Start with defer everywhere sensible, then selectively delay the heavy ones.
What is critical CSS in simple terms?
It’s the minimum CSS needed to correctly display what visitors see without scrolling. By inlining it in the page’s <head>, the browser can paint the visible page immediately instead of waiting to download full stylesheets. The full CSS still loads — just after the first paint.
Why does PageSpeed Insights still flag some files after optimization?
Usually: third-party scripts you chose not to delay (analytics, consent banners), plugins ignoring defer attributes, or fonts. Some warnings are fine — a consent banner should load early. Chase the big files, not a zero-warning report.
Is “remove unused CSS” safe with Elementor or Divi?
It’s the riskiest optimization for page builders because they generate CSS dynamically. It can work, but exclude the builder’s core stylesheets, test every template type, and be ready to turn it off. Many fast Elementor sites skip unused-CSS removal entirely and still score well.
The Bottom Line
There’s no magic toggle. It’s a sequence: reduce what loads, defer JavaScript, inline critical CSS and defer the rest, then delay only heavy third-party scripts, with exclusions wherever interactivity lives. Do it in that order, test after each step, and you’ll clear the warning without broken layouts. The score is a diagnostic. The goal is a page that feels instant on a real phone.
