Cómo mejorar las Core Web Vitals

Las Core Web Vitals (CWV) constituyen un conjunto de métricas que ayudan a Google a analizar el rendimiento general de las páginas web.

Las Core Web Vitals (CWV) son un conjunto de métricas que ayudan a Google a evaluar el rendimiento general de las páginas web.

Estas tres métricas son:

1. Largest Contentful Paint (LCP)
2. First Input Delay (FID)
3. Cumulative Layout Shift (CLS)

Cada una de las tres Core Web Vitals representa un aspecto distintivo de la experiencia del usuario.

Junto con otras web vitals, LCP, FID y CLS forman parte de las señales de experiencia de página de Google que se utilizan para fines de clasificación.

Las CWV miden y evalúan tres aspectos de las páginas web: carga, interactividad y estabilidad visual.

La primera Core Web Vital es LCP (Largest Contentful Paint). La métrica LCP se utiliza para medir el tiempo que tarda la imagen o el bloque de texto más grande dentro de una viewport definida en hacerse visible desde el momento en que una página comienza a cargarse. El benchmark actual de Google para Largest Contentful Paint es inferior a 2,5 segundos.

La segunda Core Web Vital de Google es FID (o First Input Delay). La métrica FID evalúa la capacidad de respuesta de la página y mide el tiempo que tarda una página en responder a la entrada del usuario (clic, toque o pulsación de tecla). Un buen First Input Delay se considera inferior a 100 milisegundos.

Por último, pero no menos importante, la métrica CLS mide la estabilidad visual de una página. Si las páginas web tienen elementos inestables durante la carga de la página, habrá una puntuación CLS deficiente. Una buena puntuación de Cumulative Layout Shift debe ser igual o inferior a 0,1.

Cómo se correlacionan las Core Web Vitals con las impresiones y clics orgánicos

Si lees alguno de los estudios de caso sobre Core Web Vitals, encontrarás mucha información contradictoria sobre cuánto se correlaciona una buena puntuación CWV con las impresiones y los clics orgánicos. He introducido deliberadamente esta sección al principio del estudio para mostrar cómo la optimización de las CWV ha funcionado para nosotros y por qué la hemos convertido en una de nuestras principales prioridades para el año en curso.

El informe CWV en Google Search Console tiene un límite de 3 meses en los datos disponibles. Por lo tanto, para monitorear nuestro progreso de manera más conveniente que con las herramientas de Google, creamos una integración entre la API de Google Search Console y PowerBI de Microsoft. De esta manera, pudimos combinar todos los datos en un solo panel y recopilar todos los datos históricos sin limitaciones.

Punto de partida

Todo el proceso de optimización de las CWV comenzó verificando nuestra situación actual en Google Search Console.

Además de Search Console, puedes usar PageSpeed Insights de Google para verificar las CWV en tu sitio web. Sin embargo, es importante comprender la diferencia clave entre ambos y cómo evalúan las CWV.

Search Console se basa en datos de campo, es decir, datos del Chrome User Experience Report (CrUX), lo que significa que las puntuaciones CWV se basan en cómo los usuarios reales experimentan las páginas. Estos datos se actualizan cada 28 días, por lo que debes esperar todo este tiempo antes de poder ver los resultados de las mejoras de rendimiento.

PageSpeed Insights determina las puntuaciones basándose en datos de laboratorio, una simulación de lo que Google considera un usuario web promedio. Puedes verificar cualquier página en cualquier momento.

Por lo tanto, PageSpeed Insights es útil cuando deseas obtener una estimación rápida de lo que está sucediendo con las CWV en una página determinada.

Cómo mejoramos las métricas de Core Web Vitals

Cuando nos enteramos por primera vez de las tres Core Web Vitals, su optimización nos pareció una tarea trivial. Consultábamos el informe de Lighthouse, PageSpeed Insights y Search Console y seguíamos las recomendaciones que nos daban. ¿Qué podría salir mal?

Solo unas semanas después nos dimos cuenta de que podía haber cientos de problemas que provocaban puntuaciones CWV deficientes. Así que, para compartir nuestra experiencia y ahorrarte mucho tiempo, hice todo lo posible por recopilar todo lo que se hizo en un formato fácil de entender.

