El año 2021 resultó ser una bisagra para el mundo del posicionamiento orgánico en buscadores. Desde luego, esto suena un poco extremista. Pero en verdad, con las Web Core Vitals en el ojo de la tormenta que estaba atravesando el SEO, no era para menos pensar que muchos cambios estaban a punto de producirse.
Es que, a decir verdad, los parámetros definidos como esenciales para el posicionamiento orgánico en buscadores son demasiados. Tal es así que, arriesgándonos un poco, podríamos decir que ni el propio Google los tiene definidos. Y cada uno de ellos está ligado a distintos factores tales como semántica, contenido, diseño gráfico, diseño web, experiencia de usuario, etcétera.
Obviamente estamos dando a entender que, desde un momento en particular, el motor de búsqueda dio por necesaria una estandarización superior. Los programadores web y analistas en SEO, de por sí en su día a día ya se encontraban con constantes desafíos que, al parecer, nunca tenían fin. No queremos decir que las tareas nunca pudieran cumplirse al 100% (aunque en muchos casos esto sí ocurría), pero el trabajo del SEO en particular nunca terminaba.
Constantemente salían a la luz nuevos cambios que ponían en jaque a la estructura tradicional de trabajo para los analistas SEO. Asimismo, los desarrolladores web debían encontrar nuevos mecanismos para adaptarse a las incipientes exigencias que Google presentaba.
Es así que en mayo de 2021, con la irrupción de las Web Core Vitals al mundo del SEO, las reglas se adaptaron drásticamente a un nuevo paradigma orientado muy fuertemente a la experiencia de usuario. No es precisamente inocente decir que se adaptaron a un “nuevo” paradigma puesto que el motor de búsqueda ya venía orientando sus esfuerzos a esta característica de la navegación web.
Lo que en verdad ocurrió es que, ya que las cualidades atenientes al posicionamiento orgánico desde la perspectiva UX eran tantas y tan variadas (y en muchos casos, tan complicadas de solucionar), que fue necesario reestructurar las reglas imperantes y aglutinarlas en estas tres métricas web principales. El objetivo fue definirlas según velocidad de carga, velocidad de interactividad y estabilidad visual. De este modo nacie
,ron los parámetros Largest Contentful Paint, First Input Delay y Cumulative Layout Shift
Vamos a conocerlas.
Web Core Vitals | Las nuevas métricas de Google
Como mencionamos anteriormente, el motor de búsqueda más famoso del mundo había presentado las nuevas reglas de juego para organizar su indexación. La norma general era mejorar la experiencia de usuario.
Es así que nacieron las métricas web principales, las cuales llamaremos por sus siglas LCP, FID y CLS. Estas métricas, desde entonces, deberían determinar el estado en que un sitio se encontraba (desde luego, también la página web analizada desde su perspectiva). A tal fin, en un post publicado en mayo de 2020 por el propio Google, se determinó que ellas acompañarían a las otras directivas impuestas por la empresa. Por entonces, podríamos encontrar a las siguientes:
- Optimización para dispositivos móviles
- Navegación segura
- Protocolo HTTPS
- Directrices de anuncios intersticiales intrusivos
Las Web Core Vitals, entonces, serían las nuevas métricas para evaluar el rendimiento de los sitios web analizados, siempre haciéndolo desde la perspectiva de la experiencia de usuario.
Largest Contentful Paint
Esta métrica se encargaría de medir la velocidad de carga de la página. Técnicamente hablando, lo que hace en verdad es medir tiempo. En concreto, su función es medir el tiempo transcurrido desde que la página comienza a cargarse, hasta que el elemento con contenido más grande existente en la parte superior de la misma se renderiza.
Es decir, ubica al elemento visual con contenido más grande above the fold (en la parte superior, antes de que el usuario haga scroll). Esta métrica es particularmente importante puesto que este elemento es el que, por lógica, debe captar la atención del usuario antes que cualquier otra cosa.
Sencillamente, es necesario dejar en claro la importancia de esta métrica, puesto que de ella dependerá en buena parte que un sitio web prospere o no.
First Input Delay
Esta es la segunda métrica establecida por Google. Su función, a grandes rasgos, es determinar en qué estado se encuentra la interactividad del sitio. Al igual que la primera, mide velocidad basada en segundos.
De esta forma, entendemos que First Input Delay determinará cuánto tiempo transcurre, tomando en cuenta la primera interacción del usuario, desde que se efectúa esa interacción, hasta que el navegador proporciona una respuesta.
Esto es así puesto que el navegador, al recibir una primera orden por parte del cliente, debe comenzar a procesar controladores de eventos que respondan a lo que el usuario indicó. La pauta que esto nos proporciona es que aquí, optimizar todo el Javascript es prácticamente fundamental.
Cumulative Layout Shift
La tercera de las métricas web principales es la que se encarga de medir la estabilidad visual del sitio. Particularmente, esta suele requerir una explicación un poco más a detalle puesto que, a diferencia de las otras dos, no mide velocidad, sino frecuencias.
Al hablar de estabilidad visual del sitio, estamos haciendo referencia a que, para proporcionar una buena experiencia de usuario, no deberían existir imprevistos que el cliente no pueda controlar. Y, en efecto, este es uno de los problemas más frecuentes a la hora de pensar en optimización UX.
Pongamos un ejemplo: imagina que estás navegando en un sitio y que quieres hacer clic en un botón, llevas el cursor para hacer clic y ¡BOOM!, el botón desapareció. Esto es porque ha cambiado de posición debido a cualquier factor. Y, ¿adivina qué? Esos factores son los que se deben solucionar.
A tal efecto, Cumulative Layout Shift se encarga de dimensionar la frecuencia con la que este tipo de cambios suceden. Y hoy aprenderás cómo optimizarla.
Cómo optimizar las Web Core Vitals
Como es de esperarse, para que algo se pueda optimizar, primero se debe medir. Y para hacerlo con las métricas web principales, Google estableció tres umbrales de puntaje, los cuales determinarán si la Web Core Vital analizada se encuentra en buen estado, si necesita algunas mejoras, o si hay que hacer cambios fuertes.
Estos umbrales varían según la métrica analizada, y sus delimitaciones son las siguientes.
- Largest Contentful Paint: en el caso de esta métrica, el umbral de puntaje determinará que la página analizada está en buenas condiciones cuando el tiempo de carga no supere los 2,5 segundos. Se requerirá hacer algunos ajustes cuando el tiempo esté entre los 2,5 segundos y los 4 segundos, y por último habrá que trabajar más intensamente cuando los 4 segundos sean superados.
- First Input Delay: para esta métrica, el umbral de puntaje óptimo se encuentra antes de los 100 milisegundos. Se requerirán algunas mejoras cuando el tiempo esté entre los 100 milisegundos y los 300 milisegundos, y habrá que realizar tareas más intensas cuando este último tiempo sea superado.
- Cumulative Layout Shift: en este artículo nos ocuparemos de cómo optimizar a la tercera de las Web Core Vitals. Antes de entender cómo hacer esto, deberás saber que el umbral óptimo de puntaje se encuentra antes de la marca 0,1; que se deberán realizar algunos ajustes cuando la marca esté entre 0,1 y 0,25; y que cuando la marca supere 0,25, los trabajos de optimización deberán ser mayores. Hay que prestar atención a un aspecto de esta métrica: aquí no hay unidad de medida puesto que ya no estamos hablando de velocidad sino, como dijimos anteriormente, estamos midiendo frecuencias.
Ahora bien, ¿cómo mejorar el puntaje de CLS?
Al momento de pensar en optimizar esta métrica hay que tomar en consideración algunas cuestiones. Principalmente hay que grabarse a fuego que estamos midiendo frecuencias. Y vamos a explicar por qué.
Cada vez que ocurre un cambio inesperado en el contenido del sitio analizado, puede darse por varios motivos, pero principalmente hay que entender que esto se da ya que los recursos (en la mayoría de los casos) se cargan de manera asincrónica.
Otro de los motivos puede ser que los elementos del DOM se estén agregando dinámicamente al sitio, sobreponiéndose al contenido existente.
Incluso, esta métrica puede variar fuertemente aún cuando se la esté tomando en cuenta al momento de programar el sitio. Esto es así porque el funcionamiento, cuando la web está en desarrollo, suele ser diferente al que se presenta al momento de experimentarlo por los usuarios.
De este modo encontraremos que los motivos por los que este puntaje puede bajar son muchos y muy variados. No obstante presentaremos a continuación los principales factores y sus respectivas soluciones.
Las causas más comunes de una baja puntuación en esta métrica son:
- Imágenes sin dimensionar
- Anuncios o iframes sin dimensionar
- Contenido generado dinámicamente
- Fuentes web que ocasionen FOIT o FOUT
Para resolver el primer punto, la solución es bastante práctica y sencilla: es cuestión de, siempre, utilizar en las imágenes los atributos height y width. De esta manera, el navegador ya sabrá que debe reservar un espacio para las imágenes en cuestión mientras se están cargando.
¿Y qué ocurría con los anuncios?
Respecto a este punto hay que ser un poco más cautelosos. Lo que aquí ocurre, es que son los principales causantes de redimensión de espacio en la página en cuestión. Principalmente debido a que las redes de publicidad suelen admitir tamaños de anuncios dinámicos. Nuevamente en este caso, en la medida que sea posible, siempre es conveniente asignar un espacio específico para ellos.
Con los contenidos generados dinámicamente, como te imaginarás, ocurre lo mismo. Es muy frecuente experimentar cambios de diseño en la interfaz provocados por algún elemento que aparezca arriba o abajo de la página. De hecho, sucede casi lo mismo que con los anuncios: si un banner o un formulario aparece dinámicamente, el contenido siempre va a verse modificado, restando puntaje al CLS.
Para explicar lo que ocurre con las fuentes web, primero debes saber qué es FOIT y FOUT. Respectivamente, según sus siglas, son Flash Of Invisible Text y Flash Of Unstyled Text.
- FOIT: ocurre ya que algunas fuentes web son tan pesadas, que el navegador ocultará el texto de la página hasta que la fuente esté completamente cargada.
- FOUT: ocurre básicamente por lo mismo que el anterior. Con la ligera diferencia de que aquí, el texto sí se mostrará, pero por unos segundos con una fuente distinta a la que está seteada en nuestro sitio.
Desde luego, entre ambas opciones, FOUT es la “menos penalizada”, puesto que en este caso el texto sí está visible. De acuerdo a lo que Page Speed Insights indica, siempre será mejor mostrar texto (por más que no tenga la fuente indicada – por unos breves instantes – ) antes que no mostrar nada. Para solucionar este conflicto, siempre será útil declarar la instrucción “font-display: swap”.
Mejorar los puntajes de las Web Core Vitals es una tarea bastante ardua si no se tiene mucha experiencia en el tema. Si bien es un trabajo ciertamente complejo, aventurarse en este mundo es solo cuestión de dar el primer paso.
