Corrigir 'Reduce Unused JavaScript' no Lighthouse

O que é o aviso 'reduce unused JavaScript' do Lighthouse?

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

O Lighthouse sinaliza cada ficheiro JavaScript com mais de 20 KiB de código não utilizado. Se vê este aviso, a sua página está a descarregar e executar JavaScript que não precisa para o carregamento da página atual.

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

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

O que causa JavaScript não utilizado?

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

• Demasiados plugins no seu CMS.
• Código morto que já não é usado pelo site atual.
• Scripts mal escritos com verificações e ramificações desnecessárias.
• Acesso irrestrito ao tag manager, onde as equipas de marketing adicionam tags e esquecem-se de as remover.
• Importações desnecessárias: importar uma biblioteca inteira quando só usa 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 mesmo antes de serem usados.

Como é que JavaScript não utilizado afeta os Core Web Vitals?

JavaScript não utilizado afeta o seu desempenho de duas formas:

• Contenção de rede. Cada ficheiro JavaScript precisa de ser descarregado. Estes pedidos competem por largura de banda com a sua imagem LCP, as suas fontes e o seu CSS. Numa ligação móvel, este atraso pode empurrar o seu Largest Contentful Paint bem para além do limite de 2,5 segundos.
• Bloqueio do thread principal. O navegador tem de analisar, compilar e executar todo esse JavaScript. Enquanto o faz, não pode responder à entrada do utilizador nem continuar a renderizar a página. Isto impacta diretamente tanto o LCP como o INP.

Tenha em mente que uma pontuação do Lighthouse não é uma pontuação de Core Web Vitals. Os Core Web Vitals são medidos com dados de campo de utilizadores reais (CrUX). O Lighthouse é uma ferramenta de diagnóstico que ajuda a encontrar problemas, mas o seu desempenho real é o que os seus visitantes realmente experienciam. Pode verificar o seu desempenho de campo com Real User Monitoring.

Como encontrar JavaScript não utilizado

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

1. Leia a auditoria do Lighthouse

O Lighthouse lista cada ficheiro JavaScript que tem mais de 20 KiB de código não utilizado. Mostra os bytes totais, os bytes não utilizados e a poupança potencial. Este é o seu ponto de partida. Note 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 continua lá.

2. Use a ferramenta Coverage do Chrome

A ferramenta Coverage dá-lhe uma análise linha a linha do código usado versus não usado para cada ficheiro JavaScript e CSS na página.

Abra o Chrome DevTools com Ctrl+Shift+I (ou Cmd+Option+I no Mac). Depois use Ctrl+Shift+P para abrir o menu de comandos e escreva coverage. Selecione Show Coverage, depois clique no botão de recarregar para começar a instrumentar. Após o carregamento da página, verá cada ficheiro com a sua percentagem de bytes não utilizados.

Mude para o modo de cobertura "Per block" (dropdown no topo do painel) para resultados mais granulares. A cobertura por bloco deteta ramificações não utilizadas dentro de funções, não apenas se uma função foi chamada.

Clique em qualquer linha para abrir o ficheiro no painel Sources. Linhas azuis são código usado. Linhas vermelhas são não usadas. Isto diz-lhe exatamente quais funções e ramificações nunca foram executadas durante o carregamento da página.

3. Analise os seus bundles

Se usa um bundler como webpack, Rollup ou Vite, use um analisador de bundles para visualizar o que está dentro dos seus ficheiros 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 é incluída para uma funcionalidade pequena.

Não utilizado nem sempre significa desnecessário

Tenha em mente que "não utilizado" numa página não significa "desnecessário". Um script que alimenta o seu formulário de checkout aparece como 100% não utilizado na sua página inicial. Isso não significa que deve eliminá-lo. Significa que não deve carregá-lo na página inicial.

É isto que o code splitting resolve: cada rota carrega apenas o JavaScript que realmente precisa. Se vê grandes quantidades de JavaScript "não utilizado" e o seu site é uma single page application, a solução é quase sempre melhor divisão de código por rota, não eliminar código.

Como corrigir 'reduce unused JavaScript'

Para corrigir o aviso 'reduce unused JavaScript' primeiro precisa de rastrear de onde vem o desperdício. O Lighthouse diz-lhe quais scripts têm uma grande quantidade de bytes não utilizados. Aqui estão 7 formas de o reduzir:

1. Remova plugins desnecessários. Se usa um CMS como WordPress, a vitória mais fácil é remover plugins que não precisa ou substituir plugins triviais por algumas linhas de código. O seu plugin de analytics, botões de partilha social e widget de chat são infratores comuns.
2. Remova código morto. Código morto é código que o site atual já não usa. Agende uma auditoria de código morto pelo menos duas vezes por ano. Ferramentas como Knip podem automatizar a deteção de exportações e dependências não utilizadas em projetos JavaScript.
3. Faça tree shaking dos seus bundles. O tree shaking remove exportações não utilizadas no momento da compilação. Para funcionar, precisa de sintaxe ES module (import/export), não CommonJS (require). Adicione "sideEffects": false ao seu package.json para que o seu bundler possa remover agressivamente código não utilizado. Importe apenas o que precisa:

   // Mau: importa a biblioteca inteira (70+ KB)
   import _ from 'lodash';
   const result = _.debounce(fn, 300);
   
   // Bom: importa apenas debounce (~1 KB com tree shaking)
   import { debounce } from 'lodash-es';
   const result = debounce(fn, 300);

4. Divida o código por rotas. Carregue apenas o JavaScript que cada página realmente precisa. Use import() dinâmico para dividir os seus bundles por rota ou por funcionalidade:

   // Em vez de importar tudo antecipadamente:
   import { validateForm } from './formValidation.js';
   
   // Carregue apenas quando o utilizador interage com o formulário:
   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 a nível de componente. No Next.js App Router, os React Server Components enviam zero JavaScript para o cliente por predefinição. No Vue, use defineAsyncComponent() ou importações dinâmicas no Vue Router.

5. Limpe o seu tag manager e restrinja o acesso. O tag manager é uma fonte comum de código não utilizado, especialmente quando as equipas de marketing adicionam tags sem remover as antigas. Faça auditorias regulares ao seu container de tag manager. Cada tag que dispara 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 as suas instruções de importação. Está a importar uma biblioteca inteira de componentes quando só usa dois componentes? Está a incluir o moment.js (330 KB) quando a API nativa Intl ou uma alternativa de 2 KB como dayjs seriam suficientes?
7. Adie o carregamento de scripts não críticos. Por vezes precisa de um script (para submeter um formulário, por exemplo) mas não precisa dele durante o carregamento da página. Carregue-o quando o utilizador realmente precisar. Um script que carrega na interação em vez de no carregamento da página já não é "JavaScript não utilizado" na auditoria do Lighthouse. Veja também async vs defer para compreender a diferença entre as duas estratégias de carregamento.

Quando não pode corrigir completamente

Por vezes não pode remover todo o JavaScript não utilizado. Scripts de terceiros, ferramentas de testes A/B e redes de publicidade frequentemente enviam bundles grandes sobre os quais não tem controlo. Nesse caso, minimize o seu impacto:

• Aloje scripts de terceiros no seu domínio principal quando possível. Isto evita o custo de uma nova pesquisa DNS e ligação TCP para cada domínio externo.
• Priorize recursos críticos. Pré-carregue a sua imagem LCP e fontes críticas para que não fiquem presas atrás de downloads de JavaScript na fila de 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 podem esperar.
• Monitorize os seus dados de campo. Use Real User Monitoring para verificar que as suas alterações realmente melhoraram a experiência para utilizadores reais, não apenas a pontuação do Lighthouse.