Sete em cada dez sites que reprovam no PageSpeed Insights ficam lentos por causa de JavaScript de terceiros. Scripts externos, análises, redes de anúncios, chats, tipos de letra, banners de cookies bloqueiam a renderização e atrasam o First Contentful Paint em segundos. E não pode desativá-los: as análises alimentam o marketing, o chat gera contactos, sem um banner de cookies o site não passa numa auditoria.

Existe uma solução: lazy loading. O script carrega apenas quando o conteúdo principal já foi mostrado ao utilizador. O navegador não espera, as métricas do Core Web Vitals entram na zona verde e a funcionalidade do site não é prejudicada.

Reunimos todos os métodos que funcionam, desde atributos HTML nativos a técnicas programáticas e plugins de WordPress. Com exemplos de código que pode copiar e aplicar hoje.

💡 Visão geral rápida:

• Compreender defer e async: a tabela mostra claramente a diferença entre os atributos
• Dominar o carregamento programático no evento load: uma versão moderna do método de Patrick Sexton
• Configurar o Intersection Observer para scripts abaixo da dobra: chats, mapas, comentários
• Otimizar o WordPress sem editar código: plugins Flying Scripts e Asset CleanUp

Como os scripts de terceiros atrasam o carregamento

O navegador analisa o HTML de cima para baixo. Quando encontra <script src="..."> sem atributos, a análise para: o navegador carrega o script, executa-o e só depois continua a analisar a página. Isto é bloqueio de renderização.

Para o utilizador, o resultado é um ecrã branco. A métrica First Contentful Paint (FCP), o tempo até ao primeiro conteúdo mostrado, depende diretamente da rapidez com que o navegador processou todos os scripts bloqueantes. O FCP faz parte do Core Web Vitals e afeta diretamente o posicionamento nas pesquisas.

Os scripts de terceiros têm um impacto maior do que os seus: estão alojados em servidores externos e não controla a velocidade de entrega nem a disponibilidade. Consulta de DNS, handshake TCP, handshake TLS, download, cada etapa acrescenta dezenas ou centenas de milissegundos. De acordo com os dados do HTTP Archive para 2024, a mediana dos sites em dispositivos móveis carrega 21 scripts externos, e três deles são bloqueantes.

A solução é dar ao navegador uma instrução clara: «carrega o script em segundo plano e executa-o mais tarde». É exatamente para isso que os atributos defer e async foram concebidos.

Defer e async: dois mecanismos nativos

Ambos os atributos são escritos na tag <script> e alteram o comportamento de carregamento. De formas fundamentalmente diferentes.

Defer: execução diferida com garantia de ordem

O atributo defer diz ao navegador: «carrega o script em segundo plano, executa após a análise completa do HTML». A ordem de execução é preservada, os scripts executam exatamente na sequência especificada no markup.

1
<script src="https://example.com/analytics.js" defer></script>
2
<script src="https://example.com/chat-widget.js" defer></script>

A escolha ideal para scripts que devem executar numa ordem específica: biblioteca, depois o seu plugin, depois a inicialização. O defer garante que o DOM está pronto no momento da execução. O evento DOMContentLoaded é disparado depois de todos os scripts defer.

Async: independência total

O async carrega o script em paralelo com a análise e executa-o imediatamente após o carregamento, sem esperar pelos outros. A ordem não é garantida: o script que carregar primeiro do servidor executa primeiro.

1
<script src="https://example.com/independent-widget.js" async></script>

Adequado para scripts completamente independentes: contadores de visitas, botões de redes sociais, banners publicitários. Se o script não depende do DOM nem de outros scripts, use async.

Nuance importante: um script async pode executar antes de o DOM estar construído. Se fizer referência a elementos da página que ainda não existem, obterá null e um erro na consola. Verifique sempre.

Carregamento programático no evento load: o método de Patrick Sexton

E se o script não suportar defer/async ou não controlar o markup? Por exemplo, o script é inserido através do Google Tag Manager ou está hardcoded no plugin de outra pessoa. O método programático vem em socorro.

A ideia é simples: criar um elemento <script> via JavaScript e adicioná-lo ao DOM apenas depois de a página ter carregado completamente. O autor da abordagem, Patrick Sexton, descreveu a técnica pela primeira vez no varvy.com.

A versão moderna deste código:

1
function loadScriptOnPageLoad(src) {
2
  const script = document.createElement('script');
3
  script.src = src;
4
  script.async = false;
5
  document.body.appendChild(script);
6
}
7
 
