Velocidad de página y conversión: cómo testearla de verdad

La velocidad de página mueve la conversión, y existe evidencia experimental seria de ello. Lo que casi no existe es la posibilidad de que reproduzcas esa medición en tu sitio. El efecto verdadero de una mejora realista de 200 o 300 milisegundos es demasiado pequeño para el tráfico de la inmensa mayoría de los sitios: en una tienda con conversión de 2,40 por ciento, detectar una mejora relativa de 1,8 por ciento exige 1.987.587 visitantes por variación, lo que da 928 días a 30.000 visitantes por semana. La salida no es rendirse ni repetir números de terceros como si fueran tuyos, es invertir el experimento: degradar la variación a propósito, medir la pendiente con un efecto grande y una muestra pequeña, y extrapolar. Esta guía muestra qué números sobre velocidad se sostienen, cuáles son folclore, cómo armar un experimento de lentitud que quepa en tu tráfico y qué hacer cuando ni ese cabe. Forma parte de nuestra guía completa de optimización de conversión.

Lo que se sabe de verdad sobre velocidad de página y conversión, con fuente

La literatura sobre velocidad está dominada por números repetidos de tercera mano. Conviene separar lo que salió de un experimento controlado publicado de lo que salió de una charla.

afirmación	origen	calidad de la evidencia
cada 100 ms de mejora aumenta los ingresos en 0,6%	experimento de lentitud en Bing, publicado por Kohavi y coautores	alta, experimento controlado con brazos de 100 ms y 250 ms durante dos semanas
250 ms de retraso en el servidor cuestan cerca de 1,5% de ingresos y 0,25% de CTR	mismo experimento	alta
un retraso de 100 a 400 ms reduce las búsquedas por usuario en 0,2% a 0,6%	experimento de Brutlag en Google	alta, experimento controlado con brazos de 200 ms y 400 ms
100 ms de lentitud reducen las ventas en 1% en Amazon	atribuido a Greg Linden, citado por Kohavi y coautores	media, es un dato compartido en una presentación, no un artículo con metodología
mostrar 30 resultados en lugar de 10 redujo el tráfico y los ingresos de Google en 20% por medio segundo más	charla de Marissa Mayer	baja, y los propios autores de Bing explican por qué la atribución a la velocidad no cierra

La última fila merece atención porque es el número de velocidad más citado de internet. Kohavi y coautores dan tres razones para no creer en la explicación:

1. Según los experimentos de lentitud de Bing, 500 ms impactarían los ingresos en cerca de 3 por ciento, no 20 por ciento, y el CTR en cerca de 0,50 por ciento, no 20 por ciento.
2. Brutlag midió en Google que retrasar la página de resultados de 100 a 400 ms reduce el número de búsquedas por usuario en 0,2 a 0,6 por ciento, muy en línea con Bing y muy lejos del 20 por ciento.
3. Un experimento de Bing que mostró 20 resultados en lugar de 10 vio anulada la pérdida de ingresos al agregar un anuncio principal más, lo que retrasó la página un poco más. Su conclusión es que la proporción entre anuncios y resultados orgánicos pesa más que la velocidad.

La lección de método aquí es mayor que la lección sobre velocidad: un número citado de charla en charla durante quince años no se vuelve evidencia por repetición. El mismo escepticismo vale para cualquier estadística de conversión que encuentres sin un experimento detrás, y es el espíritu de la ley de Twyman.

Vale la pena registrar el hallazgo más útil y menos citado del mismo trabajo: no toda parte de la página importa por igual. En Bing, retrasar 250 ms los elementos del panel derecho, cargados después del evento de carga de la ventana, no produjo un impacto detectable en las métricas clave, a pesar de que el experimento tenía casi 20 millones de usuarios. Es decir, lo que está fuera de la ruta crítica puede ser lento sin costo.

Cuánto tráfico exige un test honesto de velocidad de página

Ahora la cuenta que casi nunca aparece en los artículos sobre rendimiento. La tienda de ejemplo:

parámetro	valor
tráfico	30.000 visitantes por semana, 1.560.000 por año
tasa de conversión	2,40%
ticket promedio	R$ 180
ingresos anuales	R$ 6.739.200
valor de 0,1 punto porcentual de conversión	R$ 280.800 por año

