Argumentos para limitar los scripts de analítica y rastreo
Cómo afectan los scripts de analítica y rastreo a sus Core Web Vitals y qué hacer al respecto
Argumentos para limitar los scripts de analítica y rastreo
Paso gran parte de mi tiempo auditando sitios web y, en aproximadamente el 90% de esas auditorías, encuentro scripts de rastreo no utilizados. Scripts que nadie recuerda haber añadido, scripts que rastrean datos que nadie lee, scripts que eran "solo un píxel más" añadido por marketing hace dos años. Cada uno parecía inofensivo en su momento. Juntos, añaden segundos a cada carga de página.
Según el [url=https:\/\/securelist.com\/web-trackers-report-2023-2024\/113778\/]informe de rastreo web 2024 de Kaspersky[\/url], el sitio web promedio tiene ahora 48 rastreadores. El [url=https:\/\/almanac.httparchive.org\/en\/2025\/third-parties]Web Almanac 2025[\/url] muestra que más del 90% de las páginas web incluyen al menos un tercero, y los 1.000 sitios más visitados disparan una mediana de 129 solicitudes de terceros en escritorio. Eso no es una estrategia de rastreo. Eso es un problema de rendimiento.
Revisado por última vez por [url=https:\/\/www.linkedin.com\/in\/arjenkarel\/]Arjen Karel[\/url] en marzo de 2026
Por qué los sitios utilizan scripts de analítica y rastreo
Los scripts de analítica y rastreo tienen un propósito real. Google Analytics le indica de dónde vienen sus visitantes. El Píxel de Facebook rastrea las conversiones de los anuncios. Hotjar le muestra dónde hace clic la gente. Sin estos datos, está adivinando.
El problema no es que estas herramientas existan. El problema es que la mayoría de los sitios cargan mucho más rastreo del que necesitan. Herramientas populares como Google Analytics, Facebook Pixel y las analíticas de Cloudflare añaden JavaScript, cookies y solicitudes HTTP. Y rara vez son el único rastreo en la página.
Dato: En aproximadamente el 90% de todas las auditorías encuentro scripts de rastreo no utilizados. Por lo general, estos scripts se inyectan tarde a través de un gestor de etiquetas u otro script de terceros.
No todos los scripts de rastreo son iguales. Esto es lo que realmente le cuestan los más comunes:
Apile GA4 + GTM + Facebook Pixel + un banner de consentimiento y estará ante unos 400 a 600 KB de JavaScript de rastreo antes de que se ejecute nada de su propio código. Eso suele ser más que el contenido de toda la página en sí.
Cada script compite por el ancho de banda de la red y el tiempo de CPU durante la carga de la página. Incluso los scripts asíncronos consumen ancho de banda que podría utilizarse para la imagen del [url=\/core-web-vitals\/largest-contentful-paint]LCP[\/url] o el CSS crítico. Cuando carga 8 scripts de rastreo junto a su imagen hero, está obligando al navegador a compartir su limitado ancho de banda móvil entre todos ellos.
Esto es especialmente perjudicial en redes móviles. El [url=https:\/\/almanac.httparchive.org\/en\/2025\/performance]Web Almanac 2025[\/url] informa de una mediana de tiempo de bloqueo total (Total Blocking Time) en móviles de 1.916 ms (un 58% más que en 2024). Gran parte de ese bloqueo proviene del JavaScript de terceros. Puede [url=\/pagespeed\/14-methods-to-defer-javascript]posponer sus scripts[\/url], pero seguirán compitiendo por los recursos una vez que empiecen a cargarse.
[url=\/core-web-vitals\/interaction-to-next-paint]Interaction to Next Paint (INP)[\/url] es donde los scripts de rastreo causan más daño. El [url=https:\/\/almanac.httparchive.org\/en\/2024\/performance]Web Almanac 2024[\/url] encontró que el retraso de presentación (presentation delay) es el principal contribuyente a un INP deficiente, y los scripts que lo causan son herramientas de rastreo de comportamiento, proveedores de consentimiento y píxeles publicitarios.
Muchos scripts de rastreo siguen funcionando mucho después de que la página se haya cargado. Google Analytics puede configurarse para rastrear cada clic. Las herramientas de mapas de calor como Hotjar escuchan cada movimiento del ratón. Cada uno de estos escuchadores de eventos (event listeners) añade tiempo de procesamiento a las interacciones del usuario. Cuando un visitante hace clic en un botón y su código tarda 50 ms en gestionarlo, pero tres scripts de rastreo también disparan escuchadores de eventos que añaden otros 150 ms, la interacción se siente lenta.
Los números cuentan la historia: el 77% de todas las páginas móviles pasan el INP, pero solo el 53% de los 1.000 sitios web más visitados lo hacen. Esos sitios principales tienen un JavaScript más complejo y más scripts de terceros. Si quiere [url=\/pagespeed\/yield-to-main-thread]mantener la capacidad de respuesta de sus páginas[\/url], los scripts de rastreo son el primer lugar donde mirar.
Cada script de rastreo puede colocar sus propias cookies. Las cookies individuales son pequeñas (mediana de 40 bytes según el [url=https:\/\/almanac.httparchive.org\/en\/2025\/cookies]capítulo de Cookies del Web Almanac 2025[\/url]), pero su impacto colectivo se suma porque los datos de las cookies se envían con cada solicitud HTTP. Si su sitio establece 4 KB de cookies y carga 39 recursos, eso supone 156 KB de datos de subida adicionales en esas solicitudes.
Cuando el total de datos de las cookies supera los 1.500 bytes aproximadamente, los encabezados de la solicitud ya no caben en un solo paquete TCP. Eso obliga a realizar viajes de ida y vuelta (round trips) adicionales, aumentando directamente su [url=\/core-web-vitals\/time-to-first-byte]Time to First Byte[\/url] en las navegaciones posteriores y las cargas de recursos estáticos.
Los banners de consentimiento son los peores infractores en este caso. Cuando un banner de consentimiento de cookies se renderiza tarde y empuja el contenido de la página hacia abajo, provoca un [url=\/core-web-vitals\/cumulative-layout-shift]desplazamiento de diseño (layout shift)[\/url]. Algunas plataformas de consentimiento inyectan grandes árboles DOM (más de 200 nodos) que provocan un reflujo (reflow) de la página. En un caso documentado, un banner de consentimiento fue el elemento LCP para el 50% de las visitas a la página porque se renderizó encima del contenido real.
Abra su gestor de etiquetas y revise cada una de ellas. Para cada una, pregunte: ¿quién lee estos datos? ¿Cuándo se revisaron por última vez? Si nadie puede responder, elimínela. Rutinariamente encuentro etiquetas para herramientas de pruebas A\/B de campañas que terminaron hace meses, píxeles para plataformas publicitarias que la empresa ya no utiliza e implementaciones de analítica duplicadas (tanto GA4 a través de GTM como un gtag.js codificado directamente).
No todo tiene que cargarse al ver la página. Nadie se ha sentido nunca decepcionado porque un script de mapa de calor tardara 3 segundos en empezar a grabar. Dispare las etiquetas de analítica y rastreo en el evento Si envía eventos de analítica personalizados (envíos de formularios, clics en botones, profundidad de desplazamiento), utilice La forma más eficaz de eliminar el JavaScript de rastreo es no cargarlo en absoluto. [url=\/pagespeed\/configure-cloudflare-for-passing-the-core-web-vitals]Cloudflare[\/url] Zaraz traslada la ejecución de las analíticas al edge, sustituyendo los scripts del gestor de etiquetas del lado del cliente por un beacon ligero. Los contenedores de GTM del lado del servidor permiten que su servidor reenvíe los datos a los proveedores de analítica sin que ningún JavaScript del proveedor llegue al navegador. Estos enfoques requieren más esfuerzo de configuración, pero su impacto en el rendimiento es cercano a cero.
Para necesidades más sencillas, alternativas ligeras como Plausible (menos de 1 KB) o Umami (unos 2 KB) proporcionan analíticas de tráfico a una fracción del coste de los 134 KB de GA4.
En los sitios monitorizados por [url=https:\/\/coredash.app]CoreDash[\/url], las páginas que cargan menos de 5 scripts de terceros pasan el INP en aproximadamente un 88%, frente al 64% de las páginas que cargan 15 o más. La diferencia en el LCP es igual de clara: menos solicitudes compitiendo significa que el navegador puede priorizar lo que realmente importa al visitante.
No necesita eliminar todo el rastreo. Necesita ser intencional sobre lo que carga, cuándo lo carga y si alguien utiliza realmente los datos. Empiece auditando su gestor de etiquetas. Elimine lo que no necesite. Retrase lo que sí. Utilice el [url=https:\/\/coredash.app]Real User Monitoring (RUM)[\/url] para verificar la mejora en los datos de campo, porque las pruebas de laboratorio no le mostrarán la imagen completa de cómo interactúan los scripts de rastreo con las condiciones reales de la red y el comportamiento real del usuario.
[include]cwv\/authorbio.html[\/include]
¿Qué tan pesados son estos scripts?
Cómo afectan los scripts de rastreo a los Core Web Vitals
Largest Contentful Paint (LCP)
Interaction to Next Paint (INP)
Time to First Byte y sobrecarga de cookies
Cumulative Layout Shift (CLS)
Estrategias para un rastreo más inteligente
Audite lo que realmente utiliza
Retrase los scripts no esenciales
Window Loaded o, mejor aún, [url=\/pagespeed\/defer-scripts-until-needed]pospóngalas hasta que el usuario interactúe[\/url] con la página. Las pruebas de AnalyticsMania mostraron que retrasar el disparo de las etiquetas 1,5 segundos después de la carga de la página ahorraba 6 segundos en 3G lento.
\/\/ Cargar analítica solo después de la primera interacción del usuario
const events = ['click', 'scroll', 'mousemove', 'touchstart'];
const loadAnalytics = () => {
events.forEach(e => document.removeEventListener(e, loadAnalytics));
\/\/ Cargue su script de analítica aquí
const script = document.createElement('script');
script.src = 'https:\/\/www.googletagmanager.com\/gtag\/js?id=G-XXXXXXX';
document.head.appendChild(script);
};
events.forEach(e => document.addEventListener(e, loadAnalytics, {once: true}));
Utilice la API Beacon para eventos personalizados
navigator.sendBeacon() en lugar de XMLHttpRequest. La API Beacon envía datos de forma asíncrona sin bloquear el hilo principal y garantiza que se completen incluso durante la navegación por la página. Esto es especialmente importante para [url=\/pagespeed\/datalayer-inp-yield-pattern]mantener el INP bajo en las interacciones[\/url] que disparan llamadas de analítica.
\/\/ Enviar datos de analítica sin bloquear la interacción
document.querySelector('.buy-button').addEventListener('click', (e) => {
\/\/ Utilizar sendBeacon: no bloquea, sobrevive a la navegación por la página
navigator.sendBeacon('\/analytics', JSON.stringify({
event: 'purchase_click',
timestamp: Date.now()
}));
});
Considere alternativas del lado del servidor
Cómo se ve un buen resultado
