Reduzir o impacto de scripts de terceiros: Partytown e web workers em 2026

Este guia é para equipas que já mantêm WordPress e precisam de um plano sóbrio: inventariar tags, condicioná-las ao consentimento, adiar widgets que ninguém pediu e só depois avaliar a passagem para workers ou a distribuição do lado do servidor. Sem solução milagrosa e sem percentagens inventadas, apenas padrões que resistem a uma auditoria real de tags.

#Como os scripts de terceiros pioram o INP no WordPress

A thread principal do browser trata do layout, dos estilos, dos scripts e da interação do utilizador. Um SDK de terceiros que faz parsing, se inicializa e regista listeners nos primeiros segundos da visita alonga as tarefas que bloqueiam essas interações. As ferramentas de laboratório mostram isso como Total Blocking Time; os dados de campo, como INP fraco. Ambos contam, mas é o INP de campo que o ranking e os utilizadores reais sentem.

As orientações do web.dev sobre JavaScript de terceiros continuam a começar pela mesma ordem: identificar quem carrega o quê, decidir se a tag é necessária naquele URL e depois reduzir quão cedo e com que frequência corre. O WordPress torna isto mais difícil porque os plugins adicionam scripts de forma global, os gestores de tags injetam mais por cima e as equipas de marketing podem acrescentar pixéis sem deploy. A gestão de tags faz parte do trabalho de performance, não é um teatro de conformidade à parte.

Responsáveis habituais em instalações WordPress:

• Um contentor do Google Tag Manager (GTM) com tags obsoletas sem dono
• Widgets de chat que descarregam um SDK de mensagens completo em todas as páginas
• Scripts de gravação de sessões ou mapas de calor que instrumentam o DOM de forma agressiva
• Pixéis sociais e de publicidade carregados antes de se conhecer o consentimento
• Plugins de otimização “gratuitos” que voltam a injetar os mesmos terceiros com outro nome

Comece por um gráfico em cascata da rede e uma gravação no painel Performance com um perfil de telemóvel de gama média. Identifique cada origin de terceiros. Se não consegue indicar um dono e uma razão de negócio para uma tag, ela é candidata a remoção antes de qualquer magia com workers.

#Como encontrar o script de terceiros que prejudica o INP

O artigo do web.dev sobre INP fixa os limiares no percentil 75 dos carregamentos de página em campo: 200 ms ou menos é bom, acima de 500 ms é fraco e o que fica no meio precisa de melhoria. Divide cada interação em atraso de entrada, duração do processamento e atraso de apresentação. O trabalho de terceiros cai sobretudo na primeira fase: uma tarefa longa de uma tag que já está a correr quando o visitante toca no ecrã atrasa o momento em que o seu próprio handler de eventos pode começar.

Para dar nome a essa tarefa, use a Long Animation Frames API (LoAF). Chegou ao Chrome 123 e reporta frames em que a atualização de renderização se atrasou mais de 50 ms, com atribuição para cada script que correu mais de 5 ms. Cada entrada de script inclui sourceURL, invoker, invokerType e forcedStyleAndLayoutDuration, o que permite ver se um ficheiro do fornecedor correu como listener de eventos, como callback de um temporizador ou como script clássico acabado de avaliar. O Firefox e o Safari não suportam a API, por isso trate os resultados como uma amostra do Chromium e não como um censo completo.

new PerformanceObserver((list) => {
  for (const frame of list.getEntries()) {
    for (const script of frame.scripts) {
      if (script.sourceURL && !script.sourceURL.startsWith(location.origin)) {
        console.log(script.sourceURL, script.invokerType, Math.round(script.duration));
      }
    }
  }
}).observe({ type: 'long-animation-frame', buffered: true });

Para dados de campo, a biblioteca web-vitals inclui desde a versão 4 as entradas LoAF que se sobrepõem à interação na sua atribuição de INP (longAnimationFramesEntries), pelo que um endpoint RUM pode registar que origin estava ocupado durante a interação mais lenta de uma visita real. Em laboratório, o painel Performance do DevTools tem um insight de terceiros que agrupa os pedidos por fornecedor com base no conjunto de dados aberto Third Party Web. A auditoria de resumo de terceiros do Lighthouse assinala páginas em que o código de terceiros bloqueia a thread principal durante 250 ms ou mais. Use a vista de laboratório para encontrar suspeitos e os dados de campo para decidir qual deles importa.

#O Google Tag Manager torna o WordPress mais lento

O GTM e gestores semelhantes são camadas de orquestração. Não anulam o custo de download, de parsing nem de execução. Um contentor limpo, com poucas tags e regras de disparo estritas, pode ser mais leve do que cinco scripts de plugins escritos diretamente no código. Um contentor que dispara tudo em All Pages é muitas vezes pior do que os plugins que substituiu.