Preparación de servidores y CDN geoespecíficos

– Métricas afectadas: TTFB, LCP –

El tiempo de respuesta del servidor es crucial y puede anular todos los esfuerzos de optimización de CWV si no se cuida de antemano. Una de las métricas que ayudan a Google a evaluar el tiempo de respuesta de un servidor se llama Time to First Bite (TTFB) y, aunque no es una Core Web Vital, forma parte de otras Web Vitals.

El TTFB mide el tiempo que transcurre entre que un usuario llega a un sitio web y el momento en que se carga el primer «bite» de información. Generalmente, el TTFB debería ser inferior a 600 ms.

UnTTFB deficiente afecta negativamente al LCP, por lo que hacerlo lo más bajo posible es fundamental. En la mayoría de los casos, la puntuación de TTFB se puede mejorar simplemente cambiando a un mejor proveedor de hosting. Sin embargo, este no fue el caso de link-assistant.com.

Link-assistant.com tiene una audiencia global y Google utiliza datos de monitoreo de usuarios reales (RUM) para determinar si una página específica cumple los criterios de Web Vitals. Esto significa que si el TTFB es bueno para, por ejemplo, Estados Unidos y malo para la India, este último terminará reduciendo la puntuación final de TTFB.

Antes de que las CWV fueran tan importantes, solo teníamos una ubicación de servidor, en Estados Unidos. Obviamente, esto no era suficiente para un sitio web que tenía una audiencia multinacional.

Esto nos llevó a la hipótesis de que los volúmenes de tráfico de la India eran demasiado altos para un solo servidor. Por lo tanto, lo más probable es que el servidor estuviera sobrecargado, lo que provocaba un TTFB deficiente para todas las ubicaciones distintas de la India. Así que añadimos dos nuevos servidores: uno en Osaka y otro en Singapur.

Dado que los servidores adicionales se añadieron hace aproximadamente una semana, tendremos que esperar a que los resultados finales se manifiesten. Sin embargo, la mejora ya es visible para la mayoría de las ubicaciones.

El mismo problema con el TTFB se observó en América. No solo las puntuaciones de TTFB no mejoraron para las ubicaciones en EE. UU., sino que también hubo tiempos de respuesta del servidor enormemente altos para los usuarios en Brasil y Chile.

Aquí sacamos algunas conclusiones. En primer lugar, nuestro tráfico orgánico en América es tan pesado como en la India, por lo que dos servidores probablemente no son capaces de gestionar el flujo sin comprometer el TTFB.

En segundo lugar, uno de nuestros servidores estaba en Wowrack. Nuestro equipo de desarrollo descubrió que este servidor estaba gravemente sobrecargado, tenía especificaciones técnicas bastante antiguas y se encontraba en la infame zona de «Internet más antiguo» en la costa oeste de EE. UU., lo que provocaba importantes retrasos en la conexión entre los usuarios y el propio servidor.

Como solución final, hemos configurado recientemente un servidor AWS adicional, por lo que ahora tenemos tres servidores en EE. UU. Los resultados de las mejoras que hemos realizado aún no son significativos, pero los mantendremos vigilados y actualizaremos este estudio más adelante.

En general, la optimización del TTFB para link-assistant.com nos permitió mejorar significativamente esta métrica, lo que a su vez resultó en una mejora del LCP. Un resultado beneficioso para nosotros.

Además, cuando estábamos seguros de que el TTFB era lo suficientemente bueno, nos aseguramos de que todos nuestros activos estáticos (imágenes, CSS, Javascript) se cargaran desde CDN en lugar de desde nuestros servidores. Aunque de forma indirecta, tener todos los activos estáticos en CDN ayuda a mejorar las puntuaciones de TTFB, porque los servidores no se sobrecargan con solicitudes adicionales para cargar imágenes, CSS o JS.

Nota

Adquirir servidores adicionales es una solución costosa, que no es 100% obligatoria en todos los casos. Si tu sitio web sirve a una audiencia local, puedes usar un solo servidor cerca de tu público objetivo sin problemas. Si experimentas problemas con el TTFB, prueba soluciones menos drásticas como cambiar de proveedor de hosting. Si los problemas persisten, consulta este artículo de Google.

