Where the Shopify Cache Policy Warning Actually Comes From

Open PageSpeed Insights against any Shopify store that has more than three apps installed. Scroll to the diagnostics list and find the item titled "Serve static assets with an efficient cache policy." Click the expand arrow. What you'll see is a table of URLs and their Cache-Control max-age values. That table is the answer to the question most merchants ask about this warning: which files? On the merchant I audited a few weeks ago, the answer was almost none of the files I initially assumed.

Quick Answer

The shopify cache policy warning almost never flags files you can change. Most of the flagged URLs on a typical store come from third-party CDNs like static.klaviyo.com and connect.facebook.net, and the only real lever a merchant has is uninstalling the app the script belongs to.

What the expanded warning actually shows

The merchant runs a small home-goods store on Horizon and had accumulated seven or eight apps over the last year: reviews, a popup, chat, a subscription tool, custom fields, an upsell app, and two different Meta pixels courtesy of an agency that touched the store in 2024 and left. PageSpeed showed the mobile score in the low sixties and listed the cache-policy warning near the top of the diagnostics by asset count.

The expanded panel had URLs in the low twenties, and they sorted themselves into three buckets before I finished reading the list.

1. cdn.shopify.com/... - two entries. Both carrying a max-age of thirty days or so, which isn't the full year Google wants but isn't what I'd call a real problem either.
2. Third-party app CDN domains - about fourteen entries, spread across five domains. static.klaviyo.com, connect.facebook.net, cdn.judge.me, scripts.tidio.co, and one I had to look up which turned out to be the subscription app.
3. monorail-edge.shopifysvc.com plus a handful of cdn.shopify.com/shopifycloud/checkout-web/assets/ files with app.latest in the path.

That was the fingerprint. I already had a bad feeling about what was fixable in the list.

My first guess, and why it was wrong

I spent the better part of an hour on the wrong path. My first instinct was to check whether Cloudflare could sit in front of the store and rewrite cache headers on the third-party scripts. I have done that on non-Shopify sites before, and I forgot for a moment why it doesn't map here.

On Shopify, you can put Cloudflare in front of your store, but the setup is a proxy for the origin request to Shopify. It doesn't intercept the visitor's browser fetch to connect.facebook.net. That request goes directly from the visitor's browser to Facebook's CDN, and my Cloudflare zone is nowhere in the path.

I still tried a page rule with a longer edge cache TTL to prove I hadn't misremembered. I set it, re-tested, and the third-party rows in the audit came back with the exact same max-age values. Meta serves that Cache-Control header from its own infrastructure. Nothing I do in my zone changes it. This is not new information, and a Shopify Community reply from a merchant named oreoorbitz said it plainly all the way back in 2021: "there isn't a solution, you can't change Shopify's cache policy." I just needed to prove it to myself with this specific store before I moved on.

Where the trail actually went

Once I stopped trying to change headers, the audit became a different exercise. It stopped being a caching problem and started being an app audit.

I opened each flagged third-party domain and traced it back to the installed app that loaded it. Klaviyo was doing exactly what Klaviyo does: loading its snippet from static.klaviyo.com on every page, with a short cache lifetime. That short lifetime isn't a bug. Klaviyo ships script updates on a fast cycle, and a year-long cache would mean returning visitors are stuck on a year-old copy the day after they push a fix. From Klaviyo's perspective, an hour or so is the right operational answer. From PageSpeed's perspective, an hour is a red row in the audit table.

Meta's script was the same. So was the review app. The chat widget carried a longer lifetime but still nothing close to Google's threshold. Every third-party vendor makes the same trade: keep the cache short so we can push fixes quickly, and accept that PageSpeed will flag us on every audit report our merchants ever run.

The last bucket was more interesting. monorail-edge.shopifysvc.com is Shopify's own analytics endpoint. The app.latest files under cdn.shopify.com/shopifycloud/checkout-web/assets/ are Shopify's checkout-related JavaScript, and they load on every storefront page, not only at checkout. Alex_Moser posted in Shopify Community in December 2023 asking for clarification on what these files do and whether they could be deferred, noting that they added roughly 800kB per storefront page. Shopify has not answered publicly. Those rows in the audit are Shopify's own platform scripts, and they were not going anywhere no matter what I did.

The advice that keeps showing up in threads

If you search "Serve static assets with an efficient cache policy Shopify" you'll get a mix of correct and incorrect answers. The incorrect answers cluster around three shapes, and I have watched merchants try all three of them.