Supón que crees en la regla de Bing y quieres medir el efecto de quitar 300 ms del tiempo de respuesta. Según la regla de 0,6 por ciento por 100 ms, eso sería algo cercano a 1,8 por ciento relativo. Pon ese MDE en la calculadora:

Tasa de conversión actual%Efecto mínimo detectablerelativo (%)absoluto (pp)Confianza909599%Poder8090%Visitantes por semana (total)Testbilateralunilateral

-Visitantes por variación

-Total (2 variaciones)

-Duración estimada

Cálculo por aproximación normal de dos proporciones, 2 variaciones (50/50). Cambia los campos y mira el impacto en vivo.

Con una tasa base de 2,40 por ciento, 95 por ciento de confianza, 80 por ciento de poder y test bilateral, la respuesta es esta:

efecto relativo que quieres detectar	visitantes por variación	días a 30.000/semana	días a 1.000.000/semana
0,6% (100 ms, según la regla de Bing)	17.784.539	8.300	249
1,8% (300 ms)	1.987.587	928	28
3,0% (500 ms)	719.680	336	11
6,0% (1 s)	182.511	86	3
12,0% (2 s)	46.922	22	1

La columna del medio es el motivo de que existan tantos artículos sobre velocidad y tan poca medición propia. Ningún sitio de 30.000 visitantes por semana puede medir una mejora realista de velocidad a través de la tasa de conversión. No es falta de herramienta ni de rigor: es que el efecto es pequeño y la métrica es rara.

La columna de la derecha explica por qué los números confiables del mercado vienen todos de buscadores. Con un millón de visitantes por semana, el mismo test de 300 ms cierra en 28 días.

El experimento de lentitud: invierte el signo para que quepa en tu tráfico

La salida está en la última fila de la tabla, y es el diseño que Kohavi y coautores recomiendan como la mejor forma de cuantificar el impacto del rendimiento: en lugar de acelerar e intentar ver una mejora minúscula, retrasas a propósito y mides una pérdida grande.

Tres puntos que ellos señalan sobre este diseño, y que cambian cómo debe leerse el resultado:

1. La lentitud mide la pendiente en el punto de hoy. Si el sitio cambia de velocidad o el público cambia, la pendiente cambia.
2. Responde a la pregunta práctica del trade-off. Si una funcionalidad nueva mueve la métrica M en X por ciento y retrasa el sitio en T, el experimento de lentitud estima cuánto de ese X se comió el retraso, y permite estimar cuánto valdría la funcionalidad si se implementara de forma eficiente.
3. La extrapolación usa una aproximación lineal. Kohavi y coautores registran que confirmaron, corriendo lentitudes de distintos tamaños, que la aproximación lineal es bastante razonable en Bing. Eso es una verificación empírica suya, no una ley de la naturaleza: si vas a extrapolar, corre al menos dos niveles de retraso y comprueba si el efecto escala.

Y hay un segundo truco, independiente del primero: cambia la métrica primaria por una más frecuente. La conversión final es rara por definición. Agregar al carrito, iniciar el checkout, usar la búsqueda interna y la profundidad de scroll ocurren mucho más y, por ser más frecuentes, exigen una muestra mucho menor. Esto tiene un costo conceptual que hay que declarar: estás midiendo una métrica sustituta, y una sustituta no es la métrica del negocio.

Combinando los dos trucos, con una tasa de agregado al carrito de 8,00 por ciento:

efecto relativo	visitantes por brazo	días a 30.000/semana
1,8%	561.747	263
3,0%	203.325	95
6,0%	51.515	25
12,0%	13.219	7

La última fila es un test que cabe en una semana. Así fue como el experimento de velocidad pasó de imposible a rutinario, sin aflojar nada de estadística.

El ejemplo resuelto: un retraso de 2 segundos, leído en la calculadora

Diseño. La mitad del tráfico entra en el experimento, para limitar la exposición al perjuicio deliberado. Dentro del experimento, el brazo B recibe un retraso artificial de 2.000 ms en la respuesta del servidor. Métrica primaria: tasa de agregado al carrito, base de 8,00 por ciento. Métricas de guardrail: ingresos por visitante y tasa de error. Duración planificada: 13.219 visitantes por brazo, lo que da cerca de 13 días con la mitad del tráfico.

