CORE WEB VITALS

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

mejorar 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

resultados metricas web

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

seo core web vitals

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?

Abrir chat