¿La velocidad web afecta a las ventas? Lo que dicen las pruebas A/B

El coste de una web lenta es la parte de las ventas que se pierde mientras los visitantes esperan a que las páginas aparezcan y respondan. Es real y se puede medir. En una prueba A/B en la que dos versiones de la misma landing solo se diferenciaban en la velocidad, Vodafone hizo que el contenido principal apareciera un 31% antes y vendió un 8% más. Rakuten 24 hizo una prueba parecida en su tienda online y los ingresos por visitante subieron un 53%.

Este artículo es para quien aprueba el presupuesto de la web: un founder, el responsable de e-commerce, alguien de marketing que tiene que decidir si un proyecto de rendimiento compensa. Separa los estudios fiables de las cifras que solo se repiten, explica por qué unas webs pierden más que otras y enseña cómo ponerle una cifra mensual a la espera en tu web. Para las causas de una web lenta y cómo arreglar cada una, lee por qué mi web va lenta.

¿La velocidad de la web afecta a las ventas?

Sí, y las mejores pruebas vienen de experimentos, no de encuestas. Cuando la misma página llega rápida a la mitad de los visitantes y más lenta a la otra mitad, la mitad rápida compra más, envía más formularios y se va menos. El efecto es mayor en las páginas que parten lentas, en el móvil y en los pasos más cercanos a la compra. Una vez superados los umbrales de Google para una buena experiencia, la ganancia se reduce, porque quedan pocos visitantes esperando.

¿Qué muestran las pruebas controladas?

Tres casos publicados aíslan la velocidad de todo lo demás, o se acercan mucho.

• Vodafone. Repartió el tráfico de pago al 50% entre dos landings iguales en aspecto y funciones, con unas 34.000 visitas al día cada una. En la versión A el HTML esencial se generaba en el servidor, el renderizado de un widget salía del navegador y las imágenes estaban redimensionadas. Con eso logró un Largest Contentful Paint (LCP), el momento en que aparece el contenido principal, un 31% mejor en visitas reales. Trajo un 8% más de ventas, una tasa de leads por visita un 15% mejor y una de carritos por visita un 11% mejor, según el caso publicado en web.dev.
• Rakuten 24. La tienda online japonesa hizo una prueba A/B centrada en los Core Web Vitals y métricas relacionadas. Con la versión más rápida, los ingresos por visitante crecieron un 53,37%, la tasa de conversión un 33,13% y el ticket medio un 15,20%, y la tasa de salida bajó un 35,12% (web.dev).
• redBus. La web india de billetes de autobús trabajó el Interaction to Next Paint (INP), el tiempo entre un toque y la respuesta de la pantalla, y en una página lo mejoró un 72%. Las ventas totales subieron un 7%, según web.dev. El caso no describe una prueba dividida, así que parte de esa subida puede tener otras causas.

Los tres están publicados en web.dev, la web de Google para desarrolladores, y a Google le interesa una web más rápida. Aun así, las cifras sirven porque el método está explicado: a quién se puso a prueba, qué cambió y cómo se midió.

¿Y los estudios grandes, con millones de sesiones?

El más citado es Milliseconds Make Millions, encargado por Google y hecho por Deloitte y 55. Siguió 37 webs de marcas europeas y estadounidenses y más de 30 millones de sesiones desde móvil, sin rediseños durante el estudio. Cuando una web mejoraba en 0,1 segundos cuatro métricas de velocidad en todas las páginas del recorrido, en retail los usuarios pasaban de la ficha de producto a la cesta un 9,1% más a menudo y gastaban un 9,2% más. En las webs de viajes, las reservas subieron un 10%. En las de captación de leads, un 21,6% más de visitantes llegó a la página de envío del formulario.

Hay que leerlo como una correlación fuerte, no como una promesa. El estudio observó velocidad y comportamiento hora a hora, sin ralentizar páginas a propósito. Y los 0,1 segundos había que ganarlos en las cuatro métricas a la vez, en cada página del embudo, que es bastante más trabajo de lo que sugiere el titular. Una de las cuatro métricas, el First Meaningful Paint, ya se ha retirado y la ha sustituido el LCP.

¿Qué estadísticas sobre velocidad conviene dejar de citar?

La cifra más repetida, la de que cada 100 milisegundos le costaban a Amazon el 1% de las ventas, se atribuye a una charla de 2006 de Greg Linden, exingeniero de Amazon. Lleva veinte años pasando de diapositiva en diapositiva y de blog en blog sin un artículo que explique cómo se midió. Tómala como una anécdota de otra web: navegadores de escritorio, servidores más lentos y ningún smartphone en la muestra.

Lo mismo vale para cualquier porcentaje que llega sin nombre de estudio, fecha y tamaño de muestra. Si la fuente no puede decir qué páginas, qué métrica y qué visitantes, la cifra no te ayuda a dimensionar un presupuesto.