Retrasar los JS de terceros

– Métricas afectadas: LCP –

Los JS de terceros incluyen todo, desde los botones para compartir de Facebook hasta los rastreadores de Google Analytics presentes en una página. Estos elementos de la página siempre consumen muchos recursos de renderizado. Además, cada vez que un navegador encuentra una pieza de JS de este tipo, interrumpe el renderizado del HTML hasta que termina de renderizar el JS. Todo esto conduce inevitablemente a un LCP deficiente.

Lo que hicimos fue primero analizar qué JS que bloquean el renderizado teníamos en nuestras páginas. A partir de la investigación, vimos que los principales bloqueadores eran los botones para compartir en redes sociales, los bloques de comentarios de Facebook, los vídeos incrustados de YouTube y Sleeknote, que utilizábamos para los pop-ups.

Por ejemplo, los vídeos incrustados de YouTube por sí solos podían contribuir hasta un 30% de ahorro de tiempo para el LCP:

Aunque no era obligatorio, nos deshicimos de todos los scripts de terceros donde fue posible para obtener mejores puntuaciones LCP.

Al mismo tiempo, había páginas en las que queríamos mantener los botones para compartir en redes sociales, Sleeknote o los rastreadores de GA.

Para mantener estos elementos de la página sin comprometer el LCP, los sacamos de la ruta de renderizado crítica. Esto se hizo añadiendo uno de los siguientes atributos a la etiqueta «»:
<script>:

• async. Este atributo le dice al navegador que ejecute el script de forma asíncrona sin pausar el análisis de una página. Utilizamos este atributo para scripts que eran sensibles a la carga retrasada (Google Analytics):

Como simple complemento, aquí tienes una explicación visual de los atributos defer e y async:

Cabe destacar que debes evitar usar el atributo defer y usar asyncper varios scripts de seguimiento. En nuestro caso, nos faltaba casi el 15% de los datos de objetivos en Google Analytics después de mover el script de seguimiento al final del recorrido de renderizado.

Nota

La misma técnica se aplicó también a nuestro JS personalizado. Revisamos todo el JavaScript utilizado en nuestras páginas y analizamos qué partes eran irrelevantes para eliminarlas y cuáles debían conservarse: en la mayoría de los casos las hicimos cargar de forma asíncrona con el atributo async.

2. Optimización del uso de caracteres

– Métricas afectadas: LCP, CLS –

Las fuentes web son cruciales para un diseño atractivo, una mejor legibilidad y la identidad de marca, pero también son archivos pesados que pueden tardar en cargarse y perjudicar tanto el LCP como el CLS.

Si una fuente de terceros se utiliza para un bloque de texto que representa el elemento LCP, la puntuación LCP puede verse afectada negativamente porque el navegador tardará en cargar y recuperar esta fuente.

Con respecto al Cumulative Layout Shift, el principal problema de las fuentes de terceros es que antes de que se cargue una fuente específica, el navegador mostrará una fuente del sistema. Una vez cargada, la fuente de terceros puede ocupar más espacio en pantalla, lo que afecta la estabilidad visual de una página, provocando un desplazamiento del diseño y una puntuación CLS deficiente.

Así es como se ve el desplazamiento del diseño:

Antes de que las Core Web Vitals fueran algo, teníamos muchas fuentes diferentes en una sola página.

A veces, estas fuentes ni siquiera se utilizaban, pero se cargaban de todos modos. Como se puede ver en la captura de pantalla a continuación.

La fuente Roboto se utilizaba exclusivamente en la tooltip emergente, que no era visible en dispositivos móviles, pero al mismo tiempo, la fuente se cargaba igualmente.

También utilizábamos muchas fuentes externas, como Google Fonts, que se almacenaban fuera de nuestro servidor.

Por lo tanto, lo primero que hicimos fue eliminar todas las fuentes externas y pasar a las del sistema (Arial, Helvetica, Verdana, Tahoma, etc.). Esta simple solución funcionó extraordinariamente bien para nosotros y vimos una gran mejora tanto en las puntuaciones LCP como en las CLS.

