⚡ GTM y la velocidad de página: pruebas, hallazgos y 8 formas de acelerar tu sitio

Los especialistas en marketing suelen repetir: «Google Tag Manager acelera los sitios web, las páginas con GTM cargan más rápido». Los desarrolladores normalmente argumentan: «GTM solo ralentiza las cosas». La verdad, como siempre, se encuentra entre estos dos extremos.

Realizamos una serie de pruebas con diferentes configuraciones de GTM: un contenedor vacío, un contenedor con 8 códigos de seguimiento, etiquetas insertadas directamente en el código, distintos momentos de activación de los disparadores, docenas de etiquetas HTML personalizadas con manipulaciones del DOM. Medimos la velocidad mediante webpagetest.org y Lighthouse. Los resultados resultaron ser menos evidentes de lo que afirman las presentaciones de GTM.

Esto es lo que descubrimos: el contenedor de GTM por sí solo apenas ralentiza nada, pero lo que usted introduzca en él puede añadir 3 o 10 segundos a la carga de la página. Y lo fundamental es que usted puede controlarlo.

💡 Resumen rápido:

Un contenedor de GTM vacío añade unos 100 milisegundos a la carga de la página
Ocho etiquetas de seguimiento a través de GTM ralentizan la página 3 segundos en 3G rápido y hasta 10 segundos en conexiones lentas
Las mismas 8 etiquetas insertadas directamente en el código del sitio ralentizan aún más las cosas
Cuanto más tarde se activen las etiquetas, menor será su impacto: un retraso de 1,5 segundos después de Window Loaded reduce el tiempo de carga en 6 segundos en 3G lento
Una configuración de disparadores bien planificada y la limpieza del contenedor recuperan velocidad sin pérdida de datos

Cómo realizamos las pruebas

La metodología es sencilla pero exhaustiva. Ejecutamos cada prueba al menos tres veces y calculamos el promedio.

Herramientas: webpagetest.org (servidor en Irlanda, EC2, Chrome y Firefox para escritorio, OnePlus 5 para pruebas móviles) y la auditoría integrada de Lighthouse en Chrome DevTools. En Lighthouse revisamos tanto los informes para móvil como para escritorio. Chrome se inició en modo incógnito, sin extensiones, con el rendimiento del portátil al máximo.

Métricas que medimos:

En webpagetest.org: Document complete (segundos hasta que el contenido estático, las imágenes y los estilos se cargan) y Fully loaded (el punto después de onLoad en que la actividad de red se calma durante 2 segundos). En Lighthouse: First Meaningful Paint, Time to Interactive, First CPU Idle y Max Potential First Input Delay (FID).

Códigos de seguimiento en las pruebas: Google Analytics (gtag.js), Facebook Pixel, Reddit Pixel, Quora Pixel, LinkedIn Insights, Twitter Universal Tag, Google Ads Remarketing (gtag.js), Hotjar. Ocho scripts de uso generalizado.

Escenarios que comparamos:

Página limpia sin scripts de terceros y sin GTM
Página con 8 códigos de seguimiento insertados directamente antes de </head>, sin GTM
Contenedor de GTM vacío sin etiquetas
Las 8 etiquetas a través de GTM, disparador All Pages (también conocido como gtm.js)
Las mismas 8 etiquetas a través de GTM, disparador DOM Ready (gtm.dom)
Las mismas 8 etiquetas a través de GTM, disparador Window Loaded (gtm.load)
Las mismas 8 etiquetas, activándose 1,5 segundos después de Window Loaded
Contenedor de GTM con el modo de vista previa y depuración activado
Contenedor de GTM con 100 etiquetas HTML personalizadas que añaden elementos al final de <body>
Contenedor de GTM con 100 etiquetas HTML personalizadas que añaden elementos en un lugar específico de la página (después del H2)
Contenedor de GTM con 100 etiquetas HTML personalizadas que buscan todos los enlaces e insertan un elemento después del 21.º
Contenedor de GTM con 1976 variables constantes (lleno al máximo de su capacidad, 200 KB)

Lo que mostraron las pruebas

Asíncrono no significa «sin consecuencias»

Los scripts asíncronos no bloquean la renderización directamente. Pero aun así necesitan recursos de CPU, lo que implica que los scripts principales del sitio se ejecutan más lentamente. En la práctica: el evento Document Complete en una página limpia se produjo a los 4 segundos. Con ocho etiquetas, a los 7,7 segundos. Una diferencia de 3,7 segundos solo porque el procesador está ocupado con scripts de terceros.

Comparación del tiempo de Document Complete sin etiquetas y con etiquetas

Incluso un contenedor de GTM vacío aumentó ligeramente el tiempo de carga, en unos 100 milisegundos.

Impacto de un contenedor de GTM vacío en el tiempo de carga

No se trata de GTM, sino de lo que usted introduce en él

Un contenedor de GTM vacío añade unos 100 milisegundos a la carga de la página, a veces no hay ningún retraso. Los problemas empiezan cuando usted llena el contenedor con etiquetas. Pero incluso aquí, las cosas no son lineales.

Ocho etiquetas de seguimiento ralentizaron la página unos 3 segundos en una conexión 3G rápida y 10 segundos en conexiones lentas. Cada etiqueta descarga su propio script y el navegador emplea tiempo en ejecutarlos.

Document Complete sin etiquetas y con 8 etiquetas en GTM

Pero un contenedor lleno con 1976 variables constantes (200 KB, el límite de GTM) añadió solo entre 0,1 y 0,3 segundos. Las variables no cargan scripts externos ni manipulan el DOM, por lo que su impacto es mínimo.

Conclusión: lo que importa no es el tamaño del contenedor, sino qué acciones realizan sus elementos.

Las etiquetas insertadas directamente ralentizan más que las mismas etiquetas a través de GTM

Cuando añadimos 8 scripts de seguimiento directamente en el código del sitio, la página se ralentizó de forma aún más notable. En 3G rápido, las etiquetas insertadas directamente añadieron unos 600 milisegundos más de retraso en comparación con las mismas etiquetas lanzadas a través de GTM.

Comparación de etiquetas hard-coded y etiquetas mediante GTM

En el segundo gráfico, la misma imagen desde otro ángulo: los scripts insertados directamente pierden sistemáticamente frente a GTM en el tiempo de Document Complete.

Document Complete con etiquetas hard-coded frente a GTM

GTM realmente ayuda a que las páginas carguen ligeramente más rápido que cuando los scripts se añaden directamente al código. Pero esto no es una regla universal. Existen escenarios donde lanzar JS sin GTM puede implementarse de forma más eficiente, y Simo Ahava, uno de los principales expertos en GTM, coincide con esto.

El momento de activación de las etiquetas importa

Cuanto más tarde se active una etiqueta, menos afecta a la carga inicial de la página. Probamos cuatro momentos:

Page View (gtm.js), inmediatamente cuando el contenedor se carga
DOM Ready (gtm.dom), cuando el DOM está construido
Window Loaded (gtm.load), cuando todos los recursos están cargados
afterLoad, 1,5 segundos después de Window Loaded (disparador personalizado)

Código del disparador personalizado afterLoad:

1 <script>
2   (function() {
3     try {
4       window.setTimeout(function(){
5         dataLayer.push({
6           'event': 'afterLoad'
7         });
8       }, 1500);
9     } catch (err) {}
10   })();
11 </script>

Resultado: DOM Ready y Window Loaded dieron una pequeña mejora. Pero la ganancia más significativa vino de afterLoad. En 3G lento, el retraso se redujo en 6 segundos en comparación con el disparador Page View. En 3G rápido, en 600 milisegundos.

Comparación de Fully Loaded en diferentes momentos de activación de etiquetas

¿Por qué funciona esto? La página puede tener elementos que se cargan dinámicamente solo después de que todos los recursos se hayan cargado por completo. Si las etiquetas ralentizan la carga inicial, estos elementos también aparecen más tarde. Al retrasar las etiquetas no críticas, usted permite que el contenido principal se cargue sin interferencias.

Pero hay una salvedad: si retrasa etiquetas de las que depende la precisión (Google Analytics), algunos visitantes pueden abandonar la página antes de que el contador se active. Sus informes perderán algunos datos. La decisión de retrasar etiquetas debe tomarse con el equipo, no unilateralmente por un desarrollador o un especialista en marketing.

Las etiquetas de seguimiento no son las únicas culpables

Otro grupo de etiquetas «pesadas» son aquellas que manipulan el DOM. Por ejemplo, etiquetas HTML personalizadas que añaden o cambian elementos en la página.

Probamos varias variaciones:

100 etiquetas HTML personalizadas añadiendo elementos al final del <body>. Cada etiqueta ejecutaba un script simple console.log('hello') y creaba un <div>Hello!</div>. Sin especificar una ubicación de inserción concreta. El impacto en la velocidad de carga de la página resultó ser mínimo, los elementos simplemente se añadían al final.

100 etiquetas HTML personalizadas añadiendo elementos en un lugar específico de la página. Cada etiqueta buscaba el primer h2 e insertaba un h3 después de él. Script:

1 <script>
2   (function() {
3     var h3 = document.createElement('h3');
4     h3.innerText = "An additional element";
5     var title = document.querySelector('h2');
6     if (title) {
7       title.parentElement.insertBefore(h3, title.nextSibling);
8     }
9   })();
10 </script>

Esto añadió varios cientos de milisegundos a la carga de la página. Aunque el script es primitivo, buscar un elemento e insertarlo requiere recursos.

Impacto de 100 etiquetas con manipulaciones del DOM en Fully Loaded

100 etiquetas HTML personalizadas que buscan todos los enlaces de la página e insertan un elemento después del 21º. Script:

1 <script>
2   (function() {
3     var h3 = document.createElement('h3');
4     h3.innerText = "An additional element";
5     var element = document.querySelectorAll('a')[20];
6     if (element) {
7       element.parentElement.insertBefore(h3, element.nextSibling);
8     }
9   })();
10 </script>

Diferencia con el experimento anterior: querySelectorAll itera a través de todos los elementos de la página, comprueba cada uno, lo cual es más costoso. En webpagetest.org la diferencia fue pequeña (100-200 ms), pero Lighthouse mostró un aumento de 2-3 segundos en el Time to Interactive. Esto significa que durante la carga de la página, el navegador está tan ocupado insertando elementos que no responde a las acciones del usuario.

Time to Interactive con manipulaciones pesadas del DOM

Sí, 100 scripts idénticos es una exageración. Pero la cuestión es que incluso unas pocas etiquetas complejas que manipulan el DOM pueden producir un efecto similar.

Cómo reducir el impacto de GTM en la velocidad: 8 técnicas

Limpie regularmente el contenedor de etiquetas abandonadas

La experiencia de auditoría muestra: hasta un tercio de los códigos de seguimiento en los sitios pertenecen a herramientas que la empresa ya no usa. Cambió de la herramienta de analítica X a Z, pero los códigos de X todavía se cargan en cada página y la ralentizan.

Qué hacer:

Pida a un desarrollador que le proporcione una lista de todas las solicitudes HTTP y scripts en la página
Busque en Google los dominios de estas solicitudes, identifique a qué herramientas pertenecen
Pregunte a colegas de diferentes departamentos qué herramientas se siguen usando
Encuentre scripts «huérfanos» que no están en la lista de herramientas usadas
Si un script está implementado mediante GTM, páuselo por un mes; si nadie se queja, elimínelo por completo
Si un script está incrustado en el código, pida al desarrollador que lo comente temporalmente y luego lo elimine después de un mes