8
window.addEventListener('load', () => {
9
  loadScriptOnPageLoad('/wp-content/plugins/chat/chat.js');
10
  loadScriptOnPageLoad('/wp-content/plugins/analytics/tracker.js');
11
});

Duas diferenças fundamentais em relação ao código de há uma década. Primeiro: escutamos o load, não o DOMContentLoaded. O evento load ocorre mais tarde, quando todas as imagens, estilos e tipos de letra estão carregados. Um script diferido tem a garantia de não afetar o FCP ou o LCP. Segundo: sem window.attachEvent. Este método só era necessário para o Internet Explorer 8 e versões anteriores, que já não existem. O moderno addEventListener funciona em todos os navegadores atuais.

Três situações em que a abordagem programática é insubstituível

O defer e o async só funcionam para tags <script> escritas diretamente no HTML. O método programático salva-o quando:

• O script é inserido através do Google Tag Manager ou outro gestor de tags, não se vê o markup.
• Não pode editar o template: é um plugin ou tema de terceiros com uma estrutura rígida.
• Precisa de carregamento condicional: por exemplo, um script de formulário de contacto apenas nas páginas que têm um formulário.

Intersection Observer: carregamento a pedido

Para alguns scripts, até o defer é demasiado cedo. Um widget de chat não é necessário até o utilizador fazer scroll até ao footer. Um mapa, até chegar ao bloco do endereço. Comentários, até ler até à secção de discussão.

A API Intersection Observer resolve exatamente esta tarefa: o script carrega apenas quando o elemento alvo aparece na janela de visualização.

1
const chatTarget = document.getElementById('chat-container');
2
 
3
if (chatTarget) {
4
  const observer = new IntersectionObserver((entries) => {
5
    entries.forEach((entry) => {
6
      if (entry.isIntersecting) {
7
        const script = document.createElement('script');
8
        script.src = '/wp-content/plugins/chat/chat.js';
9
        document.body.appendChild(script);
10
        observer.unobserve(entry.target);
11
      }
12
    });
13
  }, { rootMargin: '200px' });
14
 
15
  observer.observe(chatTarget);
16
}

O parâmetro rootMargin: '200px' carrega o script 200 pixels antes de o elemento aparecer no ecrã, o utilizador não nota qualquer atraso. Anteriormente, os developers usaram durante anos listeners de scroll com getBoundingClientRect(), mas estes disparavam a cada pixel de scroll e sobrecarregavam a thread principal.

O Intersection Observer funciona de forma assíncrona e quase não coloca carga no browser. O suporte existe em todos os browsers modernos, incluindo o Safari a partir da versão 12.1. O IE11 não é suportado, mas a sua quota em junho de 2026 aproxima-se do erro estatístico.

WordPress: lazy loading sem editar código

Se o site estiver em WordPress, pode implementar o lazy loading de três formas, da mais simples à mais flexível.

Plugins para lazy loading de scripts

Duas opções funcionais, testadas em milhares de sites.

Flying Scripts, um plugin gratuito de Gijo Varghese, com mais de 30 000 instalações ativas, versão 1.2.4 (atualizado em maio de 2026). Permite adiar o JavaScript até à primeira interação do utilizador: movimento do rato, clique, scroll, toque em dispositivos móveis. Especifica palavras-chave do URL do script e o plugin atrasa a sua execução. Existe um timeout: se o utilizador não interagir com a página, os scripts são executados após um tempo definido. Ganho máximo nas métricas, mas o chat ou formulário de callback devem ser excluídos do atraso, pois são necessários de imediato.

WP Rocket, um plugin premium de caching com funcionalidade integrada de atraso no carregamento de JavaScript. Adiciona defer ou async a scripts selecionados através da interface de administração. Especifica o URL e o plugin altera o atributo ao renderizar a página. Adequado para quem já usa o WP Rocket para caching e não quer multiplicar plugins.

Hook script_loader_tag no functions.php

Se não quiser instalar um plugin separado, o WordPress permite filtrar a saída da tag <script> através do hook script_loader_tag. O código abaixo adiciona defer a todos os scripts, exceto jQuery e o painel de administração:

1
add_filter('script_loader_tag', function($tag, $handle) {
2
    if (is_admin()) {
3
        return $tag;
4
    }
5
    $skip = ['jquery', 'jquery-core', 'jquery-migrate'];
6
    if (in_array($handle, $skip, true)) {
7
        return $tag;
8
    }
9
    return str_replace(' src', ' defer src', $tag);
10
}, 10, 2);

