¿Por qué la velocidad de la página web afecta las ventas?
Porque el cliente decide en segundos si se queda: en el estudio «Milliseconds Make Millions» de Deloitte y Google (2020), una mejora de 0.1 segundos en la velocidad móvil aumentó la conversión alrededor de 8% en comercio y de 10% en viajes, y las páginas que tardan más de tres segundos pierden una parte grande de sus visitas antes de mostrar nada. En Latinoamérica, donde la mayoría navega desde el teléfono con datos móviles y no siempre con buena señal, el efecto es mayor que en las cifras de Estados Unidos.
Hay un segundo efecto: Google usa la experiencia de página, incluidos los Core Web Vitals, como señal de posicionamiento. Un sitio lento posiciona peor y, cuando posiciona, convierte peor. Y un tercero: la IA que recomienda empresas lee el sitio con rastreadores que tienen paciencia limitada con páginas pesadas.
¿Qué son los Core Web Vitals y cuánto debe tardar en cargar un sitio?
Los Core Web Vitals son las tres métricas con las que Google mide la experiencia de carga: LCP (cuánto tarda en mostrarse el contenido principal; bueno si es menos de 2.5 segundos), INP (cuánto tarda la página en reaccionar a un toque; bueno si es menos de 200 milisegundos) y CLS (cuánto se mueve el contenido mientras carga; bueno si es menos de 0.1). Un sitio que cumple los tres en móvil está «en verde» y no pierde clientes por velocidad. El objetivo práctico: que la página se vea y se pueda usar en menos de 2 a 3 segundos en un teléfono con datos.
Core Web Vitals: qué mide cada uno y el umbral de Google
| Métrica | Qué mide | Bueno | Malo |
|---|---|---|---|
| LCP (Largest Contentful Paint) | Cuándo aparece el contenido principal | ≤ 2.5 s | > 4.0 s |
| INP (Interaction to Next Paint) | Cuánto tarda en responder a un toque o clic | ≤ 200 ms | > 500 ms |
| CLS (Cumulative Layout Shift) | Cuánto salta el contenido mientras carga | ≤ 0.1 | > 0.25 |
Umbrales oficiales de Google, medidos en el percentil 75 de visitas reales en móvil.
¿Cómo medir la velocidad de mi página web gratis?
Se mide con PageSpeed Insights (pagespeed.web.dev): pega la dirección de tu sitio y obtienes los Core Web Vitals con datos reales de usuarios (si hay suficientes visitas) y una prueba de laboratorio en móvil y escritorio, con la lista de lo que la frena. Mira primero la pestaña móvil, no la de escritorio, y las métricas reales antes que la puntuación. Complementa con Search Console (informe «Experiencia de página») para ver qué páginas están en rojo, y con tu propio teléfono con datos: abre el sitio y cuenta.
- 1
PageSpeed Insights en móvil
Mira LCP, INP y CLS con datos reales. La puntuación de 0 a 100 es orientativa; las métricas son lo que Google usa.
- 2
Search Console, «Experiencia de página»
Qué páginas de tu sitio están en verde, naranja o rojo con datos de usuarios reales.
- 3
Tu teléfono con datos
Sin wifi, abre la portada y una página de servicio. Si tarda más de tres segundos en mostrar algo, ya perdiste visitas.
- 4
Compara con dos competidores
Mismo test. Si ellos cargan en 2 segundos y tú en 6, Google y el cliente lo notan.
¿Por qué mi página web es lenta? Las causas frecuentes
Las causas casi siempre son las mismas: un constructor genérico (WordPress con tema comprado y 30 plugins, o un constructor visual) que carga cientos de kilobytes de código que la página no usa; imágenes subidas sin comprimir ni redimensionar (una foto de 4 MB donde bastaban 80 KB); fuentes externas que bloquean el dibujo; scripts de rastreo, chats y widgets que se cargan antes que el contenido; un servidor barato y lejano; y sin caché ni red de distribución. Cada una suma; juntas hacen los 6 a 10 segundos que se ven en muchos sitios de empresa.
Qué hace lento un sitio y qué lo resuelve
| Causa | Efecto típico | Solución |
|---|---|---|
| Constructor con tema y plugins | 300–800 KB de código innecesario | Construir con código propio y ligero; sin plugins |
| Imágenes sin optimizar | Fotos de 2–5 MB | WebP/AVIF, tamaño exacto, carga diferida |
| Fuentes externas | Texto invisible 1–2 s | Fuentes del sistema o alojadas con carga controlada |
| Scripts de terceros antes del contenido | Página en blanco hasta que cargan | Cargarlos después del contenido, o quitar los que no se usan |
| Servidor compartido y lejano | Respuesta lenta desde el inicio | Sitio estático servido desde una red global |
| Sin caché | Cada visita vuelve a construirse | Páginas pregeneradas, caché en el borde |
¿Cómo se construye una página web rápida desde el inicio?
Se construye con código propio y ligero en lugar de un constructor con plugins, con las páginas pregeneradas y servidas desde una red global (no un servidor compartido), con imágenes en formato moderno al tamaño exacto y carga diferida, con fuentes controladas, con los scripts de terceros al mínimo y cargados después del contenido, y midiendo en móvil antes de entregar. Así se construyen nuestros sitios: Core Web Vitals en verde en móvil es parte de la entrega, no una optimización que se cobra después.
Un sitio lento rara vez se arregla con parches: se comprimen las imágenes y sube de 6 a 5 segundos, y el constructor sigue cargando lo mismo. Cuando el sitio se rehace bien, la velocidad viene incluida y no se pierde con el tiempo, porque no hay plugins que se acumulen.
La velocidad no es un detalle técnico: es la primera impresión que el cliente tiene de tu empresa, y la tiene antes de leer una palabra.
Lo que pedirle a quien construya tu sitio
- ✓Core Web Vitals en verde en móvil, comprobados en PageSpeed Insights antes de entregar
- ✓Sin constructor genérico ni plugins que se acumulen
- ✓Imágenes optimizadas automáticamente al subirlas
- ✓Servido desde una red global con caché
- ✓Scripts de terceros sólo los necesarios, cargados después del contenido
- ✓Que el sitio siga rápido en un año, sin mantenimiento de velocidad