Qué significa «lenta» con números
Una web se considera rápida cuando su LCP baja de 2,5 segundos en móvil, medido sobre visitas reales. Ese es el umbral que usa Google, y no es una opinión: es la línea que separa aprobar de suspender en el informe de Core Web Vitals.
Las tres métricas que importan y qué mide cada una:
| Métrica | Qué mide | Bien | Mal |
|---|---|---|---|
| LCP | Cuándo se pinta el elemento más grande (hero, titular) | < 2,5 s | > 4 s |
| INP | Cuánto tarda en responder a un toque o clic | < 200 ms | > 500 ms |
| CLS | Cuánto salta el contenido mientras carga | < 0,1 | > 0,25 |
El CLS es el que más rabia da al usuario y el que menos gente mira. Es cuando vas a pulsar «Llamar» y en ese momento carga un banner, todo baja dos centímetros y acabas pulsando otra cosa. Ese usuario no vuelve.
Por dónde se escapa el dinero
La velocidad no es un capricho de desarrollador. Toca tres sitios donde duele:
- Abandono antes de ver nada. El usuario que espera en una pantalla en blanco no está evaluando tu oferta: está volviendo a Google a mirar al siguiente. Y ese siguiente es tu competencia directa.
- Publicidad quemada. Si haces Google Ads, pagas el clic antes de que la página cargue. Cada visita que se va por lentitud es dinero gastado a cambio de nada. Además, Google penaliza la experiencia en la página y te sube el coste por clic.
- Menos rastreo. Los bots (Google y también los de IA) tienen un presupuesto de tiempo. Una web lenta se rastrea menos veces y más superficialmente. Es una de las cosas que reviso en la auditoría GEO.
Haz tú la cuenta, con tus números
No te voy a vender porcentajes de estudios de terceros aplicados a tu negocio. Haz esto en cinco minutos:
- Mira en GA4 tus visitas de móvil del último mes.
- Mira tu porcentaje de conversión actual (llamadas + formularios / visitas). Si no lo tienes medido, empieza por ahí: te lo dejo montado en el servicio de tracking con GA4 y GTM.
- Mira lo que te deja un cliente de media.
- Calcula qué pasaría si convirtieras un punto porcentual más.
Con 1.000 visitas al mes y un ticket de 400 €, un punto de conversión son 4.000 € al año. Compara eso con lo que cuesta una jornada de optimización y ya tienes la decisión tomada.
Las 7 causas reales (por orden de frecuencia)
Después de abrir bastantes webs de negocios de Madrid, el ranking casi siempre es el mismo:
1. Imágenes sin optimizar
La número uno con diferencia. Una foto de 4.000 píxeles y 3 MB subida tal cual desde el móvil, que se muestra en un hueco de 800 píxeles. El navegador se descarga los 3 MB igual.
2. Fuentes que bloquean el pintado
Tipografías cargadas desde Google Fonts sin preload y sin font-display. El texto se queda invisible esperando a que llegue la fuente desde otro dominio.
3. Scripts de terceros acumulados
Chat, píxel de Meta, píxel de TikTok que se probó una vez, mapa embebido, widget de reseñas, banner de cookies, heatmap. Cada uno pesa poco; los ocho juntos duplican el tiempo de carga.
4. Sliders y carruseles en el hero
Cargan varias imágenes grandes de golpe y suelen traer una librería de JavaScript detrás. Encima casi nadie ve la segunda diapositiva. Es el peor cambio de rendimiento por conversión que existe.
5. Plugins de más
Un WordPress con 25 plugins carga los CSS y JS de los 25 en todas las páginas, aunque el formulario de contacto solo esté en una.
6. Hosting compartido barato
Un servidor a 3 € al mes compartido con cientos de sitios responde tarde a la primera petición. Ahí se pierde medio segundo antes de empezar.
7. Frameworks que pintan en el navegador
Webs montadas con React o similares sin renderizado en servidor: el usuario descarga megas de JavaScript, el móvil los ejecuta y solo entonces aparece el texto. Y los crawlers de IA, que no ejecutan JavaScript, ven una página vacía. Lo cuento en cómo aparecer en ChatGPT y en las respuestas de IA.
Cómo medirlo bien en 5 minutos
Tres herramientas, todas gratis, y en este orden:
- PageSpeed Insights. Pega tu URL y mira solo la pestaña de móvil. Si arriba te sale el bloque de «datos de usuarios reales», eso es lo que cuenta de verdad; lo de abajo es una simulación.
- Search Console → Core Web Vitals. Datos reales de tus visitantes agrupados por tipo de página. Te dice qué plantilla está mal, no solo qué URL.
- Tu propio móvil con datos móviles. Desactiva el WiFi, abre tu web y cuenta en voz alta. Es la prueba menos científica y la más honesta.
Un aviso: una web nueva o con poco tráfico no tendrá datos reales en PageSpeed. En ese caso te fías de la simulación, sabiendo que suele ser más pesimista que la realidad.
Si sale en rojo y no sabes por dónde empezar, mándamela: en la auditoría web te devuelvo la lista de arreglos ordenada por lo que más impacto tiene, con lo que se puede tocar y lo que no.
Qué arreglar primero
Por orden de retorno. Los tres primeros suelen resolver el 80% del problema.
1. La imagen del hero
Casi siempre es el elemento que marca el LCP. Cuatro cosas:
- Conviértela a WebP o AVIF. Pesa entre un 30% y un 60% menos con la misma calidad visual.
- Redimensiónala al tamaño real en que se muestra (más un 2x para pantallas retina, no más).
- Declara
widthyheightpara que no salte el layout. - Márcala como prioritaria y no le pongas lazy loading. Este es el error clásico: se activa la carga diferida en todas las imágenes «para optimizar» y se retrasa justamente la que decide tu LCP.
<img src="/hero.webp" width="1200" height="675"
alt="Descripción real"
fetchpriority="high" decoding="async">2. Las fuentes, en tu propio dominio
Servirlas desde tu servidor en WOFF2 evita una conexión a otro dominio. Con preload el navegador empieza a bajarla antes de leer el CSS, y con font-display:swap el texto se ve desde el primer momento con una fuente del sistema.
<link rel="preload" href="/fonts/mifuente.woff2"
as="font" type="font/woff2" crossorigin>3. Auditoría de scripts de terceros
Abre las DevTools, pestaña Network, ordena por tamaño y mira qué se está cargando que no es tuyo. Para cada uno: ¿lo estoy usando? Si no, fuera. Si sí, ¿puede cargarse con defer o solo cuando el usuario haga scroll o toque algo?
El chat en vivo, el mapa de Google Maps y el widget de reseñas son los tres sospechosos habituales, y los tres se pueden cargar bajo demanda sin perder nada.
4. Caché y CDN
Cabeceras de caché largas para imágenes, fuentes, CSS y JS. Y servir desde una CDN para que los archivos salgan de un servidor cercano al usuario en vez de cruzar medio mundo.
5. Reservar el espacio (adiós al CLS)
Todo lo que carga tarde tiene que tener su hueco reservado desde el principio: imágenes con dimensiones, iframes con altura fija, banners con contenedor de tamaño definido. Y nada de inyectar avisos arriba del todo empujando el contenido hacia abajo.
Cuándo optimizar no sirve y hay que rehacer
Optimizar tiene sentido si la web es sana y está sucia. No lo tiene si el problema es estructural.
Señales de que sale más barato rehacerla:
- Constructor visual pesado (Elementor, Divi, WPBakery) con veinte plugins encima.
- Plantilla comprada con cincuenta funciones de las que usas tres.
- Más de 2 MB de JavaScript en la portada.
- Ya has pasado por dos «optimizaciones» y sigue igual.
En esos casos, poner parches cuesta más horas que empezar limpio. Una web de negocio local en HTML y CSS bien hechos carga en menos de un segundo y no necesita mantenimiento de plugins. Es lo que hago en cada proyecto de diseño web en Madrid, y por lo que esta misma web pasa los Core Web Vitals sin trucos. Si vendes online, lo mismo aplica a una tienda Shopify: ahí cada décima de segundo se nota directamente en el carrito.
Rehacer no tiene por qué ser caro: los precios están publicados, desde 500€ y con entrega en 7-14 días. Y si quieres una cifra ajustada a tu caso antes de escribirme, tienes la calculadora de precio.
Preguntas frecuentes sobre velocidad web
El umbral oficial de Google es un LCP por debajo de 2,5 segundos en el percentil 75 de visitas reales en móvil. Por debajo de 2 segundos se considera cómodo, entre 2,5 y 4 necesita mejora y por encima de 4 es deficiente. Lo importante es medirlo en móvil con 4G, no en el ordenador con fibra.
LCP mide cuánto tarda en pintarse el elemento visible más grande, normalmente la imagen o el titular del hero. INP mide cuánto tarda la página en responder cuando el usuario toca o hace clic. CLS mide cuánto se mueve el contenido mientras carga. Los umbrales para aprobar son 2,5 s, 200 ms y 0,1 respectivamente.
Sí, pero es un factor de desempate, no el principal. Entre dos páginas con contenido y autoridad parecidos, gana la que ofrece mejor experiencia. Donde el impacto es directo e inmediato es en la conversión: el usuario que se va antes de que cargue no compra, y eso pasa antes de que Google entre en la ecuación.
Porque la prueba de móvil simula un dispositivo de gama media con conexión 4G lenta, y la de escritorio simula un ordenador con buena conexión. Como la mayoría de tus visitas llegan desde el móvil, la puntuación que importa es la de móvil. La de escritorio suele dar una falsa sensación de seguridad.
Si el problema son imágenes pesadas, falta de caché o dos o tres scripts de terceros, se optimiza y se arregla. Si la web arrastra un constructor visual con veinte plugins, una plantilla comprada llena de funciones que no usas o un tema que carga varios megas de JavaScript, optimizar es poner parches: sale más barato y más rápido rehacerla ligera.
Una optimización sobre una web existente suele resolverse en una o dos jornadas de trabajo si el problema es de imágenes, caché y scripts. Rehacer una web ligera desde cero parte de 500 € y de 7 a 14 días de plazo. La forma de decidir es comparar ese coste con lo que estás perdiendo cada mes en visitas que se van antes de leerte.
¿Cuánto tarda tu web ahora mismo?
Mándame la URL por WhatsApp y te digo qué la está frenando y si compensa optimizarla o rehacerla. Respuesta con datos, no con una puntuación de colores.
Mandar mi URL por WhatsApp