Core Web Vitals: cómo prepararse para la actualización Page Experience de Google

Las Core Web Vitals son las nuevas métricas que Google va a tomar en cuenta para medir la experiencia del usuario cuando se carga una página. Sigue leyendo para descubrir todo lo que necesitas saber sobre las Core Web Vitals, incluidos consejos de optimización y ejemplos.

CORE WEB VITALS

Estas 3 métricas señalan diferentes momentos específicos durante el proceso de carga de una página. Las Core Web Vitals se agregarán al factor de posicionamiento que Google ha llamado «Page Experience» o Experiencia de Página. La actualización del algoritmo se producirá en mayo de 2021.

Podemos ayudarte con tu estrategia de SEO y marketing de contenidos: ponte en contacto con uno de nuestros expertos para ver cómo podemos ayudarte.

 

¿Qué son las Core Web Vitals?

Las Core Web Vitals son 3 métricas que califican la experiencia de un usuario al cargar una página web.

Estas métricas puntúan la velocidad de carga, qué tan rápido un navegador que carga una página web puede responder a la interacción de un usuario, y qué tan inestable es el contenido cuando se carga en el navegador.

Estas tres métricas se agruparán junto con otros indicadores que Google ya tenía en cuenta:

  • La compatibilidad con dispositivos móviles.
  • La navegación segura, HTTPS.
  • Los intersticiales intrusivos en una señal que Google llama «señal de experiencia de página».

Las 3 métricas de las Core Web Vitals

A principios de mayo de 2020, Google anunció el próximo lanzamiento de sus nuevas Core Web Vitals, 3 indicadores clave que añadirán para clasificar la experiencia del usuario en las webs.

Cuando se lance la actualización de Google en mayo de 2021, incluirán estos 3 indicadores que, en combinación con otras variables que ya influyen, constituirán un nuevo factor de posicionamiento para una experiencia de usuario estable y segura.

Antes, para medir la experiencia de página, Google usaba aspectos como si ésta era «mobile friendly» y, como ya hemos dicho, otras variables que ya influyen (están en color gris en la siguiente imagen). Ahora, para medir la experiencia en la página, van añadir las Core Web Vitals:

core web vitals experiencia de usuario

Las Core Web Vitals se basan en la carga y experiencia de usuarios reales. Son métricas de campo y de laboratorio salvo el FID que no se puede emular con ninguna herramienta y es una métrica exclusiva de campo pues depende del tipo y velocidad de conexión además del dispositivo que tenga el usuario.

las core web vitals de google

Las Core Web Vitals se miden con datos que Google proporciona en varios informes y herramientas, incluidos Lighthouse, Page Speed ​​Insights y Google Developer Tools. Las Core Web Vitals se componen de tres métricas que incluyen:

  • LCP: Largest Contentful Paint, algo así como el «Pintado de Contenido más grande».
  • FID: First Input Delay, algo así como el «Retardo en la primera interacción».
  • CLS: Cumulative Layout Shift, algo así como el tiempo que tarda en estabilizarse el diseño.

Con el tiempo, las Core Web Vitals se adaptarán a los últimos desarrollos técnicos y cambios en el comportamiento del usuario. En relación a esto, Google volverá a evaluar Core Web Vitals cada año. Esto significa que las métricas principales también pueden cambiar.

Este enfoque basado en evaluar estas tres métricas conlleva una serie de beneficios. Google puede analizar las webs sobre unos KPIs que ha comunicado claramente. Esto les da a los webmasters, desarrolladores web y SEOs una base sólida a la hora de argumentar sus trabajos y presupuestos específicos con los clientes.

LCP: Qué tan rápido empieza a mostrar una web la mayoría de elementos que se ubican en el «above the fold».

 

pintado del contenido mas grande

El «Pintado de Contenido más grande» (LCP) mide el tiempo que transcurre hasta que se carga el elemento de contenido más grande de una página. Pueden ser imágenes, bloques de texto o elementos con una imagen de fondo. Según Google, el 90 % de los casos es una imagen.

Para esta métrica LCP, los tiempos de carga de hasta 2,5 segundos son buenos, cualquier valor entre 2,5 y 4 segundos necesita mejoras, y cualquier valor inferior a 4 segundos es malo.

El LCP de una página se determina en función del estado de carga de la página, ya que, en la mayoría de los casos, el elemento más grande se carga al final. Es una métrica de campo pero que también se puede emular en laboratorio.

Aviso importante
Como ya dijimos en este artículo, Google ha anunciado que las Core Web Vitals solo va a influir en el posicionamiento de las búsquedas móviles.

Incluso en el inspeccionador de elementos de Chome hay un apartado denominado «Lighthouse« que es la herramienta creada por Google para medir estas métricas y por defecto ya está marcada la opción «Mobile» a la hora de hacer una prueba.

inspeccionador elementos ligjthouse

Ejemplo visual de lo que es el LCP

La mejor herramienta para entender visualmente lo que es el LCP es GTMetrix. Visualmente te lo muestra en la versión escritorio pero ahora vais a ver un ejemplo visual de lo que pasa cuando tarda en cargarse el LCP.