Regras práticas que funcionam em instalações WordPress:

1. Um contentor por propriedade, com donos identificados para cada tag.
2. Disparar tags de marketing nos templates que precisam delas, não em páginas legais, em passos de checkout que já estão no limite ou em vistas autenticadas próximas do admin.
3. Preferir eventos de dataLayer fornecidos pelo servidor a extrair dados do DOM, onde controla o tema.
4. Eliminar tags duplicadas (duas propriedades de analytics, dois fornecedores de chat, três pixéis para a mesma conta de anúncios).
5. Versionar o contentor como versiona as releases do tema: rever os diffs quando alguém “só adiciona uma tag”.

Se a equipa não consegue explicar numa frase o que uma tag faz, não a passe pelo Partytown: apague-a ou ponha-a em pausa. Mover ruído para um worker continua a custar rede e coordenação.

#Como carregar scripts de terceiros com defer ou async no WordPress

Os dois atributos de <script> decidem se o parser de HTML espera. Segundo o MDN, um script defer corre depois de o documento ser analisado e antes de DOMContentLoaded, pela ordem em que os scripts aparecem. Um script async é descarregado em paralelo e avaliado assim que fica disponível, sem garantia de ordem. Nenhum dos atributos faz nada num script clássico inline sem src, e os scripts de módulo já são diferidos por omissão.

Desde o WordPress 6.3 pode pedir qualquer um dos atributos através da API do núcleo, sem filtrar script_loader_tag. O último parâmetro de wp_register_script() e de wp_enqueue_script(), antes o booleano $in_footer, aceita agora também um array com as chaves strategy e in_footer. Sem strategy, mantém-se o comportamento bloqueante antigo, pelo que os plugins existentes não mudam.

add_action( 'wp_enqueue_scripts', function () {
	wp_enqueue_script(
		'vendor-analytics',
		'https://analytics.vendor.example/tag.js',
		array(),
		null,
		array(
			'strategy'  => 'async',
			'in_footer' => false,
		)
	);
} );

O que pede nem sempre é o que é impresso. A nota para programadores do WordPress 6.3 explica que o núcleo calcula uma estratégia elegível. Um handle nunca herda uma estratégia mais estrita do que a pedida e, se um script que depende dele for bloqueante, o handle e as suas dependências passam também a bloqueantes para manter a ordem de execução. Um script inline adicionado com wp_add_inline_script() na posição after tem o mesmo efeito: o núcleo assume que o handle é bloqueante e descarta a intenção defer ou async. Se uma tag de um fornecedor continua a sair sem o atributo, verifique os scripts dependentes e os fragmentos inline antes de culpar o plugin.

Que atributo escolher: o guia do web.dev sobre terceiros sugere async para scripts que têm de correr cedo, como algum analytics, e defer para recursos menos críticos. Refere também que o Chrome e outros browsers baseados em Blink baixam a prioridade de rede dos scripts carregados assim. O WordPress 6.9 acrescentou a chave fetchpriority ao mesmo array $args, para que um handle possa ter uma prioridade explícita em vez de depender do valor por omissão do browser.

#Como fazer preconnect a domínios de terceiros no WordPress

Uma tag de terceiros começa com DNS, TCP e TLS para um host que o browser ainda não contactou. Uma indicação <link rel="preconnect"> pede ao browser que prepare essa ligação antes do pedido. As orientações do web.dev sobre preconnect são restritivas: faça preconnect apenas a domínios críticos que vai usar em breve, mantenha a lista curta porque preconnects a mais podem atrasar outros recursos e use dns-prefetch para hosts menos críticos. O browser fecha uma ligação preparada que não seja usada em 10 segundos, por isso fazer preconnect ao fornecedor de um chat que só carrega ao clique desperdiça o handshake. Recursos pedidos em modo CORS anónimo, como tipos de letra, precisam do atributo crossorigin na indicação; sem ele, só a consulta DNS é reaproveitada.

O WordPress imprime estas indicações através do filtro wp_resource_hints, disponível desde a 4.6 e com arrays de atributos desde a 4.7:

add_filter( 'wp_resource_hints', function ( $urls, $relation_type ) {
	if ( 'preconnect' === $relation_type ) {
		$urls[] = array( 'href' => 'https://www.googletagmanager.com' );
	}
	return $urls;
}, 10, 2 );

Acrescente a indicação apenas para o origin que a primeira vista pede de facto, normalmente o gestor de tags ou o host de analytics, e não para cada fornecedor que consta do contentor.

#Como carregar o chat no WordPress só ao clicar

