Core Web Vitals: LCP, INP y CLS

Módulo 4: Velocidad, móvil y https · Tiempo de lectura: 13 minutos

Objetivo de aprendizaje: Después de esta lección podrá explicar las tres Core Web Vitals con sus valores límite, nombrar la diferencia entre datos de campo y datos de laboratorio, leer una medición con PageSpeed Insights, abordar las causas principales de una mala puntuación y valorar con honestidad cuánto pesa la velocidad en los resultados de búsqueda.

Conceptos clave: Core Web Vitals, LCP (Largest Contentful Paint), INP (Interaction to Next Paint), CLS (Cumulative Layout Shift), percentil 75, datos de campo (CrUX), datos de laboratorio (Lighthouse), PageSpeed Insights, informe Métricas web principales (Core Web Vitals) en Search Console, TTFB, compresión, width y height en las imágenes, loading="lazy", experiencia en la página

La velocidad en tres cifras

"¿Es rápido mi sitio?" es una pregunta vaga. Google y los creadores de Chrome la han convertido en tres preguntas medibles, las Core Web Vitals:

Algunas cosas que conviene entender bien:

• LCP mide el momento en que aparece el elemento visible más grande. Suele ser una foto grande en la parte superior (la imagen "hero") o un bloque de texto grande. En el caso de Bloemenatelier Lotte, es la foto del arreglo floral de la página de inicio.
• INP tiene en cuenta todos los clics, toques y pulsaciones de teclas durante la visita e informa de la reacción más lenta (o casi la más lenta). El 12 de marzo de 2024, INP sustituyó a la métrica anterior FID (First Input Delay), que solo se fijaba en el primer clic y solo en la espera antes del procesamiento. Si encuentra FID en un artículo antiguo, esa información está desfasada.
• CLS no es un tiempo, sino una puntuación sin unidad. Aumenta cuando los elementos se desplazan mientras usted lee: quiere tocar un botón y justo en ese momento aparece un banner encima, de modo que toca otra cosa.

El percentil 75

Una página "supera" las Core Web Vitals cuando el 75 por ciento de las visitas obtiene una buena puntuación en las tres, medidas por separado para móvil y ordenador. Esto se llama el percentil 75. Significa que no cuenta su propio ordenador rápido con fibra óptica, sino la experiencia de la mayoría de los visitantes, también la de quienes usan un teléfono más antiguo con 4G.

Datos de campo y datos de laboratorio

Hay dos tipos de mediciones, y a menudo dan cifras distintas.

• Datos de campo proceden de visitantes reales. Chrome recopila de forma anónima (en los usuarios que lo permiten) la velocidad de las páginas en el Chrome User Experience Report (CrUX). PageSpeed Insights muestra los datos de campo de los últimos 28 días. El informe Métricas web principales de Search Console usa la misma fuente. Si su página tiene muy pocas visitas, PageSpeed Insights muestra las cifras de todo su sitio (el "origen"), y si este también tiene muy pocas, no hay datos de campo.
• Datos de laboratorio proceden de una prueba simulada con Lighthouse: una sola carga en un teléfono y una conexión de gama media simulados. Lighthouse no puede medir INP (nadie hace clic) y por eso ofrece otras cifras, como Total Blocking Time, que sí dan una pista sobre el INP.

Para la evaluación cuentan los datos de campo. Los datos de laboratorio son útiles para encontrar causas y para comprobar enseguida, tras una mejora, si funciona, sin esperar 28 días.

¿Cuánto pesa?

En este punto se exagera mucho. Esto es lo que dice la propia Google en su documentación sobre la experiencia en la página:

• "Core Web Vitals are used by our ranking systems": es decir, sí cuentan.
• No existe una "señal de experiencia en la página" independiente. Según Google, otros aspectos de una buena experiencia en la página (https, ausencia de ventanas emergentes intrusivas, facilidad de uso en el móvil) no le ayudan directamente a subir posiciones, pero sí hacen su sitio más agradable.
• "Google Search always seeks to show the most relevant content, even if the page experience is sub-par." Así que una página lenta con la mejor respuesta puede aparecer perfectamente en primer lugar.
• Según Google, conseguir una puntuación perfecta solo por el SEO "puede que no sea la mejor forma de emplear su tiempo".

Conclusión: procure estar en la zona verde o, como mínimo, en la naranja, sobre todo porque los visitantes abandonan una página lenta o que se desplaza. Perseguir pasar de 90 a 100 puntos en Lighthouse aporta poco en los resultados de búsqueda.

Las causas que puede abordar usted mismo

Una primera respuesta lenta (TTFB)

Todo empieza en el momento en que llega el primer byte del HTML, el Time to First Byte. El TTFB no es en sí una Core Web Vital, pero un TTFB lento hace casi imposible un buen LCP. web.dev da como valor orientativo: bueno es 0,8 segundos o menos, malo es más de 1,8 segundos. Causas según web.dev: poca capacidad de cálculo en el alojamiento, ausencia de caché (cada página se genera de nuevo, algo típico de WordPress sin plugin de caché), redirecciones (lección 4.1) y un servidor lejano sin CDN.

La compresión también forma parte de esto: el servidor debe enviar el HTML, el CSS y el JavaScript comprimidos con gzip o Brotli. Lo verá en la cabecera Content-Encoding: gzip o br. Casi todos los alojamientos lo hacen de forma predeterminada, pero una configuración incorrecta o un servidor antiguo pueden desactivarlo.

Imágenes

Las imágenes son la causa más frecuente de un mal LCP y un mal CLS:

1. Demasiado grandes. Una foto de 4.000 píxeles de ancho y 5 MB para un espacio de 800 píxeles. Redúzcala antes de subirla y use un formato moderno como WebP o AVIF.

2. Sin ancho ni alto. Sin width y height, el navegador no sabe cuánto espacio necesita la imagen, y el texto de debajo se desplaza en cuanto la imagen llega. web.dev recomienda poner width y height en cada <img>:

   <img src="bloemstuk.webp" width="800" height="600" alt="Bruidsboeket met witte rozen">

3. Cargar en diferido la foto más importante. loading="lazy" hace que una imagen no se cargue hasta que aparece en pantalla. Está bien para las fotos situadas más abajo, pero web.dev lo dice con claridad: las imágenes que ya están a la vista al abrir la página, y sobre todo la imagen LCP, no deben cargarse en diferido. De lo contrario, el navegador retrasa precisamente la foto que determina su LCP.

Contenido que se desplaza y reacciones lentas

Otras causas de CLS según web.dev: fuentes que cambian de tamaño al cargarse, anuncios y widgets incrustados que se agrandan solos, y contenido que se inserta más tarde por encima del contenido existente (como una barra de cookies que empuja la página hacia abajo en lugar de superponerse). Un mal INP se debe casi siempre a demasiado JavaScript: temas pesados, sliders, widgets de chat y rastreadores de terceros. Revise con ojo crítico cada plugin o servicio incrustado; aquí, menos es realmente más.

En la práctica: medir con PageSpeed Insights

Vaya a pagespeed.web.dev, introduzca la dirección de su página de inicio y haga clic en Analizar. Obtendrá dos pestañas (Móvil y Ordenador). Arriba aparece la evaluación de las Core Web Vitals basada en datos de campo, si los hay. Debajo está la prueba de Lighthouse con una puntuación y una lista de "Diagnóstico" con puntos concretos, por ejemplo sobre imágenes más grandes de lo necesario o una imagen LCP que se carga en diferido (los nombres exactos cambian con las nuevas versiones de Lighthouse). Empiece por Móvil: ahí el resultado suele ser peor, y Google mira primero la versión móvil (lección 4.2).

Si tiene su sitio en Search Console (módulo 2), consulte también Experiencia, Métricas web principales. Allí verá grupos de páginas similares con su estado, también de páginas que usted no había probado.

Un sitio creado con AI Builder pone ancho y alto en las imágenes cuyo tamaño se conoce, carga la primera foto de la página directamente y con prioridad (fetchpriority="high") y el resto en diferido, y al publicar crea una variante de 800 píxeles de ancho de las fotos grandes. En WordPress lo que más ayuda es un plugin de caché y reducir el tamaño de las imágenes; el curso de WordPress lo trata con más detalle en el módulo 6. Con otros creadores de sitios web y empresas de alojamiento funciona de forma similar: los botones cambian, las causas son las mismas.

Resumen

• Las Core Web Vitals son LCP (buena hasta 2,5 s), INP (buena hasta 200 ms, desde marzo de 2024 en lugar de FID) y CLS (buena hasta 0,1), medidas en el percentil 75 por tipo de dispositivo.
• Los datos de campo (CrUX, 28 días) determinan la evaluación; los datos de laboratorio (Lighthouse) ayudan a encontrar causas.
• Google usa las Core Web Vitals en la clasificación, pero la relevancia es lo primero: una puntuación perfecta no es un fin en sí mismo.
• Mayor beneficio: respuesta rápida del servidor con caché y compresión, imágenes ligeras con width y height, no cargar en diferido la foto más importante y menos JavaScript de terceros.

Cuestionario

Ejercicio

Ejercicio A4.3: Respuesta rápida e imágenes ligeras. Introduzca la dirección de una página. El programa mide tres veces el tiempo hasta el primer byte (TTFB) desde nuestro servidor y toma el valor intermedio, comprueba si el HTML se envía comprimido (gzip, Brotli o zstd), cuenta las imágenes sin width y height, y comprueba que la imagen principal de la parte superior no se cargue con loading="lazy". Atención: se trata de una medición desde un solo lugar, no de una medición de sus visitantes. ¿No tiene sitio propio? Use www.wikipedia.org.

Ejercicio D4.3: Sus Core Web Vitals. Ejecute PageSpeed Insights en su página de inicio y en otra página importante, primero en Móvil. Anote para cada página: si hay datos de campo (de la página o de todo el sitio), el LCP, el INP y el CLS de los datos de campo, la puntuación de Lighthouse y el elemento que Lighthouse señala como elemento LCP. Elija la mejora que, en su opinión, aporta más y explique por qué.

Para seguir leyendo

• web.dev, Web Vitals: https://web.dev/articles/vitals
• web.dev, Largest Contentful Paint (LCP): https://web.dev/articles/lcp
• web.dev, Interaction to Next Paint (INP): https://web.dev/articles/inp
• web.dev, Cumulative Layout Shift (CLS): https://web.dev/articles/cls
• web.dev, Time to First Byte (TTFB): https://web.dev/articles/ttfb
• web.dev, Browser-level image lazy loading: https://web.dev/articles/browser-level-image-lazy-loading
• Google Search Central, Understanding page experience in Google Search results: https://developers.google.com/search/docs/appearance/page-experience
• PageSpeed Insights, About PageSpeed Insights: https://developers.google.com/speed/docs/insights/v5/about
• Ayuda de Search Console, Core Web Vitals report: https://support.google.com/webmasters/answer/9205520