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 tu sitio web en términos de CWV no solo mejora la experiencia de tus usuarios, sino que mejora tu posicionamiento 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 representando algún aspecto medible del rendimiento de un sitio web. Para establecer el escenario, definamos las tres métricas clave que definen los principales Web Vitals:
La pintura más grande y contentful
Pintura con contenido más grande (LCP): Mide la velocidad de carga percibida centrándose en la cantidad de tiempo que tarda en cargar el contenido visible sobre el pliegue. Para proporcionar una experiencia de usuario ideal, LCP debe activarse dentro de los 2,5 segundos en la línea de tiempo de carga de la página.
Primer retraso de entrada
Primer retardo de entrada (FID): Mide la capacidad de respuesta de la página midiendo el retardo 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 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 del negocio. Las investigaciones indican que los sitios web con puntuaciones aprobadas de CWV 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 lo hacen (Beus); y que las puntuaciones mejoradas de CWV pueden aumentar tanto los ingresos por visitante como la tasa de conversión (Duong et al.).
Mientras trabajaba con AkiraEdgio, una boutique de moda femenina, 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, en última instancia, entregando un aumento de +30% en el tráfico orgánico, una mejora de +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 permiten una mejor clasificación de 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 han aprobado las puntuaciones de FID más a menudo que no, ¡lo cual es genial de 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 necesario para recibir la entrada del usuario. Las herramientas que capturan errores y realizan grabaciones de pantalla son las mejores candidatas para un escrutinio adicional.
De hecho, cualquier cosa que bloquee el hilo de ejecución principal puede contribuir a un rendimiento FID pobre. Mantenga una estrecha vigilancia en las tareas de JavaScript que requieren muchos recursos o que duran mucho tiempo, y considere 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 siguiente pintura (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 INP y FID miden la capacidad de respuesta general de la página, 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 siga respondiendo durante toda la sesión, no solo las interacciones iniciales. INP rastrea el peor rendimiento de interacción a través de la experiencia de un usuario y lo informa a crux. Es muy probable que pronto INP reemplace a FID como medida de la capacidad de respuesta de la página, por lo que vale la pena vigilar.
La pintura más grande y contentful
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 Contenida más grande es una imagen de “héroe”, una imagen o video grande, que usualmente ocupa todo el ancho de la vista por encima del “pliegue”. Aunque las técnicas para optimizar este elemento son las mismas que cualquier otro recurso de página, el tiempo que tarda ese recurso en renderizar 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 de las solicitudes LCP que pasan en la cola es un milisegundo que contribuirá a la puntuación LCP, por lo que si encuentra que estos elementos están gastando una cantidad desproporcionada de tiempo languideciendo en la cola del navegador, investigue qué se solicita antes de ella y por qué, y tome medidas para priorizar los recursos LCP. Tal vez los recursos están debajo del pliegue, u otros scripts que pueden ser cargados perezosos 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 el 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 los usuarios finales y responder con ese recurso más rápidamente que un solo servidor de aplicaciones. Otros grandes aspectos de usar 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.
Amplio en el cable
En este punto, con suerte, el navegador estará solicitando los recursos LCP al principio del ciclo de vida de la página, y el servidor debería estar respondiendo a ellos rápidamente. El siguiente elemento a considerar es el tamaño general del recurso solicitado. Cada byte que tiene que viajar “sobre el cable” al navegador tomará algún tiempo, y cuanto más de esos bytes haya, más tiempo tomará completar la solicitud. Por lo tanto, se debe tener cuidado de garantizar que los recursos sean lo más pequeños posible para reducir al mínimo el tiempo dedicado a transferirlos. Esto podría incluir el uso de servicios de hosting y optimización de imágenes 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 hacia fuera
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 forma más inteligente. Un navegador de escritorio puede tener grandes franjas de bienes raíces de pantalla para mostrar imágenes de mayor resolución; sin embargo, esos mismos recursos atascarán un dispositivo móvil con una pantalla más pequeña. Con recursos optimizados y consultas de medios CSS, puede asegurarse de que el navegador solicita el recurso adecuado para su tipo de dispositivo y reducir el tiempo dedicado a transferir bytes del servidor al cliente.
Además, puede ayudar al navegador pidiéndole que precargue los recursos LCP y especifique una prioridad de búsqueda. Estos le darán pistas al navegador 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 renderizar, y cuanto más rápido suceda 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 que la página se construye, usted ve la pieza en la que está interesado y se mueve para hacer clic cuando de repente toda la página cambia y el enlace que pensó que estaba a punto de hacer clic es de repente en otro lugar! Este fenómeno se llama cambio 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 puntajes más altos de CLS son:
- Cabeceras adhesivas
- Banners promocionales o “héroe” que se cargan y renderizan del lado del cliente
- Boletín de noticias, cupones y avisos GPDR
- Otras integraciones de terceros que se inyectan dinámicamente en la página
Establezca algunos límites
<>¿Recuerdas el elemento de imagen al que nos referenciamos mientras discutimos LCP? No olvides añadir dimensiones a los diversos elementos contenidos en el mismo. Omitir estos valores lo saca del asiento del conductor cuando dirige el navegador sobre cómo renderizar estos elementos. Al definir las dimensiones, el navegador puede reservar la cantidad correcta de espacio en el que se pintará la imagen, reduciendo el desplazamiento.
Lo mismo ocurre con cualquier contenido que pueda agregarse dinámicamente a la página. Los anuncios, <iframe>, u otro contenido añadido 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 cambie a continuación.
Ayudar al navegador a labrar el espacio con anticipación reducirá el CLS, pero puede venir 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, implementar 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 que el navegador hace el resto del trabajo pesado para coordinar el contenido adicional de la página. Lo que es más, es que estos pueden y deben implementarse utilizando animaciones CSS en lugar de GIF animados, lo que significa que solo unas pocas líneas de CSS se pueden usar para implementar esta técnica en todo su sitio web.
Terminación
A primera vista, Core Web VITAS puede parecer las últimas piezas del fabuloso y sombrío algoritmo de Google para determinar el ranking de la 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 línea de base para describir las cosas que importan en términos de experiencia del usuario. Aunque no son exhaustivas, las técnicas antes mencionadas deberían ayudarte a solucionar problemas y optimizar el rendimiento de tu sitio web, lo que se espera que resulte en mejoras en la experiencia del usuario, el ranking de la página y los ingresos.
