web core vitals

Web Core Vitals

«Destacando excelentes experiencias de usuario en la web móvil» –ACTUALIZACIÓN 17/08/2020

El 17 de agosto de 2020, desde el blog de Chromium, comunicaron que para su próxima versión de Chrome para Android v85, el navegador mostrará un mensaje de «Sitio web rápido» cuando dentro de una web, dejes pulsado de forma prolongada un enlace interno para intentar abrir esa página en una ventana nueva por ejemplo.

Captura de pantalla página Wikipedia
Captura de pantalla página Wikipedia

Esta solución se integra dentro del plan de Google de «mejorar internet» de acuerdo a su proyecto de métricas Web Core Vitals. Es decir, el enlace llevará ese aviso de «Fast Page» si ese enlace cumple con las tres métricas clave LCP, FID y CLS tanto en la actualidad como en histórico.

Fast Page links within a page
Imagen Blog de Chromium

Por ahora y hasta que se actualice a la versión 85, puedes probar ya esta nueva función incluyendo en el navegador de Chrome para Android la ruta https:chrome://flags , buscando la opción «Context menu performance hints» y seleccionando la opción «Enabled». Después de reiniciar el navegador y si haces la prueba navegando por la Wikipedia por ejemplo, podrás ver que efectivamente se muestra el mensaje.

Captura de pantalla versión de Chrome Android v84
Captura de pantalla versión de Chrome Android v84

He revisado si algún medio de comunicación importante lo tiene ya implementado y sólo he podido ver el caso de TheGuardian. Eso sí, sólo lo he visto mostrándose desde la versión web móvil de la noticia, no desde su versión AMP…

Captura de pantalla prueba con noticia de TheGuardian
Captura de pantalla prueba con noticia de TheGuardian

El pasado 5 de mayo de 2020, Google desde su blog de Chromium publicaba un post presentando Web Vitals como las métricas esenciales a tener en cuenta para tener un «buena salud» del sitio web. También publicó el pasado 28 de Mayo un post al respecto llamado «Evaluando la experiencia de página para una mejor web» donde viene a indicar esas nuevas métricas, el impacto de la experiencia de la página en el TOP Stories, etc.

La idea principal pasa por optimizar la experiencia de usuario como elemento clave. Junto a estos se viene hablando también de un cambio a la hora de medir en kpis el impacto SEO de nuestra web y va más enfocado a métricas de calidad (porcentaje de rebote, tiempo en página, páginas por sesión, etc.), más allá de la clásica métrica que mide volumen.

Con la presentación del Web Core Vitals se trata un poco de unificar criterios de medición de la experiencia de usuario y rendimiento.

Se combinan las señales de Core Web Vitals con las ya existentes señales de búsqueda como mobile-friendly, safe-browsing, HTTPS-security, y los intrusive interstitial. Google comunicó que las Web Core Vitals serán consideradas como un factor de ranking para 2021 (que avisarán 6 meses antes) y que se especula con que su fuerza no será muy significativa (comparado al nivel quizás de HTTPS 1-3%).

Señales de Experiencia de Usuario Web Core Vitals

Nuevas métricas

Versión de Chrome 83:

Versión de Chrome 84:

Fuente: «Introducing Web Vitals»

Métricas de experiencia de usuario medidas por:

  1. Largest Contentful Paint (LCP) – experiencia de carga – muestra la rapidez con que un usuario puede ver realmente el contenido principal una página. Un valor LCP por debajo de 2.5 segundos se considera ‘Bueno’.
  2. First Input Delay (FID) – interactividad – mide la capacidad de respuesta y cuantifica la experiencia que sienten los usuarios cuando intentan interactuar por primera vez con la página; por debajo de los 100ms se considera ‘Bueno’.
  3. Cumulative Layout Shift (CLS) – estabilidad – se trata de una métrica centrada en la experiencia de usuario, y que viene a medir cuánto cambia visualmente el contenido de una página. Una puntuación baja de CLS es una señal de que los usuarios no están experimentando cambios de contenido indebidos; por lo que un valor de CLS por debajo de 0,10 se considera ‘Bueno’.

