Por qué auditar la velocidad de tu web no es opcional
El 53 % de los visitantes móviles abandona una web que tarda más de 3 segundos en cargar (estudio público de Google). Eso significa que si tu web carga lenta, estás perdiendo más de la mitad del tráfico antes de que vea nada. No es una cuestión técnica abstracta: es facturación que se queda en la mesa cada día.
Esta guía te enseña a auditar la velocidad de tu web tú mismo, sin pagar nada, con las herramientas oficiales de Google. Si después de leerla te das cuenta de que el problema es estructural y no lo puedes arreglar internamente, sabrás qué pedir a una agencia.
Paso 1: Mide los Core Web Vitals reales
Los Core Web Vitals son las tres métricas oficiales que usa Google como factor de ranking confirmado desde 2021:
- LCP (Largest Contentful Paint): cuánto tarda en aparecer el elemento más grande del primer pantallazo. Bueno: menos de 2,5 segundos.
- INP (Interaction to Next Paint): cuánto tarda tu web en responder a clics. Bueno: menos de 200 ms. Sustituyó al FID en marzo de 2024.
- CLS (Cumulative Layout Shift): cuánto se mueve el contenido al cargar. Bueno: menos de 0,1.
Para medirlos correctamente, usa la API oficial de Google PageSpeed Insights. Puedes ir a pagespeed.web.dev directamente o usar nuestro Test de Velocidad Web, que lanza el análisis en paralelo móvil + escritorio y te traduce los resultados a impacto económico.
Importante: lanza el análisis 3-5 veces y quédate con la mediana. Los resultados varían entre runs por carga del servidor y red.
Paso 2: Diferencia datos de campo vs datos de laboratorio
PageSpeed te muestra dos secciones distintas en cada análisis:
Datos de campo (CrUX): el rendimiento real que experimentan tus usuarios reales en los últimos 28 días. Sólo disponible si tu web tiene tráfico suficiente. Es lo que Google usa para rankear.
Datos de laboratorio (Lighthouse): una simulación controlada en un dispositivo virtual con red 4G limitada. Es lo que sale siempre, también en webs nuevas sin tráfico.
Si tienes datos de campo, son los que importan para SEO. Si solo tienes datos de laboratorio, son una buena aproximación pero pueden ser hasta un 20-30 % más pesimistas que la realidad. Mejor profundizar en CrUX vs lab en la guía completa.
Paso 3: Identifica los cuellos de botella concretos
Tras ejecutar PageSpeed, baja al apartado de “Diagnósticos” y “Oportunidades”. Allí Google te lista qué está frenando tu web, ordenado por impacto estimado:
- Reduce el tamaño de las imágenes: si una imagen pesa más de 200 KB en móvil, está sin optimizar.
- Sirve imágenes en formatos modernos (WebP, AVIF): aún hoy el 60 % de las webs usa JPG/PNG donde podría usar WebP, que pesa la mitad.
- Elimina recursos que bloquean el renderizado: CSS y JavaScript en la cabecera que Google tiene que descargar antes de pintar nada.
- Reduce el tiempo de respuesta del servidor (TTFB): si tu servidor tarda más de 600 ms en responder, hay un problema de hosting o de generación de la página.
- Evita los layout shifts: imágenes y embeds sin atributo width y height definidos.
Paso 4: Audita el TTFB (Time To First Byte)
El TTFB es el tiempo que tarda tu servidor en enviar el primer byte de HTML al navegador. Si supera los 600 ms, ningún ajuste posterior te va a salvar la velocidad: el problema es de hosting.
Causas típicas de TTFB alto:
- Hosting compartido sobrecargado (Hostinger, OVH compartido, 1and1)
- WordPress con muchos plugins consultando la base de datos en cada visita
- CDN mal configurado (orígenes lentos)
- Servidor sin caché de página activado
Soluciones:
- Si usas WordPress, instala un plugin de caché serio (WP Rocket, LiteSpeed Cache, FlyingPress).
- Si tu TTFB sigue alto, el problema es el hosting. Migra a un host con respuesta más rápida (Hetzner, Cloudflare Pages, Vercel) o a una arquitectura estática.
- Si tu web es estática (Astro, Next.js SSG, HTML puro) servida desde CDN edge, deberías tener TTFB inferior a 200 ms automáticamente.
Paso 5: Audita las imágenes
Las imágenes son la causa número uno de webs lentas. Auditoría rápida:
- Abre tu web en el navegador.
- Pulsa F12 (DevTools).
- Ve a la pestaña “Network”, filtra por “Img”.
- Recarga la página.
- Mira el peso total de imágenes en la barra inferior.
Si supera 1,5 MB en la primera carga, tienes trabajo:
- Convierte a WebP o AVIF: cualquier herramienta gratuita lo hace (Squoosh.app de Google, TinyPNG, ImageOptim).
- Sirve dimensiones correctas: si tu imagen se ve a 600x400 px, no la subas a 3000x2000.
- Lazy loading: añade
loading="lazy"a todas las imágenes bajo el pliegue (no a las del hero). - Atributo width y height: pónselo a TODAS las imágenes para evitar CLS.
Paso 6: Audita el JavaScript de terceros
Cada script externo (Google Analytics, Facebook Pixel, chat de Tawk, Hotjar, etc.) añade peso, retrasos de carga y a veces puntos de fallo. Audita:
- ¿Cuántos scripts externos tienes cargados? Si son más de 8-10, probablemente sobran algunos.
- ¿Cargas el chat (Tawk, Crisp) síncronamente? Cárgalo con
defero tras un delay. - ¿Tienes píxeles de Meta o LinkedIn activos en campañas que ya no usas? Quítalos.
- ¿Cargas fuentes web bloqueantes? Usa
font-display: swap.
Paso 7: Comprueba el impacto en conversión
El último paso de la auditoría no es técnico, es de negocio:
- Abre Google Analytics 4.
- Ve a “Adquisición” → “Tráfico” → “Página de destino”.
- Compara la tasa de rebote y la tasa de conversión por velocidad de página.
Si tus páginas más lentas tienen rebote significativamente mayor y conversión menor, ya tienes el caso de negocio para invertir en optimización.
Cuándo el problema es estructural y no incremental
Si tras seguir estos pasos tu LCP móvil sigue por encima de 4 segundos y has hecho todo lo razonable (caché, WebP, lazy loading), el problema probablemente es estructural:
- WordPress saturado: 50+ plugins acumulados durante años, tema heredado, base de datos hinchada. La solución incremental se agota.
- CMS pesado mal configurado: Drupal, Magento, Joomla con módulos legacy.
- Hosting compartido pésimo: TTFB > 1 s permanente.
En estos casos, lo más rentable a 12 meses suele ser migrar a una arquitectura estática (Astro, Next.js SSG, Hugo) servida desde CDN edge. La migración bien hecha baja el LCP de 5-6 s a 0,5-1 s instantáneamente.
Siguientes pasos
- Lee la guía completa de auditoría web para entender el resto de capas (SEO, GBP, conversión).
- Usa nuestro Test de Velocidad Web gratuito para medir Core Web Vitals reales.
- Si quieres ver qué cuesta una web lenta en euros perdidos, ese cálculo se incluye en el resultado del test.
- Si tu web es WordPress con problemas estructurales, lee tu web tarda más de 3 segundos.
Aplicable a estos sectores
Esta guía aplica especialmente a estos sectores donde trabajamos: