Con la incorporación de las Web Core Vitals como las nuevas métricas establecidas por Google para determinar el posicionamiento orgánico de los sitios web, el mundo del desarrollo web y del SEO debieron tomar cartas en el asunto. Anteriormente, las determinaciones del motor de búsqueda desde el punto de vista de la experiencia de usuario se podían englobar en cuatro ítems característicos: la optimización de sitios para dispositivos móviles, la navegación segura, el protocolo HTTPS y las directrices de anuncios intersticiales intrusivos.
Lo que ocurrió, según las palabras del propio Google, era que, más allá de las directivas recién mencionadas, había que tomar en cuenta los demás factores de posicionamiento orgánico tradicionales, pero sumar (dándole mucho más énfasis), a la experiencia de usuario como tal, vista desde el ángulo de la programación pura y dura.
Bajo esta determinación, la cantidad de normativas resultaba ser exorbitante, y en virtud a ello fue necesario “englobar” todo aquello que tuviera que ver con el mundo UX en ciertos parámetros, a los efectos, un tanto más generales.
De este modo, en un comunicado lanzado el jueves 28 de mayo de 2020, Google dio a conocer las Web Core Vitals (también llamadas métricas web principales). Sencillamente, consisten en tres indicadores: Largest Contentful Paint, First Input Delay y Cumulative Layout Shift.
Web Core Vitals | Largest Contentful Paint
Esta métrica se encarga de medir el tiempo de carga del contenido above the field. En otras palabras, determina la cantidad de tiempo transcurrido desde que la página comienza a cargarse, hasta que el contenido más grande ubicado en la parte principal de la página se renderiza (desde luego, sin hacer scroll).
Al igual que en el caso de las otras dos, posee tres umbrales de calificación. Para determinar que un sitio web está en buenas condiciones desde esta perspectiva, el tiempo transcurrido no debe superar los 2,5 segundos. Por otra parte, se considerará que el sitio necesita mejoras si la marca se ubica entre los 2,5 y los 4 segundos. Y finalmente, el sitio estará en malas condiciones cuando el tiempo supere los 4 segundos.
Web Core Vitals | First Input Delay
Es la segunda de las Web Core Vitals. En esta métrica, lo que se dimensiona es, básicamente, la interactividad del sitio. La explicación técnica nos dice, en resumen, que consiste en la medición del tiempo transcurrido entre la primera interacción realizada por el usuario cuando la página está cargada, y entre la respuesta del navegador.
Básicamente, es el propio navegador quien debe comenzar a procesar los controladores de eventos en respuesta a la interacción ejercida por el usuario, lo cual nos da a entender que los archivos Javascript están íntimamente ligados a esta métrica.
Al igual que en el apartado anterior, nuevamente encontraremos los umbrales de puntaje. Para que el la página analizada se encuentre en buenas condiciones desde la perspectiva del FID, el tiempo transcurrido no debe superar los 100 milisegundos. Asimismo, el sitio necesitará algunas mejoras cuando la marca del tiempo se ubique entre los 100 milisegundos y los 300 milisegundos, y superada esta última marca, puede decirse que la página necesita mejorarse en varios aspectos.
Web Core Vitals | Cumulative Layout Shift
La tercera de las Web Core Vitals es la que difiere un poco de las anteriores. En este caso, no estamos hablando de mediciones de tiempo directamente, sino que nos referiremos a frecuencias.
Estamos hablando constantemente de la experiencia de usuario. Por tal motivo, imagina lo siguiente: estás navegando en un sitio web y quieres hacer clic en algún botón, pero este mágicamente cambia de posición. Esto es algo bastante frecuente en la gran mayoría de los sitios web y, como es de esperarse, genera cierta antipatía por parte del usuario, el cual nada tuvo que ver con el cambio de ubicación del elemento requerido.
Esa es la frecuencia que Cumulative Layout Shift se encarga de medir. Nuevamente, como es de esperarse, encontramos el umbral de medición. En este caso cabe mencionar que ya no estamos hablando de una unidad de tiempo. El primer umbral determina que el sitio web estará en buenas condiciones desde esta perspectiva cuando el puntaje sea menor a 0.1. Del mismo modo, se necesitarán mejoras cuando se encuentre entre 0.1 y 0.25. Y por último, se necesitarán mejoras importantes cuando se supere el puntaje de 0.25.
Desde luego, Google no nos ha dejado solos a la deriva con la inclusión de estas nuevas métricas. La gran mayoría de sus herramientas de auditoría (sino todas) han sido adaptadas para evaluar el puntaje de las Web Core Vitals. De esta manera, si tu sitio web necesita mejoras, sean leves o severas, no es momento de desesperar porque llegaste al post indicado.
En esta oportunidad hablaremos de cómo mejorar el puntaje de la primera de las Web Core Vitals.
Conociendo Largest Contentful Paint
Anteriormente explicábamos que LCP se encarga de medir el tiempo de carga del elemento más grande renderizado en la primera parte de la página analizada. Esto da a pensar algunas situaciones. En primer lugar hay que entender que un buen puntaje de LCP, pensándolo rápidamente, indicará que la página en sí cuenta con una buena velocidad de carga. Pero no es cuestión de detenernos aquí puesto que el análisis es más profundo.
Podemos tomar en cuenta una variable muy importante: el tiempo es oro, especialmente para los navegantes de internet. Imagina que un sitio web de noticias tenga un índice de LCP lento. Esto implicaría, por ejemplo, que lo primero en cargarse sería cualquier cosa que no fuera la imagen principal (o el título -H1- según el caso). La experiencia de usuario sería baja, lo cual indefectiblemente llevaría a que el usuario no vuelva a visitar ese sitio web. En otras palabras, muchos websites (si no es que todos) dependen de su elemento más grande renderizado para triunfar.
Dicho esto, hay más por analizar. Los elementos tomados en cuenta como “candidatos” para medir al Largest Contentful Paint son cinco:
- Los elementos de imagen
- Aquellos elementos de video
- Todos los elementos de imagen incluidos dentro de un elemento svg
- Están los elementos con background de imagen cargados a través de la función url()
- Y por último, los elementos a nivel de bloque que contengan nodos de texto u otros elementos texto hijos, de nivel inline
Web Core Vitals | ¿Cómo mejorar el puntaje de Largest Contentful Paint?
Existen muchos factores que pueden llegar a afectar negativamente el puntaje recibido de LCP. Básicamente, según la información ofrecida por Google, los principales tienen que ver con tiempos de respuesta lentos del servidor; con elementos Javascript o CSS que estén bloqueando el renderizado; con tiempos de carga de recursos bastante lentos; y finalmente con la renderización del lado del cliente.
Cada uno de estos factores tiene una infinidad de soluciones posibles por llevarse a cabo. Desde luego, el tratamiento que los elementos de carga lenta puedan llegar a tener, dependerá pura y exclusivamente del sitio del que se trate, de sus recursos, de sus servidores, etcétera.
Técnicas Para Mejorar el Puntaje LCP
Existen soluciones un poco más generales a la hora de pensar en la optimización de la primera de las Web Core Vitals según el propio Google, y son las que detallaremos a continuación:
- Optimizar imágenes: desde el formato, hasta la compresión. Todo lo que se pueda hacer en pos de que la imagen esté completamente apta para ser cargada velozmente influirá en este momento. Se deben tener en cuenta la delimitación de alto y ancho, especialmente cuando el elemento más grande con contenido de la página sea una imagen, lo cual, muy frecuentemente resulta ser así.
- Optimización de archivos CSS y Js: esto se refiere a que debemos bregar por la compresión y minificación de este tipo de archivos. Solo deben utilizarse archivos .js realmente útiles y pequeños, y al mismo tiempo, implementar únicamente el CSS crítico.
- Rendimiento del servidor: es importante que el plan de hosting sea el ideal para el sitio en función a los recursos utilizados. Un CDN en este caso suele ser una opción bastante recomendable.
- Precarga y preconexión: es importante apuntar al navegador a los recursos y conexiones prioritarios mediante el uso de rel = preload, rel = preconnect y, por último, rel = dns-prefetch
- Optimización de la renderización del lado del cliente: si el sitio web en cuestión se renderiza principalmente del lado del cliente, es importante estar atentos puesto que es muy probable que, utilizando un Javascript pesado y complejo (como en el caso de React, Angular y Vue), puede afectar negativamente el puntaje de LCP. En otras palabras, el cliente no verá ningún contenido (y, desde luego, tampoco interactuará con él) hasta que todo el paquete de Js crítico de haya terminado de descargar y ejecutarse. Lo óptimo en este caso es, nuevamente, minificar los paquetes de Javascript, utilizar el renderizado del lado del servidor, y también implementar un renderizado previo.
Está claro que realizar las implementaciones técnicas necesarias para optimizar la métrica LCP puede ser una ardua tarea, pero no desesperes. Todo es cuestión de dar el primer paso.