Skip to content 
Key Takeaways
- Passing the “eliminate render-blocking resources” audit is not the same as improving LCP. The real goal is a faster paint of your Largest Contentful Paint element, and chasing the audit alone can leave LCP exactly where it was.
- CSS is render-blocking by default. Inline the small amount of CSS needed for above-the-fold content and load the rest without blocking, but never defer the styles that render your LCP element.
- For JavaScript, defer is the safe default and async is only for independent third-party scripts. Applying async to jQuery or jQuery-dependent code is the classic way to break a WooCommerce store.
- “Delay JavaScript until interaction” genuinely helps LCP, but it can break above-the-fold menus and sliders and push up your INP, so it needs careful exclusions and testing.
- Combining all your CSS and JavaScript into one file was a fix for HTTP/1.1. On the HTTP/2 and HTTP/3 connections most modern hosts use, it’s often unnecessary or counterproductive, while minifying always helps.
You can pass the audit and still have a slow store
Your WooCommerce store can pass Google’s “eliminate render-blocking resources” audit and still have a slow Largest Contentful Paint.
That’s the trap at the heart of this topic, and it’s why so much render-blocking advice quietly makes the metric worse.
Render-blocking CSS and JavaScript are real performance problems.
They stop the browser from painting your page until they’re downloaded and processed, which delays the first thing a shopper sees.
But the fix isn’t a green checkbox in PageSpeed Insights, it’s a faster paint of your actual LCP element, and those two goals don’t always line up.
This guide covers the render path the way it actually works: the CSS side and the JavaScript side, which fail and get fixed differently.
Render-blocking is one of several things that slow a store, and you can see the full set in our guide to why a WooCommerce store slows down.
Do render-blocking resources actually hurt LCP? Yes, but indirectly. CSS and JavaScript in the page head delay the browser’s first paint, and if they hold up the element that becomes your Largest Contentful Paint, your LCP score suffers.
The catch is that the goal is a fast paint of that specific element, so fixing render-blocking only helps LCP when it speeds up the LCP element rather than just clearing a warning.
What render-blocking resources are, and why LCP is the target
When a browser builds your page, it reads the HTML from top to bottom. The moment it hits a stylesheet or a script in the head, it usually stops, downloads that file, and processes it before painting anything.
That pause is what “render-blocking” describes, and on a heavy WooCommerce store it can add seconds before a shopper sees a thing.
Largest Contentful Paint measures how long the largest visible element takes to render, and it’s one of three Core Web Vitals that Google uses as ranking signals.
The other two are Interaction to Next Paint, which replaced First Input Delay in 2024, and Cumulative Layout Shift. To pass, you need LCP under 2.5 seconds, INP under 200 milliseconds, and CLS under 0.1.
Here’s the part that trips people up. Google’s own guidance is blunt that no single quick fix usually moves LCP, and that improving it is mostly about getting the LCP resource to start loading as early as possible.
So you can defer enough scripts to pass the render-blocking audit and still watch LCP sit still, because you didn’t speed up the element that actually defines it.
That’s why you measure LCP in the field with real-user data, not just in a lab tool, which is part of monitoring your store’s health.
The CSS render path: inline what’s critical, load the rest later
CSS blocks rendering for a reason: the browser won’t paint content until it knows how that content looks, or the page would flash unstyled and then jump.
So your stylesheets sit in the critical path by default, and a bulky theme or page-builder stylesheet delays every paint.
The fix is critical CSS. You identify the styles needed to render the above-the-fold view, inline those directly in the HTML so the page can paint immediately, and load the full stylesheet without blocking.
You can also use the media attribute on link tags to mark stylesheets that only apply to certain screens or to print, so the browser deprioritizes them.
There’s an LCP-specific trap here, and it’s the CSS version of the lazy-loading mistake that wrecks LCP on the image side.
If your LCP element is a block of text or a hero styled by CSS you just pushed out of the critical path, you’ve delayed the very thing being measured.
So whatever generates your critical CSS has to include the styles for the LCP element, and the better tools now build critical CSS per URL rather than per page type, which matters on a store where a product page and the homepage look nothing alike.
How do I fix render-blocking CSS without breaking my design?
Inline the critical above-the-fold CSS, load the rest of the stylesheet without blocking, and use the media attribute for styles that only apply to specific devices.
The rule that protects your LCP is to keep the styles for your largest visible element in that critical CSS, never deferred. Test for a flash of unstyled content before you ship it live.
The JavaScript render path: defer by default, async with care
JavaScript is the bigger render-blocking offender on most WooCommerce stores, because a script in the head stops HTML parsing cold until it downloads and runs. Moving non-critical scripts out of that path is where the real LCP gains usually come from. There are two attributes for it, and the difference matters more than most articles admit.
Defer downloads the script alongside the HTML and runs it after parsing finishes, in the order the scripts appear.
Async downloads alongside the HTML too, but runs each script the moment it arrives, out of order.
So defer is the safe default for WordPress, where scripts routinely depend on each other, and async suits only independent, fire-and-forget scripts like an analytics beacon.
This is exactly where stores break.
Applying async to everything is the classic way to shatter a WooCommerce site, because jQuery and the dozens of scripts that depend on it load out of order, and you get an “Uncaught ReferenceError: jQuery is not defined” and a dead cart.
Leave jQuery and your above-the-fold interactive scripts alone, defer the rest, and reach for async only on genuinely independent third-party code.
The clean way to do this changed recently.
Since WordPress 6.3 you can set a loading strategy of defer or async directly when a script is enqueued, and WordPress works out the dependency order for you, which is far safer than the old find-and-replace filters that ignored dependencies.
Should I use async or defer for my scripts?
Use defer for almost everything, because it preserves execution order and waits for the DOM, which is what most WordPress scripts need.
Reserve async for independent third-party scripts that nothing else depends on, like analytics.
Never async jQuery or anything that relies on it, and on WordPress 6.3 or newer, set the strategy when you enqueue the script.
The combine trap: an HTTP/1.1-era rule that now backfires
You’ll still see advice to combine all your CSS into one file and all your JavaScript into another. That was sound under HTTP/1.1, when every request carried real overhead and fewer files meant a faster page.
It hasn’t been a default best practice for years.
Modern hosts run HTTP/2 and HTTP/3, which download many files in parallel over one connection.
On those, merging everything into one large file can actually slow the render, since the browser could have fetched the smaller pieces at once, and a single giant bundle also forces a shopper to re-download everything when you change one line.
Combining isn’t dead, it’s just a contextual choice now rather than a reflex.
Minifying is the part that still always helps. Stripping whitespace and comments shrinks your files without touching how they’re cached or loaded, so do it everywhere.
Combine only when you have a measured reason, and note that most performance plugins switch combining off automatically once you turn on delayed JavaScript anyway.
Should I combine my CSS and JavaScript files?
Only if your host still runs HTTP/1.1, which is rare now.
On HTTP/2 or HTTP/3, combining everything into one file is usually unnecessary and can slow rendering, because the browser downloads separate files in parallel.
Minify your files either way, but treat combining as a tested experiment, not a default.
“Delay JavaScript” helps LCP, but watch your INP
Most performance plugins offer a feature that delays all JavaScript until the visitor interacts with the page, by scrolling, tapping, or moving the mouse. It’s one of the most effective LCP fixes available, and one of the most misunderstood.
The upside is real. Holding scripts back until interaction clears the main thread during the initial load, which lowers Total Blocking Time, resolves the “reduce unused JavaScript” warning, and speeds up LCP.
It even helps a long-standing WooCommerce headache, the cart-fragments request that can’t be cached, by holding it until it’s actually needed.
But the downside is just as real, and it’s why this isn’t a one-click win.
If anything above the fold needs JavaScript to work, a slider, a mega-menu, an animation, delaying it leaves that element dead until the shopper interacts, which looks broken.
The delay also adds a small wait on the first click, and that can raise your Interaction to Next Paint, the metric that replaced First Input Delay.
So you exclude the scripts your above-the-fold experience depends on, exclude consent and analytics where they need to fire early, and test that the page is usable, not just fast.
Does delaying JavaScript improve LCP?
Yes, it’s one of the strongest LCP fixes, because it takes JavaScript off the critical path during load and frees the main thread.
The cost is that it can break above-the-fold menus or sliders and add a delay to the first interaction, which hurts INP.
Use it, but exclude anything the visible page needs and test the result on a real device.
JavaScript is only one piece of the render-blocking puzzle. Unused CSS can have the same effect, especially when themes and plugins load styles on pages where they aren’t needed.
It’s common to find contact-form CSS on product pages, wishlist styles on the homepage, or slider assets loading across the entire site even when no slider is present.
Removing unused CSS reduces download size and helps the browser render the page sooner.
Third-party scripts deserve the same scrutiny. Marketing tags, live chat tools, review widgets, heatmaps, advertising platforms, and analytics scripts often add extra requests before a page can fully render.
If a script doesn’t provide measurable value, it’s worth questioning whether it belongs on the site at all.
Fonts can also delay rendering when they’re handled poorly.
Hosting fonts locally, using modern WOFF2 files, limiting unnecessary font weights, enabling font-display: swap, and preloading important fonts all help visitors see content sooner while custom fonts continue loading in the background.
How to ship this without breaking your store
Every fix here touches code your storefront depends on, so the order of operations matters as much as the fixes themselves.
Work on a staging copy, change one thing at a time, and test the full purchase flow after each change. A store that scores 95 but can’t take an order isn’t fast, it’s broken.
Run your product and category pages through PageSpeed Insights or Lighthouse and read the diagnostics, but trust the field data over the lab score.
Google grades you on real-user Core Web Vitals collected over 28 days, so a green Lighthouse run is a signal, not a verdict.
Watch LCP especially closely after any change to CSS loading or script deferral.
A performance plugin will do most of this for you. WP Rocket, Perfmatters, and FlyingPress all automate defer, delayed JavaScript, critical CSS, and minification, which is why one is worth having alongside the broader speed and performance tools.
Just remember their defaults are built for generic sites, so on a WooCommerce store you’ll set the exclusions and confirm checkout still works.
Frequently Asked Questions
What does “eliminate render-blocking resources” mean in PageSpeed Insights?
It’s the audit flagging CSS and JavaScript in your page head that delay the first paint.
Fixing it usually means deferring non-critical JavaScript and inlining critical CSS so the browser can render without waiting. Passing it is good, but it isn’t the same as a fast LCP, which depends on the whole load path.
Why is my WooCommerce LCP still slow after fixing render-blocking resources?
Because LCP depends on more than the render path. If your hero image loads late, your server’s response time is high, or you deferred the CSS or script that renders your largest element, the audit can pass while LCP stays poor.
Find your LCP element in PageSpeed Insights and make sure it starts loading as early as possible.
Will deferring JavaScript break my WooCommerce store?
It can, if you defer or async the wrong scripts. jQuery, checkout, cart, sliders, and menus are the usual casualties, and async breaks dependent scripts more often than defer. Use defer rather than async, exclude jQuery, and test a full guest purchase before and after the change.
What is critical CSS, and do I need it?
Critical CSS is the minimal set of styles needed to render your above-the-fold content, inlined so the page paints without waiting for the full stylesheet.
It helps LCP on stores with heavy theme or page-builder CSS. Generate it per template, keep your LCP element’s styles in it, and watch for a flash of unstyled content.
Does a caching plugin fix render-blocking resources automatically?
Mostly, yes. The major performance plugins automate the deferral, delayed JavaScript, critical CSS, and minification described above with a few clicks.
The catch is that their defaults are tuned for simple sites, so on a WooCommerce store you add exclusions for dynamic pages and test that checkout and cart still work.
Is INP part of Core Web Vitals now?
Yes. Interaction to Next Paint replaced First Input Delay as a Core Web Vital in March 2024, so the three metrics are LCP under 2.5 seconds, INP under 200 milliseconds, and CLS under 0.1.
It matters here because delaying JavaScript helps LCP but can raise INP, so the two need balancing.
The Bottom Line
Render-blocking CSS and JavaScript are worth fixing, but fix them for the right reason.
The target is a faster paint of your Largest Contentful Paint element, not a green audit, and the two only line up when your changes speed up the element Google is actually measuring.
Handle the two paths on their own terms.
Inline the critical CSS and keep your LCP element’s styles in it, defer your JavaScript and reserve async for independent scripts, leave jQuery alone, skip the old combine-everything habit, and use delayed JavaScript with exclusions while you keep an eye on INP.
Minify everything, and measure in the field rather than trusting a lab number.
Here’s the honest part.
Every one of these changes runs through code your checkout depends on, and the difference between a faster store and a broken one is often a single missed exclusion you won’t catch from the admin.
If you’d rather have your Core Web Vitals improved and verified without gambling your storefront, our WooCommerce developers do exactly this.