Contenedor de GTM antes de la auditoría de etiquetas abandonadas

Retrase las etiquetas no críticas

Cuantas menos etiquetas tenga el activador All Pages, más rápida será la carga inicial. No todas las etiquetas se pueden retrasar, pero si aplica este enfoque al menos a algunas de ellas, la mejora será notable.

Cómo implementar el retraso (método de Pavel Brechik):

Paso 1. Cree una etiqueta HTML personalizada con el código:

1 <script>
2   (function() {
3    try {
4      window.setTimeout(
5       function(){
6        dataLayer.push({'event': 'afterLoad'});
7       }, 1500);
8     } catch (err) {}
9   })();
10 </script>

Paso 2. Lance esta etiqueta con el activador Window Loaded.

Configuración del activador Window Loaded para etiqueta HTML personalizada

Paso 3. Cree un activador personalizado para el evento afterLoad.

Creación de un activador afterLoad personalizado en GTM

Paso 4. Asigne este activador a las etiquetas que se pueden retrasar.

Resultado en 3G lento: el retraso se redujo en 6 segundos; en 3G rápido, en 600 milisegundos.

Fully Loaded en diferentes momentos de activación de etiquetas

Qué etiquetas se pueden retrasar y cuáles no debe decidirse con el equipo. Idealmente, los desarrolladores quitarían todo por velocidad y los especialistas en marketing añadirían todo por precisión de datos. La verdad está en el punto medio.

Use etiquetas solo en las páginas que necesita

No todas las etiquetas necesitan activarse en todo el sitio. Un píxel de remarketing de Google Ads puede lanzarse solo en las páginas de destino de la campaña, no en todo el sitio. LinkedIn Insights, solo en las páginas donde llega tráfico de LinkedIn. Configure exclusiones en los activadores; esto reducirá la cantidad de scripts que se ejecutan en una página típica.

Configuración de un activador solo para páginas específicas en GTM

Evite manipulaciones pesadas del DOM

Si necesita una etiqueta HTML personalizada que añada algo a la página, intente hacerlo de la forma más ligera posible. Evite querySelectorAll con iteración a través de todos los elementos. No inserte docenas de elementos idénticos en diferentes lugares de la página. Cada manipulación del DOM consume recursos del navegador en un momento en que ya está ocupado renderizando la página.

Ejemplo de etiqueta HTML personalizada optimizada en GTM

No mida la velocidad con el modo de vista previa activado

El modo Vista previa y depuración en GTM añade una carga extra al navegador que los visitantes reales no tienen. Si mide la velocidad con la vista previa activada, los resultados serán peores que la realidad. Antes de una auditoría de velocidad, desactive siempre el modo de depuración.

Desactivación del modo de vista previa de GTM para pruebas de velocidad

Pruebe la velocidad después de cada cambio en el contenedor

¿Añadió una etiqueta nueva o cambió un activador? Compruebe inmediatamente la velocidad de la página mediante webpagetest.org o Lighthouse. Tome mediciones antes y después. Esto le permitirá detectar una etiqueta problemática de inmediato, en lugar de preguntarse más tarde por qué el sitio empezó a cargar 2 segundos más lento.

Mantenga el contenedor ligero

Elimine etiquetas, activadores y variables no utilizados. Esto no tiene tanto que ver con la velocidad (como mostró la prueba con 1976 variables), sino con la manejabilidad. En un contenedor con cien etiquetas, es fácil perder un script problemático. En un contenedor con dos docenas, cada unidad es visible.

Separe el trigo de la paja: qué reduce realmente el tiempo de carga

Pongamos punto final a los experimentos. Esto es lo que da el máximo efecto en orden descendente:

Tabla resumen del impacto de diferentes factores en la velocidad de carga

