Microsoft enxuga o clarity.js em 4,5% sem quebrar a compatibilidade
Aprofundamento CEVIU
Aprofundamento
O clarity.js é o script que roda nos sites que usam o Clarity e captura os dados de comportamento por trás dos insights da ferramenta. Como carrega junto com todo o resto da página, cada byte conta. A Microsoft usou o pi, um agente de IA de código, com autoresearch: ele altera o código, gera o build, mede a saída comprimida, roda a suíte de testes e decide se mantém ou reverte. Depois de mais de 50 experimentos, o script ficou 1.257 bytes gzip menor (4,5%), sem cortar funcionalidade.
O achado central é que código mais limpo no fonte nem sempre vira download menor. Extrair um helper coordinates() reduziu 264 bytes brutos, mas aumentou 23 bytes no gzip, porque o gzip já comprimia os quatro blocos idênticos quase a zero. O ||= também piorou, por ser um padrão raro na saída. Os ganhos vieram de trocar import * as por named imports (menos 444 bytes gzip, 35% da economia, já que o Rollup gerava cinco objetos wrapper), remover funções inteiras (menos 84), ajustar o terser com passes: 3, hoist_vars: true e freeze: false (menos 301), trocar template literals por concatenação no alvo ES5 (menos 110) e substituir um bloco de 27 linhas por Object.assign({}, buffer) (menos 109). Property mangling causou colisão com nomes de propriedades do DOM.
A maior economia ficou de fora. Subir o alvo do TypeScript de ES5 para ES2017 eliminaria os polyfills __awaiter/__generator e, com ES2020, pouparia 2.308 bytes gzip. Mas o Zone.js, usado em apps Angular, faz patch em Promise e espera o async/await gerado em ES5. Com async/await nativo, a detecção de mudanças do Angular quebra sem aviso.
O que mudou
Não há evolução do mesmo projeto na cobertura anterior. Matérias como a de 10 de agosto de 2026, "Otimização de Extensões do Azure Pipeline: esbuild Reduz Tempos de Download em 17x", e a de 29 de outubro de 2026, sobre a skill de IA do Next.js 16.4 para enviar menos JavaScript ao cliente, tratam do mesmo tema geral (reduzir JavaScript entregue), mas de outros produtos.
Por que isso importa
Para quem otimiza bundle, a lição prática é medir o tamanho gzipado, não o bruto, e testar uma mudança por vez. Para quem publica scripts de terceiros, o caso do Zone.js mostra que o alvo de compilação é decisão de compatibilidade, não só de tamanho. É uma leitura editorial, mas o exemplo sugere que automatizar microexperimentos compensa onde um humano não gastaria tempo.
Linha do tempo
CEVIU noticia a otimização de extensões do Azure Pipeline com esbuild (tema relacionado de bundle).
CEVIU noticia a skill de IA do Next.js 16.4 para enviar menos JavaScript ao cliente (tema relacionado).
Microsoft reduz o clarity.js em 1.257 bytes gzip (4,5%) com experimentos automatizados.
Perguntas frequentes
Quanto o clarity.js ficou menor?
Ficou 1.257 bytes gzip menor, uma redução de 4,5%. O resultado veio de mais de 50 experimentos automatizados, sem reduzir a funcionalidade do script.
Por que extrair helpers pode aumentar o tamanho gzip?
O gzip comprime sequências repetidas quase de graça. Um helper novo traz nome, assinatura e chamadas únicas, que custam bytes. No caso do coordinates(), o tamanho bruto caiu 264 bytes, mas o gzipado subiu 23.
Por que a Microsoft não subiu o alvo do TypeScript para ES2017?
A mudança economizaria 2.308 bytes gzip, mas quebraria sites Angular com Zone.js. O Zone.js espera o async/await gerado em ES5 e não intercepta o nativo, o que quebra a detecção de mudanças do Angular sem erro visível.
Qual mudança deu o maior ganho?
A troca de namespace imports (import * as) por named imports, com menos 444 bytes gzip, cerca de 35% da economia total. Isso vale quando o namespace é passado como valor, caso em que o Rollup cria um objeto wrapper.
Fontes
- clarity.microsoft.comfonte original
- Categoria
- CEVIU Web Dev
- Publicado
- 05 de novembro de 2026
- Editoria
- CEVIU Web Dev

