Un PageSpeed de 100 en Google Lighthouse no es un número decorativo. Significa que tu web carga en menos de un segundo en móvil, que las métricas de experiencia de usuario pasan los umbrales que Google usa para decidir si posicionar tu página o la de tu competencia. En Vadaweb Studio lo entregamos como estándar en todos los proyectos. Este artículo explica exactamente cómo se consigue.
¿Qué mide Google PageSpeed Insights?
Google PageSpeed Insights analiza tu URL con Lighthouse y devuelve una puntuación del 0 al 100 basada en métricas de rendimiento del mundo real (datos del CrUX, Chrome UX Report) y datos de laboratorio. La puntuación no mide solo la velocidad de descarga: mide cuándo el usuario puede ver el contenido (LCP), cuándo puede interactuar (INP) y si el layout se mueve mientras carga (CLS).
Los rangos orientativos son: 90-100 verde (bueno), 50-89 naranja (mejorable), 0-49 rojo (lento). Llegar a 100 en móvil requiere atacar todos los frentes al mismo tiempo — no hay un único ajuste que lo resuelva.
Los 5 factores que más afectan tu puntuación
- Imágenes sin comprimir o en formato incorrecto. Una imagen JPEG de 2 MB donde cabría un WebP de 80 KB es el problema más frecuente y el que más puntos resta. Lighthouse lo detecta inmediatamente y lo penaliza en el LCP.
- CSS y JavaScript bloqueante del render. Archivos CSS o JS que se cargan en el head sin
deferniasyncbloquean el navegador: no puede pintar nada hasta que termina de procesar esos archivos. Una web con 8 scripts en el head puede tardar 3-4 segundos solo en empezar a mostrar algo. - Render-blocking resources. Fuentes web externas cargadas con link estándar, hojas de estilos de terceros completas (Bootstrap, FontAwesome) que bloquean el render del HTML visible.
- Fuentes externas sin preconexión. Cada conexión a un dominio externo implica DNS lookup, TCP handshake y TLS negotiation. Sin preconnect, eso añade entre 200 y 500 ms en la primera carga.
- Falta de caché del navegador. Recursos estáticos (imágenes, CSS, JS) sin cabeceras Cache-Control correctas se descargan de nuevo en cada visita, penalizando tanto a usuarios recurrentes como a crawlers.
Cómo optimizar imágenes para PageSpeed
Las imágenes son habitualmente el 60-80% del peso de una página web. Estos son los pasos concretos para optimizarlas.
Usar formato WebP
WebP ofrece entre un 25% y un 35% menos de peso que JPEG a calidad visual equivalente. La combinación recomendada es servir WebP con fallback a JPEG para navegadores sin soporte:
<picture>
<source srcset="imagen.webp" type="image/webp" />
<img src="imagen.jpg" alt="Descripción" width="800" height="600" />
</picture>Definir siempre width y height en el HTML
Sin dimensiones explícitas en la etiqueta img, el navegador no puede reservar espacio antes de descargar la imagen. Esto provoca Layout Shift (CLS) cuando la imagen carga y empuja el contenido. Poner width y height en el HTML es uno de los ajustes más rápidos para mejorar el CLS sin coste adicional.
Lazy loading en imágenes fuera del viewport
El atributo loading="lazy" hace que el navegador no descargue las imágenes que están por debajo del pliegue hasta que el usuario hace scroll. Las imágenes hero y above-the-fold deben tener loading="eager". El resto, loading="lazy".
Compresión sin pérdida visible
Una imagen de producto raramente necesita más de calidad 75-80 en WebP para ser visualmente idéntica en pantalla. Herramientas como Squoosh, ImageOptim o el pipeline de Sharp en Node.js permiten automatizar esto en el proceso de build.
CSS crítico y defer de JavaScript
El CSS crítico es el subconjunto de estilos necesarios para renderizar la parte visible de la página en la primera carga. La técnica consiste en:
- Extraer los estilos críticos (above-the-fold) e incluirlos inline en el head.
- Cargar el CSS restante de forma asíncrona con
media="print" onload="this.media='all'"para que no bloquee el render. - Todo el JavaScript no crítico debe ir con
deferoasync— o mejor aún, cargarse al final del body.
En frameworks modernos como Astro, este proceso es automático: Astro genera HTML estático sin JavaScript en el cliente por defecto y solo hidrata los componentes interactivos que lo necesitan. Eso explica por qué las webs en Astro arrancan casi siempre con Lighthouse verde sin apenas configuración adicional.
Fuentes web sin bloqueo de render
Si usas Google Fonts, la forma correcta es con preconnect y display=swap para que el texto sea visible antes de que cargue la fuente:
<link rel="preconnect" href="https://fonts.googleapis.com" />
<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin />
<link href="https://fonts.googleapis.com/css2?family=Inter&display=swap"
rel="stylesheet" />La opción más agresiva — y la que usamos en Vadaweb Studio — es alojar las fuentes en el mismo servidor con @font-face, eliminando la petición externa por completo.
Core Web Vitals: LCP, INP y CLS explicados
Los Core Web Vitals son las tres métricas que Google usa directamente como señal de ranking. Entenderlas ayuda a saber exactamente dónde actuar.
LCP — Largest Contentful Paint
Mide cuándo se renderiza el elemento de contenido más grande visible en el viewport (habitualmente la imagen hero o el H1). El umbral bueno es por debajo de 2,5 segundos. Los principales causantes de un LCP alto son imágenes pesadas sin preload, CSS bloqueante y servidores lentos (TTFB alto).
INP — Interaction to Next Paint
Sustituyó al FID en 2024. Mide el tiempo entre que el usuario hace una acción (click, teclado, tap) y el navegador responde visualmente. Un INP superior a 200 ms se considera malo. El problema habitual es JavaScript excesivo en el hilo principal que bloquea la respuesta del navegador.
CLS — Cumulative Layout Shift
Mide cuánto se mueve visualmente el contenido mientras carga. Un anuncio que aparece y empuja el texto, una imagen sin dimensiones, una fuente web que cambia el interlineado al activarse — todo eso suma al CLS. El umbral bueno es por debajo de 0,1.
¿Vale la pena conseguir PageSpeed 100?
Depende de lo que entiendas por "valer la pena". Un PageSpeed de 95-98 en móvil en la práctica es indistinguible de un 100 para el usuario y para Google. Lo que importa es estar en verde en todos los Core Web Vitals y tener un LCP por debajo de 2,5 s.
El valor real no está en el número redondo, sino en lo que implica conseguirlo: imágenes optimizadas, sin JavaScript bloqueante, sin peticiones externas innecesarias, con caché bien configurada. Una web así carga en medio segundo en móvil con conexión lenta, funciona si algo de JavaScript falla y no pierde posicionamiento cuando Google actualiza sus algoritmos de experiencia de página.
La diferencia entre un PageSpeed de 45 y uno de 95 se traduce en menos tasa de rebote, más tiempo en página y, según el sector, entre un 10% y un 30% más de conversiones. Eso justifica hacer las cosas bien desde el principio en lugar de intentar arreglarlas después.
Calcula el impacto en tu tráfico o cuéntanos tu proyecto y lo analizamos juntos.
Relacionado: Diseño web para pymes en España: guía completa 2026 · Cuánto cuesta una página web en España