Coloque o código no functions.php do tema filho ou através do plugin Code Snippets. Antes de aplicar, faça um backup. defer no jQuery irá quebrar qualquer código que chame $() ou jQuery() antes do DOMContentLoaded. Comece com scripts individuais e verifique a consola à procura de erros após cada alteração.

Controlo total: Asset CleanUp

Asset CleanUp, um plugin gratuito (versão 1.4.0.4, atualizado em maio de 2026) que mostra TODOS os scripts e estilos carregados numa página. Com indicação do tamanho e da origem. Pode desativar um script específico numa página específica, alterar o atributo de carregamento para defer/async ou descarregar completamente um recurso desnecessário.

A principal vantagem em relação ao Flying Scripts: o Asset CleanUp oferece uma imagem completa de cada página. Vê exatamente o que está a carregar e toma decisões com precisão. A versão Pro adiciona carregamento condicional por tipo de ecrã e a possibilidade de mover scripts entre HEAD e BODY. Funciona em conjunto com qualquer plugin de caching, WP Rocket, W3 Total Cache, WP Fastest Cache.

Uma análise mais aprofundada sobre aceleração do WordPress está num artigo separado: 21 dicas para melhorar as pontuações do PageSpeed Insights. Se o problema não for apenas os scripts, mas a velocidade geral do alojamento, veja formas de reduzir o tempo de carregamento de páginas WordPress. E as ferramentas para verificar o desempenho do WordPress ajudarão a medir o efeito real da otimização.

Vídeo: async e defer na prática

Uma análise de cinco minutos do canal xplodivity, com diagramas visuais de carregamento e exemplos de código ao vivo:

⁉️🤔 Perguntas frequentes

defer** ou async, qual escolher para o Google Analytics?**

async. O Analytics.js e o gtag.js são completamente independentes do DOM, não precisam de ordem de execução. O GA4 recomenda oficialmente o async, a própria biblioteca trata da inicialização atrasada.

Como é que o evento load difere do DOMContentLoaded?

O DOMContentLoaded dispara quando o HTML está totalmente analisado e a árvore DOM construída, os estilos e imagens ainda podem estar a carregar. O load ocorre mais tarde: quando absolutamente tudo está carregado, incluindo imagens, fontes e folhas de estilo. Para carregamento lazy de scripts, o load é mais seguro: a página já foi definitivamente mostrada ao utilizador nessa altura.

Pode adicionar-se defer a um script inline?

Não. O atributo defer só funciona para scripts externos com o atributo src. Um script inline (<script>code</script>) com defer será ignorado, o navegador executá-lo-á como um script bloqueante normal. Para atrasar código inline, envolva-o num listener de DOMContentLoaded ou load.

É seguro colocar defer em todos os scripts de um site WordPress?

jQuery com defer quebrará qualquer código que chame $() ou jQuery() antes do DOMContentLoaded. É exatamente por isso que o jQuery é excluído do processamento no snippet acima. Comece com scripts não críticos: chat, redes sociais, anúncios. Expanda a lista gradualmente, verificando a consola em busca de erros após cada alteração.

Intersection Observer ou defer, qual é melhor?

Resolvem tarefas diferentes. O defer é para scripts que são sempre necessários na página, mas não são críticos para a primeira renderização: analytics, testes A/B. O Intersection Observer é para scripts ligados a um bloco específico: mapa, chat no footer, widget de comentários. Regra simples: script na parte superior da página, defer; script abaixo da dobra, Intersection Observer.

O que fazer se o Flying Scripts quebrar a funcionalidade?

Exclua o script problemático da lista de atraso nas definições do plugin. O Flying Scripts permite especificar palavras-chave para inclusão, remova a palavra-chave do script problemático e ele carregará normalmente. Para elementos críticos como formulários e chats, este é um passo obrigatório antes de ativar o atraso.

O que colocar no seu site: matriz de decisão

A escolha resume-se a uma tabela de decisão simples:

• O script está escrito em HTML, controla as tags, defer se depender da ordem, async se for completamente independente.
• O script é inserido via GTM ou plugin de terceiros, as tags estão inacessíveis, carregamento programático no evento load.
• O script está ligado a um bloco abaixo da dobra, Intersection Observer com rootMargin: '200px'.
• WordPress, precisa disso sem código, Flying Scripts (gratuito, mais de 30.000 sites) ou Asset CleanUp para controlo total de assets.

Comece pelo mais simples: abra o PageSpeed Insights, encontre os scripts externos bloqueantes e adicione-lhes defer. Um atributo, e o FCP pode passar de vermelho para verde. E quando dominar os atributos, veja a nossa análise de ferramentas para verificar o desempenho do WordPress, ajudará a medir o efeito real.