Scripts de terceros y rendimiento web: el impuesto que puedes elegir no pagar
Cada script de terceros — una etiqueta de analítica, un chat, un píxel de marketing, un embed de video — es otro dominio al que el navegador de tu visitante debe conectarse, otro payload que descargar, analizar y ejecutar, y otro bloque de tiempo en el único hilo principal que tu propia página y cada interacción del usuario tienen que compartir. Cerca del 94% de los sitios los llevan, promedian de 50 a 200 milisegundos de bloqueo del hilo principal cada uno, y en conjunto son la causa #1 de un mal INP — el Core Web Vital más fallado en 2026. El arreglo estándar es una escalera de mitigaciones: audita lo que de verdad cargas y borra lo que no se gana su lugar; dale defer a los que quedan para que dejen de bloquear el analizador; retrasa los no críticos hasta que el usuario interactúa; envuelve los chats y embeds de video pesados en un facade ligero; mueve los scripts tercos a un web worker con una herramienta como Partytown; autoaloja lo que puedas; y haz preconnect a los dominios que conservas. Todo eso funciona — pero fíjate que toda la escalera es esfuerzo gastado en deshacer un daño que invitaste, por lo que el arreglo más limpio es el que partimos de inicio: no añadir el tercero en primer lugar.
Por qué un script se vuelve un problema de rendimiento
La causa raíz es un hecho sobre los navegadores: casi todo el JavaScript corre en un solo hilo principal, así que cuando un script de terceros se ejecuta, tu propio código tiene que esperar (PageSpeedFix, 2026). Y un script es más que una descarga — el navegador debe analizarlo, compilarlo y ejecutarlo, un trabajo que retrasa el renderizado y empuja hacia atrás el momento en que un usuario puede interactuar (WebsiteSpeedy, 2026). Por defecto esa descarga y ejecución es síncrona, lo que significa que una etiqueta de script simple bloquea el analizador de HTML y la construcción del DOM hasta que termina (patterns.dev, 2026).
Ese único mecanismo daña los tres Core Web Vitals. El código de terceros perjudica el LCP al competir por ancho de banda y CPU, así que tu imagen o encabezado principal llega más tarde; causa CLS cuando inyecta un anuncio o banner que mueve el contenido debajo; y hunde el INP cuando corre en el hilo principal justo mientras un usuario hace clic (DebugBear, 2026). Como esos vitals alimentan el ranking de Google, esto deja de ser solo un problema de velocidad y se vuelve uno de SEO (WP Rocket, 2026). Lighthouse vuelve concreto el umbral: marca la auditoría de terceros en cuanto ese código bloquea el hilo principal por más de 250 milisegundos en total (PageSpeedFix, 2026).
Nunca es un script — son diez
La razón por la que esto importa tanto en la práctica es que los sitios rara vez se detienen en uno. Más del 94% de los sitios cargan scripts de terceros, y la mayoría llevan una multitud — analítica, gestor de etiquetas, un píxel social, una herramienta de mapas de calor, un chat, un banner de consentimiento — todos peleando por el hilo principal a la vez (PageSpeedFix, 2026). Cada uno añade en promedio de 50 a 200 milisegundos de bloqueo del hilo principal, así que la aritmética se pone fea rápido (LeadsuiteNow, 2026).
La métrica que más sufre es el INP, y los números son crudos: según datos de campo de principios de 2026, cerca del 43% de los sitios todavía falla el umbral de 200 milisegundos de INP, lo que lo vuelve el Core Web Vital más fallado, y los scripts de terceros son su causa más común (Pravin Kumar, 2026). Hay además una razón más silenciosa, organizativa, por la que el problema se enquista. Como lo puso un análisis, las etiquetas que ralentizan un sitio suelen ser la parte que no pertenece a ninguna persona ni equipo, así que caen entre las grietas y nadie las quita (SearchX, 2026).
Los peores infractores: chats y embeds
Algunos terceros son mucho más pesados de lo que parecen. Un chat puede descargar más de 500KB de JavaScript — en la práctica una aplicación React completa — solo para renderizar un botón con un icono de burbuja de diálogo (PageSpeedFix, 2026). Los embeds de video son similares: el equipo de desarrolladores de Chrome halló que los embeds de YouTube bloquean el hilo principal 4,5 segundos en el 10% de los sitios móviles, y al menos 1,6 segundos en la mitad de los sitios estudiados (PageSpeedFix, 2026). Los píxeles de seguimiento se ven diminutos por separado pero se apilan rápido — cinco de ellos pueden sumar de dos a cuatro segundos a cada carga de página (PageSpeedFix, 2026).
La buena noticia es que estos tienen arreglos conocidos. Para un chat o un embed de video, usa un facade — un botón placeholder ligero que carga la cosa real solo cuando un usuario hace clic (Pravin Kumar, 2026). Para un script de protección de formularios como reCAPTCHA, cárgalo solo en las páginas con formularios y hazlo lazy-load al enfocar el formulario en vez de en cada página (patterns.dev, 2026). El patrón en todo es el mismo: no pagues por la cosa pesada hasta el momento en que de verdad se necesita.
Paso uno: audita lo que de verdad tienes
No puedes arreglar lo que no has medido, así que el primer movimiento es un inventario. PageSpeed Insights ahora muestra un insight de “Terceros” que lista cada fuente externa con su tamaño de transferencia y su tiempo de hilo principal — informativo en vez de aprobado/reprobado, pero ideal para encontrar a los mayores infractores (WP Rocket, 2026). El panel de Rendimiento de Chrome DevTools muestra exactamente cuándo se ejecuta cada script y cuánto bloquea, y WebPageTest revela la cadena de peticiones — qué scripts cargan otros scripts, exponiendo costos ocultos (PageSpeedFix, 2026).
Luego anótalo. Documenta cada script en una hoja de cálculo con su nombre, dominio, tamaño de archivo, tiempo de bloqueo del hilo principal, el equipo responsable y su propósito de negocio, y agrúpalos en categorías como analítica, publicidad, social y soporte para decidir qué conservar, ajustar o cortar (SearchX, 2026). Aquí aparece la optimización de mayor impacto, porque eliminar un tercero por completo gana a cualquier cantidad de ajuste — quita todo lo que no contribuya de forma directa a la experiencia del usuario o a los ingresos (DebugBear, 2026).
Después difiere, retrasa y pon facades
Para los scripts que sobreviven al corte, controla cómo cargan. Añade defer a los scripts no críticos para que se descarguen en paralelo y se ejecuten solo después de que el documento se analiza, conservando su orden; defer debería ser la opción por defecto, con async para los scripts independientes que no necesitan correr en secuencia (patterns.dev, 2026). Mejor aún, retrasa los no esenciales hasta después de que la página sea interactiva — en un gestor de etiquetas, cambia los disparadores de “Todas las páginas” a un disparador de ventana cargada o de interacción para que los píxeles y las etiquetas de remarketing se disparen tarde (PageSpeedFix, 2026).
La objeción común — que diferir los scripts distorsionará la analítica o los ingresos por anuncios — se ha probado y en gran parte se ha desmentido. En un caso muy citado, diferir todos los scripts no sesgó ninguna métrica de analítica ni de publicidad; en cambio, el tiempo del “primer anuncio cargado” mejoró en un promedio de cuatro segundos (patterns.dev, 2026). Normalmente no pierdes nada medible y ganas una página visiblemente más rápida.
Web workers, autoalojar y preconnect
Cuando un script no se puede quitar ni diferir del todo, tres herramientas más ayudan. Un web worker mueve el script fuera del hilo principal a un hilo de fondo — esto es lo que hace Partytown, corriendo los scripts de terceros en un worker para que el hilo principal quede libre para renderizar y responder, a costa de que el propio script de terceros corra un poco más lento por diseño (DebugBear, 2026). Autoalojar un script que arrastra el rendimiento te da control sobre cómo carga y te deja cachearlo, así que puedes diferirlo o hacerlo lazy-load mientras conservas la funcionalidad (SearchX, 2026) — el mismo razonamiento detrás de nuestra guía sobre autoalojar fuentes web.
Para los dominios que sí conservas, establece la conexión temprano. Un resource hint preconnect completa la búsqueda de DNS, el handshake TCP y la negociación TLS por adelantado, lo que puede recortar hasta 800 milisegundos de la carga de un recurso de terceros; dns-prefetch hace la versión más ligera de solo DNS y conviene a orígenes importantes pero no críticos (WP Rocket, 2026). Son victorias pequeñas al lado del borrado, pero para un script que decidiste conservar, valen la pena.
La salvedad honesta: a veces eres tú, no ellos
Antes de culpar a un proveedor, revisa tu propia integración, porque la falla suele estar en cómo se configuró un tercero y no en el tercero mismo — correr doscientas pruebas A/B y experimentos de marketing a la vez será lento sin importar de quién es el logo en la herramienta (DebugBear, 2026). La analítica recibe más culpa de la que merece por la misma razón: Google Analytics 4 por sí solo es ligero y rara vez es la causa de un puntaje fallido, y mucha de la confusión viene de leer mal los datos de laboratorio de PageSpeed como si fueran datos de campo de usuarios reales (NitroPack, 2026). Diagnostica antes de cortar, para quitar la etiqueta que de verdad te cuesta y no la más fácil de nombrar.
El arreglo más limpio es el que partimos de inicio
Relee esa escalera — auditar, borrar, diferir, retrasar, facade, web worker, autoalojar, preconnect — y emerge un patrón: casi cada peldaño es trabajo gastado en deshacer un daño que elegiste invitar. Ese encuadre es por lo que nuestro valor por defecto es distinto. Construimos sitios sin widgets, sin embeds y con analítica mínima desde el inicio, así que no hay impuesto de hilo principal que recuperar después ni un cajón de etiquetas olvidadas que “cae entre las grietas” porque nadie lo posee. Cero peticiones de terceros no es una preferencia estética; es la aritmética de esta guía corrida al revés — cada bloque de tiempo de hilo principal de los puntos clave de arriba es tiempo que simplemente nunca gastamos.
Nada de esto significa que un tercero nunca valga la pena. Cuando uno de verdad se gana su lugar, aplica la misma caja de herramientas — difiérelo, ponle facade, autoaloja, hazle preconnect — y pagas el costo a propósito, con los ojos abiertos. Pero el valor por defecto honesto para un sitio rápido, reactivo y privado es menos de ellos, lo que además elimina toda una clase de obligaciones de privacidad y consentimiento que llegan en el momento en que el script de otro corre en tu página. Esta es la misma decisión única detrás de nuestro pilar sobre Core Web Vitals y velocidad web y nuestra guía sobre JavaScript y rendimiento web: el script más rápido y más seguro es el que nunca envías.
Frequently asked
- ¿Cuánto ralentizan un sitio los scripts de terceros?
- Cada script de terceros añade en promedio de 50 a 200 milisegundos de bloqueo del hilo principal, y el efecto se acumula porque la mayoría de los sitios corren unos diez a la vez. La investigación de Chrome halló que los peores bloquean el hilo principal hasta 1,6 segundos en más de la mitad de los sitios analizados, y apilar cinco píxeles de seguimiento puede sumar de dos a cuatro segundos a cada carga de página. Como todo ese JavaScript compite en un solo hilo principal, retrasa tanto el renderizado de tu contenido como la respuesta de cada clic.
- ¿Los scripts de terceros afectan a los Core Web Vitals y al SEO?
- Sí, a las tres métricas. Dañan el LCP al competir por ancho de banda y CPU, así que tu contenido principal renderiza más tarde; causan CLS cuando inyectan banners o contenido que mueve la página; y — lo más importante en 2026 — arruinan el INP al monopolizar el hilo principal cuando un usuario interactúa. El INP es ahora una señal de ranking y el Core Web Vital más fallado, con cerca del 43% de los sitios por debajo del umbral de 200 milisegundos, y los scripts de terceros son su causa más común. Como los Core Web Vitals alimentan el ranking de Google, esto es un problema de SEO tanto como de velocidad.
- ¿Cuál es la diferencia entre async y defer para los scripts?
- Ambos dejan que un script se descargue en paralelo en vez de bloquear el analizador de HTML, pero difieren en la ejecución. Un script con defer se descarga junto al análisis y corre solo después de que el documento se analiza, preservando el orden de varios scripts diferidos — es el valor por defecto sensato para el código no crítico. Un script con async corre en cuanto termina de descargarse, lo que puede interrumpir el análisis y no garantiza el orden. Cualquier etiqueta de script sin ninguno de los dos atributos bloquea por completo el análisis del HTML mientras se carga y corre.
- ¿Qué es Partytown y debería usarlo?
- Partytown es una librería que corre los scripts de terceros en un web worker — un hilo de fondo separado — en vez de en el hilo principal, lo que libera el hilo principal para renderizar tu contenido y manejar las interacciones. Es una buena opción cuando tienes código de terceros que no puedes quitar pero que daña la respuesta, aunque el propio script de terceros puede correr un poco más lento por diseño, ya que ahora se prioriza tu contenido. Es una herramienta de una escalera que también incluye diferir, retrasar hasta la interacción, facades y autoalojar.
- ¿Debería quitar Google Analytics para mejorar el rendimiento?
- Normalmente no — Google Analytics 4 por sí solo es relativamente ligero, cerca de 30KB, y rara vez causa un fallo de Core Web Vitals por sí mismo. El problema de rendimiento casi siempre es el peso combinado de muchas etiquetas cargadas por un gestor de etiquetas: analítica más varios píxeles, un chat, mapas de calor y herramientas de consentimiento compitiendo a la vez. La jugada productiva es auditar todo lo que se carga por tu gestor de etiquetas, quitar las etiquetas que nadie recuerda haber añadido, y retrasar las no críticas — no señalar a la analítica.