Llegado el 2021, las nuevas métricas establecidas por Google para la optimización de la experiencia de usuario de los sitios web, entraron en acción. Así, desde que las Web Core Vitals fueron anunciadas al mundo, los diseñadores web y analistas SEO comenzaron a plantearse las primeras dudas.
Las cosas se dieron de esta manera puesto que, en virtud a los retardos que podría llegar a imponer la pandemia del coronavirus (Covid-19), la empresa decidió entregar un plazo de gracia de seis meses. Dentro de este lapso, los propietarios de los sitios deberían comenzar a realizar las mejoras necesarias.
Los seis meses pasaron y Google volvió a sacar otro comunicado al respecto. En esta oportunidad se aclaraba que los nuevos parámetros establecidos comenzarían a regir desde la perspectiva del posicionamiento orgánico recién desde mayo de 2021. Hasta entonces, los principales indicadores pertenecientes al posicionamiento desde la perspectiva de la búsqueda y la experiencia de usuario,eran los siguientes: optimización para dispositivos móviles, navegación segura, protocolo HTTPS y directrices de anuncios intersticiales. Y con la llegada de las Web Core Vitals, el paradigma estaba a punto de cambiar.
El propio Google dio explicaciones sobre por qué el ingreso de estos tres parámetros se dio de esa forma. Lo que hizo fue argumentar que desde la órbita de la experiencia de usuario, no muchos desarrolladores y analistas de SEO podrían entender absolutamente todas las indicaciones técnicas de principio a fin.
Obviamente, por la inmensa cantidad que eran, y por la complejidad que algunas presentaban.
Y finalmente nacieron las Web Core Vitals
De esta manera fue que se decidió optar por englobar aquellas métricas similares que respondieran a “problemas” similares de UX. Es así como se crearon tres parámetros generales y se las dio a llamar Web Core Vitals (o métricas web principales): Largest Contentful Paint, First Input Delay y Cumulative Layout Shift.
Cada una de ellas cumple una función específica. Y en conjunto, podríamos decir que se encargan de evaluar el rendimiento de un sitio web analizado desde la perspectiva de la experiencia de usuario. De esta manera, sus tareas son las siguientes:
- Largest Contentful Paint: su tarea es determinar el tiempo de carga del contenido. En la práctica, determina cuánto transcurre entre el momento en que la página comienza a cargarse y el momento en que se renderiza el elemento más grande above the fold.
- First Input Delay: esta métrica determina la interactividad del sitio. En otras palabras, su tarea consiste en determinar cuánto tiempo transcurre desde que el usuario interactúa por primera vez con el sitio, hasta que el navegador procesa los controladores de eventos implicados en tal ejecución y devuelve una respuesta.
- Cumulative Layout Shift: la función de la tercera de las Web Core Vitals es medir la estabilidad visual del sitio. Usualmente es la más complicada de entender puesto que no mide tiempo, sino que mide frecuencias. En efecto, la frecuencia que mide es aquella con la que los elementos cambian de lugar cuando el usuario no ha tenido nada que ver en ello. Pongamos un ejemplo práctico: ¿recuerdas esos sitios donde estás por hacer clic en un botón, y mágicamente cambia de posición? Bien, esos sitios deberán trabajar para mejorar la puntuación de esta métrica.
Ahora que comprendes bien cuáles son las Web Core Vitals y a qué se dedica cada una, es momento de hablar de la optimización.
Para que se considere que el sitio analizado se encuentra en buenas condiciones desde la perspectiva de las nuevas métricas de Google, se establecieron tres umbrales de puntuación, por llamarlo de alguna manera. Encontramos así que cada una determinará que el sitio está en malas condiciones, que necesita mejoras, o que la situación es óptima. Los puntajes son los siguientes:
- En Largest Contentful Paint, los umbrales se encuentran entre 0 y 2,5 segundos cuando las condiciones son óptimas, entre 2,5 y 4 segundos cuando deben realizarse mejoras, y superior a los 4 segundos cuando el sitio no responde bien.
- Para First Input Delay, los umbrales están entre 0 y 100 milisegundos cuando no hay que realizar cambios, entre 100 milisegundos y 300 milisegundos cuando deben realizarse mejoras, y superior a los 300 milisegundos cuando el retardo es demasiado alto.
- Cumulative Layout Shift, por su parte, los umbrales están entre 0 y 0,1 cuando la frecuencia está bien, entre 0,1 y 0,25 cuando deben realizarse mejoras, y superior a 0,25 cuando la frecuencia es alta. Recordemos que en este caso no se está midiendo tiempo, por lo cual, no es necesaria la unidad de medida.
Web Core Vitals: ¿Cómo Aumentar el Puntaje de FID?
Analizaremos a continuación cuáles son las posibles mejoras a implementar desde el aspecto de la métrica que mide la interactividad.
Como dijimos, para que un sitio analizado desde éste ángulo se encuentre en buenas condiciones, será necesario que el umbral de respuesta esté determinado entre los 0 y 100 milisegundos. Desde luego, notaremos que es una respuesta increíblemente rápida. Esta cualidad se corresponde con la premisa de Google que indica que no debe interrumpirse el flujo de pensamiento del usuario en ningún momento una vez que el sitio web ya se encuentra renderizado.
De esta manera, encontraremos que las modificaciones a realizarse pueden ser varias, y muchas de ellas principalmente estarán relacionadas con las órdenes de ejecución de eventos, en otras palabras, con Javascript.
Cualquier desarrollador web, al momento de haber finalizado su proyecto y pasarlo a producción, seguramente pensará que el código escrito se ejecutará inmediatamente y sin errores. Claro, un trabajo tan arduo y probado tantas veces es imposible que no funcione a la perfección. Pues bien, esto lamentablemente casi nunca ocurre. Los entornos de ejecución finales, después de todo, son tantos como tantos usuarios vayan a utilizar el producto desarrollado.
Generalmente, lo que ocurre en la gran mayoría de los casos es que el hilo principal del navegador suele estar ocupado haciendo otra tarea, y eso, indefectiblemente, llevará a que no otorgue la respuesta indicada al momento en que se realizó la primera interacción. Y es entonces cuando la puntuación empieza a caer.
Javascript solamente puede ejecutar una tarea a la vez. Entonces, si el navegador está ejecutando otra tarea, indefectiblemente se deberá esperar a que concluya para poder pasar a la siguiente.
Esto nos presenta una pauta a considerar. Simplemente hay que comprender que el principal motivo por el que aumenta la latencia de la primera entrada es porque Javascript se está ejecutando intensamente.
Es así que se encuentran cuatro posibles soluciones:
- Dividir las tareas largas
- Optimizar la página para que esté lista para interactuar
- Utilizar un web worker
- Minimizar el tiempo de ejecución de Javascript
Vamos a explicar cada uno de estos puntos.
Mejorar FID | División de Tareas Largas
Las tareas largas son los períodos de ejecución de Javascript en los que los usuarios se dan con que su interfaz no responde. Si un fragmento del código JS bloquea el hilo principal de ejecución por más de 50 milisegundos, será considerado como una tarea larga.
Debido a esto encontramos que segmentar mejor el código o utilizar los comandos async y await se presentan como una buena solución.
Mejorar FID | Optimización de la Página
Debes saber que la ejecución de ciertos scripts puede retrasar bastante la respuesta a las interacciones. Por caso, diremos que al dividir las instrucciones del código basándonos en rutas no suele ser la mejor opción. En este caso, lo óptimo sería cambiar la lógica aplicada desde el lado del servidor, o bien, generar contenido estático durante el tiempo de compilación.
Mejorar FID | Web Worker
Como dijimos, el hilo de ejecución de Javascript solo puede procesar una tarea por vez. Al rescate en esta circunstancia salen los web workers o trabajadores web. Su función es, básicamente, ejecutar el JS en un hilo en segundo plano. Así, todas las operaciones que no sean de interfaz de usuario pueden ser movidas a un subproceso de trabajo separado.
Esto, finalmente, reducirá el tiempo de bloqueo del subproceso principal, mejorando en consecuencia, el puntaje de la segunda de las Web Core Vitals.
Mejorar FID | Tiempos de ejecución de Javascript
Otro recurso muy útil para mejorar la puntuación de First Input Delay es reducir la cantidad de Javascript utilizado. Cuando el navegador se encuentra con una secuencia de comandos vinculados a un archivo .js externo, por ejemplo, debe pausar su tarea actual para descargar, analizar, compilar y ejecutar ese JS.
Es así que queremos decir que los únicos archivos Javascript verdaderamente útiles son aquellos que responden a las interacciones con el usuario. De este modo, reducir el JS implicaría dos tareas. Hay que dividir el código en varios fragmentos o aplazar el JS no crítico, incluyendo scripts de terceros, utilizando los comandos async o defer.
Analizar las Web Core Vitals y buscar las maneras de mejorar su puntuación es una tarea verdaderamente complicada. No obstante, nada es imposible, todo es cuestión de comenzar analizando los conceptos teóricos más duros. Finalmente sólo hay que aplicar las herramientas disponibles en internet, y, obviamente, dar el primer paso.