Core Web Vitals, ya está aquí la nueva y temida actualización de Google.
Google anunció las actualizaciones del algoritmo de clasificación de la Experiencia de Página en mayo de 2020. Esta actualización incluye dos puntos clave:
- Tres nuevas métricas de rendimiento se utilizarán como señales de clasificación para el SEO.
- Top Stories ya no requiere una página AMPHTML, y el rendimiento se convertirá en un factor de clasificación.
La actualización es una gran noticia para los aficionados a la velocidad de los sitios: Google está poniendo un énfasis aún mayor en la velocidad de las experiencias de los usuarios, ofreciendo dos beneficios de SEO a los propietarios de sitios que ofrecen las experiencias rápidas que los clientes esperan.
Para conocer su rendimiento actual en relación con estas métricas, pruebe a pasar una página por PageSpeed Insights o por web.dev/measure.
Estas herramientas de Google le darán una puntuación de rendimiento y le permitirán saber cómo se compara una página con los nuevos objetivos de rendimiento.
Estas métricas de rendimiento han sido diseñadas para ser medidas universales de la velocidad de la página y para ser buenos proxies de la experiencia percibida por el usuario, deberían ser medidas válidas de cómo se siente la experiencia para casi todas las páginas web.
Dicho esto, Google ha declarado que estas métricas se revisan constantemente y pueden cambiar en el futuro.
El primer retraso de entrada es una medida del tiempo que tarda el navegador en responder a una entrada del usuario, como clics o toques.
El cambio de diseño acumulado es una medida de la inestabilidad de la página, una suma de todos los cambios de diseño inesperados en el ciclo de vida de la página.
Los valores recomendados anteriormente se determinan a partir del 75% de las experiencias reales de los usuarios: ¡al menos el 75% de las visitas a tu página deben superar el valor Bueno para aprobar esta evaluación!
Cómo mide Google la velocidad para el Core Web Vitals
Las tres nuevas métricas de rendimiento son relativamente nuevas en el mundo del rendimiento web, por lo que actualmente sólo se admiten a través de la API en los navegadores basados en Blink (Chrome, Chrome en Android, Chromium Edge).
Los datos que Google utilizará para la actualización de la experiencia de la página proceden de Chrome UX Report (CRUX), una colección de estadísticas de rendimiento anónimas tomadas de cargas de páginas reales en los navegadores Chrome de todo el mundo.
CRUX mide todas las cargas de páginas regulares, tanto para las páginas de inicio como para las de mitad de sesión, independientemente del estado de la caché.
No mide las navegaciones suaves (cambios de ruta) dentro de las aplicaciones de una sola página.
Esto significa que las navegaciones suaves serán potencialmente penalizadas, con puntuaciones CLS más altas de lo esperado y valores LCP ausentes o injustamente altos.
Lamentablemente, todavía no existe una buena solución para este problema.
Esto hace que sea aún más importante reducir los desplazamientos inesperados del trazado y optimizar el LCP en la medida de lo posible.
La actualización viene con un conjunto de objetivos de velocidad recomendados, estos se miden en el 75% de los datos CRUX, por lo que al menos el 75% de las experiencias medidas deberían cumplir o superar estos objetivos.
El caché y el estado de la sesión no están disponibles en el conjunto de datos CRUX, por lo que el valor del percentil 75 se toma de todas las cargas de páginas, con o sin caché.
PageSpeed Insights le dará tres conjuntos de métricas de rendimiento, cuando estén disponibles:
- Campo – los datos de CRUX para la URL dada.
- Resumen de origen: los datos de campo agregados de todas sus páginas.
- Laboratorio: una prueba realizada desde un servidor de Google que aplica la estrangulación.
Si su página no tiene suficiente tráfico para producir los datos de campo, sólo obtendrá el resultado del resumen de origen.
Las recomendaciones y los diagnósticos en PageSpeed Insights se producen a partir de la prueba de laboratorio, las métricas de rendimiento deben tomarse de los resultados de campo.
Las recomendaciones deberían darle una idea general de las áreas de mejora que tendrán un impacto positivo en los resultados vitales de su web.
Optimización de los resultados para los Core Web Vitals
Vamos a hablar de cómo medir, diagnosticar y mejorar cada una de las tres nuevas métricas: LCP, FID y CLS, sucesivamente. Recuerde que cualquier optimización para mejorar estas métricas hará, casi con toda seguridad, que sus páginas sean más rápidas y mejoren la experiencia del usuario.
Mayor contenido (LCP)
El LCP es un punto de tiempo que se mide cuando el elemento más grande por encima del pliegue se muestra en la pantalla.
En la mayoría de los casos se trata de una imagen/vídeo principal o del bloque de texto principal de la página.
El LCP es una buena alternativa al «tiempo de carga de la página»: mide todo lo que se necesita para que su sitio web renderice el contenido clave de una página: DNS, TLS, HTML, CSS y JavaScript de bloqueo, pero no incluye los scripts asíncronos ni el contenido cargado de forma perezosa.
El LCP se produce sólo después de que se hayan completado tres etapas de la carga de la página:
- HTML entregado y analizado.
- Descarga, análisis y procesamiento de los activos de la ruta crítica.
- Activo LCP descargado y renderizado (imagen, vídeo, fuente web, etc.).
La entrega rápida de documentos es una de las cosas más importantes que puede hacer para mejorar la velocidad de la página, si puede reducirla en 100 ms, todas las demás métricas de duración serán 100 ms más rápidas.
La entrega rápida de documentos se reduce a unas cuantas optimizaciones clave para los Core Web Vitals:
-
- DNS – El DNS es la libreta de direcciones de Internet. Optimice el DNS aumentando el TTL y utilizando un servicio de DNS distribuido globalmente.
-
- TCP – El factor que limita el establecimiento de una conexión TCP es (normalmente) el tiempo de ida y vuelta entre el usuario y el servidor. Utilice una red de entrega de contenidos para reducirlo al máximo.
-
- TLS – Los sitios web seguros requieren uno o más viajes de ida y vuelta adicionales para crear una conexión segura. Asegúrese de que tiene activado el grapado OCSP en el certificado del sitio (¡incluso puede rebajar el nivel de EV a OV para conseguirlo!) y que su servidor o CDN está configurado para soportar TLS v1.3
-
- TTFB – El tiempo hasta el primer byte de su sitio web está limitado por la rapidez con la que el servidor puede crear la respuesta. Si es posible, debería almacenarse en caché en una CDN o en un proxy inverso. Si el almacenamiento en caché de HTML no es posible (por ejemplo, si hay personalización en la página), asegúrese de que el entorno de su servidor es capaz de entregar las páginas en 100 ms.
- HTML – Puede parecer obvio, pero el tamaño y la estructura del documento HTML son fundamentales para el rendimiento. Asegúrese de que el documento HTML esté comprimido y tenga menos de 50kB en la red.
- Asegúrese de que el documento HTML esté comprimido y tenga menos de 50kB en la red. Presta atención al <head> del documento para asegurarte de que el <title> está en primer lugar y que no hay etiquetas <script> de terceros que bloqueen.
Una vez descargado el HTML, el navegador analiza el documento línea por línea para encontrar recursos en la ruta crítica.
El CSS y el JavaScript de la cabecera tienen una prioridad muy alta, y luego las imágenes del cuerpo se descargan en el orden en que aparecen.
Si el analizador del navegador ve una etiqueta de secuencia de comandos que se bloquea (es decir, sin el atributo async o defer), detendrá todo lo que esté haciendo mientras obtiene, analiza y ejecuta esa secuencia de comandos.
Por lo tanto, los scripts deberían ser siempre asíncronos, cuando el orden de ejecución no es importante, o diferidos cuando el orden de ejecución es importante.
También tiene sentido revisar los scripts inline para reducir su impacto.
Siempre que sea posible, divida su paquete de JavaScript por página y por soporte moderno de JavaScript. Esto le permitirá enviar el paquete más pequeño posible y utilizar las tecnologías modernas cuando sean compatibles.
Tenga en cuenta que el módulo tiene un comportamiento deferente por defecto:
<script type="module "src="/app-homepage.esm.js"></script><script nomodulesrc="/app-homepage.js"></script>
El siguiente paso en la ruta crítica es la carga de las hojas de estilo: sin CSS el navegador no sabe cómo renderizar la página por lo que bloqueará el renderizado en cualquier etiqueta.
Asegúrate de que el CSS está agrupado por página para reducir el peso innecesario, puedes recuperar y almacenar en caché una hoja de estilos completa más adelante en el ciclo de vida de la página utilizando el hack media=»none» (¡asegurándote de que este archivo no causará un cambio de diseño!):
<linkrel="stylesheet "href="lazy.css "media="none "onload="this.media='all'">
LCP se mide independientemente del estado de la caché, así que asegúrate de que tus activos estáticos (JavaScript, CSS, imágenes y fuentes) pueden ser almacenados en caché en el navegador durante al menos una hora con una cabecera de respuesta como «cache-control: max-age: 3600«.
Asegúrate también de que tus activos de texto están comprimidos con gzip o brotli, esto ayudará a mejorar tus Core Web Vitals.
Un problema común que veo, especialmente en los sitios de comercio electrónico, es un gran número de imágenes no críticas que se cargan al principio de la página, como en la definición de un mega menú.
El lazy-loading nativo es una gran técnica para optimizar el LCP reduciendo la contención del ancho de banda durante la carga de la página.
El atributo de carga aún no está soportado en Safari, pero sí lo está en WebKit y actualmente está disponible en Safari de iOS detrás de una bandera, por lo que podemos esperar un soporte general pronto.
Se admite en todos los navegadores que envían datos a CRUX, así que impleméntalo ahora para beneficiarte de los datos que impulsarán la actualización de Page Experience SEO.
<imgsrc="menu-img.jpg "alt="... "width="200 "height="200 "loading="lazy"><imgsrc="hero-img.jpg "alt="... "width="1024 "height="600 "loading="eager">
Asegúrate de que tu elemento hero tiene un atributo ‘loading=’eager’ y que las imágenes que están por debajo del pliegue u ocultas por defecto tienen un atributo ‘loading=’lazy’.
Esta sencilla optimización permite que el navegador dé prioridad a la descarga de los activos importantes antes, mejorando el LCP y la experiencia del usuario. Más información en web.dev
No hace falta decirlo, pero si tu elemento principal es una imagen o un vídeo, debería entregarse en el formato más optimizado para el navegador.
Esto puede significar que un servicio de terceros como Cloudinary o Akamai Image and Video Manager es una buena opción para optimizar dinámicamente su contenido multimedia.
El elemento hero no debe estar vinculado a JavaScript, por lo que es mejor sustituir los carruseles de imágenes y los reproductores de vídeo incrustados por imágenes estáticas.
Retraso en la primera entrada (FID) para mejorar los Core Web Vitals
El FID es una medida del tiempo que el navegador ha estado ocupado con otras tareas antes de poder reaccionar a un evento de entrada discreto del usuario, como un toque o un clic.
Es una indicación de la capacidad de respuesta de la interfaz de usuario para el usuario y de lo ocupada que está la CPU con el procesamiento de JavaScript.
La única forma consistente de mejorar la FID sin degradar la experiencia del usuario es reducir el tiempo de ejecución de JavaScript, tanto en la carga de la página como durante su ciclo de vida.
Una forma sencilla de jugar con esta métrica sería ocultar el contenido (tal vez detrás de una pantalla de carga / spinner) hasta que el JavaScript haya terminado de ejecutarse, para que tus visitantes no intenten interactuar antes de que tu aplicación esté completamente lista.
Sin embargo, lo más probable es que esto afecte negativamente a tus métricas LCP y CLS, así que ten cuidado.
Asumiendo que estamos tratando de mejorar el FID y mejorar el rendimiento visual, sólo tenemos unas pocas opciones:
- Retrasar o eliminar las terceras partes
- Aplazar los scripts no críticos
- Mejorar el rendimiento de JS
La primera tarea es ejecutar un rastreo de rendimiento en una página clave para ver dónde se consume el tiempo del hilo principal. Cualquier trozo grande es motivo de preocupación y debe ser investigado.
Céntrese en las tareas largas, ya que son bloques singulares de ejecución que tienen más probabilidades de causar altos retrasos en la primera entrada.
Desplazamiento de diseño acumulado (CLS)
CLS es una medida de la estabilidad de la interfaz de usuario a medida que el usuario carga e interactúa con una página. Es la suma de los cambios de diseño inesperados durante el ciclo de vida de la página, como cuando se carga un banner publicitario que desplaza el contenido principal de la página.
Las puntuaciones de los cambios de diseño se derivan del impacto que tiene el cambio en la ventana gráfica: un producto de la cantidad de cambios en la ventana gráfica y la distancia que se mueve el elemento. Una puntuación acumulada perfecta es cero, 0,1 es bueno.
Los desplazamientos inesperados del diseño significan que no se producen inmediatamente después de una interacción discreta del usuario, por lo que es probable que tengan un impacto negativo en la experiencia del usuario.
El CLS se mide con CRUX a lo largo del ciclo de vida de una página, desde el inicio de la navegación hasta que el usuario abandona la página.
Todos los cambios de diseño inesperados se suman a lo largo de este tiempo y la puntuación total se utiliza para la medición; esto hace que sea una métrica difícil de medir en un entorno de laboratorio.
Esto también significa que herramientas como WebPageTest y mPulse informarán del mejor escenario para CLS para sacar conclusiones de tus Core Web Vitals, sólo recogerán estos datos mientras la página se está cargando e ignorarán otros cambios como los que ocurren durante el desplazamiento.
Optimizar el CLS para mejorar un aspecto de los Core Web Vitals durante la carga de la página es razonablemente sencillo, sólo tenemos que evitar los cambios de diseño. Las causas de los cambios de diseño son múltiples, así que veamos algunas de ellas y cómo evitarlas.
- Fuentes web – haga coincidir los caracteres de su fuente web y el espacio entre líneas con la fuente de reserva.
- Anuncios – preasigne espacios de diseño para los anuncios, utilice una imagen de reserva si los anuncios fallan o se bloquean.
- CSS de carga tardía: asegúrese de que el CSS crítico para la maquetación está en la ruta crítica.
- Imágenes: añada siempre un atributo de anchura y altura para las imágenes, de modo que el navegador pueda asignar espacio antes de que se descargue la imagen.
- Contenido dinámico: en la medida de lo posible, preasigna espacio de diseño para los elementos dinámicos.
Las herramientas para desarrolladores de Chrome disponen ahora de un método práctico para identificar qué elementos han provocado un cambio de diseño y cómo han contribuido a la puntuación acumulada del cambio de diseño
Si pasas el ratón por el cambio de diseño en el seguimiento de la experiencia, Chrome resaltará el elemento en la página. Ten en cuenta que los detalles te muestran desde dónde se ha movido el elemento y hasta dónde.
Te recomiendo que configures las opciones de estrangulamiento de la red y la CPU en la pestaña Rendimiento, ya que así es más probable que detectes los cambios de diseño que se producen en la naturaleza debido a las condiciones de carrera de la red.
Una vez que hayas identificado los elementos que están causando los cambios de diseño, es el momento de determinar cómo reducirlos o prevenirlos.
Cuando se carga la fuente web, el elemento de texto se desplaza ya que los caracteres están más condensados y el elemento se dimensiona para ajustarse al contenido.
En este caso se trata de un pequeño cambio de diseño, pero el impacto en el cuerpo del texto puede ser mucho mayor, ya que el desbordamiento del texto puede hacer que el elemento del cuerpo cambie de tamaño.
Podría ser posible arreglar esto haciendo coincidir la fuente del sistema con la fuente web, usando descriptores font-face, pero la manera más robusta de evitar los cambios de diseño basados en la fuente es precargar la fuente web y usar font-display: optional.
Esta combinación da al navegador la mejor oportunidad de tener la(s) fuente(s) web disponible(s) cuando la(s) necesita, pero permite al navegador usar la fuente de reserva en caso de que la fuente web no esté disponible.
Esto asegura que no habrá un cambio en el diseño debido a las fuentes, tanto para la carga inicial de la página como para las subsiguientes cargas de la página que utilizarán la fuente web ahora cacheada.
Otros aspectos vitales
Aunque la actualización inicial de la experiencia de la página define LCP, FID y CLS como los valores vitales de la web (Core Web Vitals), éstos pueden cambiar con el tiempo.
Hay una gran cantidad de otras métricas que proporcionan un valor adicional y que vale la pena seguir y optimizar.
A continuación se presentan algunas otras métricas clave que puede querer seguir y mejorar.
FCP para el Core Web Vitals
Mientras que el LCP mide la pintura más grande en la pantalla, el FCP mide cuándo se produce la primera pintura.
Se trata de una métrica importante por varias razones, sobre todo porque es la primera vez que el usuario sabe que su navegación está funcionando realmente.
Este punto de tiempo también se correlaciona bien con el momento en que el navegador del usuario cambia de contexto desde la página anterior.
El FCP suele ser idéntico al primer pintado, o muy poco después. La primera pintura incluye elementos no visibles en el cálculo, mientras que FCP sólo mide el contenido que es visible para el usuario. En este caso, el logotipo del sitio y la cabecera:
Tiempo hasta la interactividad (TTI)
El tiempo hasta la interactividad (TTI) es una aproximación al momento en que la página se sentirá interactiva si un usuario intenta interactuar.
Este punto de tiempo se mide entre la primera pintura de Contentful y cuando el hilo principal ha estado libre de tareas largas durante al menos cinco segundos.
Conseguir esta métrica lo más baja posible asegurará que tus usuarios tengan una gran experiencia cuando intenten interactuar con tus páginas.
Utiliza el TTI con el TBT para obtener una imagen general de lo ocupado que está el navegador cuando se cargan tus páginas.
Tiempo total de bloqueo (TBT)
El tiempo total de bloqueo (TBT) es una medida de lo ocupada que estuvo la CPU del navegador mientras se cargaba la página, medido como la suma de tareas largas (menos de 50ms cada una) entre FCP y TTI. Reducir este tiempo probablemente mejorará la experiencia del usuario y puede ayudar a mejorar el rendimiento percibido también. Busque las tareas largas de gran tamaño en sus perfiles de JavaScript e intente reducirlas, eliminarlas o retrasarlas.
Cómo hacer un seguimiento del rendimiento
Las herramientas de Google, como PageSpeed Insights, Lighthouse y web.dev, le proporcionarán una medición de Core Web Vitals de su web.
Sin embargo, los datos del «campo» tienen algunas limitaciones: los datos se recopilan únicamente de los usuarios de Google Chrome que han optado por la recopilación de estadísticas de uso anónimas, y se agregan mensualmente con una o dos semanas de retraso.
Si desea realizar un seguimiento más exhaustivo de las características vitales de la web, busque una solución de medición de usuarios reales como Akamai y mPulse.
Las herramientas RUM pueden recopilar datos de rendimiento de todos los navegadores que los soportan y proporcionarle información en tiempo real sobre el seguimiento de su rendimiento.
También puede detectar rápidamente problemas con páginas o dispositivos específicos, haciendo que los datos sean procesables.
Conclusión y acciones
La actualización propuesta de la experiencia de la página se producirá probablemente a mediados de 2021. Esto tendrá un impacto en la clasificación SEO, así como en los criterios de elegibilidad para las Top Stories en las SERPs de Google.
Google ha propuesto tres nuevas métricas de rendimiento que se utilizarán como señales para esta actualización de SEO, con una selección basada en su adyacencia al rendimiento percibido por el usuario y la capacidad de recopilar los datos sobre el terreno.
La optimización de estas métricas de rendimiento, medidas por Google en CRUX, podría tener un impacto positivo en la clasificación en el futuro, pero sin duda tendrá un impacto positivo en la experiencia del usuario.
Sabemos que las experiencias más rápidas conducen a una menor tasa de rebote, a una mayor duración de la sesión, a mejores puntuaciones de satisfacción, a un aumento de la conversión, a un incremento del tráfico SEO, a un aumento de los ingresos… Así que, ¿por qué esperar?