Design systems deveriam ser rápidos por padrão, defende análise com testes em dez bibliotecas

A tese do texto é direta: se um componente do design system é lento, todo app construído sobre ele herda a lentidão, porque o navegador tem uma única thread principal para JavaScript, eventos e desenho. O autor testou dez bibliotecas 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 próprio da SAP) e Ionic 9.0.7 (Stencil). Os testes rodaram em builds de produção, Chrome v155, CPU com throttling de 4x e mediana de três execuções.

Duas tarefas serviram de régua: abrir um seletor com os 249 países da lista ISO e marcar 100 checkboxes de uma vez. Só o Spectrum Web Components parecia rodar benchmark por componente a cada pull request. Ant Design, Material UI e Fluent medem tamanho de bundle, o que ajuda no carregamento mas não diz nada sobre a resposta de um componente. O resultado mais visível: o seletor do Ionic levou 203ms com 50 opções e mais de 1,2 segundo com 249, com a UI travada quase todo o tempo, enquanto o do Fluent foi de 41ms para 61ms. Ant Design levou seis vezes mais que Material UI para marcar os checkboxes, mesmo ambos usando React. Logo, o framework sozinho não explica o desempenho.

O profiling apontou causas diferentes. No Ionic, a runtime do Stencil substitui appendChild e insertBefore no ion-radio-group (que não usa shadow DOM), por causa de appendChildSlotFix, ativado via experimentalSlotFixes. Cada nova opção varre as anteriores duas vezes, então o custo cresce a cada inserção. Ambas as flags são false hoje, mas a documentação do Stencil indica que devem virar true por padrão no v5. No Material UI, o DOM ganha cerca de 250 elementos ao abrir; no Ant Design, só cerca de 40, porque ele virtualiza a lista e mantém uma cópia oculta da opção destacada para leitores de tela. No UI5, cerca de metade do tempo foi Rendering: as 249 opções já estão num popover oculto e o navegador estiliza tudo de uma vez, algo como 1.500 elementos.

A cobertura anterior do CEVIU toca temas vizinhos, mas não acompanha esses testes nem essas bibliotecas. Em 26 de outubro de 2026, o CEVIU noticiou "Metade das métricas de design system já não funciona, diz artigo", que questiona métricas como número de componentes e downloads. A análise de agora complementa esse debate com uma medida concreta de desempenho por componente. Em 22 de outubro de 2026, em "Velocidade também é uma decisão de design", o foco era performance de sites em geral, não de design systems.

Para quem mantém um design system, a leitura é que olhar só o bundle deixa passar o que o usuário sente: o clique que trava. Um teste em Playwright com orçamento de tempo por interação, rodando a cada pull request, trata performance como já se trata acessibilidade. Para quem consome essas bibliotecas, vale medir com listas longas e CPU limitada antes de adotar um componente, já que o time do app dificilmente consegue consertar a causa.