La guía de Core Web Vitals de esta sección cubre las tres métricas y cómo se miden. Esta guía se centra en una de las causas más frecuentes, y más difíciles de resolver, de que esas métricas empeoren en sitios que por lo demás tienen un código propio razonablemente optimizado: los scripts de terceros. Gestores de etiquetas, píxeles publicitarios, chats en vivo, widgets de reseñas, reproductores de vídeo embebidos y herramientas de personalización son, en conjunto, una de las mayores fuentes de JavaScript que se ejecuta en una página sin que el equipo que la construye tenga control directo sobre su peso ni su comportamiento.
El problema no es que estas herramientas sean malas: casi todas resuelven un problema de negocio real. El problema es que se añaden una a una, cada una parece "ligera" por separado, y el efecto acumulado sobre el hilo principal del navegador rara vez se audita como conjunto hasta que las métricas ya están mal.
Por qué un script "pequeño" puede tener un coste grande
El peso en kilobytes de un script de terceros es solo una parte de su coste real. Lo que más afecta a Interaction to Next Paint (INP) y, en menor medida, a Largest Contentful Paint (LCP) no es cuánto pesa el archivo, sino cuánto tiempo de ejecución en el hilo principal consume: analizar el JavaScript, ejecutarlo, y en muchos casos seguir ejecutando código periódicamente después de la carga inicial (trackers que escuchan eventos de scroll o de clic en toda la página, por ejemplo). Un script de pocos kilobytes que ejecuta un bucle costoso en cada scroll puede tener peor impacto en INP que un script mucho más pesado que se ejecuta una sola vez y se queda inactivo.
El coste real de los gestores de etiquetas
Un gestor de etiquetas (Google Tag Manager y equivalentes) no es en sí mismo pesado, pero es un contenedor que carga y ejecuta otros scripts de terceros según reglas configuradas, muchas veces por equipos de marketing sin visibilidad directa del impacto técnico de cada etiqueta que añaden. El problema no es la herramienta, es la falta de gobierno: con el tiempo, un contenedor acumula etiquetas que ya nadie usa, duplicados del mismo píxel añadido por error dos veces, o etiquetas configuradas para dispararse en cada página cuando solo son necesarias en una sección concreta.
Una auditoría periódica del contenedor (qué etiquetas siguen activas, cuáles se disparan y cuántas veces, cuál es su peso y tiempo de ejecución individual medido con las herramientas de rendimiento del navegador) es la única forma de mantener bajo control algo que, por diseño, crece con el tiempo sin fricción técnica visible en cada adición individual.
Carga diferida: no todo necesita cargarse antes de la interacción
La técnica más efectiva para reducir el impacto de scripts de terceros no relacionados con el contenido principal es diferir su carga hasta después de que la página sea interactiva, en vez de cargarlos en paralelo con los recursos críticos. Un chat en vivo, un widget de reseñas o un píxel de remarketing casi nunca necesitan estar listos en el primer segundo; pueden cargarse tras el evento de carga de la página, o incluso tras la primera interacción real de la persona usuaria (el primer scroll o el primer clic), sin que eso perjudique de forma perceptible su función.
// Cargar un script de terceros después de que la página esté interactiva
window.addEventListener('load', () => {
const script = document.createElement('script');
script.src = 'https://ejemplo.com/widget-resenas.js';
script.async = true;
document.body.appendChild(script);
});El patrón "facade": simular el widget hasta que hace falta de verdad
Para widgets pesados que sí necesitan verse desde el principio (un reproductor de vídeo embebido, un mapa interactivo), la técnica del facade (fachada) consiste en mostrar una versión ligera y estática que imita visualmente al widget real (una imagen de portada con un botón de play superpuesto, en el caso de un vídeo) y cargar el script pesado del widget solo cuando la persona usuaria interactúa con esa fachada, no antes. YouTube y Vimeo ofrecen variantes de esta técnica de forma nativa; para widgets propios o de terceros que no la ofrecen, se puede implementar manualmente sustituyendo el widget real por una imagen y un evento de clic que carga el script solo en ese momento.
Particionado de tareas largas: por qué el hilo principal se bloquea aunque el script termine rápido
Cuando un script de terceros ejecuta una tarea larga sin interrupciones (un bloque de JavaScript que tarda más de 50 milisegundos en ejecutarse de corrido), el hilo principal del navegador queda bloqueado durante ese tiempo y no puede responder a ninguna interacción del usuario, lo cual es exactamente lo que mide (y penaliza) Interaction to Next Paint. Muchos scripts de terceros mal optimizados ejecutan justamente ese patrón: inicializaciones pesadas de una sola vez que bloquean el hilo principal durante cientos de milisegundos en el peor momento posible, justo cuando la página termina de cargar y la persona usuaria empieza a interactuar.
Cuando el script es propio (o de un proveedor que permite configurarlo), particionar esa inicialización en fragmentos más pequeños usando requestIdleCallback o cediendo el control al hilo principal entre fragmentos evita el bloqueo prolongado, aunque el tiempo total de ejecución sea similar. Cuando el script es de un tercero sin control sobre su código interno, la única palanca real es controlar cuándo se carga y se ejecuta, no cómo se ejecuta internamente.
Consentimiento de cookies y el coste de cargar "por si acaso"
Un patrón que agrava innecesariamente el problema: cargar todos los scripts de analítica y marketing de forma condicionada, pero seguir descargando sus archivos JavaScript antes de saber si la persona usuaria va a aceptar el consentimiento, y solo bloquear su ejecución hasta la respuesta. Esto consume ancho de banda y, dependiendo de cómo esté implementado, puede seguir bloqueando el hilo principal aunque el script "no haga nada" hasta el consentimiento. La alternativa correcta es no solicitar siquiera el archivo del script hasta que exista consentimiento explícito, inyectando la etiqueta <script> dinámicamente solo en ese momento.
Cómo auditar el coste real de terceros en un sitio existente
El panel de rendimiento del navegador (pestaña Performance en Chrome DevTools) permite grabar la carga de una página y ver, script por script, cuánto tiempo de ejecución consume cada uno en el hilo principal, agrupado por origen. Esto revela con datos reales, no con estimaciones, qué proporción del tiempo de bloqueo del hilo principal corresponde a código propio y cuánto a terceros, y dentro de terceros, cuál concentra el mayor coste, información que rara vez coincide con la intuición de "cuál parece más pesado" basada solo en el peso del archivo.
Preguntas frecuentes
¿Eliminar Google Tag Manager mejora automáticamente el rendimiento?
No por sí mismo: el contenedor en sí es ligero. El coste está en las etiquetas que carga, así que auditar y reducir esas etiquetas tiene mucho más impacto que eliminar el gestor que las organiza.
¿La carga diferida de un script perjudica su función (por ejemplo, un píxel de remarketing)?
En la mayoría de casos no de forma perceptible: diferir la carga unos segundos tras el evento de carga de la página sigue registrando la visita para efectos de remarketing sin afectar a la experiencia real, ya que la ventana de atribución de estas herramientas suele ser de días, no de milisegundos.
¿Cuántos scripts de terceros son "demasiados"?
No hay un número fijo; importa más el coste acumulado de ejecución en el hilo principal que la cantidad de scripts. Un sitio con diez scripts bien diferidos y ligeros puede rendir mejor que uno con tres scripts mal optimizados que bloquean el hilo principal en el momento crítico.
¿Los bloqueadores de anuncios del usuario "arreglan" este problema por mí?
No debe asumirse como estrategia: una parte significativa de usuarios no usa bloqueadores, y el objetivo es que el sitio rinda bien para todos, no solo para quienes ya mitigan el problema por su cuenta.
¿Un CDN para servir los scripts de terceros más rápido soluciona el problema de INP?
Ayuda con el tiempo de descarga del archivo, pero no con el tiempo de ejecución en el hilo principal, que es el factor que más pesa en INP. Un script servido instantáneamente pero que ejecuta una tarea larga sigue bloqueando el hilo principal igual.