Resultado. Después de 13 días: 11.000 visitantes en el control con 880 agregados al carrito, y 11.000 en el brazo retrasado con 774 agregados. Pégalo en la calculadora:

Control (A)

VisitantesConversiones

Variación (B)

VisitantesConversiones

Confianza90%95%99%

Control (A) · Tasa-

Variación (B) · Tasa-

Mejora relativa-

valor-p-

IC 95% de la diferencia-

Test z bilateral de dos proporciones. "Sin significancia" casi siempre significa que falta muestra, no que las versiones sean iguales.

La pantalla muestra 8,00 por ciento contra 7,04 por ciento, menos 12,0 por ciento relativo, valor p de 0,0067 y el veredicto de que el control gana, es decir, el retraso realmente hizo daño. Sin el redondeo de la pantalla, la tasa de la variación es 7,0364 por ciento, la diferencia absoluta es de menos 0,9636 puntos porcentuales, o menos 12,05 por ciento relativo, el z vale menos 2,7103, el valor p es 0,006723 y el intervalo de confianza va de menos 1,6604 a menos 0,2669 puntos porcentuales.

La extrapolación. Dos segundos son 20 bloques de 100 ms. Bajo aproximación lineal:

Ese intervalo es la parte honesta del resultado. El punto central queda cerca del 0,6 por ciento que Bing midió en ingresos, y eso es una coincidencia conveniente del ejemplo, no una confirmación independiente: los números de este escenario se eligieron justamente en esa vecindad para que la mecánica quede visible. Lo que tu test va a devolver es tu número, y la probabilidad de que sea bastante distinto es alta.

Qué hacer con él. Si 100 ms valen 0,6023 por ciento de la tasa de agregado al carrito, y si esa tasa se traduce proporcionalmente en conversión, quitar 300 ms de la ruta crítica vale algo en torno a 1,8 por ciento relativo de conversión, o 0,043 puntos porcentuales sobre la base de 2,40 por ciento. A R$ 280.800 por cada 0,1 punto al año, eso son aproximadamente R$ 121.000 por año. Ese número no es una medición, es una proyección construida sobre dos premisas declaradas (linealidad y proporcionalidad entre carrito y conversión), y el informe tiene que decirlo con todas las letras.

El error que no hay que cometer. Correr el test de lentitud, encontrar significancia y después escribir en el informe “confirmamos que 100 ms valen 0,6 por ciento”. Mediste 2 segundos. El resto es extrapolación, y la calculadora de impacto de la velocidad sirve exactamente para separar lo que se midió de lo que se proyectó.

Core Web Vitals: lo que significan los umbrales y lo que no significan

Cuando el test no cabe ni siquiera en el diseño invertido, queda usar umbrales publicados como guardrail en lugar de como resultado. Según la documentación de web.dev, las tres métricas estables y sus umbrales de “bueno” son:

métrica	qué mide	umbral de “bueno”
LCP (Largest Contentful Paint)	carga	ocurrir en 2,5 segundos o menos
INP (Interaction to Next Paint)	interactividad	200 milisegundos o menos
CLS (Cumulative Layout Shift)	estabilidad visual	0,1 o menos

Dos detalles que cambian la lectura: la evaluación se hace en el percentil 75 de las cargas, por separado para móvil y escritorio, y los datos de campo vienen del Chrome User Experience Report, que recopila mediciones reales anonimizadas de usuarios. El INP pasó a ser métrica estable en 2024, en lugar del FID.

Sobre el posicionamiento, Google es más contenido de lo que la industria del SEO suele repetir. La documentación de experiencia de página afirma que no existe una única señal, que las Core Web Vitals son usadas por los sistemas de posicionamiento y que la búsqueda siempre intenta mostrar el contenido más relevante incluso cuando la experiencia de página es mala. Traducido a decisión: la velocidad es un criterio de desempate, no un sustituto de la relevancia. Esa misma frontera aparece en CRO vs SEO.

También hay una advertencia antigua y todavía válida sobre las métricas de carga. Kohavi y coautores registran, citando a Steve Souders, que el tiempo hasta el evento de carga de la ventana tiene deficiencias serias en páginas modernas: una página de Amazon renderizaba la parte visible en 2,0 segundos mientras el evento de carga se disparaba a los 5,2 segundos, y Gmail hacía lo contrario, con el evento a los 3,3 segundos y el contenido visible recién a los 4,8 segundos. La métrica que eliges como “velocidad” cambia lo que estás optimizando, lo que es una forma de sesgo de instrumentación.