Según nuestras mediciones, la mejora más significativa proviene de retrasar etiquetas mediante afterLoad, hasta 6 segundos en conexiones lentas. En segundo lugar, eliminar códigos de seguimiento abandonados. En tercer lugar, limitar el alcance de las etiquetas a páginas específicas.

⁉️🤔 Preguntas frecuentes

¿Un GTM vacío ralentiza un sitio?

Prácticamente no. En nuestras pruebas, un contenedor vacío añadió unos 100 milisegundos a la carga de la página. A veces no hubo retraso en absoluto. Esto es margen de error, imperceptible tanto para los usuarios como para los motores de búsqueda.

¿Qué ralentiza más: GTM o los scripts incrustados en el código?

Los scripts incrustados en el código ralentizan un poco más. En nuestra prueba, 8 etiquetas de seguimiento añadidas directamente al código ralentizaron la página unos 600 milisegundos más que las mismas etiquetas a través de GTM. Pero esto no es una regla universal: un JS personalizado bien escrito puede ser más eficiente que GTM.

¿Se pueden retrasar todas las etiquetas?

Técnicamente, sí. Pero perderá datos: algunos visitantes abandonarán la página antes de que los contadores se activen. Google Analytics y herramientas similares subcontarán el tráfico. Solo retrase etiquetas que no requieran alta precisión, por ejemplo, widgets de chat o píxeles de remarketing. Es mejor dejar la analítica en Page View.

¿Cómo comprueba qué etiquetas en GTM están realmente ralentizando las cosas?

Ejecute una auditoría de Lighthouse con la pestaña Red abierta. Vea qué scripts tardan más en cargar y cuáles bloquean el renderizado. Haga coincidir los dominios de estos scripts con las etiquetas del contenedor. O ejecute una prueba A/B: desactive temporalmente las etiquetas sospechosas una por una y mida la velocidad.

¿Qué hay del GTM del lado del servidor?

El GTM del lado del servidor traslada el procesamiento de etiquetas del navegador del usuario a su servidor. El navegador recibe solo un contenedor en lugar de una docena de scripts de terceros. Esto reduce radicalmente la carga en el lado del cliente. Si tiene docenas de etiquetas de seguimiento, vale la pena considerar el GTM del lado del servidor. La tecnología está disponible desde 2020 y para 2026 su implementación se ha vuelto notablemente más sencilla.

En conclusión: ¿GTM acelera o ralentiza?

Ni en su forma pura. GTM es un despachador: por sí solo casi no pesa, y la velocidad de la página la determinan qué etiquetas y en qué cantidad lanza usted a través de él.

Ocho etiquetas de seguimiento estándar a través de GTM añaden de 3 a 10 segundos a la carga de la página. Pero esas mismas etiquetas insertadas directamente en el código ralentizan aún más las cosas. El lanzamiento diferido mediante afterLoad recupera hasta 6 segundos. Eliminar etiquetas abandonadas, unos segundos más. En total, con una configuración inteligente GTM puede superar a los scripts insertados directamente en el código, y sin configuración, perder por completo frente a una página vacía.

La regla principal es simple: no es GTM lo que hace el sitio, sino usted mismo. Audite el contenedor, elimine lo que sobra, difiera las etiquetas no críticas, configure exclusiones de página y la velocidad de su sitio se lo agradecerá.

1	<script>
2	(function() {
3	try {
4	window.setTimeout(function(){
5	dataLayer.push({
6	'event': 'afterLoad'
7	});
8	}, 1500);
9	} catch (err) {}
10	})();
11	</script>

1	<script>
2	(function() {
3	var h3 = document.createElement('h3');
4	h3.innerText = "An additional element";
5	var title = document.querySelector('h2');
6	if (title) {
7	title.parentElement.insertBefore(h3, title.nextSibling);
8	}
9	})();
10	</script>

Todo para WordPress, el desarrollo web — y mucho más

🚀 Google Tag Manager y la velocidad del sitio: lo que dicen las pruebas