Design systems precisam ser rápidos por padrão, defende artigo

A tese do texto é direta: o design system fica na base da pilha (navegador, framework, biblioteca compartilhada, produto), e a main thread é uma só. Se o equivalente ao select leva um segundo para abrir, nenhum app construído sobre ele escapa disso. O autor compara com acessibilidade: times já validam teclado e ARIA antes de cada release, mas raramente testam componentes com volume realista de dados.

Os testes cobriram dez sistemas (Mantine, Ant Design, Material UI, React Spectrum, Carbon, Fluent, Web Awesome, UI5, Spectrum Web Components e Ionic), em builds de produção, no Chrome com CPU reduzida em 4x e mediana de três execuções. Em um seletor com 249 países, Fluent e Carbon abriram mais rápido, e o do Ionic levou mais de cinco vezes o tempo do segundo mais lento. Com 50 opções o Ionic gastou 203ms, contra mais de 1,2 segundo com 249. Já no teste de 100 checkboxes, o Ant Design levou seis vezes o tempo do Material UI, ambos em React. O framework sozinho não explica o resultado.

No Ionic, o profiling apontou o tratamento de slots do Stencil em um radio group sem shadow DOM, com varreduras repetidas dos filhos a cada nova opção. O Ant Design, por outro lado, renderiza só as opções visíveis (virtualização) e mantém uma cópia oculta da opção destacada para leitores de tela. Para fixar o padrão, o texto sugere testes com budgets explícitos e publicação dos números.

O CEVIU já tinha tratado o mesmo texto. 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 olhar só o tamanho do bundle não captura interações caras. Em 30 de outubro de 2026, a cobertura "Design systems deveriam ser rápidos por padrão, defende artigo com benchmarks" falou em três causas: layout repetido, slots e animações por checkbox. Agora o recorte traz os números comparativos (Fluent e Carbon na frente, Ionic atrás) e as medidas de prevenção, como testes com Playwright, virtualização e publicação dos resultados.

Para quem trabalha com design systems, a leitura é que performance deixa de ser problema do time de produto e vira critério de qualidade do componente, como já é a acessibilidade. Para designers, isso pesa na hora de decidir padrões de interação: um seletor de 249 itens exige solução pensada (busca, virtualização) e não só visual. O cuidado com leitores de tela na virtualização mostra que velocidade e acessibilidade precisam ser desenhadas juntas.