Midiendo Core Web Vitals

El informe de UX de Chrome permite evaluar ese rendimiento tal y como lo experimentarían los usuarios de Chrome.

Lab. vs Field Data

Dos tipo de información, la simulada («Lab») y la real («Field»).

  • Lab Data (simulada): está basado en datos de rendimiento recogidos en un entorno controlado, simulando un tipo de dispositivo concreto y unas conexiones de red específicas. Se utilizan herramientas como Lighthouse o WebPageTest para recopilar esa información.
  • Field Data (real): está basado en las estadísticas recogidas por Google desde las herramientas del informe de UX de Chrome y Page Speed Insights, y es por tanto un indicador más real de cómo los usuarios navegan e interactúan con el sitio web. También se incluye la información que se muestra desde GSC en el apartado de «Core Web Vitals» y que recomiendan por ello prestarle mucha atención en su corrección.
Martin Splitt, explicación Lab Data vs Field Data

¿Por qué Lighthouse no ofrece datos de la métrica FID?

Porque FID requiere medir un usuario real, y Lighthouse es una herramienta de simulación (lab data).

En cualquier caso, y según la documentación de Google sobre la métrica FID , TBT (Total Blocking Time) es una métrica que guarda una gran correlación con FID y por tanto también captura la interactividad del usuario en la página. Mejoras en TBT también mejoran FID:

TBT correlates well with FID

Total Blocking Time (TBT) : mide la cantidad de tiempo total entre First Contentful Paint (FCP) y Time to Interactive (TTI). Es una métrica complementaria de TTI. Lo recomendable es tener un tiempo de bloqueo total de menos de 300 milisegundos.

SEJ: Google Explains Why Field Data is More Reliable Than Lab Data

Google: How To Think About Speed Tools

Herramientas de medición

Herramientas recomendadas para medir las métricas Web Core Vitals y en general de Perfomance: Lighthouse (v.84 Chrome) , Chrome DevTools , PageSpeed ​​Insights , Search Console’s Speed ​​Report y otras herramientas como la extensión de Chrome – «Web Vitals»

Módulo de Noticias Destacadas AMP – Web Core Vitals

As part of this update, we’ll also incorporate the page experience metrics into our ranking criteria for the Top Stories feature in Search on mobile, and remove the AMP requirement from Top Stories eligibility. Google continues to support AMP, and will continue to link to AMP pages when available. We’ve also updated our developer tools to help site owners optimize their page experience.

Evaluating page experience – Webmasters Google Blog

Google testará la página en la que el usuario va a acabar consumiendo, en este caso, si tienes AMP, y la mayor parte del tráfico móvil, será ésta página en AMP la que tendrá en cuenta los Web Core Vital para valorar la velocidad, calidad y usabilidad de la misma. Y será ésta página en AMP y no la versión móvil (de su canonical) la que se testará.

Por tanto, si tu sitio web está siendo rastreado por Googlebot para Smartphones, es indicativo que estás siendo considerado dentro del Mobile First Indexing. Es decir, que Google indexará la versión móvil, por tanto la versión AMP. Mostrarán la versión canonical de AMP para los resultados de Desktop.

ACTUALIZACIÓN 14/07/2020

Ya está disponible la actualización de Chrome a la versión 84, en ella, ya podrás ver en la parte de «Lighthouse 6.1» dentro de la consola de desarrolladores, las nuevas métricas.

Cómo hacer un informe de Chrome UX con Google Data Studio

Sobre el renderizado de Googlebot en cuanto a las métricas de WebCoreVitals contestado por Martin Splitt:

ACTUALIZACIÓN 07/08/2020

Interesante aplicación de las métricas en la consola de SISTRIX, bajo la ruta : Estructura -> Core Web Vitals.

Os comparto el artículo explicativo y cómo usarlo, aquí.