Home Artículos técnicos El núcleo de Web Vitals
Applications

About The Author

Outline

Introducción

Desde su introducción en mayo de 2020, la suite Core Web Vitals (CWV) de Google se ha convertido en una métrica importante para medir el rendimiento del sitio web. Dado que Google considera estos valores como parte de su algoritmo de clasificación de páginas, maximizar el rendimiento de su sitio web en términos de CWV no solo mejora la experiencia de sus usuarios, sino que mejora su clasificación en los motores de búsqueda. Este artículo explorará consejos y técnicas para ayudar a mejorar las puntuaciones de su página, aumentar la satisfacción del usuario y aumentar su resultado final.

¿Qué son Core Web Vitals?

Al igual que muchas otras cosas en tecnología, los Web Vitals de Google son un enjambre de acrónimos de tres letras, cada uno representa un aspecto medible del rendimiento de un sitio web. Para establecer el escenario, definamos las tres métricas clave que definen los Core Web Vitals:

La pintura contentful más grande

Pintura contentosa más grande (LCP): Mide la velocidad de carga percibida centrándose en la cantidad de tiempo que tarda el contenido visible sobre el pliegue en cargarse. Para proporcionar una experiencia de usuario ideal, LCP debe activarse en 2,5 segundos en la línea de tiempo de carga de la página.

Primer retraso de entrada

Primer retraso de entrada (FID): Mide la capacidad de respuesta de la página midiendo el retraso entre las acciones del usuario y la respuesta de la página. Para proporcionar una experiencia de usuario ideal, las páginas deben tener un FID de 100 milisegundos o menos.

Cambio de diseño acumulativo

Cambio de diseño acumulativo (CLS): Mide la estabilidad visual utilizando una medición compuesta de los cambios de diseño en la página a medida que se renderiza. Para proporcionar una experiencia de usuario ideal, las páginas deben mantener un CLS de 0,1 o menos; todo entre 0,1 y 0,25 se considera moderado y mayor de 0,25 es pobre.

… ¿y por qué son importantes?

Para muchas empresas, el rendimiento del sitio web tiene una correlación directa con el éxito empresarial. Las investigaciones indican que los sitios web con puntuaciones CWV que superan pueden disfrutar de hasta un 37% más de visibilidad en los resultados de búsqueda en comparación con las páginas que no (Beus); y que las puntuaciones CWV mejoradas pueden aumentar tanto los ingresos por visitante como la tasa de conversión (Duong et al.).

Mientras trabaja con Akira, Una boutique de moda femenina, Edgio fue capaz de mejorar los CWV del sitio web, llevando los tiempos de carga de la primera página de 5 segundos a ~1 segundo, mejorando las mediciones de CWV y finalmente entregando un aumento del +30% en el tráfico orgánico, una mejora del +61% en las iniciaciones de pago, y un aumento del 37% en la tasa de conversión.

En pocas palabras, los sitios web más rápidos hacen que haya mejores rankings SEO y usuarios más felices, específicamente en el contexto de los sitios web de comercio electrónico; estos se combinan para disminuir las tasas de rebote y aumentar las conversiones.

Entonces, ¿cómo podemos mejorarlos?

Primer retraso de entrada

Comencemos con la fruta baja: Primer retraso de entrada. La buena noticia es que los sitios web tienen puntuaciones de FID más a menudo que no, ¡lo cual es genial para ver! Sin embargo, si ese no es el caso, a menudo, el culpable son los scripts de terceros cargados al principio del ciclo de vida del sitio web, que pueden bloquear la ejecución del hilo principal necesaria para recibir la entrada del usuario. Las herramientas que capturan errores y realizan la grabación de pantalla son los candidatos principales para un escrutinio adicional.

De hecho, cualquier cosa que bloquee el hilo de ejecución principal puede contribuir a un rendimiento deficiente de FID. Mantente atento a las tareas de JavaScript de uso intensivo de recursos o de larga duración, y considera refactorizar código no relacionado con la interfaz de usuario a un trabajador web, así como usar técnicas de carga lenta y división de código para garantizar que solo se cargue el JavaScript requerido y solo cuando sea necesario.

