Web más lenta y caída de la tasa de conversión: cómo encontrar el cambio que la frenó

¿Una web más lenta puede hacer caer la tasa de conversión?

Sí, pero la lentitud solo es la causa cuando empezó antes de la caída y afectó a las páginas y dispositivos donde bajaron las conversiones. Los problemas de velocidad casi nunca llegan solos: el despliegue que hizo las páginas más pesadas a menudo también cambió el diseño, el formulario o el tracking.

La velocidad importa porque quien espera a que aparezca el contenido principal, o toca un botón y no pasa nada, se va antes de llegar al checkout o al formulario de contacto. Google mide esos momentos con tres Core Web Vitals: Largest Contentful Paint (LCP) para la carga, Interaction to Next Paint (INP) para la respuesta a clics y toques y Cumulative Layout Shift (CLS) para la estabilidad visual.

Este artículo no promete una cifra de ventas perdidas por segundo de retraso. Las cifras publicadas varían según el sitio y a menudo salen de estudios de proveedores. Lo que sí puedes hacer es demostrar, con tus propios datos, que un cambio con fecha hizo las páginas más lentas y que las conversiones bajaron en esas mismas páginas al mismo tiempo. Para el método general de cualquier caída, consulta cómo explicar una caída de conversiones a un cliente.

¿Qué cambios suelen hacer que una web vaya más lenta?

La mayoría de las pérdidas de velocidad vienen de algo que alguien publicó, no de Google ni del hosting. Los sospechosos habituales son scripts nuevos, contenido multimedia más pesado y despliegues de código.

La guía de Google sobre etiquetas explica que el tiempo del hilo principal se gasta evaluando y ejecutando el JavaScript del gestor de etiquetas y de las propias etiquetas, y sus autores observan una correlación entre contenedores más grandes y un INP peor. Las etiquetas duplicadas, como un píxel fijo en el HTML e inyectado otra vez desde GTM, pesan sin aportar datos. Si sospechas de una etiqueta, empieza por el historial de versiones de GTM.

¿Cómo compruebo si la web se ha vuelto realmente más lenta?

Compara los datos de campo de usuarios reales antes y después del cambio sospechoso y usa las pruebas de laboratorio solo para encontrar la causa. Una puntuación aislada de Lighthouse no es una prueba: Google advierte de que los resultados de laboratorio varían entre ejecuciones por la red, el hardware y la competencia por recursos.

Google evalúa cada métrica en el percentil 75 de las páginas vistas. Tres herramientas cubren la mayoría de los casos:

• PageSpeed Insights muestra datos de campo del Chrome UX Report de los 28 días anteriores, por URL o, si la URL no tiene datos suficientes, por origen, además de una prueba de laboratorio de Lighthouse.
• El informe Core Web Vitals de Search Console agrupa URLs similares y muestra cuántas son buenas, necesitan mejorar o son malas en los últimos 28 días. Los grupos sin datos suficientes no aparecen.
• Tu propia monitorización de usuarios reales, si la tienes, es la única fuente que muestra un salto diario el día del despliegue.

La ventana de 28 días importa para fechar. Como PageSpeed Insights agrega cada día los 28 días anteriores, una lentitud que empezó un martes aparece como una subida gradual durante las semanas siguientes, no como un escalón. Fíjate en la fecha en la que la línea empieza a curvarse y confírmala con pruebas de laboratorio de la versión antigua y la nueva.

¿Cómo aíslo qué cambio causó la lentitud y la caída?

Pon en una sola línea de tiempo todos los cambios de la semana anterior a la caída, descarta primero el tracking y solo después prueba la hipótesis de la velocidad en las páginas que se volvieron lentas. Una caída de las conversiones medidas también puede venir de una etiqueta rota, así que comprueba que la etiqueta de conversión sigue disparándose en la versión nueva antes de culpar a la velocidad.

1. Anota el día en que bajaron las conversiones y dónde: checkout en móvil, una landing page o toda la web.
2. Haz una lista de todos los cambios de los 7 a 14 días anteriores: despliegues, actualizaciones de tema o plugin, versiones de GTM, scripts nuevos y cambios de consentimiento, además de las ediciones en anuncios, como pujas, presupuestos y URLs finales.
3. Marca qué cambios tocaron las páginas que cayeron. Un script nuevo en todas las páginas y una caída solo en el checkout móvil apuntan a la respuesta en móvil.
4. Prueba en laboratorio la versión antigua y la nueva de la página y busca el script o el archivo que más tiempo añade.

Ejemplo: una tienda online de muebles pregunta por qué cayeron las ventas en móvil el martes mientras el escritorio se mantenía. Al alinear los cambios aparece una etiqueta de chat añadida en GTM el viernes, un vídeo principal nuevo en las fichas de producto el sábado y ninguna edición en los anuncios. Las pruebas de laboratorio muestran que el vídeo es ahora el elemento LCP y carga mucho más tarde que la imagen anterior. El equipo cambia el vídeo por una imagen fija y las ventas en móvil se recuperan la semana siguiente. Nombres y cifras son ilustrativos.

Con todos los cambios en una sola línea de tiempo, verías que el vídeo se publicó tres días antes de la caída, en la misma plantilla donde bajaron las ventas en móvil. En Changeline puedes registrar cada despliegue, etiqueta y cambio de consentimiento con fecha, responsable y motivo, e importar automáticamente las ediciones de Google Ads, así que la lista del paso 2 ya existe cuando llega la pregunta.

¿Cómo demuestro que fue la lentitud, y no otra cosa, lo que bajó las conversiones?

Lo demuestras enseñando que coinciden tres cosas: la lentitud empezó con el cambio, las conversiones bajaron solo en las páginas y dispositivos afectados y se recuperaron al revertir o corregir el cambio.

1. Confirma que el tracking dispara
2. Fecha la lentitud en datos de campo
3. Compara páginas afectadas y el resto
4. Revierte o corrige el cambio
5. Sigue la recuperación

• Segmenta por dispositivo y página. Si la tasa de conversión en escritorio se mantuvo, la de móvil bajó y la lentitud está sobre todo en móvil, eso es una prueba. Una caída en todos los dispositivos y páginas apunta a otra parte.
• Revisa el mix de tráfico. Una campaña, una audiencia o un presupuesto nuevo puede traer visitantes más fríos ese mismo día. Mira la tasa de conversión por fuente antes de culpar a la velocidad. Las otras causas están en por qué baja la tasa de conversión.
• Usa un grupo de control. Las páginas que no recibieron el script o el archivo nuevo son tu grupo de control. Si se mantuvieron estables, el cambio es la causa más probable.
• Revierte y observa. Quitar el script o deshacer el despliegue es la prueba más limpia. Registra la reversión como un cambio propio para que la recuperación también tenga fecha.

Guarda la evidencia por escrito: el cambio, la fecha, las mediciones de laboratorio de antes y después y la tasa de conversión en las páginas afectadas y en el resto. Es lo que te pedirá el cliente o tu responsable, y evita que la misma discusión vuelva un mes después.

¿Cómo evito que la lentitud vuelva?

Incluye la velocidad en cada despliegue y en cada etiqueta nueva, y lleva un registro de qué se publicó y cuándo. La mayoría de las regresiones vuelven porque alguien añade otra vez el script o nadie recuerda por qué se quitó.

Google recomienda pausar o eliminar las etiquetas sin uso en lugar de bloquearlas con una excepción de activador, porque una etiqueta bloqueada sigue llevando su código en el contenedor. Un registro de cambios de marketing compartido da a desarrolladores y equipo de marketing una única fuente que consultar, y el registro de cambios de la web detalla la parte del sitio.