The Shopify Page Speed Warning I Stopped Trying to Fix

A merchant posted in Shopify Community a few months ago asking why styles.css was the top render-blocking resource on their Horizon store. They had searched the theme code editor and could not find the file. A community expert replied that styles.css is auto-generated from every section's stylesheet tags, so there was nothing in the editor to defer in the first place. The thread closed without a solution. That thread is the template for every conversation about this warning, going back to 2021.

Quick Answer

The "Eliminate render-blocking resources" warning on Shopify is mostly a structural fact about how themes compile their CSS. You can spend an afternoon trying to defer the wrong file and break navigation in the process, or you can put that hour into the things that actually move your Shopify page speed score: app scripts, tracking pixels, and the LCP hero image.

Why the warning shows up on every Shopify store

Run a Shopify page speed audit against a fresh Dawn install with zero apps and no images, and you will already see render-blocking resources flagged. One merchant on Shopify Community measured 0.5 to 1.5 seconds of blocking time on that baseline. The flagged file is global.js, which Shopify's CDN ships on every theme and which carries cart, slideshow, variant, and navigation logic in one bundle.

On Horizon the file is called styles.css. On Stockholm it is base.css. Names differ; the architecture is the same. Liquid templates use {% stylesheet %} and {% javascript %} tags scattered across every section and snippet. Shopify concatenates those into compiled assets at render time and ships them as one file. The compiled file is not in your Assets folder. There is no asset key for it in the code editor. When PageSpeed tells you to defer styles.css and you go looking for styles.css, you will not find styles.css.

Horizon did not invent this pattern. Dawn has worked the same way for years. The difference is that Horizon has many more sections to compile, so the output file is bigger and the blocking time is longer. A community expert noted in March that Horizon "has a lot of those" stylesheet tags and that auditing them would be a time-consuming task with no guarantee of meaningful savings.

Why deferring it usually breaks something

The standard advice from Google and most speed-app vendors is to add defer or async, or to inline critical CSS and load the rest with media="print". None of these are wrong in general. All of them are wrong specifically here.

A merchant on Shopify Community ran the Chrome Coverage tool against their store, identified scripts that looked unused, and pulled them. The site crashed. Another merchant tried deferring glightbox.js and lost the homepage counter. Another tried the media="print" async pattern on the main stylesheet and watched their store flash unstyled until the swap finished. The community expert in that thread explicitly warned them: until the async CSS loads, your page is going to be a bit of a mess.

The reason these fail is not skill. Shopify's compiled JavaScript and CSS files are intentionally synchronous. Later code on the page depends on them. Defer the cart bundle and your add-to-cart button posts before the listener is attached. Defer the stylesheet and your hero image arrives before its grid does. Theme-native code behaves differently from a third-party tracking pixel. Pixels can be deferred without breaking your store. The compiled theme file cannot.

I used to spend an hour on each audit trying. I stopped after the third merchant called me back to say their cart drawer was broken on iOS the morning after I "fixed" it. Now I tell merchants this is the warning to leave alone.

What I work on instead when a Shopify page speed audit is the brief

Render-blocking CSS from theme compilation is one item on a PageSpeed report. The same report usually flags four or five things you can actually change. Those are the work.

1. App scripts that load on every page. Most page builders, review apps, currency widgets, and chat apps inject scripts via Content For Header or app embeds, and they load even on pages that do not use them. The audit step is checking the network panel on a clean incognito session and listing every third-party script, then asking which ones actually run on the current template.
2. Tracking pixels firing twice. Klaviyo plus the Shopify pixel customization plus a Google Tag Manager copy of the same Meta pixel is a common stack. Each one adds main-thread blocking, and the redundant fires also pollute attribution. Consolidating to one source per platform usually buys 100 to 300 ms of TBT and cleaner ad data.
3. The LCP hero image. Default Dawn lazy-loads the hero. Horizon does not behave consistently across templates. Fixing the loading attribute on the hero image cuts mobile LCP by seconds, not milliseconds.
4. Residue from uninstalled apps. Removing an app does not remove the Liquid snippets and asset injections it added to your theme. The leftover code still loads and still blocks. If you have rotated through three review apps in two years, your theme is carrying scripts from all three.

These are the audits with real returns. They are also the audits a merchant can verify in their own admin without needing a developer. If you want a second pair of eyes on which of these your store actually needs, the first 15 minutes with a help1 expert is free and that is usually enough to identify the top one or two.

When the inlining route does pay off

The honest counterargument: there are merchants who have improved render-blocking through CSS work and reported it as a real win. A 2020 thread on Shopify Community has a merchant confirming their site loaded a lot faster after extracting above-the-fold styles into an inline {% style %} block in theme.liquid and switching the main stylesheet to a preload swap pattern. This works.

It works under three conditions:

1. You have a developer, or you can comfortably edit Liquid yourself.
2. You are willing to maintain different critical CSS sets for product, collection, and homepage templates, because the above-the-fold rules differ by template.
3. You are on Dawn or another stable theme that you do not plan to update often.

If you are on Horizon, condition three is the trap. Horizon's update notice says your code customizations will not carry over to the new version, and Horizon has been shipping updates frequently. Every code-level render-blocking fix is gone after the next update unless you re-apply it. Merchants who paid a Fiverr freelancer for this optimization in March are paying again in June. If the developer cannot show you a documented re-application workflow, do not commission the work.

What's left after you've tried everything

Dawn has a roughly 0.5 to 1.5 second baseline of render-blocking from theme-native code. Horizon's structural floor is higher. By community measurement on the same content, Horizon stores land 15 to 30 mobile PageSpeed points below Dawn equivalents. I have not tested this on Impulse, Prestige, or every custom build, so if you are on a paid theme your floor is whatever your floor is. The first audit step there is finding it before you start cutting things to chase a score that may already be at its theme limit.

What does not matter very much, in my experience, is the Lighthouse mobile score itself. A store at 35 on PageSpeed Insights can pass Core Web Vitals on real user data. A store at 90 in a sterile lab test can fail when a real customer with three browser extensions and a Meta-app-embedded webview hits it. The numbers that matter are the ones in your Web Performance dashboard from real visitors. A single-flag synthetic run is one browser session with one extension state, and PageSpeed Insights can disagree with itself between two runs done back to back.

A related read: I wrote about why I tell merchants to stop chasing the Shopify page speed score a couple of weeks ago, and the framing there applies double to this warning. The render-blocking line item will still be there on your next audit. That is fine. Your job is to make the merchant experience and the real-user numbers better, not to clear a synthetic checklist that does not even agree with itself between runs.

Final take

Render-blocking CSS from Shopify's theme compilation is one of the few items on a Shopify page speed audit that I tell merchants to ignore on purpose. You cannot reach that lever from the theme editor, and your developer cannot reach it reliably from anywhere else - put the audit hours into the levers that are within reach.