desarrollo

El cementerio de scripts: cómo el tracking bloat destruye tu web y cómo frenarlo

Cada script de tracking añadido tiene un coste real en velocidad y conversiones. Aprende a auditarlos, medirlos en euros y recuperar el control de tu GTM.

Equipo AliadoTech

El cementerio de scripts: cómo el tracking bloat destruye tu web y cómo frenarlo

El problema que nadie quiere nombrar

Hay un patrón que se repite en casi cualquier web con algo de historia detrás: la primera versión cargaba en menos de dos segundos, tenía tres o cuatro scripts externos y el equipo técnico sabía exactamente para qué servía cada uno. Cinco años después, hay veintidós tags en GTM, la mitad sin documentar, y nadie recuerda quién añadió los últimos seis.

Esto no es negligencia puntual. Es el resultado lógico de un sistema de incentivos donde agregar una herramienta nueva genera un KPI trimestral y eliminarla solo genera riesgo. El desarrollador que la añadió ya no está. El de marketing que la pidió tampoco. El script sigue ahí, cargando en cada visita, consumiendo milisegundos que se traducen directamente en usuarios que se van.

La frustración de quienes trabajan en el lado técnico de este problema es comprensible: abres cualquier web mediana, ves los mismos patrones que llevan años documentados como perjudiciales, y luego vas al trabajo y los implementas tú mismo porque alguien con autoridad los pidió. Es una sensación difícil de sacudir.

Pero el problema no se resuelve con lamento. Se resuelve traduciendo el coste técnico a un idioma que la organización entienda.

Por qué el lazy loading no te salva

Una de las defensas más habituales de las herramientas martech cuando les preguntas por su impacto en rendimiento es que cargan de forma diferida, así que no afectan al tiempo de carga inicial. Técnicamente, parte de eso es cierto. Prácticamente, es una forma de eludir la conversación real.

El problema no es solo cuándo empieza a cargar la página. Es cuánto tiempo tarda en ser interactiva. Esa métrica tiene nombre: TTI, Time to Interactive. Y es precisamente ahí donde los scripts de martech hacen más daño, porque se ejecutan segundos después de que el contenido visual ya se ve, bloqueando el hilo principal justo cuando el usuario intenta hacer clic en algo.

El resultado es ese momento incómodo en el que la página parece cargada pero no responde. El usuario hace clic, no pasa nada, vuelve a hacer clic, la página reacciona de golpe a los dos clics seguidos. Eso no es un problema de percepción: es un problema medible en FID (First Input Delay) y en INP (Interaction to Next Paint), que forman parte de los Core Web Vitals que Google usa para valorar tu posicionamiento.

Las herramientas de banners de notificación, A/B testing externo y pop-ups de captura son especialmente agresivas en este sentido. Cargan tarde a propósito para no aparecer en las métricas de carga, pero interrumpen la experiencia en el momento en que el usuario está intentando hacer algo útil. Una versión de la web sin esas capas —algo que cualquier desarrollador puede montar en local en diez minutos— deja clara la diferencia de forma inmediata.

GTM sin gobernanza es una puerta abierta

Google Tag Manager es una herramienta legítima y bien diseñada. El problema no es GTM: es a quién se le da acceso de publicación y con qué criterios.

Cuando una agencia SEO externa tiene permisos de administrador en tu contenedor de GTM, puede añadir cualquier script en cualquier momento sin que el equipo técnico lo revise. Puede ocurrir —y ocurre— que cada mes aparezcan nuevos tags de tracking que nadie del equipo interno ha visto, que no están documentados en ningún sitio y que nadie se atreve a eliminar porque no sabe exactamente qué romperían.

Este es el mecanismo concreto por el que se construyen los cementerios de scripts: un tag entra por alguien que perseguía un número concreto ese trimestre, y desde ese momento es permanente porque eliminarlo es puro riesgo sin recompensa organizacional visible. Nadie en la historia de ninguna empresa ha sido ascendido por limpiar deuda técnica de tracking.

La solución no es técnica en su origen. Es de gobernanza. GTM tiene un sistema de permisos por niveles: puedes dar acceso de vista previa y depuración a los equipos de marketing para que configuren y prueben sus tags sin que nada llegue a producción hasta que alguien técnico lo revise y publique. No es un freno a la velocidad de marketing: es un control de calidad que les protege a ellos también, porque un tag mal configurado puede romper el tracking de conversiones de toda la cuenta.

Cómo auditar lo que tienes ahora mismo

El primer paso es saber qué está cargando realmente tu web. No lo que está documentado en el contenedor de GTM, sino lo que se ejecuta en cada visita.

  • Chrome DevTools, pestaña Network: filtra por tipo de script y mira qué dominios externos aparecen. Cada dominio externo es un punto de fallo ajeno a ti y un coste en tiempo de resolución DNS.
  • Chrome DevTools, pestaña Performance: graba una carga completa y busca los bloques largos en el hilo principal después del primer pintado. Ahí están los culpables del TTI alto.
  • PageSpeed Insights o Lighthouse: te da los Core Web Vitals reales del dispositivo y señala los recursos que más penalizan. Úsalo tanto en escritorio como en móvil, porque la diferencia suele ser significativa.
  • GTM mismo: entra en el contenedor y lista todos los tags activos. Para cada uno, pregunta: ¿quién lo añadió, cuándo, para qué objetivo concreto y si ese objetivo sigue siendo válido?

