Shopify turns 64KB limit into a design system rule in checkout

What Shopify changed in Checkout Blocks

Shopify detailed, in a technical post published this week, the rebuild of the Checkout Blocks app, used to customize checkout without writing code. Five high-traffic extensions, present in about a third of all customized checkouts, moved away from React with the legacy Remote UI bridge and started using remote-dom with Preact and Polaris web components. The code was rewritten in TypeScript and migrated from API version 2025-07 to 2026-01 (source: InfoQ).

The result in numbers: transferred package sizes dropped between 40% and 85%, with the payment icons extension shrinking 84.4%. Extension load time fell about 8% at the median and 7% at the 90th percentile, weighted by checkout volume. For those designing a store's checkout, this means payment screens appearing faster at the most sensitive moment of the purchase journey, when any friction can cost a conversion.

A performance budget became a design system rule

The drop didn't come from good engineering intentions alone: the 2026-01 version of the remote-dom CLI started enforcing a hard cap of 64KB gzip per extension, down from the 100KB to 112KB gzipped that older extensions used to weigh. In practice, Shopify turned a performance goal into a mandatory constraint of the Polaris design system, the same way an accessibility or spacing guideline is also mandatory.

This is the product decision that matters to anyone maintaining a design system: performance stopped being a recommendation in the style guide and became a constraint that the build tooling itself refuses to ignore. Teams that today treat "performance" as a recurring backlog item can look at this case as a model for turning the goal into a CI rule, instead of relying on each squad's goodwill.

The technical trade-offs that fit within the budget

To fit within the 64KB cap, the team swapped out entire pieces of the stack:

• React for Preact, eliminating react-reconciler and saving about 89KB on its own;
• liquidjs (about 73KB) for a proprietary parser nicknamed "droplet", at 13KB gzipped, validated against a 42,000-line parity corpus taken from real merchant configurations;
• dayjs for a smaller, proprietary date utility;
• markdown-to-jsx was kept, but aliased to run on top of Preact instead of being replaced.

For product thinkers, the revealing detail is what Shopify decided NOT to swap: markdown-to-jsx survived the cut because rewriting it wasn't worth the effort relative to the bundle gain. It's the kind of prioritization call every performance roadmap requires, and one that rarely gets documented in a public case like this.

The price of consistency: incomplete components

The push to migrate everything to framework-agnostic web components (the s-* elements loaded from Shopify's CDN) took effect as early as API version 2025-10, released in late 2025. At the time, the reception was largely positive: the development platform Gadget called the change

a great update

Gadget, a development platform for Shopify apps

highlighting that Preact delivers a React-like experience at a fraction of the runtime. On Hacker News, developers praised the fact that the components come without Shadow DOM, though some warned that web components "are not a panacea" and don't replace framework component systems.

A year later, with 2026-01 becoming the mandatory path, sentiment turned more divided. A Reddit thread classified the new components as incomplete, citing the lack of an equivalent to IndexTable, which existed in Polaris React, a component used to list and manage records in admin screens. It's the kind of gap that PMs and designers feel first: the design system's visual consistency improved, but the available component catalog shrank.

Migration with no middle ground

Shopify didn't leave the adoption of version 2026-01 as a scheduling choice for each team: since October 1, 2026, deployments of apps still using extension versions earlier than 2026-01 are blocked. In April 2026, a developer had already complained on Shopify's forums about another side effect of this architecture:

a nightmare for stability

Developer on Shopify's forum, April 2026

The complaint was about publishing a CDN script with no fixed versioning, no way to pin a specific version. The point remained active in the community in mid-2026: when a design system lives on a shared CDN, losing control over which component version is running on a customer's store is a risk that product ops would normally not accept in other parts of the stack.

What this teaches about designing a design system

For those leading product or design system teams, the Checkout Blocks case brings together three decisions that normally appear separately: a performance target turning into a build rule, selective dependency swaps based on measured real cost (not preference), and a deprecation schedule with a fixed date and no fallback. All three were decided in the same migration, and each brought its own friction, from the loss of IndexTable to the lack of pinnable versioning.

Anyone maintaining a checkout app, a theme, or an extension on top of Shopify has a practical reason to review the dependency list in the upgrade and migration guides published by the company itself for Checkout and Customer Account extensions before the next mandatory cycle. And anyone designing their own design system, inside or outside the Shopify ecosystem, gets a concrete example here of how far it's worth imposing technical constraints in the name of consistency, and where that same constraint starts demanding completeness back.