A plataforma web evolui rapidamente, incorporando funcionalidades que antes exigiam bibliotecas JavaScript. Entenda como auditar suas dependências e otimizar seu site empresarial, melhorando performance e SEO.
Menos JavaScript, Mais Performance: Otimizando Seu Site Empresarial
Se você cuida de um site empresarial, sabe que cada kilobyte conta. Um site mais leve carrega mais rápido, melhora a experiência do usuário e ganha pontos com os motores de busca. Por anos, a solução para muitas funcionalidades web era adicionar uma biblioteca JavaScript. Mas a realidade mudou: o que antes exigia um pacote externo, agora pode ser feito diretamente pelo navegador. Essa evolução da plataforma web, impulsionada por iniciativas como o projeto Baseline, oferece uma oportunidade real de otimizar seu site.
O foco aqui é prático: como identificar e remover dependências JavaScript desnecessárias, reduzindo o tamanho do seu código e, consequentemente, melhorando o carregamento e o SEO do seu site. Vamos entender o que é o Baseline e como ele pode ser seu aliado nessa auditoria.
O Que é Baseline e Por Que Ele Importa Para Seu Site?
Antes de começar a remover código, é fundamental entender o conceito de Baseline. Trata-se de um projeto do WebDX Community Group que classifica a segurança do uso de recursos web nos principais navegadores (Chrome, Edge, Firefox e Safari). Um recurso pode estar em três estados:
- Disponibilidade Limitada: O recurso ainda não está em todos os navegadores principais. Não é seguro depender dele sem um fallback.
- Baseline Recém-Disponível: O recurso acabou de chegar em todos os navegadores principais. Funciona para usuários com navegadores atualizados, mas pode não estar disponível em dispositivos mais antigos.
- Baseline Amplamente Disponível: O recurso está presente em todos os navegadores principais há 30 meses ou mais. Você pode usá-lo sem grandes preocupações.
Essa distinção de 30 meses entre “Recém-Disponível” e “Amplamente Disponível” é crucial. Um recurso Amplamente Disponível geralmente permite a remoção imediata de uma biblioteca. Já um recurso Recém-Disponível exige uma análise do seu público-alvo ou a implementação de uma verificação de recurso antes de ser adotado. Você pode consultar o status de qualquer recurso em webstatus.dev, no MDN (que exibe um selo Baseline) ou programaticamente com o pacote npm web-features.
Um Guia de Decisão Antes de Eliminar Código
A ideia de remover bibliotecas pode ser tentadora, mas uma troca apressada pode quebrar funcionalidades ou prejudicar uma parte dos seus usuários. Para evitar problemas, faça três perguntas antes de descartar qualquer biblioteca:
- O substituto nativo é Baseline-seguro para o meu público? Não basta ser Baseline, precisa ser seguro para quem realmente usa seu site. Se for Amplamente Disponível, geralmente é um sim. Se for Recém-Disponível, verifique suas análises de tráfego ou configurações do
browserslist. Um painel B2B com usuários em navegadores modernos é diferente de um site público com muitos dispositivos Android antigos. - Qual o custo real da troca? Remover uma biblioteca não é sempre “grátis”. Se o recurso nativo não for amplamente suportado e você precisar de um polyfill, ele pode ser mais pesado que a biblioteca original, aumentando o tamanho do seu pacote, a menos que seja carregado condicionalmente.
- O recurso da plataforma cobre meu caso de uso real? Bibliotecas muitas vezes fazem mais do que o recurso nativo que se assemelham.
axios, por exemplo, não é apenasfetchcom parsing automático de JSON; ele tem interceptores, cancelamento de requisições e retentativas. Se você usa essas funcionalidades, a troca direta parafetchexigirá que você as reimplemente. Verifique o que você realmente usa antes de presumir que é uma substituição direta.
Mantenha essas perguntas em mente. Cada “cluster” de dependências que veremos a seguir é, na verdade, a aplicação dessas perguntas a uma área específica do seu código.
Cluster 1: Internacionalização (O Maior Ganho Imediato)
Este é o cluster onde você geralmente encontrará a maior quantidade de KBs provenientes de funcionalidades que já são Amplamente Disponíveis. O navegador oferece uma série de ferramentas de formatação sob o namespace Intl, tornando muitas bibliotecas populares desnecessárias.
Os “suspeitos” comuns e suas substituições:
timeago.js(1 KB gz) →Intl.RelativeTimeFormatpluralize(2.3 KB gz) →Intl.PluralRulesnumeral(3.9 KB gz) →Intl.NumberFormathumanize-duration(6.6 KB gz) →Intl.DurationFormat- Auxiliares de junção de listas →
Intl.ListFormat
Vamos a alguns exemplos:
- Tempo Relativo:
timeago.jstransforma um timestamp em “3 horas atrás”.Intl.RelativeTimeFormatfaz o mesmo e é Baseline Amplamente Disponível. A opçãonumeric: "auto"oferece “ontem” em vez de “1 dia atrás”, quando o idioma permite. A única diferença é que você precisa calcular a unidade (segundos, dias) por conta própria, o que é uma tarefa simples de algumas linhas de código. - Números, Moedas e Listas:
Intl.NumberFormatcobre a maioria das necessidades de formatação numérica: separadores de milhar, moedas, porcentagens e notação compacta. JáIntl.ListFormat, também Amplamente Disponível, resolve o problema de unir um array em uma frase, incluindo a vírgula de Oxford, algo que muitas vezes leva a funções auxiliares complexas.
A Ressalva das Duração: humanize-duration transforma milissegundos em “1 hora, 30 minutos”. O equivalente na plataforma é Intl.DurationFormat. No entanto, Intl.DurationFormat é Baseline Recém-Disponível, não Amplamente Disponível. Ele chegou aos principais navegadores em março de 2025 e deve ser Amplamente Disponível em 2027. Para sites com público amplo, ele falha na primeira pergunta, a menos que você verifique seu tráfego ou adicione um fallback. Para ferramentas internas em navegadores modernos, pode ser usado hoje.
A Matemática Deste Cluster: Se seu site usa o conjunto completo dessas bibliotecas (humanize-duration, timeago.js, pluralize, numeral), você pode estar carregando cerca de 14 KB gzipped de dependências, a maioria delas substituível agora por APIs Amplamente Disponíveis. O cluster de internacionalização é geralmente o ganho mais fácil em toda a auditoria.
Cluster 2: Clientes HTTP (Uma Análise Mais Detalhada)
Este cluster exige uma análise mais cuidadosa. Bibliotecas HTTP como axios (17 KB gz) e superagent (19 KB gz) são comuns. Para a maioria das requisições, fetch, combinado com AbortController, cobre o que você precisa, e ambos são Amplamente Disponíveis.
Uma requisição GET básica é simples:
- Com axios:
const { data } = await axios.get("/api/users"); - Com fetch:
const res = await fetch("/api/users"); const data = await res.json();
A linha extra (res.json()) mostra que fetch é mais explícito. Essa é a tendência: fetch faz menos por padrão, e você decide se precisa das funcionalidades que ele omite.
Timeouts: axios tem uma opção de timeout. fetch utiliza AbortSignal.timeout(), que permite abortar uma requisição após um tempo específico.
Onde fetch Não Substitui axios Diretamente: Aqui é onde a terceira pergunta do nosso guia de decisão é mais importante. As principais lacunas são:
fetchnão rejeita em erros HTTP: Um status 404 ou 500 é uma promessa resolvida, não uma rejeição. Você precisa verificarres.okmanualmente.axiosrejeita em qualquer status diferente de 2xx.- Sem interceptores: Se você depende de interceptores do
axiospara anexar tokens de autenticação ou lidar com erros 401 em um único lugar,fetchnão tem um equivalente. Você precisaria encapsularfetchem sua própria função ou classe para obter o mesmo comportamento. - Sem retentativas automáticas:
axios(com um plugin) pode tentar novamente requisições falhas. Comfetch, esse código é sua responsabilidade. - Sem progresso de upload:
fetchainda não relata o progresso de upload de forma nativa. Se você tem um uploader de arquivos com barra de progresso, essa é uma razão válida para manter uma biblioteca.
Nenhuma dessas funcionalidades é difícil de recriar, e a maioria dos sites usa apenas uma ou duas delas. Mas este é um cluster onde você não deve fazer uma substituição cega. Analise como você realmente usa seu cliente HTTP. Se forem apenas GETs e POSTs simples, trocar axios por um wrapper fino de fetch pode economizar cerca de 17 KB gzipped.
Cluster 3: Primitivos de UI (Acessibilidade e Eficiência)
Este cluster oferece algumas das substituições mais satisfatórias, pois os recursos da plataforma não apenas correspondem às bibliotecas, mas muitas vezes são mais acessíveis do que o que as equipes implementam manualmente. Isso impacta diretamente na experiência do usuário e na conformidade do seu site.
As bibliotecas aqui incluem:
- Diálogos modais: Como
a11y-dialog(1.8 KB gz). - Tooltips e popovers: Como
tippy.js(14 KB gz, que inclui Popper para posicionamento). - Focus-trap: (6.6 KB gz).
- Body-scroll-lock: (1.3 KB gz).
Elas são substituídas por três recursos da plataforma: o elemento <dialog>, a Popover API e o posicionamento de âncora CSS.
O Elemento <dialog>
Uma vasta quantidade de código relacionado a modais existe para resolver problemas de acessibilidade: prender o foco dentro do modal, fechar ao pressionar Escape, restaurar o foco para o elemento anterior ao fechar o diálogo e renderizar acima de tudo. O elemento <dialog>, Amplamente Disponível, faz tudo isso por você.
Ao usar <dialog>, o foco se move para dentro, o fundo se torna inerte e a tecla Escape o fecha automaticamente. Isso simplifica drasticamente a implementação de modais acessíveis e reduz a necessidade de bibliotecas externas complexas.
Conclusão: Um Site Mais Leve e Eficiente Começa na Auditoria
A evolução constante da plataforma web é uma ótima notícia para quem busca otimizar sites empresariais. Ao auditar suas dependências JavaScript com base nas diretrizes do Baseline, você pode identificar oportunidades significativas para reduzir o tamanho do seu código, melhorar a performance de carregamento e, por consequência, impulsionar o SEO e a experiência do usuário. Não se trata de remover bibliotecas cegamente, mas de fazer escolhas informadas que tragam benefícios reais para seu negócio.
Comece pelo cluster de internacionalização para os ganhos mais rápidos. Analise cuidadosamente os clientes HTTP e, para primitivos de UI, explore as soluções nativas que oferecem acessibilidade aprimorada. Um site mais leve é um site mais rápido, e um site mais rápido é um site que converte mais.
Perguntas frequentes
O que é o projeto Baseline?
Baseline é uma iniciativa que informa a segurança e compatibilidade de recursos web nos principais navegadores (Chrome, Edge, Firefox, Safari), classificando-os como Disponibilidade Limitada, Recém-Disponível ou Amplamente Disponível.
Como o Baseline ajuda a otimizar meu site?
Ele permite identificar funcionalidades que antes dependiam de bibliotecas JavaScript, mas que agora são nativas do navegador e Amplamente Disponíveis, possibilitando a remoção dessas dependências e a redução do tamanho do código.
Quais são os principais benefícios de reduzir o JavaScript do meu site?
Os benefícios incluem carregamento mais rápido do site, melhor experiência do usuário, pontuação aprimorada em métricas de performance (Core Web Vitals) e um impacto positivo no ranking de SEO.
Devo remover todas as minhas bibliotecas JavaScript?
Não. É crucial auditar cada dependência, verificando se o recurso nativo da plataforma é seguro para seu público, qual o custo real da troca (considerando polyfills) e se ele cobre todos os casos de uso que a biblioteca original oferecia.
Onde posso verificar o status Baseline de um recurso web?
Você pode consultar o status de qualquer recurso em webstatus.dev ou nas páginas de referência do MDN, que exibem um selo Baseline próximo ao topo.
Fonte: Smashing Magazine
