Cómo interpretar PageSpeed Insights: Core Web Vitals en lenguaje sencillo
Ha probado su sitio web en PageSpeed Insights y ve un número en rojo, por ejemplo 45. ¿Qué significa eso y qué gravedad tiene? En este artículo descubrirá cómo leer el informe, qué miden las tres Core Web Vitals y qué puede mejorar usted mismo.
Las tres mediciones
| Medición | Qué mide | Bien | Mejora necesaria | Mal |
|---|---|---|---|---|
| LCP (Largest Contentful Paint) | Qué tan rápido aparece el elemento de contenido más grande en pantalla, a menudo la imagen grande de la parte superior | hasta 2,5 s | de 2,5 a 4 s | más de 4 s |
| INP (Interaction to Next Paint) | Qué tan rápido responde la página cuando hace clic, toca o escribe | hasta 200 ms | de 200 a 500 ms | más de 500 ms |
| CLS (Cumulative Layout Shift) | Cuánto se desplaza la página durante la carga (una puntuación, no un tiempo) | hasta 0,1 | de 0,1 a 0,25 | más de 0,25 |
Una página cumple con las Core Web Vitals si al menos el 75 por ciento de las visitas obtiene una buena puntuación en las tres, por separado para móvil y escritorio. Por lo tanto, no cuenta su ordenador rápido, sino la experiencia de la mayoría de los visitantes, también en un teléfono más antiguo. INP sustituyó en marzo de 2024 a la medición anterior, FID. Si todavía se encuentra con FID, esa información está desactualizada.
Datos de campo y datos de laboratorio
PageSpeed Insights muestra dos tipos de mediciones, que a menudo arrojan cifras diferentes:
- Datos de campo (arriba): mediciones de visitantes reales con Chrome durante los últimos 28 días. Esto determina si cumple con las Core Web Vitals. Si su página tiene pocas visitas, verá las cifras de todo su sitio, o ningún dato de campo.
- Datos de laboratorio (debajo): una prueba con Lighthouse, que carga la página una vez en un teléfono y una conexión intermedios simulados. De ahí viene el número de 0 a 100. Lighthouse no puede medir el INP, porque nadie hace clic.
Utilice los datos de laboratorio para encontrar causas y para comprobar de inmediato, tras una mejora, si esta ayuda. Comience por la pestaña Móvil: suele ser peor ahí, y Google se fija sobre todo en la versión móvil de su sitio.
¿Cuánto peso tiene esto en Google?
Google indica que las Core Web Vitals influyen en la clasificación. Pero Google siempre muestra el contenido más relevante, aunque esa página no sea la más rápida. El número de 0 a 100 procede de la prueba de laboratorio y no es una valoración de Google; esa valoración procede de los datos de campo. Obtener una puntuación perfecta solo para Google no es, según el propio Google, la mejor forma de invertir su tiempo. Procure situarse en la zona verde o al menos en la naranja, sobre todo porque los visitantes abandonan una página lenta o que se desplaza de forma inestable.
Qué puede mejorar en la propia página
- Imágenes más pequeñas. Una foto de miles de píxeles de ancho para un espacio de 800 píxeles es la causa más frecuente de un LCP lento. Reduzca el tamaño de las fotos antes de subirlas y utilice un formato moderno como WebP o AVIF.
- Ancho y alto en cada imagen. Sin
widthyheight, el navegador no sabe cuánto espacio necesita una foto, y el texto se desplaza cuando esta llega. Eso aumenta el CLS:<img src="bloemstuk.webp" width="800" height="600" alt="Bruidsboeket met witte rozen">
- No aplique carga diferida a la imagen más importante.
loading="lazy"es adecuado para fotos que aparecen más abajo, pero no para la foto que ya está en pantalla al abrir la página. De lo contrario, el navegador precisamente retrasa la foto que determina su LCP. - No inserte nada posteriormente por encima del contenido. Una barra de cookies, un anuncio o un widget que empuje la página hacia abajo hace que todo se desplace. Es preferible que dicha barra se superponga a la página.
- Menos scripts de terceros. Un INP deficiente casi siempre se debe a demasiado JavaScript: temas pesados, sliders, ventanas de chat y rastreadores. Revise con sentido crítico cada complemento o servicio incrustado.
Qué hace el servidor
Todo empieza con la primera respuesta del servidor, el Time to First Byte (TTFB). Este no es en sí una Core Web Vital, pero con una primera respuesta lenta, un buen LCP resulta casi imposible. Como valor de referencia, 0,8 segundos o menos es adecuado. Las causas suelen ser un sitio sin caché, poca capacidad de procesamiento o redirecciones. El servidor también debería enviar los archivos de texto comprimidos (compresión con gzip o Brotli). Puede leer cómo abordar el lado del servidor en Mi sitio web va lento o utiliza demasiada CPU: así lo hace más rápido y en la guía de DirectAdmin, Mi sitio web va lento.
En el IA Bouwer y WordPress
Un sitio del IA Bouwer establece el ancho y el alto en las imágenes cuyo tamaño se conoce, carga la primera foto de una página de inmediato y con prioridad, y el resto solo cuando entran en pantalla, y crea una versión más pequeña de las fotos grandes al publicar. En WordPress, un complemento de caché y la reducción del tamaño de las imágenes son lo que más ayuda. Puede leerlo en el curso gratuito de WordPress, lecciones ¿Qué hace que un sitio vaya lento y cómo se mide? y Imágenes, PHP y otras mejoras de velocidad.
Más información
- web.dev: Web Vitals (en inglés)
- Acerca de PageSpeed Insights (en inglés)
- Google: experiencia de página y Búsqueda de Google (en inglés)
- Google: el informe sobre señales web esenciales