El SEO que viene. Del Mobile-first a las Core Web Vitals

26 abril, 2021
mobile-first-core-web

Mantener un sitio web actualizado, para que posicione adecuadamente en los buscadores, implica un seguimiento continuo de los cambios que los buscadores realizan en sus algoritmos para evitar las estrategias de posicionamiento de los especialistas en SEO. Esta persecución entre “gatos y ratones” añade una carga adicional a la labor de generar contenidos interesantes, seleccionar palabras clave, definir nichos de posicionamiento, organizar el linkbuilding, definir la estrategia de contenidos… y, ahora, el SEO técnico. Aquellos factores ocultos, como las Core Web Vitals, que el usuario no percibe cuando se realizan correctamente y que castigan la experiencia de usuario cuando no ocurre.

La evolución de experiencia de usuario en el SEO

Junio de 2021 es la fecha seleccionada por Google para introducir los últimos cambios en su algoritmo, las denominadas Core Web Vitals.

La utilización de métricas, como elemento que influenciador en el posicionamiento, vinculadas a la percepción del usuario es un proceso iniciado en 2016, con la eliminación de los pop ups que dificultaban la navegación. En 2017 se incluyó el safe browsing, la verificación de que los sitios están libres de malware que pueda infectar a los equipos clientes, y la utilización de certificados de servidor que encripten las comunicaciones de los internautas. El Mobile Friendly es la evaluación de la experiencia de usuario en dispositivos móviles que se introdujo en 2015.

Hasta este año, Google diferenciaba el rastreo de las páginas publicadas en internet, entre la experiencia de “escritorio” y la de teléfonos móviles, aunque fue en 2016 cuando comenzó a utilizar las versiones móviles como referencia para establecer el orden de los resultados de las búsquedas.

Este proceso, finalizado en marzo de 2021, supuso la incorporación definitiva del mobile-first indexing, de modo que ya solo se considera el rastreo de las versiones móviles de los sitios web.

Elaboración propia

Este cambio tiene implicaciones para los sitios que no hayan considerado el diseño mobile, ya que, no importa si el tráfico de un sitio es básicamente de escritorio, su posicionamiento dependerá exclusivamente de cómo rinda en su versión móvil. Con este cambio el objetivo del buscador es forzar, a los propietarios de los sitios, a ofrecer la misma experiencia, con independencia del dispositivo utilizado por los usuarios. Y, como es habitual, para poder comprobar el desempeño de un sitio ante sus métricas, Google nos ofrece, además de Search Console, una herramienta para la adaptación de una página en dispositivos móviles.

En el año 2020, Google introdujo 3 nuevos factores para complementar la evaluación de la experiencia de usuario en la navegación. Un modo de dar más peso a la parte técnica del SEO, el Web Perfomance Optimization (WPO) como complemento a la experiencia de página.

La aplicación de estos cambios no implica que las estrategias de construcción de enlaces, la estructura de la información de un sitio o la redacción de contenidos deje de ser importante. Al contrario, desde el buscador se sigue indicando que el mejor modo de conseguir un buen posicionamiento pasa por generar contenido de calidad, aunque ahora la presentación al usuario es mucho más importante.

Estos nuevos factores de evaluación trabajan en relación con el viewport, o “espacio visible de ventana”, durante el renderizado de las páginas. Se han sustituido las mediciones de los tiempos de carga, por información sobre el modo en que los sitios web reaccionan a las acciones de los usuarios.

¿Cuáles son las Core Web Vitals?

Largest Contentful Paint (LCP)

Fuente: https://web.dev/lcp

Con esta métrica se evalúa el tiempo que tarda en mostrarse la imagen, o bloque de texto más grande, que se debería mostrar en la ventana inicial. De acuerdo con las especificaciones de la medición, Google considera que el límite de una buena experiencia de usuario se encuentra en los 2’5 segundos estableciendo como “malo” cualquier resultado por encima de los 4 segundos.

Para calcular el tiempo es importante considerar que el «bloque más grande» no es un elemento fijo que se identifica al inicio de la carga, sino que conforme se van renderizando elementos la característica puede ser transferida a un nuevo elemento incrementando los valores LCP. Por ejemplo, cuando se carga un bloque de texto se “etiqueta” como el “largest-contentful-paint”. Ahora bien, si a continuación carga una imagen más grande, dentro del viewport, la imagen será el nuevo “largest-contentful-paint”, incrementándose el valor de la métrica.

First Input Delay (FID)

Fuente: https://web.dev/fid/

EL FID mide la capacidad de reacción de una página frente a una interacción del usuario, es decir, el tiempo máximo que debe tardar la página en responder a un usuario que clica un enlace, pulsa un botón…

Complementa al anterior, en el sentido de que el LCP será la primera impresión de la página para el usuario (renderizado rápido). Sin embargo, el FID mide desde la primera acción con la página hasta que se muestra el resultado de la interacción. Una reacción lenta perjudica la experiencia de navegación para el usuario, por lo que, desde el buscador, se considera que el tiempo máximo de reacción medio de una página debería estar, el 75% de las veces, por debajo de 100 ms.

Cumulative Layout Shift (CLS)

Fuente: https://web.dev/cls/

EL CLS establece la estabilidad visual de una página. Es el más técnico de los tres y se relaciona con el modo en el que se dibujan las páginas web.