Chat, calendários de reservas e media incorporados partilham um padrão: o utilizador raramente precisa do SDK completo na primeira pintura. Envie um elemento leve (botão em CSS, avatar estático, fachada lite de YouTube ou Vimeo) e carregue o script do fornecedor apenas perante intenção: clique, foco ou hover com um pequeno atraso, para que uma passagem acidental do rato não desencadeie uma avalanche de downloads.

No WordPress isto costuma significar:

• Desativar o carregamento automático do plugin ou do tema
• Renderizar o seu próprio markup no rodapé ou num bloco
• Injetar o script real só depois de o handler de interação correr uma vez
• Manter a acessibilidade: o controlo estático tem de ser um botão ou link real com etiqueta clara

const loadChatOnce = () => {
  if (window.__chatLoaded) return;
  window.__chatLoaded = true;
  const s = document.createElement('script');
  s.src = 'https://vendor.example/chat.js';
  s.async = true;
  document.head.appendChild(s);
};

document.getElementById('open-chat')?.addEventListener('click', loadChatOnce, {
  once: true,
});

O mesmo padrão aplica-se a mapas e conteúdos incorporados de redes sociais. Uma imagem estática de mapa com link para o Google Maps ou o OpenStreetMap ganha muitas vezes a um SDK de mapa interativo em artigos de blog. Reserve o conteúdo incorporado pesado para páginas em que a interação é o produto.

A documentação do Lighthouse chama a este padrão fachada: um elemento estático que se parece com o conteúdo incorporado, mas que só funciona quando o visitante interage com ele. A auditoria de fachadas enumera opções de código aberto como lite-youtube-embed e lite-vimeo-embed para vídeo, e react-live-chat-loader para Intercom, Drift, Help Scout e Facebook Messenger. Também aponta os custos: uma fachada de chat pode não ter funções como o indicador de nova mensagem do Drift até o widget real carregar, e a reprodução automática de vídeo pode não funcionar de forma fiável quando o leitor é carregado de forma diferida.

#Modo de consentimento e ordem de carregamento do CMP no WordPress

As plataformas de consentimento mudam quando as tags podem correr. Não as tornam baratas por si só. Configurações fracas carregam toda a pilha de marketing e voltam a carregá-la depois de o utilizador aceitar, ou bloqueiam a medição de forma errada enquanto continuam a enviar chat e mapas de calor que nunca precisaram de execução antecipada.

Uma sequência que funciona no WordPress:

1. Carregar o CMP cedo o suficiente para registar a escolha, sem juntar ao lado todos os SDKs de publicidade.
2. Por omissão, pôr as tags de marketing e publicidade à espera de uma decisão onde a lei e a política o exigem (RGPD).
3. Depois do consentimento, inicializar apenas as tags que a escolha permite, uma única vez.
4. Manter o JS essencial do site (navegação, formulários, checkout) fora do ramo de consentimento de marketing, para que a experiência não espere pela biblioteca do banner.

O modo de consentimento (para tags Google) e APIs equivalentes de outros fornecedores ajustam o comportamento da medição em diferentes estados de consentimento. Trate-os como ligação da política mais configuração de tags e, mesmo assim, aplique o diferimento e os cortes no inventário. Um contentor consentido mas sobredimensionado continua a ser um problema de INP.

Documente a matriz: que tags correm antes do consentimento, quais depois do consentimento de analytics, quais só depois do consentimento de publicidade e quais nunca correm naquela versão de idioma. Guarde a matriz junto ao workspace do GTM, para que o próximo lançamento de campanha não volte a abrir todos os scripts em All Pages.

#Vale a pena usar o Partytown no WordPress

O Partytown move scripts de terceiros selecionados para um web worker e encaminha o acesso ao DOM de volta para a thread principal através de um proxy. Em algumas cargas de analytics e pixéis, isso pode reduzir a disputa pela thread principal. Não é um acelerador universal.

Restrições a planear:

• Scripts que têm de alterar o layout de forma síncrona (muitas ferramentas de A/B e personalização) são maus candidatos a worker.
• Encaminhar chamadas ao DOM tem custos; uma tag pequena pode não ganhar nada.
• O service worker, a CDN e a CSP têm de permitir a biblioteca Partytown, os scripts do worker e os canais de atomics ou proxy que ativar.
• A depuração fica mais difícil: as falhas aparecem como hits em falta, não como um erro PHP óbvio no tema.
• Caches de página e plugins de otimização que reescrevem tags de script podem partir a passagem por type="text/partytown" (ou equivalente) se não forem configurados em conjunto.

A própria página de compromissos do projeto é concreta sobre onde o Partytown encaixa. Indica o Google Tag Manager e o Facebook Pixel como o tipo de scripts a que melhor se adapta e avisa que scripts que inserem muitos nós no DOM, ou scripts com muita interface como diálogos com formulários, podem ser maus candidatos. Um handler de terceiros que chama event.preventDefault() não tem efeito a partir do worker. As operações no DOM são propositadamente limitadas e agrupadas, e uma chamada bloqueante pode demorar alguns milissegundos. A versão com service worker usa três threads e a versão com Atomics usa duas. Alguns fornecedores não enviam os cabeçalhos CORS de que o worker precisa, e esses pedidos têm de passar por um proxy operado por si.

Um caminho de adoção mais seguro:

1. Concluir o inventário, o controlo por consentimento e o click-to-load para chat e media.
2. Escolher uma tag de analytics não crítica como piloto.
3. Verificar os hits na interface do fornecedor e o RUM e INP antes e depois nos mesmos URLs.
4. Alargar apenas a tags que continuam corretas atrás do proxy.
5. Manter uma saída explícita para carregamento na thread principal para as tags que falham a validação.

Existem outros padrões com workers (workers próprios para trabalho first-party pesado, iframes isolados para widgets não fiáveis). A mesma cautela: isole onde ajuda, meça e não anuncie “zero terceiros na thread principal” a menos que os seus dados de campo o confirmem.

#Deve alojar localmente ou isolar os scripts de terceiros

O guia do web.dev sobre terceiros descreve três opções entre manter uma tag tal como está e apagá-la. Alojar um script crítico no seu servidor dá-lhe controlo sobre o tempo de DNS e os cabeçalhos de cache HTTP, mas uma cópia própria não recebe as alterações de API nem as correções de segurança do fornecedor até alguém a atualizar à mão. No WordPress isso significa uma tarefa de atualização agendada ou um passo de build, e não um ficheiro copiado uma vez para a pasta do tema e esquecido.

Carregar um script diretamente dentro de um iframe impede-o de bloquear a execução da página principal, e o atributo sandbox restringe o que o script pode fazer. Isso encaixa melhor em widgets não fiáveis do que em analytics, que normalmente precisa do contexto first-party da página. Um service worker pode guardar em cache scripts de terceiros para controlar com que frequência são pedidos à rede, ou reter pedidos de terceiros não essenciais até a página chegar a um momento-chave para o utilizador. Num site WordPress típico, o click-to-load e as regras de disparo por template cobrem quase todo esse terreno com menos maquinaria, por isso reserve a via do service worker para os casos em que já tem um.

#Quando usar GTM do lado do servidor no WordPress

O GTM do lado do servidor e endpoints de recolha first-party podem tirar do browser a distribuição para a Google, a Meta e outros fornecedores. O visitante fala então sobretudo com o seu domínio e o seu servidor distribui os eventos. Isso pode reduzir o peso dos scripts de terceiros, mas traz alojamento, reencaminhamento de consentimento, questões de identidade e trabalho de QA.

Use-o quando o marketing precisa mesmo de muitos destinos e a pilha do browser é o estrangulamento que mediu, não porque um artigo lhe chamou o padrão de 2026. Mantenha um coletor mínimo no browser, respeite os sinais de consentimento de ponta a ponta e faça testes de regressão às conversões após cada alteração ao contentor.

#Lista de verificação para auditar scripts de terceiros no WordPress

1. Exportar cada URL de script de um carregamento a frio dos templates principais (página inicial, produto, checkout, artigo).
2. Associar cada origin a um dono e a uma categoria de consentimento.
3. Remover ou pôr em pausa duplicados e tags mortas no GTM e nos plugins.
4. Converter o chat e os conteúdos incorporados não essenciais em click-to-load.
5. Alinhar o CMP e o modo de consentimento para que as tags se inicializem uma vez, no estado certo.
6. Voltar a medir o INP de campo e as tarefas longas de laboratório na mesma classe de dispositivo.
7. Só então avaliar o Partytown ou o tagging do lado do servidor para o peso de analytics que resta.

Se precisa de um programador WordPress para ligar consentimento, gestão de tags e medição de performance ao tema sem partir os relatórios de marketing, trate isso como trabalho de engenharia com testes de aceitação, e não como um interruptor de um clique num “plugin de velocidade”.

#Quando está concluída a limpeza dos scripts de terceiros

Concluído não é uma captura perfeita do Lighthouse. Concluído é uma lista de terceiros mais curta, um comportamento de consentimento claro, widgets que carregam a pedido e um INP de campo que já não cai quando o marketing acrescenta uma tag de campanha. Guarde o rasto da auditoria: versões do contentor, configuração do CMP e as notas de medição de antes e depois. É esse rasto que mantém a thread principal sua quando chegar o próximo pedido de pixel.

Veja os nossos serviços de otimização de velocidade WordPress.