Design systems deveriam ser rápidos por padrão, defende artigo com testes em dez sistemas
Aprofundamento CEVIU
Aprofundamento
A tese do artigo é direta: se um componente do design system é lento, todo app construído sobre ele herda a lentidão, porque o navegador tem uma única main thread para JavaScript, eventos e pintura. O autor testou dez sistemas em outubro de 2026: Mantine 9.7.1, Ant Design 6.6.5, Material UI 9.5.0 e React Spectrum 3.47.6 (React), além de Carbon 2.65.0, Web Awesome 3.14.0 e Spectrum Web Components 1.12.4 (Lit), Fluent 3.1.3 (FAST), UI5 2.27.2 (framework da SAP) e Ionic 9.0.7 (Stencil).
Os dois casos de estresse foram abrir um seletor com os 249 países da lista ISO e marcar 100 checkboxes de uma vez. Os testes usaram builds de produção, Chrome v155 e CPU com throttling de 4x. O resultado mais claro: o seletor do Ionic levou 203ms com 50 opções e mais de 1,2 segundo com 249, enquanto o do Fluent foi de 41ms para 61ms. O perfil mostrou que o Stencil, com o ajuste de slots ativado por experimentalSlotFixes e appendChildSlotFix, varre os filhos existentes três vezes a cada nova opção, num ion-radio-group sem shadow DOM. Já o Ant Design renderiza só as opções visíveis (virtualização), o que explica por que abriu mais rápido que o Material UI. O autor também notou que só o Spectrum Web Components parecia rodar benchmarks automaticamente por pull request.
O que mudou
O CEVIU já acompanhava o tema. Em 27 de outubro de 2026, noticiou "Design systems deveriam ser rápidos por padrão, defende análise com testes em dez bibliotecas", com foco em como o tamanho do bundle não captura interações caras. Em 30 de outubro de 2026, a matéria "Design systems deveriam ser rápidos por padrão, defende artigo com benchmarks" atribuiu a lentidão a layout repetido, tratamento de slots e animações por checkbox. Em 2 de novembro de 2026, saiu "Design systems precisam ser rápidos por padrão, defende artigo". A cobertura atual acrescenta a abordagem prática de performance budgets com Playwright, verificações de long frames e de escalonamento não linear.
Por que isso importa
Para quem mantém um design system, a leitura é que performance de interação merece teste automatizado, como já acontece com acessibilidade. Para quem só consome a biblioteca, vale medir com throttling de CPU antes de adotar um componente em listas grandes, já que o problema dificilmente é corrigível no código do app.
Linha do tempo
CEVIU noticia que métricas tradicionais de design system já não dizem muito sobre qualidade do trabalho.
Artigo com testes em dez design systems é publicado e coberto pelo CEVIU.
CEVIU detalha benchmarks que ligam a lentidão a layout repetido, slots e animações por checkbox.
CEVIU publica nova matéria sobre a defesa de design systems rápidos por padrão.
Cobertura atual destaca a abordagem prática com performance budgets, Playwright e virtualização.
Perguntas frequentes
Por que o tamanho do bundle não basta para medir a performance de um design system?
O bundle afeta o tempo de carregamento da página, mas não diz quão rápido um componente responde à interação. No teste, Ant Design, Material UI e Fluent checam bundle size, mas isso não captura casos como abrir um seletor com 249 opções.
Qual foi a causa da lentidão no seletor do Ionic?
O ion-radio-group não usa shadow DOM, então o Stencil trata os slots. Com experimentalSlotFixes e appendChildSlotFix ativos, ele checa todas as opções já inseridas três vezes a cada nova opção, e o custo cresce de forma não linear.
A escolha do framework define a performance do design system?
Não sozinha. Carbon, Web Awesome e Spectrum Web Components usam Lit, mas o seletor do Spectrum Web Components levou mais que o dobro do tempo do Carbon para abrir. O Ionic foi o mais lento no seletor, mas teve checkboxes mais rápidos que a maioria.
Como o teste foi feito?
Foram usados builds de produção no Chrome v155, num MacBook Pro M1 Pro, com CPU reduzida em 4x. Cada teste rodou três vezes e valeu a mediana. Os testes estão no repositório design-system-performance-tests, no GitHub.
Fontes
- denodell.comfonte original
- Categoria
- CEVIU Web Dev
- Publicado
- 06 de novembro de 2026
- Editoria
- CEVIU Web Dev