Tu web tarda 5 segundos. Esto es lo que te está costando.

Abre tu web en el móvil. Empieza a contar.

Si llegaste a tres y todavía estás mirando una pantalla en blanco, no necesitas otra frase sobre «experiencia de usuario». Necesitas saber qué parte del negocio puede estar escapándose durante esa espera.

No existe una cifra universal. Una tienda con 50.000 visitas no pierde lo mismo que un despacho que consigue veinte contactos al mes. Pero sí existe una forma honesta de estimarlo con tus propios datos.

La fórmula que convierte segundos en dinero

Necesitas cuatro números:

1. Visitas mensuales a las páginas donde ocurre la conversión.
2. Tasa de conversión actual.
3. Valor medio de una venta o de un lead.
4. Porcentaje de conversión que estimas recuperar al mejorar el rendimiento.

La fórmula es esta:

visitas × tasa de conversión × valor medio × pérdida estimada

Ese último porcentaje no debe inventarse. Se plantea como escenario y después se valida comparando periodos, dispositivos y canales antes y después de la mejora.

Tres escenarios, no tres promesas

Tipo de negocio	Datos de partida	Escenario de pérdida	Coste mensual estimado
Servicio local	5.000 visitas × 3 % × 120 € por lead o venta	20 %	3.600 €
Captación B2B	10.000 visitas × 1,5 % × 300 € por lead	10 %	4.500 €
Ecommerce pequeño	2.000 visitas × 5 % × 50 € por pedido	15 %	750 €

Son simulaciones para entender la fórmula. No significan que cualquier web lenta pierda esas cantidades. El cálculo útil es el que usa tus métricas y separa móvil, escritorio, canal y página de entrada.

Qué dicen los estudios y qué no dicen

Un análisis de Portent sobre velocidad y conversión encontró que, en su muestra, un sitio B2B que cargaba en un segundo tenía una tasa de conversión tres veces mayor que uno que tardaba cinco segundos. En ecommerce, la diferencia observada entre uno y cinco segundos fue de 2,5 veces.

Eso demuestra asociación dentro de una muestra concreta. No autoriza a multiplicar automáticamente tus ventas por tres. El sector, el tráfico, el dispositivo, el precio y la intención del visitante cambian el resultado.

El estudio Milliseconds Make Millions, publicado por Deloitte en 2020, analizó cómo pequeñas mejoras de velocidad móvil afectaban al comportamiento y a la conversión de marcas participantes. Su utilidad no está en copiar una cifra aislada, sino en recordar que incluso mejoras pequeñas pueden medirse en el negocio cuando existe suficiente tráfico.

La conclusión seria es menos espectacular y más útil: la velocidad puede afectar la conversión, pero debes medir cuánto en tu caso.

Dónde se rompe la experiencia

El usuario no espera de forma neutral. Mientras la página carga, decide si confía, si merece la pena continuar o si vuelve al resultado anterior.

En una tienda, la fricción puede aparecer en una ficha de producto o en el checkout. En un negocio local, en la página de servicio o en el formulario. En B2B, en una landing que tarda tanto en mostrar la propuesta que el visitante nunca llega a entenderla.

Por eso el promedio de todo el sitio puede esconder el problema. La pregunta no es solo «¿mi web es rápida?». Es «¿son rápidas las páginas que generan negocio, en los dispositivos y canales que usan mis clientes?».

Core Web Vitals sin dramatismo

Google utiliza tres métricas principales para describir la experiencia real:

• LCP: cuándo aparece el contenido principal. El umbral considerado bueno es 2,5 segundos o menos.
• INP: cuánto tarda la página en responder a una interacción. El objetivo es 200 milisegundos o menos.
• CLS: cuánto se desplaza inesperadamente el contenido. El valor bueno es 0,1 o menos.

Los umbrales y su metodología están documentados en Web Vitals. Se evalúan en el percentil 75: no basta con que una visita rápida salga bien si una parte relevante de los usuarios recibe una experiencia pobre.

Pero conviene decirlo correctamente: no existe una penalización automática y aislada por fallar una sola métrica. Google explica que sus sistemas consideran múltiples señales de experiencia y que Core Web Vitals forman parte de ese conjunto. Una página rápida no sustituye contenido útil, y una página valiosa no debería usar eso como excusa para cargar mal. Puedes consultar la explicación oficial sobre experiencia de página en Google Search.

Datos de campo y pruebas de laboratorio

PageSpeed Insights muestra dos tipos de información:

• Datos de campo: experiencia agregada de usuarios reales, cuando existe suficiente tráfico.
• Datos de laboratorio: una simulación controlada para diagnosticar problemas.

La puntuación de Lighthouse ayuda a encontrar qué falla, pero no es una factura ni el dato real de todos tus visitantes. Para decidir, cruza:

• Core Web Vitals de Search Console;
• tiempos y dispositivos en analítica;
• conversión por página de entrada;
• formularios, llamadas o pedidos;
• una prueba antes/después con el mismo periodo y canal cuando sea posible.

Qué medir antes de tocar la web

Guarda una línea base. Sin ella, después solo tendrás sensaciones.

Como mínimo:

1. LCP, INP y CLS de las páginas importantes.
2. Conversión móvil y escritorio por separado.
3. Tiempo de carga de las páginas que reciben tráfico de campañas o Google.
4. Número de pasos hasta contactar o comprar.
5. Errores de formulario y abandono del checkout, si aplica.
6. Fecha y alcance de cada cambio.

Una captura suelta de PageSpeed no es un antes/después. Las condiciones del test varían. Lo fiable es comparar varias mediciones y, sobre todo, datos de usuarios reales y conversiones.

Cuándo optimizar y cuándo reconstruir

Hay problemas que se corrigen sin cambiar la arquitectura:

• imágenes demasiado pesadas;
• fuentes que bloquean el renderizado;
• scripts de terceros innecesarios;
• caché mal configurada;
• plugins que ya no se usan;
• una imagen principal que se carga demasiado tarde.

Otros problemas son estructurales. Un constructor visual puede cargar CSS y JavaScript para funciones que esa página no utiliza. Una pila de plugins puede añadir solicitudes, dependencias y conflictos. En ese punto, optimizar se convierte en compensar una arquitectura que sigue produciendo el problema.

Eso no significa que toda web en Elementor deba migrar. En casi nueve años trabajando con Elementor aprendimos precisamente lo contrario: hay proyectos donde WordPress y un constructor siguen siendo una respuesta razonable por presupuesto, autonomía editorial o alcance.

Cuando la prioridad es una web de contenido con muy poco JavaScript, Astro parte de una arquitectura distinta. Esa explicación tecnológica pertenece allí. En esta página importa otra cosa: si el cambio reduce tiempo y mejora negocio de forma medible.

Un plan de prueba que sí permite decidir

1. Elige una página con tráfico y una conversión definida.
2. Guarda cuatro semanas de línea base, si el volumen lo permite.
3. Corrige primero el cuello de botella principal, no veinte cosas a la vez.
4. Comprueba que el cambio no rompió formularios, analítica ni SEO.
5. Compara el mismo dispositivo y canal.
6. Documenta el resultado, también si no mejora.

Si la velocidad mejora pero la conversión no cambia, puede que el problema esté en la propuesta, el precio, la confianza o el flujo. El rendimiento elimina fricción; no arregla por sí solo un negocio que no convence.

Si quieres calcular el coste con tus datos y distinguir entre una optimización razonable y una reconstrucción innecesaria, podemos revisarlo en un análisis gratis. Primero los números. Después, si hace falta, la solución.