Core Web Vitals: ¿Qué son y cómo mejorar el nuevo factor SEO?

  • 27 julio, 2020
  • SEO

Llegas a una página web y te cuesta encontrar la información sobre el envío. Los colores son tan chillones y hay tantas fotos que el contenido principal pasa desapercibido. La página tarda tanto en cargar que terminas cerrando y haciendo clic en el siguiente resultado. Se carga un anuncio y acabas haciendo clic en otro sitio. Todos estos factores están relacionados con una buena experiencia de usuario, resultan claves para el éxito a largo plazo de un sitio web y son métricas que formarán parte del algoritmo de Google en 2021. En esta dirección, el buscador está impulsando el proyecto Web Vitals, cuyo objetivo es mejorar la experiencia de usuario de tu web y ayudarte a identificar todas las oportunidades de mejora.

A lo largo de los años, Google ha proporcionado e impulsado una serie de herramientas para medir e informar sobre el rendimiento web. El famoso test PageSpeed, el sitio thinkwithgoogle y, más recientemente, Google Lighthouse, una herramienta de código abierto para medir la velocidad y calidad de las páginas web. Lighthouse se ha convertido para los SEOs en una herramienta fundamental, aunque por su complejidad y resultados de algunos análisis no siempre resulta lo útil que debería. Por poner un ejemplo, la herramienta te dice que tienes código de terceros que ralentizan la web, pero resulta que ese “tercero” es el propio Google con las diferentes llamadas a sus productos. Otras métricas como FCP (First Contentful Paint) se han quedado obsoletas.

En esta imagen podemos ver la diferencia entre FCP y LCP

Core Web Vitals

Core Web Vitals (CWV) son un subconjunto de Web Vitals que se encuentran en todas las páginas web y que pueden y deben ser medidos por los webmasters con la ayuda de las herramientas principales que Google y otros partners ponen a nuestra disposición. Estas son las herramientas más conocidas y usadas que incorporan en su core los datos de CWV:

  • Search Console: La pestaña Métricas web principales que ha sido actualizada además hace poco tiempo.
  • PageSpeed Insights
  • Chrome UV Report
  • Chrome DevTools
  • Lighthouse
  • Web Vitals Extension
  • WebPageTest

Core Web Vitals formarán parte del algoritmo de Google en 2021

Las métricas que componen Core Web Vitals evolucionarán con el tiempo. Para los SEOs y otros responsables web es importante saber que Core Web Vitals entrarán a formar parte del algoritmo de Google en 2021.

Cada una de las patas de CWV representa una faceta distinta de la experiencia del usuario y es medible de forma individual. De momento, Core Web Vitals se centra en tres aspectos de experiencia del usuario -carga, interactividad y estabilidad visual- e incluye las siguientes métricas (y sus respectivos umbrales);

  • Largest Contentful Paint (LCP): mide el rendimiento de la carga. Para proporcionar una buena experiencia al usuario, el LCP debe ocurrir en los primeros 2.5 segundos desde que la página comienza a cargarse hasta que se ha renderizado el elemento más grande.
  • First Input Delay (FID): mide la interactividad. Para proporcionar una buena experiencia al usuario, las páginas deben tener un FID de menos de 100 milisegundos.
  • Cumulative Layout Shift (CLS): mide la estabilidad visual. Para proporcionar una buena experiencia al usuario, las páginas deben mantener un CLS de menos de 0,1.

Para tener un resultado exitoso de estas métricas habría que asegurar que al menos el 75% de las páginas de tu site aprueban cada una de las partes. Vamos a verlas más en profundidad:

LCP

Con Core Vitals se acaba definitivamente (si no lo estaba ya) con la antigua métrica que reflejaba solo el tiempo de carga del DOM (DOMContentLoaded) y que no representa la carga real de la página. A partir de ahora para definir el tiempo de carga de una página (LCP) se medirá cuándo se ha renderizado el elemento más grande.

Para definir el tiempo de carga de una página se medirá cuándo se ha renderizado el elemento más grande

Como veíamos antes, hay que tratar de que el LCP ocurra en los primeros 2,5 segundos desde que la página empieza a cargarse y tener al menos un 75% de nuestras páginas cumpliendo esta métrica

Mejorar LCP

Los datos LCP se ven afectados sobre todo por estos factores:

Tiempo de respuesta del servidor