Además, aunque técnicamente no es un elemento central de los CWV, vale la pena mencionar otra métrica relacionada: Interacción con la pintura siguiente (INP). INP mide el tiempo entre la interacción con una página y la actualización de la página posterior que refleja esa interacción. Mientras que el INP y el FID miden la respuesta general de la página, el INP se ocupa de todas las interacciones de la página en lugar de la primera interacción, con el objetivo de garantizar que la página permanezca receptiva durante toda la sesión, no solo las interacciones iniciales. INP realiza un seguimiento del peor rendimiento de interacción en la experiencia de un usuario y lo informa para que se desactive. Es muy probable que pronto la INP reemplace a la FID como una medida de la capacidad de respuesta de la página, por lo que vale la pena vigilar.

La pintura contentful más grande

Podría decirse que la métrica más importante e impactante para el rendimiento de la página es LCP. De manera algo predecible, el ejemplo más común de Pintura contentosa más grande es una imagen de “héroe”, una imagen o video grande, que generalmente ocupa todo el ancho de la vista sobre el “pliegue”. Aunque las técnicas para optimizar este elemento son las mismas que cualquier otro recurso de página, el tiempo que tarda en renderizar ese recurso es de máxima importancia porque este es el primer elemento principal que experimentará un usuario.

Esperando en la cola
Desglosar el tiempo de solicitud para el elemento LCP es tremendamente útil para optimizar su rendimiento. Cualquier solicitud realizada por un navegador comienza con la cola. Cada milisegundo que las solicitudes LCP gastan en la cola es un milisegundo que contribuirá a la puntuación LCP, por lo que si descubre que estos elementos están pasando una cantidad desproporcionada de tiempo languideciendo en la cola del navegador, investigue qué se está solicitando antes y por qué, y tome medidas para priorizar los recursos de LCP. Tal vez los recursos están por debajo del pliegue, u otros scripts que pueden ser cargados perezosamente o diferidos de otra manera. El orden de las operaciones es clave.

Esperando en el servidor
Después de iniciar la solicitud de red, el cliente del navegador tiene que esperar a que el servidor reciba, procese y responda a esa solicitud. Esta métrica se llama tiempo al primer byte (TTFB). Si el servidor es lento para responder a la solicitud, su puntuación LCP sufrirá. Esta es una de las áreas en las que tener una CDN puede afectar significativamente la mejora de la velocidad, ya que las CDN pueden mantener una copia en caché del recurso en una ubicación geográficamente cercana a sus usuarios finales y responder con ese recurso más rápidamente que un solo servidor de aplicaciones. Otros grandes aspectos del uso de una CDN incluyen WAFs de seguridad incorporados y la capacidad de responder a grandes picos de tráfico. Si vas por la velocidad, deberías usar una CDN.

Ancho en el cable
En este punto, esperemos que el navegador solicite los recursos LCP al principio del ciclo de vida de la página, y el servidor debería responder a ellos rápidamente. El siguiente elemento a considerar es el tamaño general del recurso solicitado. Cada byte que tenga que viajar “por cable” al navegador tomará algún tiempo, y cuanto más de esos bytes haya, más tiempo tardará en completarse la solicitud. Por lo tanto, debe tenerse cuidado de garantizar que los recursos sean lo más pequeños posible para minimizar el tiempo dedicado a transferirlos. Esto podría incluir el uso de servicios de optimización de imágenes y hosting de terceros como kraken.io o imgix.com, que pueden optimizar y servir archivos multimedia en formatos “NextGen” como WebP, reduciendo aún más el tamaño.

