Action Required Themes

{% stylesheet %} The CSS in
is automatically narrowed to "only the pages that use it"

Starting April 20, 2026, Shopify will deliver only the CSS related to the sections / blocks / snippets actually rendered on each page. The old approach of loading all CSS on every page is going away. Self-contained themes need no changes, but if you reference classes across files, styles can go missing.

What's on this page
  1. What's actually changing (understand in 30 seconds)
  2. How it works: traditional delivery vs subset delivery
  3. Determining whether you're affected
  4. Concrete examples of what breaks
  5. Response checklist (3 steps)
  6. 5 key points engineers should know
  7. 3 use cases you can apply to your work
  8. One-line summary for proposals

1What's actually changing

Until now {% stylesheet %} CSS written inEverything bundled together on every pagewas being delivered.
Starting April 20, 2026,only the CSS related to the section / block / snippet actually rendered on that pagewill be delivered (CSS subset delivery). The goal is to improve storefront rendering performance.

Before: everything bundled together

All {% stylesheet %} CSS was delivered on every page load regardless of content. Unused CSS was shipped along with the rest.

From now on: only the relevant portion is delivered

Only the CSS related to the section / block / snippet rendered on that page is delivered. Unnecessary CSS is reduced, making the page lighter.

Tagged as Action Required.A change that Shopify will apply automatically on or after April 20, 2026. Self-contained themes don't need to do anything, but themes that reuse classes across files need to check and fix themin advance.

2Diagram: traditional delivery vs subset delivery

Theme files section-a.liquid + CSS block-b.liquid + CSS snippet-c.liquid + CSS section-d.liquid + CSS Product page Only A and C are rendered Render section-a Render snippet-c B and D are not rendered CSS that gets delivered A's CSS ✓ C's CSS ✓ B and D's CSS is not bundled CSS that gets excluded B's CSS ✕ D's CSS ✕ Not needed on this page
The key point is "Only the CSS of rendered files gets loaded". When a file is {% render %} the direct children called via that method are rendered together with the parent, so their CSS is also delivered together. The problem case is when you rely on "CSS from files that aren't rendered".

3How to tell if you're affected

No change needed

Your CSS is self-contained

Each file's {% stylesheet %} only targetsHTML elements in the same fileor{% render %} directly nested children referenced withis the only thing being styled. → Already compatible. Nothing needs to be done.

Needs attention

A class is used across multiple files

In one file, {% stylesheet %} defines a class, butan unrelated separate fileuses it on an HTML element. → Styles won't apply on pages where the definition isn't rendered. This isthe pattern you should find and fix.

How CSS classes are usedBehavior on and after 4/20Action needed
Applies only to elements in the same file Works as is None
{% render %} Applies to direct children called with Works as is(Delivered together with the parent) None
Applies to elements in unrelated separate files Risk of missing styles(Page where the definition source isn't rendered) Fix required

4Concrete example of a breaking pattern

Reducing the article's explanation to a typical structure looks roughly like the following (code is a schematic example for understanding).

Bad: definition and usage live in separate files

// section-promo.liquid (the file that defines this class) {% stylesheet %} .badge-sale { color: red; font-weight: bold; } {% endstylesheet %} // product-card.liquid (a separate file using .badge-sale) <span class="badge-sale">SALE</span> ← definition lives on the section-promo side
section-promo is not rendered (e.g., product-card only this page is rendered) .badge-sale the CSS forisn't delivered, so the red color and bold styling aren't applied. This is the "classes used in other unrelated files" issue the article describes.

OK: Definition and usage live in the same file, or are kept within parent-child scope

// product-card.liquid (defined and used in the same file) <span class="badge-sale">SALE</span> {% stylesheet %} .badge-sale { color: red; font-weight: bold; } {% endstylesheet %} // Direct children called via render are delivered together {% render 'badge', text: 'SALE' %} ← Rendered at the same time as the parent → child CSS is bundled in
If a class is used only inside "the file where it's defined" or "a child called via{% render %} ", then whenever that file is rendered the CSS is guaranteed to ship with it, so it won't go missing.

5Compatibility check flow (3 steps)

1

Identify cross-file references

{% stylesheet %} Across all theme files, check whether class names defined in are being used in HTML files other than the one where they are defined.

2

Refactor toward self-contained styles

Move the relevant classes into the consuming file's {% stylesheet %} or{% render %} restructure them so they stay scoped within a parent-child relationship.

3

Verify rendering on each template

Preview pages such as product, collection, and cart to check for layout issues on pages where the defining file isn't rendered.

For a detailed remediation guide, see the "stylesheet subsetting documentation" (no specific URL isprovided in the article)).

65 key points engineers should know

4/20

1. Auto-applied, rolling out from April 20

Shopify will progressively enable this starting April 20, 2026. It's not opt-in — the behavior itself changes, so finish your audit and fixes before then.

2. Delivery is scoped to rendered elements

Delivery targets the CSS associated with the section / block / snippet rendered on that page. Files that aren't rendered {% stylesheet %} won't be loaded.

3. Children of render are delivered together

{% render %} Children invoked via this method are rendered at the same time as the parent, so the child's CSS is bundled together. A design closed within parent-child is safe.

4. The danger is "cross-file references"

The single point of failure is where a class is reused in a file unrelated to its definition source. CSS goes missing on pages where the definition source is not rendered.

5. Verify across templates. Refer to the documentation for details

Since the impact appears on "pages where the definition source is not rendered," check multiple templates such as product / collection / cart / search via real-device preview. For specific fix procedures, refer to the stylesheet subsetting documentation the article points to (the article body containsno detailed steps or URL).

7Three use cases you can apply to your work

USE CASE 1

Sweeping audit of "cross-file CSS dependencies" in existing themes

Challenge
In a theme that has been added to over many years, you don't have a grasp of which classes are defined in which files and where they are used. You can't tell whether style breakage will occur after 4/20.
Action
Cross-reference all class definitions in {% stylesheet %} with the class usage on the HTML side, and list out locations where the definition and usage live in separate files.
Impact
You can identify the spots that will break on or after 4/20 ahead of time and avoid production incidents. The audit results can be used directly as the basis for remediation estimates.
Technical notes
The criterion is whether it is self-contained within the same file or as a direct child of {% render %} . If self-contained, no action is needed.
Display speed
USE CASE 2

Explained as a performance improvement suggestion that "takes effect automatically"

Problem
Pages are bloated with unused CSS and you want to improve load speed, but proposing CSS splitting is hard because the effort is difficult to estimate.
Approach
Explain that starting 4/20, Shopify will roll out per-page CSS subsetting. Just by keeping the theme self-contained, unused CSS will no longer be loaded on every page.
Impact
The amount of CSS delivered on each page decreases, making storefront loads lighter (the article's main focus = performance improvement).
Technical notes
The reduction depends on theme structure. Concrete improvement figures arenot statedin the article, so measure before/after and present the results.
Common
USE CASE 3

Standardize CSS design rules for new and refactored themes around "self-contained" styles

Problem
On themes touched by multiple people, CSS ends up scattered across files, making cross-file dependencies easy to introduce.
Approach
Make it a design rule that "CSS lives in the same file as the element it styles, or {% render %} scoped to its children." Reject cross-file references at review time.
Impact
Becomes compatible with subset delivery from day one, structurally eliminating the risk of future breakage. Readability and maintainability also improve.
Technical notes
The article explicitly states how to consolidate shared styles (such as where to place them so they are always delivered)Not specified. Confirm in the documentation and codify as a rule.

8A one-line summary you can use in proposals

"Starting April 20, 2026, {% stylesheet %} CSS foris delivered only for the elements rendered on the page.
CSS isin the same file, or {% render %} If they are scoped within children of this element, no changes are needed.
Only the places where classes are reused across filesneed to be identified and refactored to be self-contained."