Core Web Vitals y los tres cambios que de verdad mueven el LCP
Google publicó Core Web Vitals en mayo de 2020 con umbrales de 2,5 segundos para LCP y 0,1 para CLS. Tres cambios mueven el LCP en un sitio real: servidor, recursos bloqueantes e imagen principal.
Contenido
- Puntos clave
- Qué mide cada una de las tres métricas
- La señal de ranking está anunciada, no activa
- El tiempo de respuesta del servidor es el suelo
- CSS y JavaScript que bloquean el render
- La imagen principal suele ser el elemento LCP
- El dato de campo puntúa, el de laboratorio explica
- Qué cambió en esta actualización
- Preguntas frecuentes
- Primero el servidor, luego el head, luego la imagen
Actualizado el 22 de enero de 2024 — First Input Delay deja de ser Core Web Vital y lo sustituye Interaction to Next Paint.
Core Web Vitals son las tres métricas de campo que Google publicó en mayo de 2020: Largest Contentful Paint, First Input Delay y Cumulative Layout Shift. En un sitio real solo tres cambios mueven el LCP: un servidor más rápido, menos recursos bloqueantes en el head y una entrega más temprana de la imagen principal.
Puntos clave
- Google puntúa Core Web Vitals en el percentil 75. El límite "bueno" son 2,5 segundos en LCP y 0,1 en CLS.
- La señal de ranking de page experience se anunció el 28 de mayo de 2020 y aún no se ha activado, con seis meses de aviso prometidos.
- El LCP tiene pocas causas: servidor, CSS y JavaScript bloqueantes, carga de recursos y renderizado en cliente.
- Las imágenes eran 893 KB de los 1.745 KB de la página móvil mediana del Web Almanac de 2019.
Qué mide cada una de las tres métricas
Google presentó Core Web Vitals en el blog de Chromium el 5 de mayo de 2020, con web-vitals, una librería JavaScript de código abierto para recoger valores de usuarios reales. El LCP marca cuándo se vuelve visible el elemento de contenido más grande. El FID mide el retraso hasta que el navegador responde a la primera interacción. El CLS cuantifica el movimiento inesperado del layout.
Los umbrales no son cifras redondas. Bryan McQuade y Barry Pollard publicaron el razonamiento en web.dev el 21 de mayo de 2020, con el argumento del percentil 75 frente a la mediana.
Google evalúa Core Web Vitals en el percentil 75 de las cargas, de modo que tres de cada cuatro visitas alcanzan el objetivo. El límite "bueno" de Largest Contentful Paint es 2,5 segundos y el límite "malo" son 4 segundos (web.dev, 21 de mayo de 2020).
La señal de ranking está anunciada, no activa
El 28 de mayo de 2020 Google indicó que Core Web Vitals se integraría con sus señales de page experience en un único factor de ranking, y prometió avisar antes. A septiembre de 2020 no hay fecha publicada.
Ese margen resulta útil: permite justificar el trabajo por el motivo comercial. El tiempo de carga forma parte de lo que una empresa compra cuando compra una web, no de una fase posterior.
El 28 de mayo de 2020 Google anunció una señal combinada de page experience. Core Web Vitals se sumaría a la compatibilidad móvil, la navegación segura, el HTTPS y la ausencia de interstitials intrusivos, con seis meses de aviso (Google Search Central, 28 de mayo de 2020).
El tiempo de respuesta del servidor es el suelo
Nada se pinta antes de que llegue el primer byte. Si el servidor tarda 900 ms en responder, al resto de la página le quedan 1,6 segundos dentro de un presupuesto de 2,5. La guía de optimización de LCP de web.dev, del 30 de abril de 2020, encabeza sus causas con la respuesta lenta del servidor.
Las soluciones no son vistosas: cachear el HTML, poner un CDN delante y eliminar las redirecciones encadenadas.
CSS y JavaScript que bloquean el render
Una hoja de estilos en el head bloquea el renderizado hasta descargarse y parsearse. Un script síncrono bloquea el parseo de lo que viene detrás. Los dos retrasan el pintado del LCP por rápido que llegue la imagen.
Conviene incrustar el CSS mínimo de la primera pantalla, cargar el resto sin bloquear y diferir los scripts que no hacen falta al principio. Un brief que fija un objetivo de Largest Contentful Paint y una fecha de medición acota esto. Es un argumento más para pedir resultados y no una lista de funcionalidades.
La imagen principal suele ser el elemento LCP
En casi toda página de marketing el elemento más grande es una imagen principal, o un titular sobre ella. El peso de imagen no es un detalle lateral.
En el Web Almanac de HTTP Archive de 2019, la página móvil mediana pesaba 1.745 KB. Las imágenes eran 893 KB, más de la mitad de la carga (Web Almanac, 11 de noviembre de 2019).
Cuatro cosas mueven esa entrega: compresión, formato moderno, dimensiones acordes al layout y descubribilidad en el HTML inicial. Una imagen inyectada por JavaScript no se descarga hasta que el framework se ejecuta.
El dato de campo puntúa, el de laboratorio explica
Lighthouse ejecuta una carga simulada con un perfil de dispositivo. Core Web Vitals se puntúan con lo que vivieron visitantes reales. Cuando los dos se contradicen, manda el dato de campo.
Instrumenta el sitio con la librería web-vitals y envía los valores a la analítica que ya exista. Decidirlo antes de construir y no después es una de las preguntas que deciden si un proyecto fracasa.
Qué cambió en esta actualización
Google anunció el 10 de mayo de 2023 que Interaction to Next Paint sustituiría a First Input Delay como Core Web Vital de respuesta. INP pasó de experimental a pendiente, con el relevo previsto para marzo de 2024. Mide la latencia de toda la visita y su umbral "bueno" son 200 ms en el percentil 75 (web.dev). Lo que dice este artículo sobre LCP no cambia, tampoco para quien esté eligiendo entre Jamstack y WordPress.
Preguntas frecuentes
¿Qué se considera un buen LCP?
2,5 segundos o menos, en el percentil 75 de cargas reales y separando móvil de escritorio. Entre 2,5 y 4 segundos hay que mejorar; por encima de 4 es malo. Una ejecución de laboratorio es un diagnóstico, no la cifra que evalúa Google.
¿Core Web Vitals ya afecta al posicionamiento?
Todavía no. Google anunció el 28 de mayo de 2020 que se sumarían a las señales de page experience, con al menos seis meses de aviso. A septiembre de 2020 no hay fecha publicada.
¿Por qué cambio conviene empezar?
Por medir el tiempo de respuesta del servidor. Si el time to first byte es alto, nada del navegador lo compensa. Después se quitan los recursos bloqueantes y luego se arregla la imagen principal. Invertir ese orden produce trabajo que no aparece en el dato de campo.
Primero el servidor, luego el head, luego la imagen
Arregla la respuesta del servidor, quita después los recursos bloqueantes y cambia en tercer lugar la imagen. Lo demás es teatro de medición mientras eso siga sin resolverse. Seis meses de dato de campo dirán si el percentil 75 se movió, y un sitio que hoy no lo recoge ya tiene su primera tarea.