Ayuda al Navegador
Además de las optimizaciones de tamaño, considere el uso de <etiquetas de imagen> , que permitirán al navegador elegir el recurso adecuado para solicitar el dispositivo de manera más inteligente. Un navegador de escritorio puede tener grandes extensiones de pantalla real para mostrar imágenes de mayor resolución; sin embargo, esos mismos recursos empantanarán un dispositivo móvil con una pantalla más pequeña. Al utilizar recursos optimizados y consultas de medios CSS, puede asegurarse de que el navegador solicite el recurso adecuado para su tipo de dispositivo y reducir el tiempo dedicado a transferir bytes desde el servidor al cliente.

Además, puede darle al navegador una mano de ayuda pidiéndole que precargue recursos LCP y especifique una prioridad de búsqueda. Esto le dará al navegador pistas para priorizar los recursos clave por delante de los menos críticos. Cuanto más rápido lleguen las cosas al navegador, más rápido se pueden representar, y cuanto más rápido ocurra el LCP, mejor.

Cambio de diseño acumulativo

Lo vemos todo el tiempo. Después de enviar su navegador para buscar un sitio web, la página comienza a cargarse; mientras la página se construye, ves la pieza que te interesa y mueves a hacer clic en ella cuando de repente toda la página cambia y el enlace que creías que estabas a punto de hacer clic está de repente en otro lugar! Este fenómeno se llama desplazamiento de diseño. Es molesto para todos, generalmente autoinfligido, y debemos esforzarnos por minimizarlo por el bien de la humanidad.

Los sospechosos habituales
Los culpables típicos de las puntuaciones más altas de CLS son:

  • Cabeceras pegajosas
  • Banners promocionales o “héroe” que se cargan y renderizan del lado del cliente
  • Boletín de noticias, cupones y avisos de GPDR
  • Otras integraciones de terceros que se inyectan dinámicamente en la página

Establece algunos límites
¿Recuerdas el <elemento de imagen> al que nos referimos mientras discutíamos LCP? No olvides añadir dimensiones a los diversos elementos contenidos en él. Omitir estos valores te saca del asiento del conductor al dirigir al navegador sobre cómo representar estos elementos. Al definir las dimensiones, el navegador puede reservar la cantidad correcta de espacio en el que se pintará la imagen, lo que reduce el cambio.

Lo mismo se aplica a cualquier contenido que se pueda agregar dinámicamente a la página. Los anuncios, <iframe>, u otro contenido agregado dinámicamente pueden contribuir a CLS. El contenido de la página cambiará menos reservando espacio para estos elementos con anticipación. Además, evite agregar el contenido por encima del contenido de la página existente, ya que esto hará que toda la página se desplace a continuación.

Ayudar al navegador a crear el espacio antes de tiempo reducirá el CLS, pero puede llegar a expensas de la experiencia general del usuario, ya que el usuario espera a que estas partes de la página en blanco se llenen con contenido útil. Como punto medio, la implementación de esqueletos de carga de elementos puede ser una técnica útil para comunicar al usuario que hay más por venir, dando la impresión de una experiencia más rápida mientras el navegador hace el resto de la carga pesada para coordinar el contenido adicional de la página. Lo que es más es que estos pueden y deben ser implementados usando animaciones CSS en lugar de GIF animados, lo que significa que solo unas pocas líneas de CSS se pueden utilizar para implementar esta técnica en todo su sitio web.

Envolviendo

En la superficie, Core Web Vitas puede parecer como las últimas piezas del legendario y sombrío algoritmo de Google para determinar el rango de página dentro de sus resultados de búsqueda, y hasta cierto punto, eso podría ser correcto. Sin embargo, más que eso, los Core Web Vitals representan un marco más concreto para medir el rendimiento de la página y establecer una base para describir las cosas que importan en términos de experiencia del usuario. Aunque no son exhaustivas, las técnicas mencionadas anteriormente deberían ayudarte a mejorar la resolución de problemas y optimizar el rendimiento de tu sitio web, con suerte, lo que se traducirá en mejoras en la experiencia del usuario, el rango de página y los ingresos.