Design systems deveriam ser rápidos por padrão, defende artigo com benchmarks

O argumento central do texto é de arquitetura. O navegador tem uma única main thread para rodar JavaScript, responder a eventos e desenhar a tela. Se um componente de design system leva um segundo para abrir uma lista, o app que o consome herda esse custo, por melhor que seja o resto do código. O autor defende que performance fique na lista de prioridades ao lado de acessibilidade.

Os testes cobriram dez bibliotecas (Mantine, Ant Design, Material UI, React Spectrum, Carbon, Fluent, Web Awesome, UI5, Spectrum Web Components e Ionic), em Chrome v155, com CPU limitada em 4x e mediana de três execuções. Duas tarefas: abrir um seletor com 249 países e marcar 100 checkboxes. Só o Spectrum Web Components parecia rodar benchmarks automáticos por pull request. Fluent tem benchmarks, mas sem execução automática visível. Ant Design, Material UI e Fluent checam tamanho de bundle, que não mede a resposta do componente.

O caso do Ionic é o mais detalhado. Com 50 opções, o seletor levou 203ms, mas passou de 1,2 segundo com 249. A causa está no runtime do Stencil: como o ion-radio-group não usa shadow DOM, o Stencil substitui appendChild e insertBefore e percorre as opções já existentes três vezes a cada inserção, o que gera custo crescente. Isso vem da configuração appendChildSlotFix, ativada via experimentalSlotFixes, hoje false por padrão, mas prevista para virar true no Stencil v5, segundo a documentação citada. Removendo a terceira checagem numa cópia do Stencil, a inserção de 2.000 elementos ficou cerca de sete vezes mais rápida. Já o Ant Design abriu mais rápido por renderizar só as opções visíveis (virtualização), com cerca de 40 elementos novos no DOM contra cerca de 250 no Material UI.

Em 27 de outubro de 2026, o CEVIU noticiou "Design systems deveriam ser rápidos por padrão, defende análise com testes em dez bibliotecas", com foco nos caminhos lentos e na limitação de olhar só o bundle. Esta nova matéria acrescenta o desenho dos testes em Playwright com budgets de tempo, que fazem componentes compartilhados falharem diante de regressões de performance.

Para quem mantém um design system, a leitura é que medir bundle não basta: vale testar cada componente com volumes realistas e transformar o tempo de interação em teste que quebra o build. Para quem consome essas bibliotecas, o recado é checar o comportamento com listas grandes antes de adotar, já que o time do app dificilmente consegue corrigir o gargalo por conta própria.