El JavaScript de terceros suele ser la superficie menos controlada de un sitio WordPress. Analytics, anuncios, chat, heatmaps, herramientas A/B y stacks de píxeles llegan cuando el tema y los plugins ya pelean por el hilo principal. Cuando el visitante abre un menú o envía un formulario, ese trabajo aparece como pintura retrasada: el problema de Interaction to Next Paint (INP) que documenta web.dev.
Esta guía es para equipos que ya publican WordPress y necesitan un playbook sobrio: inventariar etiquetas, limitarlas con consentimiento, diferir widgets que nadie ha pedido y solo entonces valorar offload a worker o fan-out server-side. Sin bala de plata ni porcentajes inventados: patrones que aguantan una auditoría real de etiquetas.
Conoce más sobre optimización de velocidad WordPress en WPPoland.
Por qué los scripts de terceros dañan el INP
El hilo principal del navegador gestiona layout, estilo, scripting e input. Un SDK de terceros que parsea, hidrata y adjunta listeners en los primeros segundos alarga tareas que bloquean esas interacciones. Las herramientas de laboratorio lo muestran como Total Blocking Time; los datos de campo, como INP débil. Ambos importan, pero el INP de campo es lo que sienten ranking y usuarios reales.
La guía de web.dev sobre JavaScript de terceros sigue el mismo orden: identifica quién carga qué, decide si la etiqueta hace falta en esa URL y reduce cuánto de temprano y con qué frecuencia se ejecuta. WordPress lo complica porque los plugins encolan scripts de forma global, los gestores de etiquetas inyectan más encima y marketing puede añadir píxeles sin un deploy. La gobernanza es parte del trabajo de rendimiento, no un teatro aparte de cumplimiento.
Ofensores habituales en installs WordPress:
- Un contenedor Google Tag Manager (GTM) con etiquetas obsoletas sin dueño
- Widgets de chat que descargan un SDK de mensajería completo en cada página
- Scripts de session replay o heatmap que instrumentan el DOM con agresividad
- Píxeles sociales y publicitarios cargados antes de conocer el consentimiento
- Plugins de “optimización” que reinyectan los mismos terceros con otro nombre
Empieza con un waterfall de red y una grabación Performance en un perfil móvil de gama media. Nombra cada origen de terceros. Si no puedes nombrar un dueño y un motivo de negocio para una etiqueta, es candidata a eliminación antes de cualquier magia con workers.
Cómo encontrar qué script de terceros empeora el INP
El artículo de web.dev sobre INP fija los umbrales en el percentil 75 de las cargas de página de campo: 200 ms o menos es bueno, más de 500 ms es pobre y lo que queda en medio necesita mejora. Divide cada interacción en retraso de entrada, duración de procesamiento y retraso de presentación. El trabajo de terceros cae sobre todo en la primera fase: una tarea larga de una etiqueta que ya se está ejecutando cuando el visitante toca la pantalla retrasa el momento en que puede arrancar su propio manejador de eventos.
Para ponerle nombre a esa tarea, usa la Long Animation Frames API (LoAF). Llegó en Chrome 123 y registra los frames en los que la actualización de renderizado se retrasó más de 50 ms, con atribución para cada script que corrió más de 5 ms. Cada entrada de script incluye sourceURL, invoker, invokerType y forcedStyleAndLayoutDuration, así que puedes ver si un archivo del vendor se ejecutó como listener de eventos, como callback de un temporizador o como script clásico recién evaluado. Firefox y Safari no soportan la API, de modo que los resultados son una muestra de Chromium, no un 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 datos de campo, la librería web-vitals incluye desde la versión 4 las entradas LoAF que se solapan con la interacción en su atribución de INP (longAnimationFramesEntries), así que un endpoint RUM puede registrar qué origen estaba ocupado durante la interacción más lenta de una visita real. En laboratorio, el panel Performance de DevTools ofrece un insight de terceros que agrupa las peticiones por proveedor con el dataset abierto Third Party Web. La auditoría de resumen de terceros de Lighthouse señala las páginas donde el código de terceros bloquea el hilo principal 250 ms o más. Usa la vista de laboratorio para encontrar sospechosos y los datos de campo para decidir cuál de ellos importa.
Google Tag Manager ralentiza WordPress
GTM y gestores similares son capas de orquestación. No cancelan coste de descarga, parseo ni ejecución. Un contenedor limpio con pocas etiquetas y reglas estrictas puede ser más ligero que cinco scripts hardcodeados de plugins. Un contenedor que dispara todo en All Pages suele ser peor que los plugins que sustituyó.
Reglas prácticas que aguantan en WordPress:
- Un contenedor por propiedad, con dueños nombrados para cada etiqueta.
- Dispara etiquetas de marketing en las plantillas que las necesitan, no en páginas legales, pasos de checkout ya justos o vistas cercanas al admin autenticado.
- Prefiere eventos dataLayer servidos por el servidor frente a scraping del DOM cuando controlas el tema.
- Elimina etiquetas duplicadas (dos propiedades de analytics, dos vendors de chat, tres píxeles de la misma cuenta).
- Versiona el contenedor como versionas releases del tema: revisa diffs cuando alguien “solo añade una etiqueta”.
Si el equipo no puede explicar qué hace una etiqueta en una frase, no la pases por Partytown: elimínala o páusala. Offload de ruido sigue costando red y coordinación del worker.
Cómo cargar scripts de terceros con defer o async en WordPress
Los dos atributos de <script> deciden si el parser HTML espera. Según MDN, un script defer se ejecuta después de analizar el documento y antes de DOMContentLoaded, en el orden en que aparecen los scripts. Un script async se descarga en paralelo y se evalúa en cuanto está disponible, sin garantía de orden. Ninguno de los dos atributos hace nada en un script clásico inline sin src, y los scripts de módulo ya se difieren por defecto.
Desde WordPress 6.3 puedes pedir cualquiera de los dos atributos con la API del núcleo, sin filtrar script_loader_tag. El último parámetro de wp_register_script() y de wp_enqueue_script(), antes el booleano $in_footer, acepta ahora también un array con las claves strategy e in_footer. Si omites strategy, se mantiene el comportamiento bloqueante de siempre, así que los plugins existentes no cambian.
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,
)
);
} );Lo que pides no siempre es lo que se imprime. La nota para desarrolladores de WordPress 6.3 explica que el núcleo calcula una estrategia elegible. Un handle nunca hereda una estrategia más estricta que la solicitada, y si un script que depende de él es bloqueante, el handle y sus dependencias pasan a ser bloqueantes para conservar el orden de ejecución. Un script inline añadido con wp_add_inline_script() en la posición after tiene el mismo efecto: el núcleo asume que el handle es bloqueante y descarta la intención defer o async. Si una etiqueta de un vendor sigue saliendo sin el atributo, revisa sus dependientes y sus fragmentos inline antes de culpar al plugin.
Qué atributo elegir: la guía de web.dev sobre terceros sugiere async para scripts que deben ejecutarse pronto, como algunos de analytics, y defer para recursos menos críticos. También señala que Chrome y otros navegadores basados en Blink bajan la prioridad de red de los scripts cargados así. WordPress 6.9 añadió la clave fetchpriority al mismo array $args, de modo que un handle puede llevar una prioridad explícita en lugar de depender del valor por defecto del navegador.
Cómo hacer preconnect a orígenes de terceros en WordPress
Una etiqueta de terceros empieza con DNS, TCP y TLS hacia un host que el navegador aún no ha contactado. Una pista <link rel="preconnect"> pide al navegador que prepare esa conexión antes de la petición. La guía de web.dev sobre preconnect es restrictiva: haz preconnect solo a dominios críticos que vayas a usar pronto, mantén la lista corta porque los preconnect de más pueden retrasar otros recursos y usa dns-prefetch para hosts menos críticos. El navegador cierra una conexión preconectada que no se usa en 10 segundos, así que hacer preconnect al vendor de un chat que solo carga al hacer clic desperdicia el handshake. Los recursos que se piden en modo CORS anónimo, como las fuentes, necesitan el atributo crossorigin en la pista; sin él, solo se reaprovecha la consulta DNS.
WordPress imprime estas pistas con el filtro wp_resource_hints, disponible desde 4.6 y con arrays de atributos desde 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 );Añade la pista solo para el origen que la primera vista pide de verdad, normalmente el gestor de etiquetas o el host de analytics, no para cada vendor que figure en el contenedor.
Cómo cargar el chat en WordPress al hacer clic
Chat, calendarios de reserva y embeds de medios comparten patrón: el usuario rara vez necesita el SDK completo en el primer paint. Envía un control ligero (botón CSS, avatar estático, fachada lite de YouTube/Vimeo) y carga el script del vendor bajo intención: clic, foco o hover con un retardo corto para que un pase accidental del ratón no dispare una tormenta de descargas.
En WordPress esto suele significar:
- Desencolar el enqueue automático del plugin o del tema
- Renderizar tu propio markup en el footer o en un bloque
- Inyectar el script real solo tras el handler de interacción, una vez
- Mantener accesibilidad: el control estático debe ser un botón o enlace real con etiqueta clara
El mismo patrón aplica a mapas y embeds sociales. Una imagen estática de mapa que enlace a Google Maps u OpenStreetMap suele ganar a un SDK interactivo en posts de blog. Reserva el embed pesado para páginas donde la interacción es el producto.
La documentación de Lighthouse llama a este patrón fachada: un elemento estático que se parece al embed pero no funciona hasta que el visitante interactúa con él. La auditoría de fachadas enumera opciones de código abierto como lite-youtube-embed y lite-vimeo-embed para vídeo, y react-live-chat-loader para Intercom, Drift, Help Scout y Facebook Messenger. También nombra los costes: una fachada de chat puede perder funciones como el indicador de mensaje nuevo de Drift hasta que carga el widget real, y la reproducción automática de vídeo puede no funcionar de forma fiable cuando el reproductor se carga en diferido.
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,
});Modo de consentimiento y orden de carga del CMP
Las plataformas de consentimiento cambian cuándo pueden ejecutarse las etiquetas. No las hacen baratas por arte de magia. Configuraciones flojas cargan el stack de marketing completo, luego lo cargan otra vez tras aceptar, o bloquean la medición de forma incorrecta mientras siguen enviando chat y heatmaps que nunca necesitaron ejecución temprana.
Secuencia workable en WordPress:
- Carga el CMP lo bastante pronto para registrar una elección, sin empaquetar cada SDK publicitario a su lado.
- Por defecto, haz esperar a marketing y ads a una decisión donde tu jurisdicción y política lo exijan (RGPD / LOPDGDD en España).
- Tras el consentimiento, inicializa solo las etiquetas que la elección permite, una vez.
- Mantén el JS esencial del sitio (navegación, formularios, checkout) fuera de la rama de consentimiento de marketing para que la UX no espere a la librería del banner.
El consentimiento mode (para etiquetas Google) y APIs equivalentes de otros vendors ajustan cómo se comporta la medición bajo distintos estados. Trátalos como cableado de política más configuración de etiquetas, y sigue aplicando diferido y recortes de inventario. Un contenedor consentido pero sobredimensionado sigue siendo un problema de INP.
Documenta la matriz: qué etiquetas corren antes del consentimiento, cuáles tras consentimiento de analytics, cuáles solo tras ads, y cuáles nunca en ese locale. Guarda esa matriz junto al workspace de GTM para que el próximo lanzamiento de campaña no reabra todos los scripts en All Pages.
Merece la pena Partytown en WordPress
Partytown mueve scripts de terceros seleccionados a un web worker y proxifica el acceso al DOM de vuelta al hilo principal. En algunas cargas de analytics y píxeles puede reducir contención. No es un acelerador universal.
Restricciones a planificar:
- Scripts que deben mutar el layout de forma síncrona (muchas herramientas A/B y de personalización) son malos candidatos a worker.
- Proxificar llamadas DOM tiene overhead; una etiqueta pequeña puede no beneficiarse.
- Service worker, CDN y CSP deben permitir la librería Partytown, los workers y cualquier canal de atomics/proxy que active.
- El debugging se endurece: los fallos aparecen como hits perdidos, no como un error PHP obvio del tema.
- Caches de página y plugins de optimización que reescriben tags de script pueden romper el handoff
type="text/partytown"(o equivalente) si no se configuran juntos.
La propia página de trade-offs de Partytown concreta dónde encaja. Nombra Google Tag Manager y Facebook Pixel como el tipo de script al que mejor se adapta, y advierte que los scripts que insertan muchos nodos en el DOM, o los scripts con mucha interfaz como diálogos con formularios, pueden ser malos candidatos. Un manejador de terceros que llama a event.preventDefault() no tiene efecto desde el worker. Las operaciones DOM se limitan y se agrupan a propósito, y una llamada bloqueante puede tardar unos milisegundos. La versión con service worker usa tres hilos; la versión con Atomics, dos. Algunos vendors no envían las cabeceras CORS que necesita el worker, y esas peticiones tienen que pasar por un proxy que tú operes.
Camino de adopción más seguro:
- Termina inventario, gating de consentimiento y click-to-load para chat/medios.
- Elige una etiqueta de analytics no crítica como piloto.
- Verifica hits en la UI del vendor y RUM/INP antes y después en las mismas URLs.
- Amplía solo a etiquetas que sigan siendo correctas bajo el proxy.
- Mantén un escape explícito a carga en hilo principal para etiquetas que fallen la validación.
Existen otros patrones con workers (workers propios para trabajo first-party pesado, iframes aislados para widgets no fiables). La misma cautela: aísla donde ayude, mide y no anuncies “cero terceros en el hilo principal” salvo que tus datos de campo lo respalden.
Conviene alojar en local o aislar los scripts de terceros
La guía de web.dev sobre terceros describe tres opciones entre mantener una etiqueta tal cual y eliminarla. Alojar en tu servidor un script crítico te da control sobre el tiempo de DNS y las cabeceras de caché HTTP, pero una copia propia no recibe los cambios de API ni las correcciones de seguridad del vendor hasta que alguien la actualiza a mano. En WordPress eso significa una tarea de actualización programada o un paso de build, no un archivo copiado una vez en la carpeta del tema y olvidado.
Cargar un script directamente dentro de un iframe evita que bloquee la ejecución de la página principal, y el atributo sandbox restringe lo que el script puede hacer. Eso encaja mejor con widgets no fiables que con analytics, que suele necesitar el contexto first-party de la página. Un service worker puede cachear scripts de terceros para controlar cada cuánto se piden a la red, o retener peticiones de terceros no esenciales hasta que la página llega a un momento clave para el usuario. En un sitio WordPress típico, el click-to-load y las reglas de disparo por plantilla cubren casi todo ese terreno con menos maquinaria, así que reserva la vía del service worker para los casos en que ya tengas uno.
Cuándo usar GTM server-side en WordPress
GTM server-side y endpoints first-party pueden mover el fan-out hacia Google, Meta y otros vendors fuera del navegador. El visitante habla sobre todo con tu dominio; tu servidor distribuye eventos. Eso reduce peso de terceros, pero introduce hosting, reenvío de consentimiento, identidad y QA.
Úsalo cuando marketing necesita de verdad muchos destinos y el stack del navegador es el cuello de botella que has medido, no porque un artículo lo haya llamado el estándar de 2026. Mantén un colector mínimo, respeta consentimiento de extremo a extremo y haz regression de conversiones tras cada cambio de contenedor.
Checklist para auditar scripts de terceros en WordPress
- Exporta cada URL de script de una carga en frío de plantillas clave (home, producto, checkout, artículo).
- Mapea cada origen a un dueño y una categoría de consentimiento.
- Elimina o pausa duplicados y etiquetas muertas en GTM y plugins.
- Convierte chat y embeds no esenciales a click-to-load.
- Alinea CMP y consentimiento mode para que las etiquetas se inicialicen una vez, bajo el estado correcto.
- Remide INP de campo y long tasks de laboratorio en la misma clase de dispositivo.
- Solo entonces evalúa Partytown o tagging server-side para el peso de analytics restante.
Si necesitas un desarrollador WordPress para cablear consentimiento, gobernanza de etiquetas y medición de rendimiento en el tema sin romper el reporting de marketing, trátalo como ingeniería con tests de aceptación, no como un interruptor de plugin de velocidad.
Cuándo está terminada la limpieza de scripts de terceros
Hecho no es un screenshot perfecto de Lighthouse. Hecho es una lista de terceros más corta, comportamiento de consentimiento claro, widgets que cargan bajo demanda e INP de campo que ya no se derrumba cuando marketing añade una etiqueta de campaña. Conserva la pista de auditoría: versiones de contenedor, config del CMP y notas de medición antes/después. Ese rastro es lo que mantiene el hilo principal tuyo cuando llega la siguiente petición de píxel.
Si necesitas ayuda para auditar y optimizar los scripts de terceros de tu sitio WordPress, el equipo de WPPoland ofrece optimización de velocidad con auditoría de etiquetas, CMP e INP de campo.
