Corrigir 'Reduza o JavaScript não utilizado' no Lighthouse

O que é o aviso 'reduza o JavaScript não utilizado' do Lighthouse?

Última revisão por Arjen Karel em março de 2026

O Lighthouse sinaliza todo arquivo JavaScript com mais de 20 KiB de código não utilizado. Se você vir este aviso, sua página está baixando e executando JavaScript de que não precisa para o carregamento atual da página.

Este aviso afeta diretamente sua pontuação de desempenho no Lighthouse. Mas o mais importante, o JavaScript não utilizado prejudica seus usuários reais. De acordo com o Web Almanac 2025, a página móvel mediana envia 646 KB de JavaScript, e 251 KB disso não são utilizados na página onde são carregados. No 90º percentil, esse número sobe para 931 KB de JavaScript desperdiçado.

Enquanto isso, o Total Blocking Time em dispositivos móveis aumentou 58% em relação ao ano anterior para uma mediana de 1.916 ms de acordo com o capítulo de Performance do Web Almanac 2025. Os payloads de JavaScript estão crescendo mais rápido do que os dispositivos estão ficando mais rápidos. Em todos os sites monitorados pelo CoreDash, as origens que mantêm seu JavaScript não utilizado abaixo de 100 KB obtêm uma pontuação "boa" no INP 93% das vezes, em comparação com 64% para origens que excedem 400 KB.

O que causa o JavaScript não utilizado?

O JavaScript não utilizado pode ter muitas causas. As mais comuns são:

• Muitos plugins no seu CMS.
• Código morto que não é mais usado pelo site atual.
• Scripts mal escritos com verificações e ramificações desnecessárias.
• Acesso irrestrito ao gerenciador de tags, onde as equipes de marketing adicionam tags e esquecem de removê-las.
• Importações desnecessárias: puxar uma biblioteca inteira quando você usa apenas uma função.
• Código que é executado em todas as páginas, mas só é necessário em rotas específicas.
• Scripts carregados imediatamente que poderiam ter sido carregados logo antes do uso.

Como o JavaScript não utilizado afeta as Core Web Vitals?

O JavaScript não utilizado afeta seu desempenho de duas maneiras:

• Contenção de rede. Todo arquivo JavaScript precisa ser baixado. Essas solicitações competem por largura de banda com sua imagem de LCP, suas fontes e seu CSS. Em uma conexão móvel, esse atraso pode empurrar sua Largest Contentful Paint para muito além do limite de 2,5 segundos.
• Bloqueio da thread principal. O navegador tem que analisar, compilar e executar todo esse JavaScript. Enquanto isso, ele não pode responder à entrada do usuário ou continuar renderizando a página. Isso afeta diretamente tanto a LCP quanto a INP.

Tenha em mente que uma pontuação do Lighthouse não é uma pontuação das Core Web Vitals. As Core Web Vitals são medidas com dados de campo de usuários reais (CrUX). O Lighthouse é uma ferramenta de diagnóstico que ajuda você a encontrar problemas, mas seu desempenho real é o que seus visitantes vivenciam na prática. Você pode verificar seu desempenho de campo com o Real User Monitoring.

Como encontrar JavaScript não utilizado

Existem três maneiras de identificar o JavaScript não utilizado em sua página:

1. Leia a auditoria do Lighthouse

O Lighthouse lista todo arquivo JavaScript que tem mais de 20 KiB de código não utilizado. Ele mostra os bytes totais, os bytes não utilizados e a economia potencial. Este é o seu ponto de partida. Observe que o Lighthouse 13 (outubro de 2025) mudou para um formato de auditoria baseado em insights, mas a verificação de JavaScript não utilizado ainda está presente.

2. Use a ferramenta Coverage do Chrome

A ferramenta Coverage fornece um detalhamento linha por linha do código utilizado em comparação ao não utilizado para cada arquivo JavaScript e CSS da página.

Abra o Chrome DevTools com Ctrl+Shift+I (ou Cmd+Option+I no Mac). Em seguida, use Ctrl+Shift+P para abrir o menu de comandos e digite coverage. Selecione Show Coverage, depois clique no botão de recarregar para iniciar a instrumentação. Após o carregamento da página, você verá cada arquivo com sua porcentagem de bytes não utilizados.

Mude para o modo de cobertura "Per block" (menu suspenso na parte superior do painel) para resultados mais granulares. A cobertura em nível de bloco detecta ramificações não utilizadas dentro de funções, e não apenas se uma função foi chamada.

Clique em qualquer linha para abrir o arquivo no painel Sources. As linhas azuis são código utilizado. As linhas vermelhas são não utilizadas. Isso diz a você exatamente quais funções e ramificações nunca foram executadas durante o carregamento da página.

3. Analise seus bundles

Se você usa um bundler como webpack, Rollup ou Vite, use um analisador de bundle para visualizar o que está dentro dos seus arquivos JavaScript. Ferramentas como webpack-bundle-analyzer e source-map-explorer mostram um treemap de cada módulo no seu bundle, tornando óbvio quando uma grande biblioteca é puxada para um recurso pequeno.

Não utilizado nem sempre significa desnecessário

Tenha em mente que "não utilizado" em uma página não significa "desnecessário". Um script que alimenta seu formulário de checkout é exibido como 100% não utilizado na sua página inicial. Isso não significa que você deva excluí-lo. Isso significa que você não deve carregá-lo na página inicial.

É isso que o code splitting resolve: cada rota carrega apenas o JavaScript de que realmente precisa. Se você vir grandes quantidades de JavaScript "não utilizado" e seu site for uma single page application, a correção quase sempre é um melhor code splitting em nível de rota, não a exclusão de código.

Como corrigir 'reduza o JavaScript não utilizado'

Para corrigir o aviso 'reduza o JavaScript não utilizado', primeiro você precisa rastrear de onde vem o desperdício. O Lighthouse informa quais scripts têm uma alta quantidade de bytes não utilizados. Aqui estão 7 maneiras de reduzi-lo:

1. Remova plugins desnecessários. Se você usa um CMS como o WordPress, o ganho mais fácil é remover plugins de que não precisa ou substituir plugins triviais por algumas linhas de código. Seu plugin de analytics, botões de compartilhamento social e widget de chat são ofensores comuns.
2. Remova o código morto. O código morto é o código que o site atual não usa mais. Programe uma auditoria de código morto pelo menos duas vezes por ano. Ferramentas como o Knip podem automatizar a detecção de exports e dependências não utilizadas em projetos JavaScript.
3. Faça tree shaking em seus bundles. O tree shaking remove exports não utilizados em tempo de build. Para funcionar, você precisa da sintaxe de ES modules (import/export), não de CommonJS (require). Adicione "sideEffects": false ao seu package.json para que seu bundler possa remover o código não utilizado de forma agressiva. Importe apenas o que você precisa:

   // Bad: imports the entire library (70+ KB)
   import _ from 'lodash';
   const result = _.debounce(fn, 300);
   
   // Good: imports only debounce (~1 KB with tree shaking)
   import { debounce } from 'lodash-es';
   const result = debounce(fn, 300);

4. Faça code splitting em suas rotas. Carregue apenas o JavaScript de que cada página realmente precisa. Use o import() dinâmico para dividir seus bundles por rota ou por funcionalidade:

   // Instead of importing everything upfront:
   import { validateForm } from './formValidation.js';
   
   // Load it only when the user interacts with the form:
   document.querySelector('form').addEventListener('focus', async () => {
     const { validateForm } = await import('./formValidation.js');
     validateForm();
   }, { once: true });

   No React, use React.lazy() com <Suspense> para divisão no nível do componente. No App Router do Next.js, os React Server Components enviam zero JavaScript para o cliente por padrão. No Vue, use defineAsyncComponent() ou importações dinâmicas no Vue Router.

5. Limpe seu gerenciador de tags e restrinja o acesso. O gerenciador de tags é uma fonte comum de código não utilizado, especialmente quando as equipes de marketing adicionam tags sem remover as antigas. Faça auditorias em seu contêiner do gerenciador de tags regularmente. Cada tag disparada no carregamento da página adiciona JavaScript que compete por recursos.
6. Remova importações desnecessárias. Em projetos React, Vue e Next.js, verifique suas instruções de importação. Você está importando uma biblioteca de componentes inteira quando usa apenas dois componentes? Você está puxando o moment.js (330 KB) quando a API Intl nativa ou uma alternativa de 2 KB como o dayjs resolveria?
7. Adie o carregamento de scripts não críticos. Às vezes você precisa de um script (para enviar um formulário, por exemplo), mas não precisa dele durante o carregamento da página. Carregue-o quando o usuário realmente precisar. Um script que carrega na interação em vez de no carregamento da página não é mais "JavaScript não utilizado" na auditoria do Lighthouse. Veja também async vs defer para entender a diferença entre as duas estratégias de carregamento.

Quando você não pode corrigir totalmente

Às vezes você não consegue remover todo o JavaScript não utilizado. Scripts de terceiros, ferramentas de teste A/B e redes de anúncios geralmente enviam grandes bundles sobre os quais você não tem controle. Nesse caso, minimize o impacto deles:

• Faça self-host de scripts de terceiros em seu domínio principal sempre que possível. Isso evita o custo de uma nova consulta DNS e conexão TCP para cada domínio externo.
• Priorize recursos críticos. Faça preload da sua imagem de LCP e fontes críticas para que não fiquem presas atrás de downloads de JavaScript na fila da rede.
• Adie o máximo de JavaScript possível. Mova scripts não críticos para fora do caminho crítico de renderização usando defer, async ou carregamento atrasado.
• Use fetchpriority="low" em recursos de script não essenciais para dizer ao navegador que eles podem esperar.
• Monitore seus dados de campo. Use o Real User Monitoring para verificar se as suas alterações realmente melhoraram a experiência de usuários reais, não apenas a pontuação do Lighthouse.