Cuanto más tiempo tarda un navegador en recibir el contenido del servidor, más tiempo tarda en mostrar algo en la pantalla. “Un tiempo de respuesta más rápido del servidor mejora directamente cada métrica de carga de página, incluyendo LCP”. No lo digo yo, lo asegura Google. Puedes usar la métrica Time to First Byte (TTFB) para comprobar el nivel de optimización de tu servidor y mejorarla aplicando las siguientes soluciones:

  • Optimizar el servidor: Optimizar el servidor es a menudo la solución más efectiva. Dejando aparte temas físicos del tamaño de la máquina, puedes aligerar la carga del servidor con CSR (Client Side Rendering) o DR (Dynamic Rendering).
  • Implementar una CDN: Usar un Content Delivery Network (CDN puede mejorar el rendimiento de tu web, especialmente si recibe peticiones desde diferentes partes del mundo. Además, sirve de escudo en caso de un ataque. 
  • Establecer una caché: La caché guarda en el navegador una copia del recurso, de manera que cuando se solicita se sirve esta copia en lugar de volver a solicitarla al servidor.
  • Hacer más temprano las llamadas a terceros: Las solicitudes del servidor a terceros también pueden afectar a LCP. Puedes utilizar la etiqueta rel=»preconnect» para informar al navegador que la página tiene la intención de establecer una conexión lo antes posible.

Renderizar bloqueando JavaScript y CSS

Antes de que un navegador pueda mostrar un contenido, necesita analizar el HTML en el árbol DOM. El navegador va recibiendo el código HTML a mostrar y a medida que lo va recibiendo, lo lee y lo procesa. Pero, cuando se topa con un fichero (hoja de estilo externa (<link rel=»stylesheet»>) o etiquetas JavaScript síncronas (<script src=»main.js»>) el navegador detiene la lectura HTML y comienza a ejecutar el Javascript. Una vez terminado continúa con el resto y repite el proceso si es necesario. 

Tanto los scripts como las hojas de estilo son recursos de bloqueo que retrasan el FCP, y por consiguiente el LCP. Por lo tanto, retrasa cualquier JavaScript y CSS no fundamental para acelerar la carga del contenido principal de tu página web.

Defer javascript

Reducir el tiempo de bloqueo de CSS 

Usando la pestaña “Cobertura” de Chrome Developers asegúrate de utilizas sólo la cantidad de CSS necesario. Puedes probar con lo siguiente:

  • Minimiza el CSS
  • Aplazar el CSS no crítico
  • Implementa CSS crítico en línea

Optimizar las imágenes

Las imágenes son a menudo un motivo de que la página vaya lenta. Si somos los dueños de la web debemos procurar siempre que o sobrepase un tamaño máximo (en mi opinión más de 200 kb ya sería en general demasiado) y si tenemos una web con diferentes colaboradores podemos implementar un Plugin que impida que alguien pueda subir una foto de 3 mb. Para evitar que las imágenes empeoren nuestro LCP, prueba estas mejoras:

  • No utilices una imagen al principio de la página: ¿Aporta algo la imagen? Si no es relevante para el contenido, elimínala o déjala para el final.
  • Comprime las imágenes
  • Convierte las imágenes en formatos más nuevos (JPEG 2000, JPEG XR, o WebP)
  • Usa Lazy Loading

Precarga los recursos importantes

Los recursos elementales pueden ser priorizados usando la etiqueta <link rel=»preload»>. Muchos tipos de recursos pueden ser precargados, pero debes centrarte en la precarga de los activos críticos, como las fuentes, las imágenes o los vídeos que existan “above the fold”, y el CSS y JavaScript crítico.

  • <link rel=»preload» as=»script» href=»script.js»>
  • <link rel=»preload» as=»style» href=»style.css»>
  • <link rel=»preload» as=»image» href=»img.png»>
  • <link rel=»preload» as=»video» href=»vid.webm» type=»video/webm»>
  • <link rel=»preload» href=»font.woff2″ as=»font» type=»font/woff2″ crossorigin>

FID

First Input Delay (FID) es una métrica de Core Web Vitals que trata de entender la primera impresión de un usuario sobre la web. Para ello, se mide el tiempo desde que un usuario interactúa por primera vez con la página hasta el momento en que el navegador es realmente capaz de responder a esa interacción de forma satisfactoria.

Mide el tiempo desde que un usuario interactúa por primera vez con la página hasta el momento en que el navegador responde

Una buena métrica sería un FID de menos de 100 milisegundos, entre 100 y 300 sería normal y más de 300 sería mala

Mejorar FID

Optimiza JavaScript

La causa principal de un mal FID se debe generalmente a la pesada ejecución de JavaScript. Optimizar la forma en que el JavaScript se analiza, compila y ejecuta reducirá directamente el tiempo de FID.

Optimiza el código y pon fin a las “Tareas Largas”

Las Tareas Largas son bloques JS que bloquean la ejecución del html principal durante 50 milisegundos o más. Investiga sobre qué tareas de este tipo están perjudicando tu web.

Pre Renderizado

Ojo con el uso de procesadores de pre renderizado y métodos SSR que aumentan la carga del servidor.

Scripts de Terceros

Intenta no abusar de los scripts de terceros. Implementa sólo los imprescindibles para tu negocio y piensa en usar la etiqueta rel=»preconnect» para los más importantes.

CLS

Cumulative Layout Shift (CLS) mide cuando un elemento visible del contenido renderizado cambia de posición. Así escrito no parece fácil de entender, pero se entenderá mejor con este ejemplo: >Imagina que estás leyendo la homepage de tu periódico favorito, vas a hacer clic en una noticia y de repente se carga un recurso nuevo que hace que hagas clic en un anuncio en lugar de en el artículo que querías. Esto resulta un perfecto ejemplo de problemas de usabilidad.

Un contenido ya renderizado cambia de posición de manera imprevista

Métricas CLS de google web vitals
Una buena puntuación CLS será inferior a 0,1. Como en el resto de casos, el 75% de tus páginas deben cumplir con esta nota.

Mejorar CLS

Las causas más comunes de una mala nota CLS son:

Imágenes sin dimensiones

Define el tamaño de tus imágenes e incluye siempre un alto y un ancho. 

Anuncios sin dimensiones

Los anuncios suelen ser una de las principales causas de un mal CLS al emplearse casi siempre anuncios responsive con tamaño dinámico. Suele ocurrir que al cargar un anuncio en la parte superior de la página se desplaza el contenido hacia abajo y resulta fatal para el usuario.

Contenido dinámico

Intenta no insertar dinámicamente nuevos contenidos sobre los ya existentes, a menos que sea en respuesta a una interacción del usuario. De esta forma cualquier cambio en la página puede ser esperado.

Fuentes web que causan FOIT/FOUT

La descarga y la representación de las fuentes web pueden causar también cambios en el diseño.

Nota: La información viene ampliada de forma oficial en la página Web Vitals. Todas las imágenes incluídas dentro del contenido se han extraído del dominio https://web.dev/.

SEO de Calidad, Claridad y Cofianza

Suscríbete a nuestra NewsLetter

More from our blog

See all posts

Dejar un Comentario