De esa lista, clasifica en tres categorías: imprescindible (sin él no puedes medir conversiones ni cumplir obligaciones legales), útil con coste justificado (aporta datos que usas activamente), y zombie (nadie sabe bien para qué sirve o los datos que genera no los usa nadie). Los de la tercera categoría son candidatos inmediatos a eliminar.

Traducir el coste técnico a lenguaje de negocio

Este es el cambio más importante que puedes hacer si quieres que la conversación avance. Decir que la web es lenta o que el TTI está alto no mueve a nadie fuera del equipo técnico. Pero hay una traducción que funciona, y la lógica es sencilla.

Mide el TTI actual con el conjunto de scripts activos. Luego mide el TTI desactivando los scripts que has identificado como prescindibles. La diferencia en milisegundos es tu argumento. Cruza esa diferencia con datos conocidos sobre la relación entre velocidad y conversión: cada 100ms adicionales de tiempo de respuesta tiene un impacto medible en la tasa de conversión. El número exacto varía según el tipo de negocio y el funnel, pero la dirección es siempre la misma.

Cuando presentas ese cálculo —estos scripts suman X milisegundos al TTI, y eso representa una caída estimada de Y puntos en tu tasa de conversión— el problema deja de ser una opinión técnica y se convierte en un KPI de negocio. De repente es su problema, no solo el tuyo.

Ese cambio de encuadre es lo que convierte una discusión frustrante sobre UX en una decisión ejecutiva con datos sobre la mesa.

El problema del RGPD que nadie lee

Hay otro ángulo que vale la pena nombrar aunque incomode. Cada herramienta de terceros que añades a tu web con capacidad de seguimiento de usuarios requiere base legal explícita bajo el RGPD. El consentimiento informado es la base más habitual, pero para que sea válido tiene que ser real: el usuario debe poder entender qué acepta y rechazarlo sin coste.

Un banner de cookies que lista más de cien proveedores en un desplegable técnicamente cumple el requisito de transparencia. En la práctica, nadie lo lee. En móvil, es directamente ilegible. La AEPD ha publicado guías específicas sobre lo que constituye consentimiento válido para cookies y tracking, y la línea entre cumplimiento formal y cumplimiento real es más estrecha de lo que muchos banners actuales sugieren.

Cada script que eliminas por rendimiento es también un script menos en tu política de cookies, un riesgo legal menos y un banner más corto que los usuarios pueden leer de verdad. El argumento de simplificación técnica y el argumento de cumplimiento normativo apuntan en la misma dirección.

Alternativas que dan el 80% con menos carga

No se trata de eliminar toda visibilidad analítica. Se trata de ser selectivo con las herramientas y honesto sobre lo que realmente usas.

  • Analytics propio frente a múltiples capas externas: muchos de los datos que recogen herramientas martech de pago duplican información que ya tienes en tu plataforma o en Google Analytics 4. Antes de añadir otra herramienta, pregunta si el dato que necesitas ya existe en algún sitio.
  • Mapas de calor bajo demanda: herramientas como las de grabación de sesiones son muy pesadas si cargan en todas las visitas. Activarlas solo durante periodos de prueba concretos —un sprint de optimización de una landing— y apagarlas después reduce el impacto drásticamente.
  • A/B testing integrado: los frameworks de frontend modernos permiten implementar variantes de forma nativa sin depender de scripts externos que modifican el DOM después de la carga, que es exactamente lo que provoca el efecto de parpadeo y el retraso en TTI.
  • Un tag de conversión bien configurado frente a tres mal configurados: Meta Pixel, LinkedIn Insight Tag y similares son scripts con un coste real. Si los tienes activos, asegúrate de que los datos que recogen los usas activamente en campañas. Si no hay campañas activas en esa plataforma, el tag no debería estar cargando.

El problema real es de incentivos, no de herramientas

La solución técnica —auditar scripts, medir TTI, configurar permisos en GTM, usar defer y type module donde corresponda— existe y está documentada. No es un problema sin solución conocida.

El problema de fondo es que en la mayoría de organizaciones se recompensa agregar y se penaliza (o simplemente no se reconoce) limpiar. Un responsable de marketing que añade una herramienta nueva tiene un resultado visible ese trimestre. Un desarrollador que elimina ocho scripts zombie y mejora el TTI en 700ms tiene un resultado que nadie en dirección sabe interpretar si no se lo traducen.

Por eso el trabajo de traducción es tan importante. No como truco retórico, sino porque es la única forma de hacer que la conversación ocurra entre personas que tienen incentivos distintos y hablan idiomas distintos.

Si gestionas una web con varios años de historia, vale la pena hacer esa auditoría aunque sea una vez. Lo que encuentres probablemente te sorprenda, y la conversación que esa auditoría hace posible puede tener un impacto más directo en resultados que cualquier campaña nueva que estés considerando añadir.

Seguir leyendo

Artículos relacionados

Ver todos los artículos