1. Set a Cache-Control header of public, max-age=31536000. This one shows up in a March 2023 Shopify Community reply from a vendor account. It's not executable. Merchants have no server-level HTTP response header control on Shopify-hosted assets and no control at all over third-party CDN assets.
2. Put Cloudflare in front of your store. The one I tried. Cloudflare proxies your origin, not your visitor's request to static.klaviyo.com.
3. Add a CDN. This is confused advice. Shopify already runs its own CDN, which serves theme assets with a full one-year cache lifetime. Adding a second CDN in front doesn't change how third-party scripts load. There is no configuration you can do that reaches those scripts.

There is a legitimate related fix that often shows up in the same threads: deferring third-party scripts with requestIdleCallback or a scroll/mouse trigger so they don't run before first paint. That approach improves TBT and INP because the scripts stop blocking the main thread. It does not change the max-age those scripts carry once they eventually load. Deferred loading and long cache lifetimes solve different problems. Merchants who defer and then re-run PSI expecting the shopify cache policy warning to drop are usually disappointed, because the warning does not measure loading order.

What actually moves the shopify cache policy warning

There is one lever, and it's the same lever that improves every other app-driven speed metric on the store: fewer apps.

On the merchant I was auditing, we took a full app inventory. Two of the seven or eight apps hadn't been opened in Shopify Admin in the last ninety days. One had been replaced by a second app doing the same thing (that agency again). One had been installed for a Black Friday promotion the year before and left running. We uninstalled four apps, then went into the theme code editor and pulled out the leftover snippet blocks and script tags that Shopify's uninstall flow doesn't clean up on its own.

We re-ran PSI a few days later. The shopify cache policy warning still fired. It listed about a dozen URLs instead of the earlier count, which is a real reduction. The mobile score moved from the low sixties into the mid-seventies, driven mostly by lower TBT from the removed scripts. The warning didn't disappear, because Klaviyo and Meta are still loading and those are the apps the merchant genuinely uses.

That is the correct outcome. The shopify cache policy warning is the byproduct of an app-heavy stack, and the app-heavy stack is what actually costs conversion. You address the underlying problem and the warning shrinks. You do not address the warning directly.

If a merchant asks me to "fix the cache warning" as a distinct line item, that's the conversation I have. If they're bringing a whole PSI report and they want a second pair of eyes on which of the ten diagnostics are worth their afternoon, that's what help1's expert chat is for. The first fifteen minutes are free and a quick app audit fits comfortably inside them.

Two edge cases worth naming

Two situations came up in the audit that I did not want to leave unexplained.

Shopify custom pixels. If a merchant has migrated tracking scripts from theme injection into Shopify's customer events sandbox (which is the path Shopify now recommends), those scripts will still appear in the cache-policy warning list. The sandbox loads them inside iframes, and iframe sandboxing blocks caching by design. tim_tairli in a November 2024 Shopify Community thread put it plainly: "being an event pixel it only makes sense to avoid caching." Don't revert to theme-injected pixels to make the warning go away; the security trade is the correct one.

Automatic Early Hints. Shopify rolled out automatic Early Hints in August 2026, and the results are real - 76ms FCP improvement and 100ms LCP improvement at p75. But Early Hints is a preconnect and preload mechanism. It reduces the time to open a TCP/TLS connection to static.klaviyo.com. It does not change the max-age Klaviyo returns when it hands over the script. Merchants who notice their LCP jumping after Early Hints rolled out should not expect the shopify cache policy warning to move with it.

What I check on the shopify cache policy warning now

When this warning appears in a report I'm reviewing, my sequence is short.

1. Expand the warning in PSI and count how many URLs come from cdn.shopify.com. If it's most of the list, something odd is going on and it's worth a closer look. It rarely is.
2. Group the remaining URLs by domain. That gives me a shortlist of apps to review.
3. Match each domain to an installed app. If the merchant can't answer "am I actively using this?" for a given app, it becomes a candidate for removal.
4. Note the Shopify platform scripts (monorail-edge, app.latest, Redesign.latest) and set them aside. They are not merchant errors.
5. Segment by visitor mix. If most of the store's traffic is first-time paid ads, the cache warning has minimal real-world impact - fresh visitors download every script anyway. If the store runs on returning email-list buyers or SEO traffic, the impact is meaningfully higher, and I push the app audit harder.

That's the whole procedure. There isn't a fifteenth step where I compress a CSS file or write a Cloudflare rule. This is the same underlying app-count conversation I have with merchants about the render-blocking CSS warning, wearing different clothes.

Every audit like this one lands in the same place: the fingerprint on the report is different, the fix is the same audit as last time, and the story of chasing the warning is more interesting than the warning itself.