CSS renders correctly in Theme Editor but fails / shows stale styles on Theme Preview (compiled_assets/styles.css stuck on CDN edge cache)

Online Store and Theme Development
1

Short description of issue

CSS inside {% stylesheet %} renders correctly in the Theme Editor, but the exact same section shows old/missing styles on the Theme Preview URL. This looks like the same underlying compiled_assets/styles.css caching bug @driftkween flagged in this thread: {%- stylesheet -%} compiled_assets working intermittantly - #7 by driftkween — quoting: “I’ve been experiencing the same issue. The /compiled_assets/styles.css file auto-generated from the {% stylesheet %} tag keeps displaying stale css from theme blocks that aren’t even rendered on the page.”

Reproduction steps

  1. Add/edit CSS inside a section’s {% stylesheet %} tag and push/save the change.
  2. Open the Theme Editor (Customizer) - the new CSS renders correctly and immediately.
  3. Open the Theme Preview URL (?preview_theme_id=…) for the same theme - the same section renders with the old/stale CSS, or is missing the new rule entirely (e.g. position: static instead of the position: relative I’d just pushed).
  4. Confirmed via “shopify theme pull” that the remote .liquid file is byte-identical to local - so the source is 100% correctly deployed. This isn’t a code problem.
  5. Inspected the compiled bundle URL (https://[store]/cdn/shop/t/[theme-id]/compiled_assets/styles.css?v=[hash]) - the v= hash is identical before and after the push/edit. Shopify’s backend never recomputed it.
  6. Response headers on that exact URL: cache-control: public, max-age=31536000, immutable and cf-cache-status: HIT - a full year “never revalidate” cache sitting in front of Shopify’s origin (Cloudflare).
  7. Fetching the identical asset path with a different (or no) v= query param returns the correct, up-to-date CSS immediately - proof this is purely a caching artifact, not a code issue.
  8. The HTML document itself is served cache-control: private, no-store (always fresh), so this is isolated to the one bundled CSS/JS asset, not full-page caching. That’s also why it’s consistent across every browser/device - it’s a shared edge cache, not a per-client one.

Additional info

Why it happens: Shopify assumes v= reliably fingerprints the compiled stylesheet content and tells the CDN to cache it forever on that assumption. In this case the backend just doesn’t regenerate a new fingerprint promptly after the theme push/edit, so the immutable cache keeps serving pre-change bytes indefinitely under the unchanged URL - but apparently only on the storefront preview render path, since the Theme Editor’s own render is unaffected.

What worked around it: a second CLI push alone did not fix it. Opening the theme customizer (/admin/themes/[theme-id]/editor) and clicking Save once with no changes forced Shopify to recompute the bundle’s version hash, which busted the stale cache and fixed the preview too.

So: don’t assume your CSS is wrong if the editor looks right but preview doesn’t - confirm via “shopify theme pull” diff that the file actually deployed, then if preview is still stale, try the customizer Save trick before re-pushing repeatedly.

This seems to be the same root cause reported across multiple threads on this bug (compiled_assets/styles.css not recompiling its fingerprint reliably), just surfacing here specifically as an editor-vs-preview mismatch rather than editor-vs-live.

What type of topic is this

Bug report

2

Hey @Taksh_Shah - thanks for flagging this.

I can’t confirm the root cause yet, but the unchanged v= value plus the no-op Theme Editor save forcing a refresh does seem odd. To look into this on our end, could you share:

  • Shop domain + theme ID + affected preview URL/page path
  • UTC timestamp when you reproduced it
  • The stale compiled_assets/styles.css URL, response headers, and any request IDs/HAR from the HTML + CSS requests
  • The specific selector/rule expected vs the stale rule served

Also just confirming: are you opening the ?preview_theme_id= URL from Admin with the preview bar visible, or navigating to it manually?

If you’d rather share shop/theme details privately, let me know and I can set up a DM.

3

Hey Alan, yes I’d prefer to share privately if you can setup a DM.
Can share findings here later, once we pinpoint the issue.
Please setup a DM, I’ll do fresh test to record results.

4

Usinge the preview_theme_id= from shopify CLI while running theme dev.
I have experienced this on published themes too in past but that was weeks ago haven’t tested live themes recently.

6

Hey @Taksh_Shah - thanks for confirming.

For local theme development, I’d recommend using the local URL returned by shopify theme dev, usually http://127.0.0.1:9292, as the source of truth for validating local changes.

The ?preview_theme_id= storefront URL is better treated as a share/preview URL rather than the main local development surface, so it may not always reflect local theme-dev changes in the same way as the localhost preview.

Could you do a fresh test against the localhost URL from shopify theme dev and confirm whether the CSS updates correctly there?

If localhost is rendering correctly, then I’d stick with that for local dev validation. If you’re still seeing stale CSS on localhost, in the Theme Editor, on a generated share preview link, or on the published theme without preview_theme_id, then please just grab the timestamp, affected path, compiled asset URL, and response headers and we can dig further on our end.

Let me know what you see after testing against localhost. Hope this helps!