Core Web Vitals 2021: qué son y cómo preparase en SEO

El pasado 10 de Noviembre de 2020 Google publicó un post llamado «Plazos para incluir la experiencia en la página en la Búsqueda de Google» donde actualizó la información que comentaba el 5 de mayo de 2020 desde su blog de Chromium y después el 28 de Mayo de 2020 donde presentaban las conocidas como Core Web Vitals, las métricas esenciales a tener en cuenta para tener una «buena salud» del sitio web.

05/10/2021CÓMO MEJORAR LCP

LCP es la métrica que mide la rapidez con la que se carga el contenido principal de una página y se muestra (o pinta). En este video, Google ofrece toda la información al detalle sobre esta métrica CWV y sobre todo acciones para ayudar a optimizarla.

21/09/2021CÓMO MEJORAR FID

FID es una de las tres métricas que conforman las Core Web Vitals y lo que mide en concreto, es el tiempo que tarda el navegador en responder a una interacción del usuario en la página. En este vídeo de Google ofrece podrás ver más información sobre cómo mejorarla.

10/08/2021CONSEJOS PARA VALIDAR SI TUS PÁGINAS CUMPLEN CON UNA BUENA EXPERIENCIA

Google compartió en su canal de Youtube (bajo la playlist de «Getting Started with Page Experience» un vídeo explicativo con algunos consejos básicos para validar el cumplimiento de tus páginas en el nuevo factor de posicionamiento llamado «Experiencia de Página». El vídeo se centra exclusivamente en la parte de los factores de «Experiencia de Página» que tienen que ver con: HTTPS, Mobile-Friendly e Insterstitials; la otra parte es Core Web Vitals.

Habla de cómo validar nuestras páginas para cumplir con esos factores de ranking que hablamos anteriormente. De forma que:

  • HTTPS: su validación es booleana, es decir, está en https la página, o no. No hay más interpretaciones. Además, insiste en unificar las señales de la página hacia su versión securizada indicándosela desde la etiqueta rel canonical. Asegúrate de redireccionar con 301 tu versión no segura.
  • Mobile Friendly: asegúrate que el contenido mostrado en tus páginas está disponible y adaptado a todos los dispositivos en los que el usuario aterriza para verlo (que el texto no sea demasiado pequeño, los enlaces cuesten clicarse, etc). Se recomienda el diseño responsive ya que el coste de mantenimiento está centrado en una única versión de url, y no en varias como m.dominio.com o dominio.com/m , etc. Algunas meta etiquetas en el código como meta viewport ayudan al navegador a entender las dimensiones del contenido de la página y reescalar. Puedes validar si tu página cumple con Mobile-Friendly test desde la propia tool de Google.
  • Anuncios Intersticiales: no existe una herramienta específica (y estable) para validar que el aterrizaje que se produce del usuario desde Google a la página destino no esté interrumpida (al menos durante los primeros 5s) por un anuncio en formato pop-up por ejemplo que bloquee el consumo o lectura del contenido destino sin perjudicar la experiencia de usuario.
  • Validando páginas AMP: si dispones de un formato de página adicional exclusiva para móviles (por ahora) como es AMP, se recomienda pasar esa url por el validador de «AMP Pape Experience» y comprobar cuáles son las recomendaciones a nivel técnico disponible para mejorar CWV y la experiencia de página en global, pese a que este framework se encuentra de base ya bastante optimizado…

04/08/2021«SAFE BROWSING» fuera del Page Experience

El pasado 4 de agosto Google comunicó en su blog que el informe de «Experiencia en la página» quedaría simplificado al no tener en cuenta el factor de Safe Browsing (que no HTTPS). La justificación viene a decir que, teniendo en cuenta que los propietarios de los sitios no siempre pueden controlar ataques de hackers que ponen en compromiso la navegación segura del usuario, tiene sentido no incluir esa parte dentro del informe de «Experiencia en la página». Aunque si Google detecta que la navegación no es segura en tu sitio, se te notificará en Search Console dentro del apartado «Seguridad y acciones manuales«.

Aviso incluido en su página sobre Page Experience – enlace

Otro recordatorio importante es el de «Experiencia de anuncios», y es que de acuerdo con Google:

También hemos quitado el widget de experiencia de anuncio para no mostrar la misma información en dos secciones distintas de Search Console. Seguirás teniendo disponible la herramienta independiente de experiencia de anuncios para consultar el estado de tu sitio e identificar las experiencias de anuncio que infringen los estándares Better Ads. Para que quede claro: nunca se ha tenido en cuenta la experiencia de anuncio a la hora de evaluar la experiencia en las páginas de un sitio, por lo que este cambio no afectará a tu sitio en ese sentido.

15/06/2021PAGE EXPERIENCE RANKING FACTOR ROLLOUT

Llegó el día, tal y como lo había anunciado Google después del retraso de Mayo, ha sido justo a mediados de Junio (15) y finalizó en Septiembre (2) cuando finalmente la nueva señal de experiencia de página entra en el algoritmo para evaluar las página que, por una lado ofrecen resultados CWV óptimos, y por otro se les suma los factores que ya venía aplicando (https, mobile friendly, safe browsing e intersticials).

Actualizaciones con esta nueva señal:

Esta nueva señal justo se enlaza casi con el final del despliegue del core update de Junio (finalizó el 12) y que se completó en Julio con otra parte del core update que comenzó el 1 de julio (y acabó el 12 de julio). Recordemos que del último core update de Diciembre 20 a este han pasado 6 meses, algo poco habitual entre core y core.

10/06/2021FID «no data» en PSI field data

El pasado mes de junio de 2021, Rick Viscomi (desarrollador de Google en CWV) confirmó en twitter un comportamiento en la métrica FID que tendría su impacto en PSI.

En concreto, habla de que, a la hora de reportar PSI los datos de field data, es posible que algunas urls no muestren ningún dato en FID porque por ejemplo, al analizarse según el comportamiento del usuario a la hora de interactuar con la página, es posible que no haya ninguna acción requerida al navegador como clic en enlace, etc porque quizás el usuario simplemente a hecho scroll y ha salido. En ese caso, FID no reportaría ningún dato.

Por tanto, en esos casos en los que FID no resuelva ningún tiempo en ms, lo que se hará para calcular el CWV de la página, es tener en cuenta sólo las otras dos métricas de CWV, en concreto LCP y CLS. Si FID tuviera dato, tendría que ser con un buen valor para que entre los tres tengan una valoración de buena.

19/05/2021Novedades de Google I/O 2021Enlace SEOsly recopilatorio

CWV comenzará a tenerse en cuenta también en Escritorio después de la salida inicial en Junio (no sólo en Móvil como de inicio). Vídeo

17/05/2021 – EN QUÉ CONSISTE PAGE EXPERIENCE

En la serie de vídeos explicativos sobre la nueva señal Page Experience, Google, en su canal de Youtube «Google Search Central», sube diferentes vídeos al respecto para aclarar algunas de las muchas dudas que tienen los webmasters.

En concreto una que me parece muy interesante es si la aplicación de esta señal es de SÍ o NO, es decir, ¿sólo páginas con «buena experiencia» pueden conseguir el boost o hay algún tipo de grado en cómo la señal de experiencia de página afecta en ranking?. Google apunta que tener una muy buena puntuación de CWV frente a otra página que no, no es garantía de posicionar mejor, entre otras cosas porque se sigue teniendo en cuenta la relevancia del contenido como un factor muy fuerte en el ranking (ver esta parte del vídeo concreta).

Por otro lado, apuntar que, la experiencia de página además combina otras señales, que en este caso sí son de check o no, como si tu sitio tiene HTTPS, es mobile friendly, lleva anuncios intersticiales y la navegación es segura (vídeo de abajo).

19/04/2021 – NOVEDADES «EXPERIENCIA DE PÁGINA» – CWVEnlace

Se añaden nuevas opciones en Google Search Console

  • «Experiencia» – donde se unifica todo lo relacionado con la señal de Experiencia de Página, es decir, los apartados de: Core Web Vitals (Métricas web principales»), Usabilidad móvil y «Experiencia en la página». Ésta última muestra estadísticas sobre el volumen de impresiones que las urls consideradas como «buenas» han tenido y el porcentaje que representan.
  • Tráfico que empiezan a generar las páginas consideradas como «buenas» desde Rendimiento -> Apariencia en el buscador -> «Buena experiencia en la página».

¿Cuáles son los criterios por los que Google considera un URL como buena en el estado de experiencia en la página de Búsqueda?

Criterios de estado – Fuente Ayuda de Search Console

13/04/2021CLS afina su cálculo en Chrome

Desde la página de desarrolladores WebDev se publica una actualización a la hora de medir y calcular la puntuación de la métrica CLS. En este artículo hace oficial su aplicación desde el 02/06/2021 y entra en vigor para las herramientas de Google: Lighthouse, PSI y CrUX. *También se ha hecho a partir del 01 de junio la actualización del CLS dentro de la herramienta Search Console – métricas web principales. En cualquier caso, empezó a tener efecto desde mediados de abril, aunque con la nueva señal se ha ido aplicando de forma estable en las diferentes tools.

En concreto se refieren a lo que llaman «Window» donde se producen cambios de layout, y al tiempo o gap que pasa entre una ventana y otra …teniendo en cuenta así a las páginas que ofrecían por ejemplo un tiempo de carga largo, scroll infinito o SPA.​ De tal forma que se reporta el mayor valor de CLS que se produce en esas ventanas.

Cada ventana es un periodo de tiempo que tiene una duración máxima de 5s. Cada cambio de layout dentro de la window se produce en un periodo de tiempo <1s.​ En la herramienta de WebPageTest.org ya es posible ver esa diferenciación visual en el filmstrip del renderizadao de la página y analizar las distintas ventanas de layout así como el impacto en el CLS que tiene cada cambio. Así lo explican en su entrada del blog.

Análisis de la web Gardeners.com

En ningún caso se verá una peor puntuación del CLS en GSC, en todo caso mejores puntuaciones de «urls buenas». (Fuente: Data anomalies in Seach Console).

31/03/2021 – Core Web Vitals & Page Experience FAQs

Google ha actualizado la página de FAQs relacionada con las CWV y la Experiencia de Página (la anterior es de Dic2020):

  • Si hay varias páginas de calidad y contenido similares, las que tengan una mejor experiencia en la página podrían tener un mejor rendimiento que las que no las tienen.
  • Si bien todos los componentes de la experiencia de la página son importantes, daremos prioridad a las páginas con la mejor información en general, incluso si algunos aspectos de la experiencia de la página son insatisfactorios.
  • AMP no es un factor de posicionamiento (aunque si bien es cierto que su framework aporta muchos beneficios en cuanto a rendimiento). Más información sobre la optimización de las páginas AMP para CWV aquí.
  • Además, coincidiendo con la salida de esta nueva señal de posicionamiento «Experiencia de Página», Google anunció que las páginas No-AMP entrarán a competir en el módulo de Noticias Destacadas en Móvil con páginas AMP siempre y cuando cumplan con las señales de experiencia de página (ver enlace).
  • La aplicación de las CWV sólo será en dispositivos móviles, al meno de inicio. Por tanto, los resultados desktop no sufrirán cambios por ello.

Por tanto, se recomienda al menos para sites ya establecidos y no nuevos, que, se centre en las funcionalidades de la web a nivel usuario y el contenido, antes que en la velocidad. Ya que puedes tener una página muy rápida pero poco útil para el usuario y por tanto posicionar peor que la competencia, que pese a servir una página más lenta, sí que responde mejor a la intención de búsqueda del usuario. Enlace Vídeo.

17/02/2021Nuevos límites de puntuación para las métricas LCP, CLS y FID

El pasado 17 de febrero de 2021 Google anunció en su registro de incidencias en Search Console «Data anomalies» en la parte de Core Web Vitals que, la forma en la que agrupar las puntuaciones de las tres métricas, se actualiza, dando un poco de «manga ancha» a los sitios web.

La forma en la que actualiza los criterios de puntuación es que, en lugar de que los valores a cumplir sean «menores que» en las urls válidas y necesitan mejorar, pasen a ser «menores o iguales que». De esta manera las gráficas en Search Console asociadas a estas métricas en éstas páginas verán seguramente reflejados mejores datos.

Fuente: SearchEngineLand

10/02/2021 – ¿Qué tan útil es tu sitio web?

Quizás por error (sin una comunicación previa), se indexó esta página de Google donde avanzaban la opción de añadir un nuevo apartado en Search Console específicamente enfocado en la Experiencia de Página.

En este nuevo informe se unifican los apartados de Usabilidad Móvil, Métricas Web Principales (CWV), HTTPS (o avisos de contenido mixto), Problemas de seguridad y Experiencia publicitaria. La mayoría de ellas incluidas ya en Search Console (nueva versión) salvo HTTPS.

En concreto, Google lo desglosa y especifica en:

Usabilidad móvil: si la página se ve y funciona bien en un dispositivo móvil. Más del 50% de todas las búsquedas se realizan en un dispositivo móvil. Haga clic en la evaluación de usabilidad móvil de su sitio para abrir el informe de usabilidad móvil, que proporciona detalles sobre qué páginas tienen problemas de usabilidad móvil.

Core Web Vitals: la velocidad y la estabilidad visual de una página durante la carga de la página. Las páginas deben cargarse rápidamente y estar disponibles para las interacciones, y no deben saltar visualmente a medida que se cargan las partes más lentas de la página. Haga clic en su evaluación de Core Web Values ​​para abrir el informe Core Web Values, que proporciona detalles sobre cualquier problema en su sitio.

Uso de HTTPS:  si la mayoría de su sitio utiliza HTTPS, en lugar de HTTP. HTTPS proporciona una experiencia de usuario mucho más segura que HTTP, por lo que solo las páginas que usan HTTPS se consideran elegibles para la acreditación de buena experiencia de página.

Los problemas de seguridad en un sitio pueden causar una experiencia mala o incluso dañina. Si su sitio ha sido pirateado para mostrar spam o distribuir descargas dañinas, o tiene malas prácticas como facturación poco clara, esto puede descalificar sus páginas para que no se consideren una buena experiencia. Informe «Problemas de Seguridad».

Experiencia publicitaria: las páginas web con ventanas emergentes que roban el foco y otros comportamientos publicitarios que distraen son una mala experiencia para el usuario. Aunque aún no se muestra en el informe de experiencia de página, puede visitar el informe vinculado para ver la evaluación de su sitio. Informe de experiencia de anuncio (antigua versión de Search Console)..

El informe Page Experience muestra sus métricas de usabilidad móvil y Core Web Vitals, y puede mostrar el número aproximado de páginas que se considera que tienen una buena experiencia de página. Se considera que las páginas que superan todas las métricas tienen una buena experiencia de usuario en dispositivos móviles y pueden obtener una insignia, y en el futuro serán elegibles para un aumento de clasificación en los resultados de búsqueda móvil.

Página Support Google – Archivado en WaybachMachine

ACTUALIZACIÓN 19/04/2021 – Efectivamente, Google acabó publicando esta unificación de señales enfocadas en la Experiencia de Página tal y como se filtró en febrero 2021. En realidad la url que recoge esa información a fecha de hoy es la de Informe «Experiencia en la página» en GSC.


Señales de Experiencia de Usuario Core Web Vitals

Core Web Vitals Metrics

Nuevas métricas de experiencia de usuario:

  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 o igual a 2.5 segundos se considera ‘Bueno’. Algunas de las soluciones pasan por: probar nuevas tecnologías de renderizado de la página como por ejemplo el uso de SSR; optimización de imágenes de nueva generación (WebP) y compresión de las mimas; precarga de imágenes preload; aplicar LazyLoad en imágenes que no son LCP, etc. Caso de ejemplo visto por Takopedia&Vodafone
  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 o igual a los 100ms se considera ‘Bueno’. mide la capacidad de respuesta de tu página cuando tienes un usuario real que interactúa con ella. Esta métrica ocurre cuando el usuario está intentando por ejemplo interactuar con el menú, pero el hilo principal (main thread) de la página está bloqueado por el JavaScript que se ejecuta en la página, por lo que el navegador tiene que esperar hasta que todo el JavaScript esté finalizado. Eso hace que el menú tarde mucho en abrirse. Como alternativa de medición en herramientas de laboratorio o entorno simulado, estaría Total Blocking Time (TBT) que mediría la cantidad total de tiempo que transcurre entre el primer pintado del contenido en la página (FCP) y el tiempo en el que el usuario puede interactuar con la página (TTI).​ Cuando una tarea tarda más de 50ms, TBT es malo y si tarda <50ms, estará ok.​ Total Blocking Time (TBT): que viene a sustituir a la métrica FID en Lighthouse como métrica de laboratorio y que se explica más abajo.
  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 o igual a 0,10 se considera ‘Bueno’. Si realizas una auditoría con PSI verás que ésta métrica difiere según si el resultado procede de lab data o field data. Y es que: en lab data (Lighthouse) el análisis de la ventana CLS termina cuando la página completa su carga bajo esas condiciones simuladas, mientras que en field data (PSI) la ventana de observación de CLS se extiende a toda la carga completa de la página incluyendo la actividad post carga. Sin embargo con el nuevo ajuste de Junio, sto queda resuelto por ejemplo para páginas con scroll infinito, etc. – Enlace

Y es que éstas tres métricas no tiene el mismo peso sobre el total de las métricas de rendimiento en Lighthouse. Esto se puede ver claramente en la calculadora de peso de Core Web Vitals y que constantemente los ingenieros actualizan en el % de peso para ajustarse a las necesidades del usuario.

Así por ejemplo, se ha publicado recientemente que la versión 8 de Lighthouse aplica desde la versión de Chrome 93, llega con algunas actualizaciones, entre la que destaca el cambio de peso que se les otorga a las diferentes métricas de rendimiento, quedando de la siguiente forma: CLS aumentaría su peso x3, otras métricas como FCP, SI o TTI (bajan un 5%), TBT (FID) sube un 5% y LCP se mantiene en un 25%.

Métricas No Core Web Vitals (por ahora)

Como se muestra en la imagen superior a la hora de calcular los valores en Lighthouse, es importante tener en cuenta el papel que juegan otras métricas de rendimiento como:

  • First Contentful Paint (FCP): mide la velocidad de carga percibida por el usuario, ya que marca el primer elemento que se carga y visualiza en el renderizado de la página y que el usuario puede ver. Para esta métrica, «contenido» se refiere a texto, imágenes (incluidas imágenes de fondo) «svg» logo, elementos o elementos que no son blancos «canvas». Se puede medir tanto en laboratorio como campo. Más información.
  • Speed Index (SI): mide la rapidez con la que se muestra visualmente el contenido durante la carga de la página.
  • Time to Interactive (TTI): mide el tiempo desde que la página comienza a cargarse hasta que se cargan sus principales recursos secundarios y es capaz de responder a la interacción del usuario. Se trata de una métrica de laboratorio.
Addy Osmani Tweet

Midiendo Core Web Vitals

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

Diferencias entre información «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. Ésta información es la que utilizan herramientas como Lighthouse o WebPageTest.
Martin Splitt, explicación Lab Data vs Field Data
ContentKing-CoreWebVitals

¿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), por tanto si usas Lighthouse en tus validaciones CWV, la métrica que según la documentación de Google, mejor sustituye a la métrica FID es TBT (Total Blocking Time).

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

Debuggeando CLS

Cuando se analiza con PSI una url existe una diferencia entre la información por ejemplo que se ofrece para CLS entre field y lab data. Esta diferencia puede ocurrir cuando la página tiene mucho contenido interactivo que no está siendo usado cuando se testea por ejemplo en Lighthouse sobre un entorno simulado.​

La idea es detectar el elemento que más impacto tiene en layout sobre el resto de elementos.​ Más información.

Otras herramientas para medir el rendimiento de tus páginas

Core Web Vitals Tools Free Online
Core Web Vitals Tools

El futuro de las Core Web Vitals

Fuente: ContentKing


Optimizing Web Vitals using Lighthouse (Web.Dev)