Los navegadores son aplicaciones que interpretan un archivo de texto (la página web). Conforme identifican una etiqueta HTML, la renderizan y asignan un espacio a cada recurso que tiene que mostrar. Estos pueden ser desde una imagen (img, image, svg), una tabla de datos (table, th, tr, td), un encabezado (h1, h2, h3), un bloque de navegación o publicidad (nav, div)… Así se presenta a los usuarios un diseño ordenado de lo que sería la carga completa de la página.

Sin embargo, para mejorar los tiempos de carga, se puede indicar al navegador que retrase la llamada de algunos recursos (imágenes, archivos de javascript…) después del renderizado inicial. Cuando se utilizan estas técnicas se obtienen dos versiones de la página, el de la carga inicial y el definitivo.

Esta métrica mide la variación del diseño inicial y final en el viewport como un porcentaje, recomendando que la variación no supere el 0.1 (10% de la pantalla visible).

¿Cómo se miden estas métricas?

Las Core Web Vitals son registros de experiencia de usuario (RUM – Real User Metrics). Esto significa que, cuando se hace una medición desde el navegador, se obtienen los resultados de ese momento y con la actual configuración, por consiguiente, se dificulta conocer los datos agregados de usuario para una página. Google plantea dos tipos de herramientas para medir los resultados de core web vitals:

Herramientas de campo:

Chrome UX Report: recopila los datos de usuario de forma anónima desde las instancias de Google Chrome que tienen registrado un usuario. Es un conjunto de datos públicos con información agregada.

Web vitals Extension: Extensión para Google Chrome que recopila la información LCP, FID y CLS de la página en la que está el usuario. Mide los datos de la interacción que está registrando.

Herramientas de Laboratorio:

Google Lighthouse: Genera un entorno para la realización de pruebas en el propio navegador. En lugar del FID mide el “Tiempo total de bloqueo” (cuando puede realizar la primera interacción el usuario). La diferencia entre ambas es que el FID se mide desde que el usuario interactúa, el TBT desde que se inicia la carga de la página.

Otras herramientas:

PageSpeed Insights, Search Console: son dos frontend que utilizan los datos de Chrome UX report para crear los informes sobre las páginas consultadas.

¿Cómo se pueden optimizar las páginas para mejorar la experiencia de usuario?

Largest Contentful Paint (LCP)

Las principales causas para obtener malos resultados en el LCP se vinculan a utilizar servidores con tiempos de respuesta altos o tiempos de carga altos de las páginas por tener los recursos poco optimizados.

Entre las posibles soluciones que se podrían implementar para mejorar los resultados de esta métrica se podría contratar servidores con mayores recursos, optimizar la carga de archivos css o javascript a través de precargas (fuentes, diseño), o diferimiento (archivos de seguimiento), según si necesitamos que se carguen, o no, al principio del renderizado de la página. También mejora con la utilización de CDN, el caché de archivos que disminuyan los tiempos de respuesta del servidor, la minimización de archivos css… en definitiva, utilizar estrategias de WPO.

First Input Delay (FID)

Un FID lento suele relacionarse con excesos de carga al inicio del renderizado. En estos casos, la mejor opción es revisar los elementos que piden interactuar en la carga de la página (habitualmente javascript) reduciendo al máximo su número, dejando los esenciales y estableciendo una jerarquía de carga para aquellos indispensables.

Cumulative Layout Shift (CLS)

Una puntuación alta en CLS suele determinarse por un mal uso del HTML, especialmente imágenes o iframes, en los que no se han definido sus dimensiones en los atributos, o recursos (habitualmente externos) que al cargarse modifican el tamaño de un elemento ya dibujado (letras, imágenes o videos).

En estos casos la solución más sencilla es definir correctamente las dimensiones de los elementos que cargan desde el inicio. Otra opción es no cargar este tipo de recursos en espacio visible de ventana inicial.

El SEO que viene

Con la irrupción de las IA en el indexado de los buscadores, y la cada vez mayor competencia en los resultados de las búsquedas, las estrategias SEO deben enfocarse hacia los contenidos de mayor calidad, con el objetivo de mantener la presencia de usuarios en los sitios el mayor tiempo posible. Por ello, la parte más técnica del SEO es aquella que puede generar el elemento diferenciador con respecto a la competencia. La experiencia de usuario ya no es solo una cuestión de diseño ¿cómo se debe pintar un enlace?, sino también cómo de rápida es la página.


Fuentes de información:

Finding more mobile-friendly search: results: https://developers.google.com/search/blog/2015/02/finding-more-mobile-friendly-search

Mobile-first Indexing: https://developers.google.com/search/blog/2016/11/mobile-first-indexing

Google Page Experience Algorithm Update Launching in Mid-June: https://www.searchenginejournal.com/google-page-experience-algorithm-update-launching-in-mid-june/403023

Timing for bringing page experience to Google Search: https://developers.google.com/search/blog/2020/11/timing-for-page-experience

Web Vitals: https://web.dev/vitals/

Largest Contentful Paint (LCP): https://web.dev/lcp/

First Input Delay (FID): https://web.dev/fid/

Cumulative Layout Shift (CLS): https://web.dev/cls/

Web Vital Tools: https://web.dev/vitals-tools/

Optimize Largest Contentful Paint: https://web.dev/optimize-lcp/

Optimize First Input Delay: https://web.dev/optimize-fid/

Optimize Cumulative Layout Shift: https://web.dev/optimize-cls/

Autor / Autora
Doctor en economía aplicada. Profesor colaborador de la asignatura Posicionamiento en Buscadores (SEO) del Master de Marketing Digital de los Estudios de Economía y Empresa de la Universitat Oberta de Catalunya (UOC) y colaborador en aceleratuweb.com
Comentarios
Deja un comentario