Cómo Optimizar Scripts de Terceros en 2026: Partytown, Facade Pattern y Presupuestos con Lighthouse CI
Los scripts de terceros (GTM, Intercom, píxeles, chat) son la causa número uno de INP y LCP degradados. Esta guía práctica muestra cómo auditarlos con Lighthouse y third-party-web, moverlos al Web Worker con Partytown, aplicar el patrón facade a embeds pesados y bloquear regresiones con presupuestos en Lighthouse CI.
Para optimizar los scripts de terceros en 2026 hay que hacer tres cosas en este orden: auditar con Lighthouse y third-party-web para saber quién cuesta cuántos milisegundos, mover los scripts no críticos al Web Worker con Partytown, y reemplazar los embeds pesados (YouTube, Intercom, mapas) con el facade pattern. En un e-commerce real que auditamos el trimestre pasado, esta combinación recortó casi 1,6 segundos del Total Blocking Time y bajó el INP de la zona roja (más de 500 ms) a la zona verde (por debajo de 200 ms) sin tocar el JavaScript propio.
Los scripts de terceros representan de media el 45–60% del tiempo de bloqueo en sitios de e-commerce en 2026 (datos HTTP Archive).
La auditoría empieza en Lighthouse ("Reduce the impact of third-party code") y sigue en la librería third-party-web, que clasifica cada dominio por categoría y coste.
Partytown 0.10+ mueve GTM, Google Analytics, Meta Pixel e Intercom al Web Worker, liberando el hilo principal.
El facade pattern reemplaza embeds pesados (YouTube, Vimeo, chat widgets) por una imagen o placeholder ligero que sólo carga el script real tras interacción.
fetchpriority, defer, async y loading="lazy" en iframes son ajustes de cinco minutos con impacto medible en INP.
Un presupuesto de rendimiento declarado en lighthouserc.js convierte cualquier PR que meta un script no autorizado en un fallo de CI.
¿Qué son los scripts de terceros y por qué duelen tanto?
Un script de tercero es cualquier JavaScript que tu página descarga desde un dominio que no controlas: Google Tag Manager, Google Analytics 4, Meta Pixel, TikTok Pixel, Intercom, Zendesk, HotJar, Optimizely, ChatGPT widgets, Stripe.js, Cloudflare Turnstile, embeds de YouTube… la lista real de un e-commerce mediano ronda los 25–40 dominios distintos. Y sí, es exactamente tan feo como suena. Duelen por tres razones concretas y medibles:
Bloquean el hilo principal. Aunque los cargues con async, en cuanto llegan se parsean y ejecutan en el hilo principal, generando long tasks que retrasan INP y TBT.
Compiten por ancho de banda con recursos críticos. Un GTM que se descarga antes que la fuente WOFF2 empuja el LCP hacia arriba.
Cambian sin que te enteres. Un tag manager permite a marketing añadir nuevos píxeles sin pasar por revisión de código; una mañana te levantas con 300 ms más de TBT y nadie sabe por qué.
Según el informe Web Almanac 2025 (Third Parties), el 94% de los sitios cargan al menos un recurso de tercero, y la mediana de páginas móviles pasa 1,2 segundos ejecutando código de terceros. En categorías como e-commerce y publicaciones esa cifra sube por encima de 2 segundos. Google penaliza esto en Core Web Vitals, y desde la subida de INP como métrica oficial en marzo de 2024, los scripts que "sólo" añaden 80 ms cada uno acaban destrozando la puntuación p75.
¿Cómo auditar los scripts de terceros de tu sitio?
Antes de tocar nada, hay que medir. Sin datos, cualquier "optimización" es fe. En mi flujo uso tres herramientas por este orden:
1. Lighthouse: el diagnóstico rápido
Ejecuta Lighthouse en modo Mobile, con throttling Slow 4G activado. Busca dos auditorías concretas:
"Reduce the impact of third-party code": te da una tabla con dominio, tamaño de transferencia y tiempo bloqueado en el hilo principal.
"Minimize main-thread work": aquí ves si el problema es Script Evaluation (parsing) o Script Parsing & Compilation.
Si "Reduce the impact of third-party code" te reporta más de 250 ms bloqueando el hilo, tienes un problema medible. Si supera los 600 ms en 4G lento, tienes un problema de negocio: cada 100 ms extra en móvil bajan la conversión entre 1% y 2%, según los estudios de web.dev.
2. third-party-web: el catálogo con nombres y apellidos
La librería third-party-web de Patrick Hulce clasifica más de 5.000 dominios por categoría (analytics, tag-manager, ads, social, video, customer-success, cdn, hosting…). Lighthouse la usa internamente. Puedes correrla contra un HAR local:
// audit-3p.mjs: cruza tu HAR con la clasificación de third-party-web
import { getEntity, getFirstPartyEntity } from 'third-party-web';
import fs from 'node:fs';
const har = JSON.parse(fs.readFileSync('trace.har', 'utf8'));
const totals = new Map();
for (const entry of har.log.entries) {
const url = entry.request.url;
const entity = getEntity(url);
if (!entity) continue; // primera parte
const bytes = entry.response.content.size || 0;
const blockingTime = entry._blockingTime || 0; // Chrome DevTools lo añade
const prev = totals.get(entity.name) || { bytes: 0, blockingTime: 0, category: entity.categories[0] };
totals.set(entity.name, {
bytes: prev.bytes + bytes,
blockingTime: prev.blockingTime + blockingTime,
category: prev.category,
});
}
// Ordena por tiempo de bloqueo (los peores primero)
const worst = [...totals.entries()]
.sort((a, b) => b[1].blockingTime - a[1].blockingTime)
.slice(0, 10);
console.table(worst.map(([name, s]) => ({
name,
category: s.category,
kb: (s.bytes / 1024).toFixed(1),
blockingMs: s.blockingTime.toFixed(0),
})));
3. Chrome DevTools Performance: la reproducción sobre el terreno
Graba una traza en la ruta más crítica (normalmente Home → PDP en e-commerce) y filtra el Bottom-Up por Group by URL. Cualquier URL que no sea tuya y aparezca en el top 10 es candidato. Anota Self Time, no sólo Total Time. Combinado con un seguimiento RUM de Core Web Vitals, esta traza te dice qué duele en laboratorio y en campo.
Estrategia de cuatro niveles para reducir su impacto
Cuando ya tienes la lista de culpables, aplico esta escalera por orden. Cada nivel es más caro en esfuerzo, pero también más eficaz:
GTM, GA4, píxeles, herramientas de personalización
El error más común que veo en revisiones es saltar al nivel 4 sin haber pasado por el 1. Si tienes cinco proveedores de analytics porque nadie ha limpiado desde 2022, Partytown no te va a salvar; te va a mover cinco cosas al worker que no deberían existir. La regla de mi equipo, y no la negocio: ningún script entra sin dueño y sin fecha de revisión.
Partytown: cómo mover GTM y píxeles al Web Worker
Partytown es una librería de Builder.io que intercepta las llamadas a document, window y APIs del DOM desde un Web Worker, las serializa mediante synchronous XHR a un service worker y las reproduce en el hilo principal. En la práctica: metes GTM en un worker y el hilo principal sólo procesa las mutaciones DOM que realmente ocurren (que suelen ser cero para un píxel puro).
Instalación en un proyecto Next.js 15
npm install @builder.io/partytown@^0.10.3
En next.config.js, copia los assets de Partytown al directorio público:
// next.config.js
import { copyLibFiles } from '@builder.io/partytown/utils';
const nextConfig = {
async redirects() { return []; },
webpack(config, { isServer }) {
if (isServer) {
// Copia partytown.js y su worker a /public/~partytown
copyLibFiles('./public/~partytown');
}
return config;
},
};
export default nextConfig;
En el app/layout.tsx, inyecta el script type="text/partytown". Partytown lo intercepta y lo ejecuta en el worker:
// app/layout.tsx
import { Partytown } from '@builder.io/partytown/react';
export default function RootLayout({ children }) {
return (
<html lang="es">
<head>
<Partytown
debug={process.env.NODE_ENV !== 'production'}
forward={['dataLayer.push', 'gtag']}
/>
{/* GTM en el worker (nota el type) */}
<script
type="text/partytown"
dangerouslySetInnerHTML={{
__html: `
window.dataLayer = window.dataLayer || [];
function gtag(){dataLayer.push(arguments);}
gtag('js', new Date());
gtag('config', 'G-XXXXXXX');
`,
}}
/>
<script
type="text/partytown"
src="https://www.googletagmanager.com/gtm.js?id=GTM-XXXX"
/>
</head>
<body>{children}</body>
</html>
);
}
Lo importante es la propiedad forward. Como el resto de tu app sigue llamando a dataLayer.push() desde el hilo principal, Partytown necesita saber que esas llamadas hay que reenviarlas al worker. Sin esa lista, los eventos se pierden. Me pasó en un despliegue nuestro: durante 48 horas GA4 no registró ni un evento personalizado porque olvidamos añadir gtag al forward. Nadie se dio cuenta hasta que marketing preguntó por los datos.
Qué esperar en métricas
En una PDP de nuestro e-commerce, medido con WebPageTest en un Moto G4 sobre 4G lento, mover GTM + GA4 + Meta Pixel + TikTok Pixel a Partytown bajó el TBT de 1420 ms a 380 ms y el INP p75 de 510 ms a 190 ms. El LCP mejoró 220 ms porque el hilo principal ya no competía por parsear JS mientras el navegador intentaba pintar la imagen del producto. Si te interesa profundizar en INP, tenemos una guía sobre depuración de INP con LoAF y scheduler.yield().
Facade pattern para YouTube, Intercom y mapas
El facade pattern (o import on interaction) consiste en reemplazar un embed pesado por una imagen o marcador de posición estático que sólo carga el script real cuando el usuario interactúa (click, hover). Es la única técnica que reduce el coste a cero hasta que hace falta.
Los tres candidatos clásicos son:
Vídeo (YouTube/Vimeo): un iframe de YouTube trae ~600 KB de JavaScript y ~10 dominios de terceros. Un facade con la miniatura y un botón de play carga 15 KB.
Chat (Intercom/Zendesk/Drift): el bundle de Intercom pasa de 400 KB. Un botón "Chat" que hace import() del SDK al click ahorra el coste completo en el 96% de las sesiones que nunca lo abren.
Mapas (Google Maps): igual, una imagen estática de Static Maps API con un click-to-load.
Facade para YouTube con lite-youtube-embed
<!-- HTML: 0 KB de JS hasta el click -->
<link
rel="stylesheet"
href="/vendor/lite-youtube-embed.css"
/>
<script type="module" src="/vendor/lite-youtube-embed.js" defer></script>
<lite-youtube
videoid="dQw4w9WgXcQ"
playlabel="Reproducir: título del vídeo"
style="background-image: url('/img/thumbs/dQw4w9WgXcQ.webp');"
></lite-youtube>
Facade para Intercom (carga bajo demanda)
// components/ChatFacade.tsx
'use client';
import { useState, useCallback } from 'react';
export function ChatFacade() {
const [loading, setLoading] = useState(false);
const loadIntercom = useCallback(async () => {
if (window.Intercom || loading) return;
setLoading(true);
// El SDK real de Intercom entra ahora, no en la carga inicial
await new Promise<void>((resolve, reject) => {
const s = document.createElement('script');
s.src = 'https://widget.intercom.io/widget/APP_ID';
s.async = true;
s.onload = () => resolve();
s.onerror = reject;
document.head.appendChild(s);
});
window.Intercom('boot', { app_id: 'APP_ID' });
window.Intercom('show');
}, [loading]);
return (
<button
type="button"
aria-label="Abrir chat de soporte"
onClick={loadIntercom}
className="chat-facade-btn"
>
💬 Soporte
</button>
);
}
El facade tiene una ventaja adicional que suele olvidarse: elimina el CLS que provocan los widgets que se pintan tarde. Si Intercom aparece 2 segundos después de la carga, tu esquina inferior derecha da un salto que Google mide. Con un facade, el botón vive ahí desde el primer paint. Si quieres ir más lejos con CLS, tenemos una guía dedicada a eliminar layout shifts con aspect-ratio y CSS Containment.
fetchpriority, defer/async y lazy iframes en 2026
Estos son los ajustes de menor coste. Se hacen en HTML, no requieren librerías y suelen dar un +5 a +10 en Performance Score de Lighthouse. Honestamente, son la fruta a la altura de la mano.
fetchpriority en scripts (Chrome 121+, Safari 17.2+, Firefox 132+)
Todos los iframes que no estén above-the-fold deben llevar loading="lazy". Es una línea, universalmente soportado desde 2022, y evita descargar el bundle completo del embed hasta que se acerca al viewport:
<iframe
src="https://player.vimeo.com/video/XXXX"
loading="lazy"
title="Vídeo de producto"
width="640"
height="360"
></iframe>
La regla de oro defer vs async
Después de años de auditorías, uso esta heurística sin excepción:
defer por defecto para scripts propios y de terceros que dependen del DOM (analytics con selectores, A/B testing).
async sólo para píxeles totalmente independientes (Meta Pixel, LinkedIn Insight).
Nada (blocking) sólo si el script debe ejecutarse antes de que se pinte cualquier cosa, normalmente scripts anti-flicker de A/B testing. Y sí, esos son los que más duelen: audítalos.
Presupuesto de rendimiento con Lighthouse CI
Sin un presupuesto declarado en CI, cualquier optimización se erosiona en semanas. Marketing añade un pixel, un desarrollador incluye un SDK "temporal", y en tres meses estás donde empezaste. Lighthouse CI resuelve esto: cualquier PR que meta más de X KB de JavaScript de terceros falla el build.
El resultado es simple: nadie mete un tag sin que Lighthouse lo vea, y la revisión deja de depender de la memoria del reviewer. Complementa esto con métricas de TTFB con Early Hints y Edge SSR para tener cobertura de todo el camino desde el servidor hasta la interacción.
Preguntas frecuentes
¿Partytown funciona con todos los scripts de terceros?
No. Partytown funciona muy bien con analytics, píxeles y tag managers (GTM, GA4, Meta, TikTok, HotJar, Segment). No funciona con scripts que necesiten manipular el DOM de forma síncrona o que dependan de APIs del hilo principal como document.write tardío, algunos widgets de chat con iframes inyectados en la carga, o A/B testing anti-flicker. Para esos, usa facade pattern o cárgalos con defer.
¿Cuál es la diferencia entre defer y async?
async descarga el script en paralelo y lo ejecuta en cuanto llega, sin respetar orden. defer también descarga en paralelo pero ejecuta al final, respetando el orden del HTML y después de que el DOM esté parseado. Para scripts de terceros que dependen del DOM (analytics con selectores, testing), usa defer. Para píxeles independientes, async.
¿Cómo mido el impacto real de un script de tercero en INP?
Con la Long Animation Frames API (LoAF), disponible en Chrome 123+. Registra PerformanceLongAnimationFrameTiming entries desde tu RUM y correlaciona scripts[].invoker y scripts[].sourceURL con la URL del script. Cualquier entry mayor de 50 ms cuyo sourceURL sea un dominio de tercero es un candidato a Partytown o facade.
¿El facade pattern afecta al SEO de vídeos y contenido embebido?
No si se implementa bien. Usa la miniatura oficial del proveedor, mantén schema.org/VideoObject con contentUrl y thumbnailUrl, y asegúrate de que el HTML incluye el título del vídeo en texto plano. Googlebot indexa el markup, no el iframe. Para YouTube, lite-youtube-embed preserva todo esto out of the box.
¿Cuánto tarda ver mejoras en Core Web Vitals reales después de estos cambios?
Los datos de laboratorio (Lighthouse, WebPageTest) mejoran inmediatamente al desplegar. Los datos de campo (CrUX, tu RUM) usan una ventana móvil de 28 días, así que verás el efecto completo entre 3 y 5 semanas después del despliegue. Usa RUM propio para no esperar tanto: web-vitals.js te da la señal en horas, no en semanas.
Cómo optimizar el bfcache en 2026: usa NotRestoredReasons para diagnosticar por qué Chrome expulsa tu página, arregla los 8 bloqueadores comunes (unload, WebSocket, no-store) y sube tu hit rate al 60% con impacto directo en LCP e INP.
Aprende a implementar compresión con diccionario compartido (SDC) en 2026: dcb (Brotli), dcz (Zstandard), Use-As-Dictionary y passthrough en Cloudflare, con ejemplos de código y métricas RUM.
Implementa RUM de Core Web Vitals con web-vitals.js v5 y la CrUX API. Recolecta LCP, INP y CLS reales, calcula p75 por dispositivo y compara contra el CrUX oficial en menos de 30 líneas.
