Shopify cache warming: what you can (and can't) warm on a hosted platform

Shopify is different from WordPress or Magento in one fundamental way: you don't run the server. Shopify operates the infrastructure, the CDN and the cache, and gives you almost no knobs for any of them. So the honest first question isn't "how do I warm my Shopify cache" but "which cache, and is it even mine to warm?" Let's take the layers apart.

What Shopify caches for you

For a standard Liquid storefront, Shopify caches rendered pages internally and serves them via its Cloudflare-backed edge. Popular pages are usually warm. But "usually" hides the same pattern every cache has: the long tail runs cold. Products with a handful of daily views, filtered collection pages, and any page right after a theme publish or a bulk product update will render Liquid on demand, and you can feel it in the TTFB. Shopify's own monitoring shows storefront TTFB varying by hundreds of milliseconds between a cached and an uncached render.

Where cold starts still happen on Shopify

• Theme publishes invalidate rendered pages: your whole store re-renders on first view.
• Bulk operations (price updates, inventory syncs from an ERP, app-driven metafield writes) invalidate the affected pages.
• Long-tail products and collections without steady traffic drop out of hot caches.
• International visitors: markets with less traffic keep fewer pages warm at their nearest edge.

A scheduled crawl of your sitemap keeps these paths rendered and cached. Shopify explicitly tolerates polite sitemap crawling (it serves Googlebot the same way); a warmer that reads /sitemap.xml and paces its requests behaves exactly like a search engine, with the side effect that the next human gets a warm page. That's what warmup.rocks does, from 40+ countries, so the warm copies land in the edge locations where your actual markets are. You can verify the effect per location with our free cache checker.

Headless Shopify: now warming is fully yours

The picture changes completely when you go headless: Hydrogen on Oxygen, Next.js on Vercel, or a custom storefront behind Cloudflare. Now you own the rendering layer and its caches:

• Your SSR output is cacheable at whatever edge you deploy to, and it starts cold in every location after every deploy.
• Storefront API responses you cache (product data, collections) have TTLs and go cold on their own schedule.
• ISR/SSG pages regenerate on demand; the first visitor after a revalidation gets the slow render.

This is standard cache warming territory: point a warmer at your sitemap, warm after every deploy, and watch the hit ratio per edge location. Headless stores are also where TTFB regressions hide best: a cold Lambda or Workers isolate plus a cold cache stacks up fast.

Shopify Plus with your own Cloudflare zone

Plus merchants running Cloudflare Orange-to-Orange (O2O) in front of Shopify get their own Cloudflare zone with its own cache. If you enable HTML caching for anonymous traffic there, you've created a second per-colo cache, one that behaves exactly like the Cloudflare setup we've covered in depth, and one that benefits from scheduled multi-location warming immediately.

The honest summary

1. Standard Shopify storefront: warming helps the long tail, after theme publishes and bulk updates, and in secondary markets. It won't change your top pages; Shopify already keeps those warm.
2. Headless storefront: warming is as valuable as on any self-hosted stack. You own the caches now.
3. Plus + own CDN zone: treat it like any Cloudflare HTML-caching site and warm every colo.