Analizamos una página y mira lo que pasa:

que es lcp

En 0,7 segundos nos muestra el primer pintado: se empiezan a ver los primeros elementos de la web. Sin embargo, hasta que no llegamos a los 3,5 segundos, lo que se ve en el «above de fold» (el primer pantallazo que vemos de una web sin necesidad de hacer scroll) no queda cargado completamente.

Google ha hecho todo lo posible para que la documentación de cada Core Web Vitals sea lo más detallada y clara posible. Se puede encontrar más información y la base exacta de los cálculos en la Documentación de Google sobre Largest Contentful Paint (LCP).

Optimización para el LCP

– El servidor responde demasiado lento:

Cuanto más tiempo necesite el navegador para recibir contenido del servidor, más tardará la página en cargarse para el usuario. Puede ser útil establecer una red de entrega de contenido (CDN) para permitir que las solicitudes se envíen desde el servidor más cercano al usuario.

– Bloqueo de renderizado de JavaScript y CSS: 

Antes de que el navegador pueda realmente renderizar elementos de contenido, es decir, visualizarlos para el usuario, el marcado HTML debe analizarse en lo que se denomina Modelo de objetos de documento (DOM).

El problema aquí, sin embargo, es que el analizador HTML se detiene cada vez que se cargan hojas de estilo CSS o recursos JavaScript. Para eliminar este problema, Google recomienda minimizar los archivos CSS o JavaScript, diferir los estilos o JS que no son críticos e incorporar atributos CSS críticos.

– Los recursos se cargan con demasiada lentitud:

Las imágenes, los vídeos o los bloques de contenido a menudo pueden hacer que los recursos se carguen con demasiada lentitud.

Aquí, Google recomienda reducir las imágenes al tamaño necesario, por ejemplo, utilizando formatos de archivo más nuevos que tengan una compresión de imagen superior, como JPEG 2000, JPEG XR o WebP.

 Otro enfoque sería precargar los recursos principales y comprimir archivos HTML, CSS o JavaScript mediante Gzip. 

– Otros consejos de optimización:

Google tiene un artículo en el cual ofrece una serie de consejos para mejorar la carga del LCP.

FID: ¿Cuándo puede el usuario interactuar con una página?

retraso primera interaccion

El retraso en la primera interacción (FID) mide el tiempo desde que un usuario interactúa por primera vez con un sitio hasta el punto en el que el navegador puede responder a esa interacción.

Por ejemplo, los usuarios van a una web e inmediatamente hacen clic en el texto o en un botón sin esperar a que primero la página se cargue por completo. Es frecuente que no suceda nada porque el navegador está ocupado cargando la página.

La métrica FID mide el retraso que ocurre entre la entrada del usuario y la respuesta del navegador. Según Google, cualquier valor inferior a 100 milisegundos es bueno, cualquier valor entre 100 y 300 milisegundos necesita mejoras, mientras que los valores de FID superiores a 300 milisegundos se consideran pobres.

Optimización del FID

Los detalles sobre el FID se pueden encontrar en la documentación de Google sobre esta métrica.

– División de tareas largas:

El retraso a menudo se debe a la ejecución de JavaScript, lo que significa que es posible que los usuarios no puedan interactuar con la web. Dividir las tareas puede ayudar con esto. Para Google, las tareas largas son aquellas en las que un fragmento de código bloquea el hilo principal durante más de 50 milisegundos.

– Priorizar la interactividad:

En otras palabras, dar prioridad al código que es esencial para la interactividad del sitio.

– Reducir los tiempos de ejecución de JavaScript:

Todos los archivos JavaScript que se ejecutan cuando se carga una web, deben ser analizados con el fin de diferir los que no son esenciales.

– Otros consejos de optimización: 

Google tiene un artículo en el cual ofrece una serie de consejos para mejorar la carga del FID.

CLS: la estabilidad visual en una web.

 

estabilidad visual web

El CLS se refiere a la estabilidad visual durante la interactividad en una web. Cuando se carga una web, algunos elementos pueden aparecer primero en la pantalla pero cuando se carga un elemento que tarda demasiado, empuja a los otros elementos hacia abajo en la página.

Cuando se cargan los primeros elementos, el usuario ya puede empezar a interactuar con ellos, pero de repente, el elemento que tarda más en cargarse aparece en la pantalla y el usuario hace un clic no deseado en ese elemento final.

Podemos ver un ejemplo en en el siguiente vídeo. El usuario ha seleccionado 56 productos que evidentemente no quiere comprar y cuando va a cancelar la orden, se carga un elemento final que hace que el botón de cancelar baje y haga clic sobre el botón de confirmar la orden:

Otro ejemplo puede darse cuando el usuario quiere hacer clic en descargar un recurso y de repente se carga un banner de Adsense y el usuario acaba haciendo clic en la publicidad. Esto es malo para Google y puede que haya pensado esta métrica para no perjudicar su negocio de publicidad.

En otras palabras, el CLS muestra si se producen cambios de diseño inesperados mientras el usuario interactúa con la web. Cuanto menor sea esta métrica, mejor.

