Como o Baseline ajuda a enviar menos JavaScript para o navegador

Enviar menos JavaScript é, provavelmente, a alavanca de performance mais subestimada no front-end. Cada kilobyte que atravessa a rede precisa ser baixado, parseado e executado, e no Brasil, onde 4G instável e aparelhos modestos ainda são a regra fora dos grandes centros, esse custo é sentido no tempo até a página ficar interativa. É nesse contexto que vale olhar para o artigo de Jad Joubran, destacado pela newsletter JavaScript Weekly #798, sobre como usar o Baseline para auditar dependências e cortar código de forma segura.

O que é o Baseline, rapidamente

O Baseline é a iniciativa (mantida por navegadores e pela comunidade via web.dev/MDN) que classifica quais recursos da plataforma web já são amplamente suportados. Em vez de você consultar caso a caso o caniuse para Intl, structuredClone, URL ou AbortController, o Baseline diz de forma objetiva se um recurso já é "widely available" nos navegadores relevantes. A sacada do artigo é usar esse selo como critério para decidir quando uma dependência do node_modules virou peso morto, porque o navegador já faz o mesmo trabalho de graça.

O método: agrupar antes de deletar

O que diferencia o texto de um simples "remova o lodash" é a proposta de um método reutilizável. Joubran sugere agrupar as dependências em clusters por finalidade, algo como:

• Internacionalização (formatação de datas, números, moedas): candidatas a serem substituídas por Intl.
• HTTP e rede: axios e afins, hoje muitas vezes cobertos por fetch.
• Primitivas de UI.
• Utilitários gerais, como o próprio lodash.

Para cada cluster, o método propõe perguntas antes de apagar qualquer coisa: o recurso nativo equivalente é Baseline? A API nativa cobre todos os casos de uso que você realmente usa da lib, ou só os triviais? Existe diferença de comportamento (por exemplo, arredondamento de números ou tratamento de fuso horário)? Essa disciplina evita o clássico erro de trocar uma dependência por uma API nativa e descobrir em produção que faltava um edge case.

Quando remover a lib aumenta o bundle

O ponto mais interessante do artigo, e o mais contraintuitivo, é o caso em que a troca sai pela culatra. Joubran trabalha o exemplo de migrar de Day.js para a API nativa Temporal. Parece o movimento óbvio: sair de uma biblioteca externa para um recurso da plataforma. Só que, dependendo do estado de suporte e da necessidade de polyfill, o Temporal pode acabar pesando mais que o Day.js, que é notoriamente enxuto.

Esse exemplo resume a lição central: "nativo" não é sinônimo automático de "mais leve". Se o recurso ainda não é Baseline e exige um polyfill grande para atender ao seu público-alvo, você trocou uma dependência pequena e bem otimizada por outra maior. A decisão precisa ser medida, não presumida, o que é uma boa regra de ouro para qualquer otimização de bundle.

Como aplicar isso na prática

Algumas ações concretas para quem quer sair da teoria:

• Meça primeiro. Rode um analisador de bundle (vite-bundle-visualizer, webpack-bundle-analyzer ou source-map-explorer) para ver quem ocupa espaço de verdade. Otimizar pelo palpite é desperdício de tempo.
• Confirme o Baseline do recurso nativo candidato antes de assumir que ele é seguro para seus usuários. Cheque o suporte real no seu público, não no genérico.
• Valide o comportamento com testes, especialmente em datas, fusos e formatação de números, onde as diferenças mordem.
• Compare o custo dos dois lados, incluindo o tamanho do polyfill quando o recurso ainda não estiver amplamente disponível.

A mesma edição da newsletter reforça o tema por outros ângulos: um relato de Remy Sharp sobre progressive enhancement dentro do próprio JavaScript (ligar handlers cedo e reexecutar a intenção do usuário depois que o JS carrega) e o trabalho contínuo do jsDelivr para servir pacotes npm como ESM no navegador sem build. São peças diferentes de um mesmo movimento: entregar ao usuário o mínimo necessário, no momento certo. Para quem desenvolve pensando no mobile brasileiro, o Baseline vira menos um selo de compatibilidade e mais uma ferramenta de decisão sobre o que realmente precisa ir para o navegador.

Fonte: JavaScript Weekly