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 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.