O GitHub publicou em 25 de setembro os resultados de uma migração que retirou CSS-in-JS de sua interface e passou a entregar estilos com arquivos estáticos. A adoção de CSS Modules no GitHub reduziu trabalho durante a renderização no servidor e durante a inicialização de componentes no navegador, segundo medições da própria empresa.
No relato técnico, o GitHub informa que o Primer, seu sistema de design, registrou redução de 55% no tempo de renderização no servidor e de 25% no tempo de inicialização de componentes em testes internos. A migração completa do site havia sido concluída em junho de 2026 e foi detalhada agora pela equipe de engenharia.
Por que CSS-in-JS custava tempo de execução
CSS-in-JS permite manter estilos próximos aos componentes e gerar regras a partir de propriedades. Essa flexibilidade vem com trabalho adicional: a aplicação precisa interpretar JavaScript, criar classes, resolver valores e injetar estilos enquanto monta a página. Em uma plataforma do tamanho do GitHub, pequenas operações repetidas em muitos componentes acumulam custo.
Com CSS Modules no GitHub, boa parte desse trabalho passa para a etapa de build. Os componentes importam classes com escopo local, enquanto o navegador recebe CSS que pode analisar e aplicar com mecanismos nativos. O JavaScript continua responsável pela interação, mas deixa de fabricar grande parte da apresentação durante a execução.
Isso também altera o caminho crítico da página. CSS disponível cedo pode ser processado enquanto outros recursos carregam, reduzindo a dependência de baixar e executar JavaScript antes de exibir a interface com o estilo correto.
A migração foi feita por partes
O GitHub não trocou todos os componentes em uma única entrega. A equipe criou compatibilidade temporária, migrou componentes do Primer, ativou mudanças com feature flags e usou testes de regressão visual para comparar resultados. Esse método permitiu identificar diferenças de aparência sem bloquear toda a evolução do produto.
O processo se aproxima de outras migrações em que o comportamento precisa permanecer estável enquanto a implementação muda. O texto sobre APIs e testes automatizados descreve o mesmo princípio aplicado a contratos: evolução gradual exige verificações que detectem quebra antes da publicação.
Também houve trabalho para lidar com regras dinâmicas. Nem todo valor calculado precisa virar uma nova classe. Variáveis CSS podem carregar valores definidos pelo componente sem exigir que uma biblioteca gere uma folha de estilos inteira em runtime.
Os números dependem da arquitetura
As reduções de 55% e 25% foram medidas no contexto do Primer e do GitHub. Um site pequeno, uma aplicação com pouco CSS-in-JS ou um framework com extração estática pode observar resultado diferente. A comparação precisa separar tempo de servidor, JavaScript enviado, inicialização do cliente, estabilidade visual e cache.
O post sobre arquitetura simples em serviços web ajuda a enquadrar a decisão: remover uma camada de runtime vale quando reduz custo operacional sem perder uma capacidade necessária.
O fluxo adotado pelo GitHub
A sequência documentada foi medir o custo atual, preparar componentes equivalentes, liberar por flags, executar testes visuais e ampliar a adoção até retirar a solução anterior. As métricas do Primer foram usadas para verificar o efeito, não como estimativa universal.
Para equipes que avaliam mudança semelhante, o dado necessário é local: quantidade de JavaScript eliminada, tempo de renderização, início de interação, incidência de regressões e esforço para manter estilos dinâmicos. CSS Modules no GitHub funcionaram dentro desse conjunto de requisitos e medições.
O tamanho real da migração
A retirada do `sx`, a propriedade de estilo usada em componentes React do Primer, mostra a escala do trabalho. O GitHub contabilizou cerca de 7.760 usos no início da fase principal. Oito engenheiros migraram 6.419 deles ao longo de seis meses; o restante foi removido ou tratado por outras mudanças. A equipe começou esse esforço em abril de 2025 e concluiu a adoção integral de CSS Modules no site em junho de 2026.
O Primer já havia feito uma etapa anterior. Até dezembro de 2024, seus componentes estavam migrados para a nova base. Foi nesse conjunto que o GitHub mediu redução de 55% no tempo de renderização no servidor e de 25% na inicialização dos componentes. Nas páginas do produto, os ganhos de renderização no servidor variaram entre 1% e 22%, diferença que reforça o efeito da composição de cada rota.
Esses dados também mostram por que a troca não pode ser resumida como instalar uma dependência. O sistema de design, os componentes do produto e milhares de chamadas de estilo precisaram convergir. Ao final, GitHub retirou `sx`, styled-components e styled-system do caminho principal, reduzindo compatibilidade temporária e custo de manutenção duplicado.
Escopo local sem geração em runtime
A documentação de CSS Modules define o mecanismo em torno de arquivos CSS cujas classes e animações têm escopo local por padrão. Um componente importa um mapa de nomes e aplica a classe correspondente. Durante o build, ferramentas geram identificadores que evitam colisões globais e produzem folhas de estilo comuns para o navegador.
Esse modelo preserva uma vantagem que atraía equipes para CSS-in-JS: associar estilos ao componente sem depender de convenções globais frágeis. A diferença é quando o trabalho ocorre. Em vez de calcular regras a cada renderização, a maior parte é resolvida antes da entrega. O navegador recebe CSS, e o componente recebe referências estáveis às classes.
Valores verdadeiramente dinâmicos continuam possíveis. Variáveis CSS podem transportar cor, tamanho ou posição calculados, enquanto classes descrevem a estrutura. Variantes discretas, como tamanho pequeno, médio ou grande, podem ser classes compostas. A migração fica mais simples quando a equipe separa o que é escolha entre estados conhecidos do que depende de um valor produzido a cada interação.
A camada de transição evitou uma troca abrupta
O GitHub criou `@primer/styled-react` como uma interface temporária. Ela ofereceu compatibilidade suficiente para que produtos mudassem em etapas enquanto o sistema de design avançava. Feature flags permitiram comparar versões antigas e novas, e testes de regressão visual registraram diferenças antes da liberação ampla.
Esse tipo de camada precisa ter prazo de retirada. Se dois sistemas permanecem indefinidamente, cada componente novo pode escolher um caminho diferente e ampliar a dívida. No caso relatado, a direção era explícita: migrar o Primer, converter usos de `sx`, medir páginas e remover as bibliotecas de runtime quando a cobertura chegasse ao fim.
Revisão visual foi necessária porque equivalência de código não garante equivalência de aparência. Especificidade, ordem das folhas, estados de foco, responsividade e temas podem mudar sem erro de compilação. Snapshots ajudam a detectar a alteração, mas uma pessoa ainda precisa decidir se a diferença é defeito ou resultado esperado.
Quando CSS-in-JS ainda pode ter utilidade
O relato não estabelece que todo CSS-in-JS é lento da mesma forma. Há bibliotecas que extraem estilos em build, aplicações pequenas nas quais o custo não é significativo e interfaces com geração dinâmica difícil de expressar em classes. A decisão depende do mecanismo usado, do volume de componentes, da renderização no servidor e do orçamento de JavaScript.
Antes de migrar, uma equipe deve medir quanto tempo é gasto na criação de estilos, qual JavaScript pertence à solução atual, quando o CSS fica disponível e quantas regras são realmente dinâmicas. Se o gargalo está em consulta de dados ou processamento pesado, mudar estilos pode não alterar a experiência. Se milhares de componentes repetem trabalho durante renderização, a oportunidade cresce.
A manutenção também conta. Tipagem de tokens, experiência do desenvolvedor, theming, ferramentas de lint e depuração precisam ter substitutos claros. O `sx` oferecia propriedades tipadas e acesso direto ao sistema de design. O novo fluxo teve de manter esses benefícios por APIs, classes e variáveis compatíveis com os componentes.
Como testar uma migração semelhante
Uma linha de base deve registrar renderização no servidor, JavaScript transferido, tempo de inicialização, CSS transferido, maior renderização de conteúdo e estabilidade visual. Rotas leves e pesadas precisam ser medidas separadamente. Depois, um grupo pequeno de componentes pode migrar com flag, mantendo a mesma carga e o mesmo ambiente de teste.
O resultado deve incluir desempenho e custo de engenharia: regressões visuais, tempo para converter um componente, dificuldade para temas, quantidade de exceções e conhecimento exigido na manutenção. Ganho de 10% em uma rota crítica pode justificar a mudança; ganho imperceptível acompanhado de grande complexidade pode não justificar.
O caso do CSS Modules no GitHub fornece números concretos e uma sequência operacional, mas não uma porcentagem pronta para outros sites. A evidência transferível é o método: localizar trabalho de runtime, mover o que for estático para build, preservar estilos dinâmicos com mecanismos nativos, liberar por etapas e remover a camada anterior somente depois de medir comportamento e aparência.