¿Por qué la lentitud le cuesta más a unas webs que a otras?

Porque la pérdida está en los visitantes que esperan. Los Core Web Vitals de Google ponen el umbral de una buena experiencia en un LCP de 2,5 segundos o menos, un INP de 200 milisegundos o menos y un Cumulative Layout Shift (CLS) de 0,1 o menos, medidos en el percentil 75 de las visitas reales, como documenta web.dev. El Web Almanac 2025 de HTTP Archive encontró que el 48% de las webs en móvil supera los tres umbrales, frente al 56% en escritorio.

Lo que pierde cada web depende de tres cosas:

1. De dónde parte. Una web con un LCP de 5 segundos en móvil tiene muchos visitantes a punto de irse. Una a 1,8 segundos tiene pocos. El primer segundo que quitas vale más que el último.
2. Los dispositivos. Quien navega desde el móvil con datos es quien más espera, y por eso todos los estudios citados miden tráfico móvil.
3. El paso del recorrido. El retraso pesa más donde el visitante está a punto de decidir: de la ficha de producto a la cesta, del formulario al envío, del plan al pago. Un artículo lento cuesta atención. Un checkout lento cuesta pedidos.

¿Una web lenta también pierde tráfico de Google?

Algo, menos de lo que temen muchos propietarios. Google dice que sus sistemas de ranking premian una buena experiencia de página e incluye los Core Web Vitals en ella. También dice que la búsqueda intenta siempre mostrar el contenido más relevante, aunque la experiencia de página sea floja (Google Search Central). La velocidad ayuda cuando varias páginas responden igual de bien a una búsqueda; no sube una página que responde peor. Por eso la mayor parte del valor de la velocidad está en la conversión, en los visitantes que ya tienes.

¿Cómo se mide lo que cuesta la lentitud en tu propia web?

Una estimación se hace en una tarde con datos que ya tienes, y luego se confirma con una prueba. Cuatro pasos.

1. Lee los datos reales de las páginas que generan ingresos. PageSpeed Insights muestra para cada URL el Chrome UX Report: el LCP, el INP y el CLS que tuvieron tus visitantes reales en los últimos 28 días. El informe de Core Web Vitals de Search Console agrupa las páginas por estado. La puntuación de Lighthouse es una prueba de laboratorio en un solo dispositivo simulado, no lo que vieron tus clientes.
2. Cruza velocidad y conversión en la analítica. Envía el LCP y el INP de cada visita a tu herramienta de analítica (la librería open source web-vitals de Google lo hace en pocas líneas) y marca cada sesión como buena, mejorable o deficiente. Después compara la tasa de conversión de los tres grupos, por dispositivo.
3. Convierte la diferencia en dinero. Multiplica las sesiones del grupo lento por la diferencia de tasa de conversión entre el grupo rápido y el lento, y luego por el ticket medio o el valor de un lead. Eso son los ingresos mensuales en juego.
4. Confírmalo con una prueba dividida. Las sesiones lentas también vienen de móviles antiguos y conexiones flojas, y esos visitantes pueden comprar menos por otros motivos. Así que la cifra del tercer paso es un techo, no una previsión. Para encontrar la cifra real se hace como Vodafone: se sirve una versión más rápida de una página a la mitad del tráfico, se deja todo lo demás igual y se compara.

Un ejemplo con números

Toma una tienda online con estos datos, inventados para el ejemplo: 40.000 sesiones desde móvil al mes, el 30% en el grupo con LCP deficiente, una tasa de conversión del 1,2% en ese grupo frente al 2,0% en el grupo bueno, y un ticket medio de 60 €.

• Sesiones lentas: 12.000 al mes.
• Diferencia de conversión: 0,8 puntos porcentuales, o sea, 96 pedidos al mes.
• Techo de ingresos en juego: 96 × 60 € = 5.760 € al mes, unos 69.000 € al año.

Si luego una prueba dividida muestra que la mitad de esa diferencia es real, el trabajo de velocidad vale para esta tienda unos 2.900 € al mes. Esa cifra, puesta al lado del presupuesto del arreglo y de lo que cuesta mantener la web rápida después, es la decisión. En una web con Next.js los arreglos habituales ya se conocen y están en Core Web Vitals en Next.js en 2026.

¿Cuándo la velocidad no es el problema?

Cuando los datos reales ya están en verde y la conversión sigue baja. Una página que supera los tres Core Web Vitals en el percentil 75 tiene pocos visitantes esperando, y más trabajo de velocidad mueve poco. Entonces la fuga está en la oferta, el precio, los textos o el formulario. La velocidad es una de las causas de una conversión baja, no la única. También es la más fácil de medir, y por eso tienta arreglarla primero aunque no sea la mayor.