You want a faster WordPress site. But you don’t want to install another heavy plugin to get it.
I get it. It feels backward, doesn’t it? Installing a massive optimization plugin just to fix a speed warning often adds more code than it removes.
When you run your site through Google PageSpeed Insights, you likely see that annoying red flag: "Eliminate render-blocking resources."
It kills your load time. It hurts your user experience. And yes, it drags down your SEO rankings.
Most guides tell you to go buy WP Rocket or install Autoptimize. Those are great tools. But they aren’t the only way. In fact, for developers and purists who want total control, the manual method is often better.
At Infineural Technologies, we believe in clean code over band-aid solutions. So, how do you fix this manually?
Here is exactly how to eliminate render-blocking resources in WordPress without a single plugin.
What Are Render-Blocking Resources?
Think of your website like a restaurant.
You are the customer (the browser). The waiter (the server) brings you the menu. But before you can even look at the food options (the content), the waiter forces you to read a 50-page rulebook on table etiquette (CSS and JavaScript).
You just want to eat. But you are blocked.
That is render-blocking. The browser stops building the page visuals to download and parse CSS and JavaScript files found in the <head> section. Until those files are processed, the user sees a blank white screen.
This delays your First Contentful Paint (FCP) and Largest Contentful Paint (LCP).
If you want to master the full spectrum of speed metrics, you should read our parent guide on Optimizing WordPress for Core Web Vitals: The 2026 Speed Guide. It explains why these metrics matter for your bottom line.
Why Fix This Manually?
Why not just click a button in a plugin?
- Control: Plugins sometimes break visual elements. Manual code lets you exclude specific scripts.
- Cost: High-end optimization plugins cost money. Code is free.
- Performance: Plugins execute their own logic. Adding a few lines to your theme is lighter on the server.
Ready to get your hands dirty? Let’s fix this.
Step 1: Identify the Culprits
Don’t guess. Measure.
Go to PageSpeed Insights. Run your URL. Look at the "Eliminate render-blocking resources" section.
It will give you a list of URLs. Usually, they end in .css (stylesheets) or .js (JavaScript). These are the files we need to defer or load asynchronously.
Step 2: Defer JavaScript via functions.php
This is the big one.
By default, WordPress loads scripts in the header. We want to tell the browser: "Download this script in the background, but don’t stop rendering the page."
We do this by adding the defer or async attribute to your script tags.
Warning: Always backup your site or use a staging environment before editing theme files.
Open your theme’s functions.php file. Add this code snippet:
function add_defer_attribute($tag, $handle) {
// Exclude jQuery to avoid breaking plugins that rely on it immediately
if ( 'jquery-core' === $handle ) {
return $tag;
}
return str_replace( ' src', ' defer src', $tag );
}
add_filter( 'script_loader_tag', 'add_defer_attribute', 10, 2 );
What does this do?
It intercepts every script WordPress tries to load. It adds the defer attribute. This tells the browser to execute the script only after the HTML is fully parsed.
Notice I excluded jQuery? That is intentional. Many themes rely on jQuery being present immediately. If you defer it, your sliders or menus might break. If you are an advanced user, you can try deferring jQuery too, but test it thoroughly.
Async vs. Defer
Why did I use defer and not async?
Async downloads the file during parsing and pauses the parser to execute it the moment it finishes downloading. The order isn’t guaranteed.
Defer downloads the file during parsing but only executes it after parsing is done. The order of scripts is preserved. For WordPress, defer is usually safer.
Step 3: Optimizing CSS Delivery Manually
CSS is trickier. You cannot just defer all of it, or your site will look like a broken 1990s HTML page for two seconds (that’s called a Flash of Unstyled Content, or FOUC).
The goal is to split your CSS into two parts:
- Critical CSS: The styles needed for the "above the fold" content. This should be inline in the HTML.
- Non-Critical CSS: Everything else (footer, comments, sidebar). This should load later.
The Manual CSS Swap Trick
We can trick the browser into thinking a stylesheet is for printing only. The browser will download it with low priority and not block rendering. Once it loads, we switch it back to "all" styles.
Add this to your functions.php to target non-critical stylesheets (you need the handle name of your style, which you can find in your theme code):
function defer_non_critical_css( $html, $handle ) {
// Replace 'your-style-handle' with the actual handle of your CSS
if ( 'your-style-handle' !== $handle ) {
return $html;
}
return str_replace( "rel='stylesheet'", "rel='preload' as='style' onload="this.onload=null;this.rel='stylesheet'"", $html );
}
add_filter( 'style_loader_tag', 'defer_non_critical_css', 10, 2 );
This is a powerful technique. But it requires you to know which stylesheet is heavy and non-essential.
If you need to dive deeper into how layout shifts happen when CSS loads late, check our guide on How to Reduce Cumulative Layout Shift WordPress Manually (2026).
Step 4: Hosting Google Fonts Locally
Google Fonts are notorious render-blockers. The browser has to go to Google’s server, ask for the font, and come back.
The fix? Host them locally.
1. Download your font files (WOFF2 format is best).
2. Upload them to your theme’s /fonts folder.
3. Add the @font-face declaration in your main style.css.
Then, preload the font in your header.php file inside the <head> tags:
<link rel="preload" href="path/to/font.woff2" as="font" type="font/woff2" crossorigin>This ensures the font starts downloading immediately, preventing the invisible text issue.
The Results
After implementing these snippets, clear your cache. Go back to PageSpeed Insights.
You should see the "Eliminate render-blocking resources" warning vanish or drop significantly. More importantly, your LCP score should improve.
Speed isn’t just about plugins. It’s about understanding how browsers work. When you remove the friction, you get the results.
And if you are looking to clean up other areas of your Core Web Vitals, specifically specifically heavy visual elements, read our breakdown on Fixing Largest Contentful Paint in WordPress Elementor.
FAQ
Is it safe to defer all JavaScript?
No. Deferring core scripts like jQuery often breaks interactive elements like sliders or mobile menus. Always exclude jQuery unless you know how to refactor your code.
What is the difference between inline and deferred CSS?
Inline CSS is placed directly in the HTML head and loads instantly. Deferred CSS loads in a separate file after the page has started rendering.
Does this method work for Elementor or Divi?
Yes, but page builders generate complex CSS/JS files. You may need to identify multiple handles to defer them correctly without breaking the layout.
Can I just move scripts to the footer?
Moving scripts to the footer is an old-school method that works similarly to defer. However, defer is cleaner and modern browsers handle it better.
Will this fix my slow server response time?
No. Render-blocking resources are a frontend issue. Server response time (TTFB) depends on your hosting provider and PHP processing speed.
Do I need to touch the htaccess file?
Not for render-blocking. The .htaccess file is used for caching and compression (GZIP), which is a different part of speed optimization.
How do I find the "handle" for my scripts?
You can install a plugin like "Query Monitor" temporarily to see the handles of all enqueued scripts, then remove it once you have the names.
Why is PageSpeed Insights still showing a warning?
Ensure you have cleared all caches (server, CDN, browser). Sometimes third-party scripts (like chat widgets or ads) are the blockers, which you cannot fully control.
Ready to Scale?
You have fixed the code. Your site is leaner. But optimization is a constant battle.
If you want a partner who treats your infrastructure with this level of detail, let’s talk. At Infineural Technologies, we don’t just patch sites; we engineer them for dominance.
