What Are Render-Blocking Resources?
When your browser loads a Shopify page, it reads the HTML from top to bottom. When it encounters a <script> tag (without async or defer), it stops rendering, downloads the script, executes it, and only then continues. The same happens with <link rel="stylesheet"> tags for external CSS — the browser won't paint anything until the CSS is downloaded and parsed.
This is why your visitors see a blank white page (or a partially loaded page) for several seconds while the browser processes these files in the background. The browser is literally blocked from rendering visible content.
Three Types of Render-Blocking Resources on Shopify
JavaScript files — Theme scripts, app scripts, analytics trackers. The biggest offender on most Shopify stores. Each script tag without defer pauses rendering completely.
CSS stylesheets — External stylesheets loaded in the <head>. The browser must download and parse all CSS before painting anything.
Web fonts — Custom fonts that must download before text displays. Without font-display: swap, the browser shows invisible text until the font arrives.
On a typical Shopify store, the "Eliminate render-blocking resources" warning in PageSpeed Insights accounts for 1–4 seconds of delay. The more apps you have installed, the worse it gets — each app can add multiple render-blocking scripts.
Why This Matters for Your Store
Render-blocking resources aren't just a technical issue — they directly impact your revenue:
7%
conversion drop per 1 second of delay
Source: Google/Deloitte
53%
of mobile visitors leave if a page takes over 3 seconds
Source: Google
SEO
Core Web Vitals are a Google ranking factor since 2021
Source: Google Search Central
If your store takes 5 seconds to show content because of render-blocking resources, you're losing visitors before they even see your products. Fixing this is one of the highest-ROI speed optimizations you can make. For a broader look at every optimization technique, see our complete speed optimization guide.
The Easy Fix: Automatic Optimization with Thunder
Before we dive into the manual, code-level fixes below — there's a much easier way. Thunder Page Speed Optimizer automatically detects and fixes render-blocking resources on your Shopify store, with no code changes required.
What Thunder fixes automatically:
Script Deferral
Automatically defers third-party app scripts — even ones you can't control manually
Critical CSS Inlining
Extracts and inlines above-the-fold CSS so your page renders instantly
Font Optimization
Adds font-display: swap and preloads critical fonts automatically
Smart Dependency Mapping
Understands which scripts depend on each other — defers safely without breaking apps
CSS Minification
Removes unused CSS and compresses the rest for smaller file sizes
Continuous Monitoring
Tracks your speed daily and alerts you if new apps introduce render-blocking resources
Average improvement: +27 PageSpeed points
Thunder users see an average 27-point improvement in their Google PageSpeed score. Most stores go from red/orange to green within minutes of enabling optimizations.
Free plan available · No credit card required · 30-second setup · Works with all themes · View all plans
Why use an app instead of fixing it manually? The manual fixes below require editing Liquid theme files, understanding script dependencies, generating critical CSS, and testing thoroughly. One mistake can break your checkout or apps. It also needs to be redone every time you install a new app or update your theme. Thunder handles all of this automatically and continuously.
How to Identify Render-Blocking Resources on Your Store
⚡ Skip this step: Thunder's free plan automatically identifies all render-blocking resources on your store and shows you exactly which ones are slowing it down — no manual testing needed.
Method 1: Google PageSpeed Insights
Go to pagespeed.web.dev, enter your store URL, and wait for the analysis. You can also run a free speed test using our tool for a quick overview. In the results, scroll to the "Opportunities" section and look for "Eliminate render-blocking resources." Click to expand it — you'll see every file that's blocking rendering and the estimated time savings.
Method 2: Chrome DevTools Coverage
Open your store in Chrome, press F12, then Ctrl+Shift+P (or Cmd+Shift+P on Mac) and type "Coverage." This shows how much of each CSS and JavaScript file is actually used during load. Red bars = unused code the browser downloaded but didn't need.
Method 3: Network Waterfall
In Chrome DevTools → Network tab, reload the page and look at the waterfall chart. Files that load early with long bars are blocking rendering. Focus on JavaScript and CSS files that load before the first image.
💡 Tip: Test on mobile. Switch Chrome DevTools to mobile emulation before analyzing. Render-blocking resources have a much bigger impact on mobile due to slower processors and connections — see our Shopify mobile speed optimization guide for more on this.
Manual Fix: Render-Blocking JavaScript
⚠️ Difficulty: Intermediate to Advanced. Editing theme JavaScript requires understanding of script dependencies, execution order, and Shopify's Liquid templating. Mistakes can break your checkout, apps, and tracking. Always back up your theme before making changes.
JavaScript is the biggest render-blocking culprit on most Shopify stores. Here's how to address each type manually:
1. Add defer to Custom Scripts
If you've added custom script tags in your theme files (theme.liquid, section files, etc.), add the defer attribute:
<!-- ❌ Before: render-blocking -->
<script src="https://example.com/custom-script.js"></script>
<!-- ✅ After: non-render-blocking -->
<script src="https://example.com/custom-script.js" defer></script> defer tells the browser: "Download this in the background, and execute it after the HTML is fully parsed." This preserves execution order while eliminating the render-blocking behavior.
2. Move Scripts to the Bottom
For inline scripts (code between <script> tags), move them from the <head> to just before </body>:
<!-- ❌ Before: in <head>, blocks rendering -->
<head>
<script>
// analytics or tracking code
</script>
</head>
<!-- ✅ After: before </body>, renders first -->
<body>
<!-- ... page content ... -->
<script>
// analytics or tracking code
</script>
</body>3. Use async for Independent Scripts
For scripts that don't depend on other scripts (like standalone analytics trackers), async downloads and executes without blocking — but doesn't guarantee execution order:
<!-- ✅ Good for independent scripts like analytics -->
<script src="https://analytics.example.com/track.js" async></script>
<!-- ✅ Better for scripts with dependencies -->
<script src="https://cdn.example.com/library.js" defer></script>
<script src="https://cdn.example.com/app.js" defer></script> When to use which: Use defer for most scripts — it preserves execution order. Use async only for truly independent scripts. When in doubt, use defer.
Manual Fix: Render-Blocking CSS
⚠️ Difficulty: Advanced. Critical CSS extraction is one of the hardest speed optimizations to do correctly. Getting it wrong causes a Flash of Unstyled Content (FOUC) — your page briefly appears broken before the styles load. This is why most developers use automated tools for this.
CSS is inherently render-blocking — the browser needs to know how things look before displaying them. You can't simply defer all CSS (the page would flash unstyled). The correct approach:
1. Inline Critical CSS
Critical CSS is the minimum CSS needed to style above-the-fold content. Inline it directly in <head> so the browser renders instantly, then load the full stylesheet asynchronously:
<head>
<!-- ✅ Critical CSS inlined for instant rendering -->
<style>
/* Only styles for above-the-fold content */
header {display:flex;align-items:center;height:64px}
.hero {padding:4rem 1rem;text-align:center}
.hero h1 {font-size:2.5rem;font-weight:800}
</style>
<!-- ✅ Full CSS loaded asynchronously -->
<link rel="preload" href="{{ "theme.css" | asset_url }}" as="style"
onload="this.onload=null;this.rel='stylesheet'">
<noscript><link rel="stylesheet" href="{{ "theme.css" | asset_url }}"></noscript>
</head>The hard part? Figuring out which CSS is critical. It's different for every page (homepage, collection, product) and every theme. Tools like Critical by Addy Osmani can help, but they need to be run for each page template and updated whenever you change your theme.
2. Remove Unused CSS
Many Shopify themes ship CSS for every possible feature — mega menus, accordions, quickview — even if you don't use them. Use Chrome DevTools Coverage tab to measure. If less than 50% is used, there's significant room for optimization. But removing CSS manually risks breaking features you didn't know existed.
3. Minimize External CSS
Each external CSS file (Google Fonts, app stylesheets, widgets) adds a blocking request. Self-host fonts, combine small stylesheets, and audit which app CSS is actually necessary. Pairing these CSS fixes with proper lazy loading ensures the browser only loads what's needed for the initial viewport.
Manual Fix: Render-Blocking Fonts
Web fonts cause two problems: they block text rendering (FOIT — Flash of Invisible Text), and loading them from external domains adds extra network latency.
1. Use font-display: swap
Shows text immediately in a fallback font, then swaps to the custom font when it's ready:
@font-face {
font-family: 'YourCustomFont';
src: url('your-font.woff2') format('woff2');
font-weight: 400;
font-display: swap; /* ✅ Shows fallback text immediately */
}2. Preload Critical Fonts
Start downloading your most important font early:
<link rel="preload" href="/fonts/your-font.woff2" as="font"
type="font/woff2" crossorigin>Only preload 1–2 critical fonts. Preloading too many wastes bandwidth.
3. Self-Host Instead of Google Fonts
Loading from fonts.googleapis.com requires extra DNS lookups. Self-hosting puts fonts on Shopify's CDN:
- Download fonts from Google Webfonts Helper
- Upload
.woff2files to your theme's Assets folder - Update CSS
@font-faceto reference local files - Remove the Google Fonts
<link>tag
4. Limit Font Weights
Each weight (regular, bold, italic) is a separate download. Most stores only need regular (400) and bold (700). Loading 4–6 weights adds 200–600KB unnecessarily.
The Third-Party Script Problem (Why Manual Fixes Aren't Enough)
Here's the hard truth about everything above: the manual techniques work great for code you control — but on most Shopify stores, the biggest render-blocking offenders are third-party app scripts that you can't edit.
When a Shopify app injects a <script> tag into your storefront, you don't get to choose whether it has defer or async. The app developer made that decision — and many don't add either, making their scripts render-blocking by default.
A typical Shopify store has 5–15 apps installed. Even if each adds just one render-blocking script, that's 5–15 files the browser must download and execute before showing any content. We cover this in depth in our guide on managing third-party scripts on Shopify. And every time you install a new app, it can undo all your manual optimization work.
The Manual Approach vs. Thunder
This is exactly why we built Thunder. It works at the theme level — intercepting and optimizing how all scripts load, including third-party ones you can't touch manually. And it adapts automatically when you add new apps or update your theme. Plans start at $19.99/mo — significantly less than hiring a developer to do manual script deferral. If you're also considering a theme change, check our guide to the fastest Shopify themes — pairing a fast theme with Thunder gives you the best possible baseline.
How to Verify Your Fixes
Whether you used Thunder or fixed things manually, here's how to confirm render-blocking resources are eliminated:
Re-run PageSpeed Insights
The "Eliminate render-blocking resources" opportunity should show reduced savings or disappear entirely. Your Performance score should improve.
Check LCP and TBT
LCP should decrease (content renders sooner). TBT should decrease (fewer scripts block the main thread).
Test app functionality
Verify review widgets, popups, search, cart, and checkout still work. Deferring scripts can cause timing issues — Thunder handles this automatically, but manual changes need thorough testing.
Monitor over 28 days
Lab data changes immediately, but real user metrics (CrUX data in Search Console) take 28 days. Keep monitoring to confirm improvements hold.
Frequently Asked Questions
What are render-blocking resources on Shopify?
Render-blocking resources are CSS files, JavaScript files, and fonts that prevent the browser from displaying your page content until they've been fully downloaded and processed. On Shopify, the most common render-blocking resources are third-party app scripts, theme JavaScript, external CSS stylesheets, and web fonts. They force the visitor to stare at a blank or partially loaded page while the browser works through them.
How do I find render-blocking resources on my Shopify store?
The easiest way is to install Thunder Page Speed Optimizer — it automatically scans your store and identifies every render-blocking resource, showing you exactly which scripts and stylesheets are slowing your store. For a manual check, run your store URL through Google PageSpeed Insights (pagespeed.web.dev) and look for the 'Eliminate render-blocking resources' opportunity.
Can I fix render-blocking resources without coding?
Yes. Thunder Page Speed Optimizer fixes render-blocking resources automatically — no code changes needed. It defers third-party scripts, inlines critical CSS, and optimizes font loading with one click. The manual approach requires editing Liquid theme files, which risks breaking your store if done incorrectly.
Can I add defer or async to Shopify app scripts?
Not directly — third-party app scripts are injected by the apps themselves, and you don't control their script tags. You'd have to contact each app developer and ask them to add defer/async, which rarely happens quickly. Thunder solves this by automatically intercepting and deferring third-party scripts without modifying the apps themselves.
Will deferring scripts break my Shopify apps?
It can if done manually. Naive script deferral (just adding 'defer' to everything) can break apps that depend on scripts loading in a specific order. Thunder handles this intelligently — it maps dependency chains between scripts and defers them safely while preserving execution order, so your apps continue working correctly.
What's the difference between async and defer for scripts?
Both download scripts in the background without blocking rendering, but they execute differently. 'async' executes as soon as it downloads, regardless of order — risky if scripts depend on each other. 'defer' waits until the HTML is fully parsed, then executes in order. For most Shopify optimization, 'defer' is safer. Thunder automatically chooses the right strategy for each script.
How much faster will my store be after fixing render-blocking resources?
Most Shopify stores see a 1–3 second improvement in load time after fixing render-blocking resources. The exact improvement depends on how many blocking resources you have and their file sizes. Stores with many installed apps typically see the largest gains. Thunder users report an average PageSpeed improvement of 27+ points.
What does 'your page has blocking CSS resources' mean?
This PageSpeed Insights warning means your page has external CSS stylesheets in the <head> that the browser must fully download and parse before it can render any visible content. Every external CSS file adds a round-trip delay — typically 50-200ms each. On Shopify, this includes your theme's main stylesheet, app-injected CSS, and Google Fonts. The fix is to inline critical CSS (the styles needed for above-the-fold content) and load the rest asynchronously.
How many render-blocking resources does a typical Shopify store have?
A typical Shopify store with 8-12 apps installed has 10-25 render-blocking resources: 3-5 from the theme (JavaScript and CSS), 5-15 from installed apps (each app can add 1-3 scripts), and 2-5 from fonts and external services. Each blocking resource adds 50-200ms of delay. Thunder automatically identifies every render-blocking resource on your store and shows you exactly which apps are responsible.