También nos dimos cuenta de que podría haber casos en los que necesitáramos usar fuentes de terceros. Para tales casos, hacemos que la fuente se autoalberge en nuestros servidores y la precargamos en la sección head del HTML de una página. Como toque final, también nos aseguramos de no usar fuentes de iconos. Estas son las fuentes que se utilizan para reemplazar imágenes esquemáticas, como una lupa, utilizada para las barras de búsqueda. Estos iconos fueron reemplazados por imágenes SVG alojadas en nuestros servidores para que el navegador no tenga que cargarlas de fuentes externas cada vez.

Nota Importante

El autoalojamiento de fuentes web podría no ayudar a mejorar el LCP si su sitio web no utiliza CDN y HTTP/2. Intente experimentar tanto con fuentes autoalojadas como de terceros para ver qué solución funciona mejor para usted.

3. Extraer CSS y JS críticos

– Métricas afectadas: LCP –

El CSS es un recurso que bloquea la renderización, lo que significa que una página no se puede renderizar hasta que el navegador recupera y analiza todos los archivos CSS. Si el CSS es pesado, tardará mucho en cargarse, lo que afectará directamente la puntuación LCP.

En nuestro caso, no era solo el tamaño del CSS que utilizábamos. Antes de comenzar los trabajos de optimización, teníamos una única hoja de estilo CSS para todas las páginas, con más de 70.000 líneas. El mismo CSS pesado se cargaba para cada página, incluso si no se utilizaba allí.

Para solucionar esto, primero consultamos el informe de cobertura en las Herramientas para desarrolladores de Chrome. Luego revisamos todo el contenido de ese archivo CSS y nos deshicimos de todas las líneas irrelevantes. Esto nos permitió reducir significativamente su tamaño real y el porcentaje de bytes no utilizados.

Nota

Para reducir aún más el tamaño de nuestros archivos CSS y asegurarnos de que no afecten negativamente la puntuación LCP, también los sometimos a un proceso de minificación de CSS.

Las hojas de estilo CSS a menudo contienen comentarios, espacios y saltos de línea superfluos, y deshacerse de todo esto a menudo puede ayudar a reducir el tamaño final del archivo hasta en un 50%. Utilizamos CSS Minifier para reducir el tamaño de nuestro CSS y JSCompress para hacer lo mismo con el JavaScript que bloquea la renderización.

Al final, nuestro equipo de desarrollo desarrolló una herramienta dedicada, que ahora gestiona la minificación de forma automática.

Además, al igual que con el JS, no había necesidad de cargar el mismo CSS enorme para cada página cada vez. Por lo tanto, extrajimos solo los estilos necesarios para el área sobre el pliegue de una página específica y los añadimos al archivo HTML de esa página.

4. Compresión de contenido HTTP

– Métricas afectadas: LCP –

La compresión de contenido HTTP es una excelente práctica para reducir el tamaño de los archivos transferidos entre el servidor y el navegador. Esto puede reducir significativamente los tiempos de carga de las páginas y mejorar la puntuación LCP.

Para comprimir el contenido HTTP, configuramos la compresión gzip en nuestro servidor. Esto permitió reducir significativamente el tamaño de los archivos que se envían al navegador, mejorando así el LCP.

La compresión gzip es una técnica de compresión de datos que reduce el tamaño de los archivos sin perder información. Esto permite transferir los archivos más rápido y, por lo tanto, mejorar el tiempo de carga de las páginas.

5. Optimización de imágenes

– Métricas afectadas: LCP –

Las imágenes no optimizadas pueden ralentizar la carga de las páginas y afectar negativamente la puntuación LCP. Por lo tanto, prestamos especial atención a la optimización de las imágenes para mejorar el rendimiento de las Core Web Vitals.

Para optimizar las imágenes, seguimos los siguientes pasos:

• Redimensionamos las imágenes a las dimensiones reales en las que deben mostrarse en la página. La reducción de las dimensiones físicas de las imágenes puede reducir significativamente su tamaño de archivo y acelerar el proceso de carga.
• Utilizamos un formato de compresión adecuado para cada imagen. Por ejemplo, las imágenes con pocos detalles y colores planos se convirtieron a formatos como PNG o SVG, que ofrecen una mejor compresión para este tipo de imágenes. Las imágenes con muchas gradaciones o detalles complejos se convirtieron al formato JPEG, que es más adecuado para imágenes complejas.
• Utilizamos herramientas de compresión de imágenes para reducir aún más el tamaño de los archivos. Estas herramientas reducen el tamaño de los archivos sin perder calidad visual.
• Implementamos la compresión progresiva de imágenes para mejorar la experiencia del usuario durante la carga de las páginas. La compresión progresiva permite mostrar una vista previa de la imagen mientras se carga, en lugar de esperar a que se cargue por completo.

La optimización de las imágenes tuvo un impacto significativo en la puntuación LCP y el tiempo de carga de las páginas en general. Notamos una mejora notable en el rendimiento después de implementar estas optimizaciones.

6. Ajustes finales

Después de completar los pasos anteriores, realizamos los ajustes finales para optimizar aún más las Core Web Vitals.

Llevamos a cabo un análisis exhaustivo de nuestras páginas para identificar cualquier otro problema que pudiera afectar la puntuación de las CWV. Por ejemplo, comprobamos si había scripts o recursos adicionales que estuvieran bloqueando la renderización o causando retrasos en la interactividad.

También verificamos el uso de cookies en nuestro sitio web y minimizamos el número de cookies utilizadas para evitar ralentizaciones en el rendimiento.

Finalmente, realizamos numerosas pruebas y monitorizamos constantemente el rendimiento de las Core Web Vitals utilizando herramientas como Google Search Console, PageSpeed Insights y Lighthouse.

Resultados de las optimizaciones de Core Web Vitals

Después de realizar todas las optimizaciones descritas anteriormente, notamos una mejora significativa en las puntuaciones de las Core Web Vitals.

La puntuación LCP mejoró notablemente, con un tiempo de carga inferior a 2,5 segundos. La puntuación FID disminuyó a menos de 100 milisegundos, lo que hizo que la página fuera más receptiva a la entrada del usuario. La puntuación CLS se mantuvo por debajo de 0,1, garantizando una mayor estabilidad visual.

Estas mejoras tuvieron un impacto directo en el rendimiento general de las páginas. Notamos un aumento significativo en los clics orgánicos y las impresiones, lo que indica una mejor experiencia del usuario y una mejor clasificación en Google.

La optimización de las Core Web Vitals es un proceso continuo

Es importante destacar que la optimización de las Core Web Vitals es un proceso continuo. El rendimiento de las páginas puede deteriorarse con el tiempo debido a nuevos cambios o actualizaciones, por lo que es fundamental monitorizar constantemente las CWV y realizar las correcciones o mejoras necesarias.

Seguiremos vigilando las Core Web Vitals de link-assistant.com e implementando optimizaciones adicionales si es necesario. Mantener una buena experiencia de usuario y un alto posicionamiento en los rankings de Google es fundamental para el éxito de nuestro sitio web.

Consideraciones Finales

Las Core Web Vitals se han convertido en un factor de ranking esencial para Google. Optimizar las CWV puede tener un impacto significativo en el rendimiento de las páginas, la experiencia del usuario y el posicionamiento en los rankings de Google.

En nuestro estudio de caso sobre las Core Web Vitals, demostramos cómo mejoramos las CWV para link-assistant.com y cómo esto nos ayudó a recuperarnos de una caída repentina en las posiciones del ranking.

Las optimizaciones que realizamos incluyen la configuración de servidores y CDN geográficos específicos, la postergación de JS de terceros, la optimización del uso de fuentes, la extracción de CSS y JS críticos, la compresión del contenido HTTP, la optimización de imágenes y los ajustes finales.

Estas optimizaciones llevaron a una mejora significativa de las Core Web Vitals y tuvieron un impacto positivo en el rendimiento de las páginas y en los resultados orgánicos.

Recuerde que la optimización de las Core Web Vitals es un proceso continuo. Es importante monitorizar constantemente el rendimiento de las páginas, realizar correcciones o mejoras y mantenerse al día con las últimas directrices y mejores prácticas de Google para garantizar una experiencia de usuario óptima y un alto posicionamiento.

Artículo adaptado de Link-Assistant

Pubblicato in Marketing Digital, SEO