Cómo armar el programa cuando nada de esto cabe

Para sitios en los que ni el experimento de lentitud cierra, la respuesta honesta no es inventar una medición, es cambiar el tipo de decisión. Tres caminos, en orden de preferencia:

1. Trata la velocidad como higiene, no como experimento. Establece los umbrales de Core Web Vitals como guardrail permanente, con una alerta cuando el percentil 75 salga del rango. Eso no prueba ingresos, pero evita regresiones silenciosas, y es lo que hacen las métricas de guardrail.
2. Mide la velocidad como costo dentro de otros tests. Todo test A/B de una funcionalidad nueva debe llevar el tiempo de respuesta como guardrail. Cuando una funcionalidad gana 2 por ciento de conversión y retrasa la página en 400 ms, el experimento de lentitud dice cuánto de esa ganancia es deuda.
3. Usa el valor esperado para decidir sin medir. Si optimizar imágenes cuesta dos días de trabajo y el rango plausible de mejora va de 0 a 1,5 por ciento relativo, el cálculo del valor de la información normalmente dice que simplemente lo hagas, sin ningún test. Testear es caro; optimizar imágenes es barato y reversible.

Para sitios de bajo tráfico, este razonamiento se generaliza, y el blog lo trata en CRO para sitios de bajo tráfico.

Cómo aplicar esto en la práctica

1. Nunca cites un número de velocidad de terceros como si fuera de tu sitio. Cítalo con la fuente y con el contexto (“en Bing, cada 100 ms valió 0,6 por ciento de ingresos”).
2. Antes de proponer un test de velocidad, haz la cuenta de tráfico. Si el resultado supera los 60 días, el test no va a ocurrir, y es mejor saberlo antes.
3. Invierte el experimento cuando necesites un número propio. Retrasa a propósito, con un retraso grande, en una fracción del tráfico, por poco tiempo.
4. Corre al menos dos niveles de retraso. Sin eso, la extrapolación lineal es fe, no método. Así fue como Bing validó la linealidad.
5. Elige una métrica frecuente como primaria y declara que es sustituta. Ganar sensibilidad no puede convertirse en un cambio silencioso de lo que el negocio quiere.
6. Separa lo que está en la ruta crítica de lo que no lo está. El experimento del panel derecho de Bing muestra que retrasar lo que carga después puede costar cero.
7. Registra la pendiente medida y la fecha. Vale para el sitio de hoy, con el público de hoy, en el punto de velocidad de hoy.
8. Sigue el efecto después de que el experimento termina. Brutlag observó que quienes pasaron por el retraso de 400 ms hicieron en promedio 0,21 por ciento menos búsquedas en las cinco semanas siguientes al fin de la inyección del retraso. La degradación deja huella.

Errores comunes

• Usar la misma cuenta de tamaño de muestra de un test de botón. El efecto de la velocidad es un orden de magnitud menor, y la cuenta cambia con el cuadrado de eso. La vara de medir es la del efecto mínimo detectable.
• Concluir que la velocidad no importa porque el test dio nulo. Un nulo con poder bajo no dice nada. Sin poder calculado, el resultado es solo ausencia de evidencia.
• Extrapolar de 2 segundos a 50 milisegundos. La aproximación lineal se verificó en un rango, no en todos.
• Medir la velocidad solo en laboratorio. Una herramienta sintética mide una máquina; el percentil 75 de campo mide a tu público, y es lo que cuenta en la evaluación de Core Web Vitals.
• Tratar las Core Web Vitals como promesa de posicionamiento. Google dice explícitamente que no hay una única señal y que la relevancia va primero.
• Correr el test de lentitud en el 100 por ciento del tráfico. Estás perjudicando a personas a propósito. Fracción pequeña, tiempo corto, guardrail de ingresos activado.
• Olvidar que el navegador del usuario es parte del experimento. Un retraso en el servidor afecta a todos por igual; una optimización de JavaScript afecta mucho más a quien tiene un dispositivo débil, y eso se convierte en un efecto heterogéneo por segmento.

Haz esto automático en Donnu