Para Google, cualquier valor por debajo de 0,1 es bueno y cualquier valor superior a 0,25 es malo. Cualquier cosa intermedia necesita mejorar. Los detalles sobre el CLS se pueden encontrar en la documentación de Google sobre esta métrica.

Optimización del CLS

– Especifica el tamaño de las imágenes y los elementos de vídeo:

Especificar el tamaño exacto (An x Al) de las imágenes y los vídeos asegurará que no haya sorpresas desagradables para los usuarios. Alternativamente, el espacio necesario para estos elementos también se puede definir usando la relación de aspecto con CSS.

De esta manera, el navegador mantendrá libre el espacio exacto necesario para la imagen o vídeo mientras se carga.

Así se vería la carga de una página con CLS optimizado:

imagen cls optimizado
Captura de imagen extraída de la ponencia de Víctor Recio, SEO de Vodafone España, para el evento de ClickSEO.

En este ejemplo de CLS optimizado podemos ver cómo se ha definido una relación de aspecto al CSS para las imágenes y cómo el navegador reserva ya un espacio para la carga de la imagen grande.

– Anuncios sin datos de altura / ancho: 

Según Google, los anuncios son una de las razones más comunes que provocan esos cambios repentinos de diseño en las webs. Esto se debe a que las redes publicitarias, incluido Google Adsense, a menudo utilizan formatos de anuncios dinámicos.

Los elementos de marcador de posición pueden serte útiles: los datos históricos te permitirán seleccionar el tamaño más probable para un determinado espacio publicitario.

– Otros consejos de optimización: 

En este artículo, el propio Google proporciona varios consejos sobre cómo reducir o prevenir el CLS.

Estudio de caso: la página de inicio de la web de moda Chloé optimiza para Core Web Vitals

El siguiente vídeo muestra un caso de estudio de la página de inicio de la web de Chloé y describe cómo la empresa logró optimizar las Core Web Vitals para su página de inicio, llevándola al nivel «verde» en las listas de Google.

Por ejemplo, la métrica de LCP se redujo de 2,9 a 1,5 segundos, por ejemplo, optimizando los CSS de ruta crítica o mediante la compresión de imágenes. El gerente de ingeniería de Google, Addy Osmani,  explica los elementos fundamentales de esta optimización:

¿Dónde puedo acceder al informe Core Web Vitals?

Ya hemos visto que puedes utilizar la propia consola de Google Chrome o GTMetrix para obtener las métricas de las Core Web Vitals PERO… ¿cómo sé las métricas oficiales de las CWV referentes a las páginas de mi web? Es decir ¿dónde puedo ver las métricas que le han dado a Google en las Core Web Vitals?

Muy fácil, en Search Console tienes un apartado en la página principal, al final de todo, donde dice «Mejoras» – «Métricas Web Principales» y tienes un enlace que pone «Abrir informe». Te muestra dos informes: uno para móviles y otro para ordenadores. Google no tiene los mismos valores para móvil que para escritorio.

Si abres el informe de «Móviles», en el que te deberías centrar, verás el número de urls pobres, rápidas y aquellas que necesitan una mejora. Más abajo hay un apartado de «Detalles» en el cuál te mostrará la métrica que está dando problemas en las urls pobres. Si haces clic, te mostrará un ejemplo de url:

informe LCP google

Conclusiones

Las Core Web Vitals de Google se convertirán en las métricas centrales para medir la experiencia del usuario. Se lanzarán inicialmente con tres métricas principales para la carga:

  • LCP,  pintado del elemento más grande.
  • FID, interactividad del sitio.
  • CLS estabilidad visual.

Además, las Core Web Vitals se fusionarán con factores de posicionamiento que ya existen, como la compatibilidad con dispositivos móviles o tener el protocolo HTTPS. Todo ello para crear un factor de posicionamiento completamente nuevo: ¡la experiencia de página!

Para una mayor transparencia en las Core Web Vitals, Google ha hecho todo lo posible y ha publicado documentación detallada que brinda a los webmasters, desarrolladores y SEOs toda la información que necesitan para comprender completamente cómo se establecen los criterios individuales.

Si aún no lo has hecho, te recomendamos que utilices el inspeccionador de elementos de Chrome o la herramienta GTMetrix  para ejecutar una verificación adecuada en tus propios proyectos web y ver cómo se están desempeñando con las Core Web Vitals. La mayoría de las web tienen margen de mejora.

Si quieres optimizar tu web para que esté dentro de los valores recomendados en las Core Web Vitals, puedes contactar con nosotros.

Contactar
Resumen
Core Web Vitals: prepararse para la actualización Page Experience
Título del artículo
Core Web Vitals: prepararse para la actualización Page Experience
Descripción
Te mostramos qué son las Core Web Vitals, cómo puedes medirlas, dónde se encuentran en Search Console y qué puedes hacer para optimizarlas.
Autor
Agencia
Adrenalina
Logo

2 comentarios en “Core Web Vitals: cómo prepararse para la actualización Page Experience de Google”

  1. Muy buen artículo. Me ha gustado mucho el detalle de las explicaciones y los gráficos.
    Gracias y enhorabuena.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *