Shopify transforma limite de 64KB em regra de design system no checkout

O que a Shopify mudou no Checkout Blocks

A Shopify detalhou, em post técnico publicado nesta semana, a reconstrução do app Checkout Blocks, usado para customizar o checkout sem escrever código. Cinco extensões de alto tráfego, presentes em cerca de um terço de todos os checkouts personalizados, saíram do React↳React37 conteúdos7 erros com React moderno que só aparecem em produção; e como evitarDev (Back & Front) · abr 2026React Native 0.76: o futuro do desenvolvimento mobileDev (Back & Front) · out 2024Simplificando componentes com React HooksDev (Back & Front) · mar 2019Ver tudo em Dev (Back & Front) → com a ponte legada Remote UI e passaram a usar remote-dom com Preact e os componentes web do Polaris. O código foi reescrito em TypeScript e migrado da versão de API 2025-07 para a 2026-01 (fonte: InfoQ).

O resultado em números: o tamanho dos pacotes transferidos caiu entre 40% e 85%, com a extensão de ícones de pagamento encolhendo 84,4%. O tempo de carregamento das extensões caiu cerca de 8% na mediana e 7% no percentil 90, ponderado pelo volume de checkouts. Para quem desenha o checkout de uma loja, isso significa telas de pagamento aparecendo mais rápido no momento mais sensível da jornada de compra, quando qualquer atrito pode custar conversão.

Um orçamento de performance virou regra do design system

A queda não veio só de boas intenções de engenharia: o CLI da versão 2026-01 do remote-dom passou a impor um teto rígido de 64KB gzip por extensão, contra os 100KB a 112KB gzipped que as extensões antigas costumavam pesar. Na prática, a Shopify transformou um objetivo de performance em restrição obrigatória do design system↳Design system5 conteúdosComo desenvolvemos o novo Design System do AsaasProduto & UX · jul 2024UX e Código: Por que designers que conhecem programação têm uma vantagem estratégicaProduto & UX · abr 2025A importância do HTML e CSS para quem trabalha com UI Design e Design SystemProduto & UX · dez 2024Ver tudo em Produto & UX → Polaris, do jeito que uma guideline de acessibilidade ou de espaçamento também é obrigatória.

Essa é a decisão de produto que interessa a quem mantém um design system: performance deixou de ser recomendação no guia de estilo e virou constraint que o próprio tooling de build recusa a ignorar. Times que hoje tratam "performance" como item de backlog recorrente podem olhar para esse caso como modelo de como transformar a meta em regra de CI, em vez de depender de boa vontade de cada squad.

As trocas técnicas que couberam dentro do orçamento

Para caber no teto de 64KB, a equipe trocou peças inteiras da stack:

• React por Preact, eliminando o react-reconciler e economizando cerca de 89KB sozinho;
• liquidjs (cerca de 73KB) por um parser próprio apelidado de "droplet", com 13KB gzipped, validado contra um corpus de paridade de 42 mil linhas tirado de configurações reais de lojistas;
• dayjs por um utilitário de datas próprio, menor;
• markdown-to-jsx foi mantido, mas apontado (aliased) para rodar sobre Preact em vez de ser substituído.

Para quem pensa em produto, o detalhe revelador é o que a Shopify decidiu NÃO trocar: markdown-to-jsx sobreviveu ao corte porque reescrevê-lo não valia o esforço frente ao ganho de bundle. É o tipo de chamada de priorização que todo roadmap de performance exige, e que raramente aparece documentada num case público como este.

O preço da consistência: componentes incompletos

A direção de migrar tudo para componentes web agnósticos de framework (os elementos s-* carregados do CDN da Shopify) começou a valer já na versão de API 2025-10, lançada no fim de 2025. Na época, a recepção foi majoritariamente positiva: a plataforma de desenvolvimento Gadget chamou a mudança de

Uma grande atualização.

a great updateGadget, plataforma de desenvolvimento para apps Shopify

destacando que o Preact entrega uma experiência parecida com React a uma fração do runtime. No Hacker News, desenvolvedores elogiaram o fato de os componentes virem sem Shadow DOM, embora alguns tenham avisado que web components "não são panaceia" e não substituem sistemas de componentes de framework.

Um ano depois, com a 2026-01 virando caminho obrigatório, o sentimento ficou mais dividido. Uma thread no Reddit classificou os novos componentes como incompletos, citando a ausência de um equivalente ao IndexTable que existia no Polaris React, componente usado para listar e gerenciar registros em telas de admin. É o tipo de lacuna que PM e designer sentem primeiro: a consistência visual do design system ficou melhor, mas o catálogo de peças disponíveis encolheu.

Migração sem meio-termo

A Shopify não deixou a adoção da versão 2026-01 como escolha de cronograma de cada time: desde 1º de outubro de 2026, deployments de apps que ainda usem versões de extensão anteriores a 2026-01 são bloqueados. Em abril de 2026, um desenvolvedor já havia reclamado nos fóruns da Shopify sobre outro efeito colateral dessa arquitetura:

Um pesadelo para estabilidade.

a nightmare for stabilityDesenvolvedor no fórum da Shopify, abril de 2026

A queixa era sobre publicar um script de CDN sem versionamento fixo, sem forma de travar (pin) uma versão específica. O ponto segue ativo na comunidade em meados de 2026: quando o design system vive num CDN compartilhado, perder controle sobre qual versão do componente está rodando na loja de um cliente é um risco que product ops normalmente não aceitaria em outras partes do stack.

O que isso ensina sobre desenhar um design system

Para quem lidera produto ou design system, o caso Checkout Blocks junta três decisões que normalmente aparecem separadas: meta de performance virando regra de build, troca seletiva de dependências com base em custo real medido (não em preferência), e cronograma de depreciação com data fixa e sem fallback. As três foram decididas na mesma migração, e cada uma trouxe sua própria fricção, da perda do IndexTable à falta de versionamento pinável.

Quem mantém um app de checkout, um tema ou uma extensão sobre a Shopify tem motivo prático para revisar a lista de dependências nos guias de upgrade e migração publicados pela própria empresa para Checkout e Customer Account extensions antes do próximo ciclo de obrigatoriedade. E quem desenha um design system próprio, dentro ou fora do ecossistema Shopify, ganha aqui um exemplo concreto de até onde vale a pena impor restrição técnica em nome de consistência, e onde essa mesma restrição começa a cobrar completude de volta.

Fonte: InfoQ