Eliminate Render-Blocking Resources in WordPress: How to Fix It

What render-blocking means in WordPress

When the browser reads the head of your HTML and meets a normal stylesheet link or a script tag without defer or async, it stops. A stylesheet must be downloaded and parsed before the page is painted, so nothing appears until it arrives. A plain script must be downloaded and run before the browser even continues reading the HTML. Each blocking file adds at least one network round trip before the first paint, and on a phone over mobile data that adds up quickly.

In current versions of PageSpeed Insights this appears as the Render-blocking requests insight; older reports call it Eliminate render-blocking resources. Both list each file with its size and an estimate of the time it costs. Treat the estimate as a guide, not a promise, because removing one file can expose the next.

WordPress makes the problem common because of how assets are added. Each plugin calls wp_enqueue_style and wp_enqueue_script to add its files, and many do so on every page so that their feature works wherever you might use it. A site with twenty plugins can easily load fifteen stylesheets and a dozen scripts in the head of a simple blog post. The general principles are covered in the render-blocking resources guide; this page focuses on WordPress.

How to trace each file to its plugin or theme

The URL of each flagged file usually tells you where it came from:

To find the handle WordPress uses for a file, view the page source. Stylesheets carry an id made of the handle plus -css, and scripts carry the handle plus -js:

<link rel="stylesheet" id="contact-form-7-css" href="https://example.com/wp-content/plugins/contact-form-7/includes/css/styles.css" media="all">
<script src="https://example.com/wp-content/plugins/contact-form-7/includes/swv/js/index.js" id="swv-js"></script>

Here the handles are contact-form-7 and swv. The Query Monitor plugin also lists every enqueued script and style on a page with its handle, its dependencies and the component that added it, which is quicker on a busy site.

Stop plugins loading files where they are not used

The best render-blocking file is one that is never loaded. Start by deleting plugins you no longer use, then stop the rest from loading on pages that do not need them.

Many plugins have their own setting for this. Others can be controlled with a script manager such as the one in Perfmatters or the Asset CleanUp plugin, which let you turn files off per page or per post type. If you prefer code, dequeue the files in your child theme's functions.php or a small site plugin:

add_action( 'wp_enqueue_scripts', function () {
    if ( ! is_page( 'contact' ) ) {
        wp_dequeue_style( 'contact-form-7' );
        wp_dequeue_script( 'contact-form-7' );
        wp_dequeue_script( 'swv' );
    }
}, 100 );

The priority of 100 makes the function run after the plugin has enqueued its files. Contact Form 7 also offers its own filters, wpcf7_load_js and wpcf7_load_css, for the same purpose. Always check the page that does use the plugin afterwards, and send a test form.

Defer scripts the WordPress way

Since WordPress 6.3, scripts can be registered with a loading strategy. WordPress adds the attribute and keeps dependencies in a safe order:

wp_enqueue_script(
    'site-menu',
    get_stylesheet_directory_uri() . '/js/menu.js',
    array(),
    '1.2.0',
    array( 'strategy' => 'defer', 'in_footer' => true )
);

If a script with a defer strategy is a dependency of a script that must block, WordPress quietly downgrades it to blocking rather than breaking the order, so check the final HTML to see what you actually got. More detail on scripts is in render-blocking JavaScript, and on stylesheets in render-blocking CSS.

jQuery, critical CSS and fonts

jQuery is the file most likely to break things. Many themes and plugins print small inline scripts that call jQuery(...) immediately. If jQuery is deferred, those inline scripts run first and fail with jQuery is not defined, so menus, sliders and forms stop working. Defer jQuery only if every script that uses it, including inline ones, is deferred or delayed too. Caching plugins handle this differently: some keep jQuery blocking by default, while delay features hold all scripts until the first interaction. Check the browser Console for errors after any change.

Critical CSS means placing the small set of styles needed for the first screen directly in the head and loading the full stylesheet without blocking. WP Rocket, LiteSpeed Cache and Autoptimize can generate it. The usual pattern for the non-critical file is:

<link rel="preload" href="https://example.com/wp-content/themes/site/style.css" as="style"
  onload="this.onload=null;this.rel='stylesheet'">

After switching it on, reload several page types and watch for a flash of unstyled content, where the page appears briefly without its design. If you see it, the critical CSS is missing rules for that template and needs regenerating.

Fonts from Google Fonts load a stylesheet from another domain, which costs an extra connection before the font file is even requested. Host the font files on your own server, preload only the main font used above the fold and use font-display: swap so text shows straight away. The font layout shift guide explains how to keep the swap from moving the layout.

Performance plugin settings

Use one performance plugin for these features, not two. Running two that both rewrite CSS and scripts is a common cause of broken layouts and files loading twice. Combining files into one large file matters much less than it used to, because HTTP/2 handles many small files well; deferring and removing files usually gives a bigger gain.

A worked example

A small accountancy firm's WordPress site shows eleven render-blocking files in the mobile report, adding an estimated 1.4 seconds. Tracing the URLs shows a contact form plugin's CSS and two scripts, a slider plugin used only on the home page, the theme's main stylesheet, two Google Fonts stylesheets and jQuery.

The form plugin's files are dequeued everywhere except the contact page, and the slider files everywhere except the home page, using a script manager. The fonts are downloaded and served from the theme folder with font-display: swap. The theme's own scripts are switched to a defer strategy. jQuery stays as it is because the theme's menu uses inline jQuery code. The report now shows three blocking files, and mobile LCP on blog posts falls from 3.4 to 2.4 seconds.

The fix, step by step

Edge cases worth knowing

• Different templates load different files. A product page, a blog post and the home page can each have a different set of blocking files. Test each template, not just the home page.
• Logged-in views. The admin bar and editor add their own files when you are logged in. Test in a private window.
• Cached pages after changes. Clear the page cache and any CDN cache after changing asset settings, or you may be testing the old HTML.
• Async is not always safer. Scripts with async run as soon as they arrive, in any order. Use defer for scripts that depend on each other.
• Analytics and tags. A tag manager snippet is normally async already. If it injects blocking scripts, review the tags inside it.

Keeping it fixed

Every new plugin is a new set of files, so check the page source and the PageSpeed Insights report after installing or updating one. Keep a short list of which files you have dequeued and why, so a future developer does not undo it. Make changes on a staging site first where you can, and test forms and menus before going live.

Check the main templates in PageSpeed Insights every month, and the Core Web Vitals report in Google Search Console for real-visitor results. For wider WordPress speed work, see WordPress page speed.