Lo que traba un programa de velocidad casi nunca es la instrumentación de rendimiento, que todo el mundo ya tiene. Es la falta de un registro de qué lectura de pendiente está vigente hoy y de cuándo se midió. Sin eso, cada discusión sobre rendimiento vuelve a empezar desde cero, y el número más citado en la reunión termina siendo el de Bing, que no es de tu sitio.

Donnu guarda la configuración de cada experimento en el momento en que se crea, con la métrica primaria declarada, las métricas de guardrail y el historial congelado por experimento. Eso es lo que permite volver meses después y responder “¿cuándo medimos la pendiente de velocidad, y con qué retraso?”, que es la pregunta que separa un programa de rendimiento de una opinión recurrente.

La recomendación más barata de esta guía: pon el tiempo de respuesta como guardrail en todos tus tests A/B, incluso en los que no tienen nada que ver con rendimiento. El costo es cero y, la primera vez que una funcionalidad nueva gane conversión y retrase la página, vas a tener los dos números lado a lado en lugar de uno solo. La calculadora de impacto de la velocidad en la conversión convierte la pendiente medida en dinero por año.

Referencias

• Kohavi, R., Deng, A., Longbotham, R. y Xu, Y. Seven Rules of Thumb for Web Site Experimenters. KDD 2014, Nueva York. Fuente del experimento de lentitud de Bing que retrasó al 10 por ciento de los usuarios en 100 ms y a otro 10 por ciento en 250 ms durante dos semanas, mostrando que cada 100 ms de mejora aumenta los ingresos en 0,6 por ciento; de la estimación de que 250 ms de retraso en el servidor impactan los ingresos en cerca de 1,5 por ciento y el CTR en 0,25 por ciento; del registro de que 500 ms impactarían los ingresos en cerca de 3 por ciento y no en 20 por ciento; de las tres razones para dudar de la atribución a la velocidad en el caso de los 30 resultados de Google; del experimento del panel derecho, en el que retrasar 250 ms los elementos cargados después del evento de carga de la ventana no produjo un impacto detectable a pesar de casi 20 millones de usuarios; de la recomendación del diseño de lentitud como la mejor forma de aislar el rendimiento; de la confirmación empírica de que la aproximación lineal es razonable en Bing; de la mención al dato de 100 ms y 1 por ciento de ventas en Amazon, atribuido a Greg Linden; y de las deficiencias del tiempo hasta el evento de carga, con los ejemplos de Amazon (parte visible en 2,0 segundos frente al evento a los 5,2 segundos) y de Gmail (evento a los 3,3 segundos frente al contenido visible a los 4,8 segundos). exp-platform.com.
• Brutlag, J. Speed Matters. Google Research, 23 de junio de 2009. Fuente del experimento que retrasó la página de resultados de 100 a 400 ms y midió una caída de 0,2 a 0,6 por ciento en el número de búsquedas por usuario, con la descomposición por brazo (0,22 por ciento en las semanas 1 a 3 y 0,36 por ciento en las semanas 4 a 6 para el retraso de 200 ms; 0,44 por ciento y luego 0,76 por ciento para el retraso de 400 ms) y del efecto residual de 0,21 por ciento menos búsquedas en las cinco semanas posteriores al fin de la inyección del retraso en el grupo de 400 ms. research.google.
• web.dev. Web Vitals. Documentación de referencia de las Core Web Vitals. Fuente de los umbrales de “bueno” usados en esta guía: LCP en 2,5 segundos o menos, INP en 200 milisegundos o menos y CLS en 0,1 o menos; de la evaluación en el percentil 75 de las cargas, por separado para móvil y escritorio; de la recopilación de datos de campo anonimizados por el Chrome User Experience Report; y del registro de que el INP se convirtió en métrica estable en 2024, en lugar del FID. web.dev.
• Google Search Central. Understanding page experience in Google Search results. Fuente de las afirmaciones oficiales de que no existe una única señal de experiencia de página, de que las Core Web Vitals son usadas por los sistemas de posicionamiento y de que la búsqueda siempre intenta mostrar el contenido más relevante incluso cuando la experiencia de página es mala. developers.google.com.

Lee también: Métricas de guardrail · Métrica sustituta · Efecto mínimo detectable · CRO para sitios de bajo tráfico · Ley de Twyman · Calculadora de impacto de la velocidad · Leia em português · Read in English