Home Artículos técnicos Cómo optimizar los principales Web Vitals para sitios web de comercio electrónico
Applications

Cómo optimizar los principales Web Vitals para sitios web de comercio electrónico

About The Author

Outline

La próxima actualización de Google Page Experience introduce señales derivadas de Core Web Vitals (CWV) en el algoritmo de clasificación oficial. Core Web Vitals son un conjunto de métricas que miden la velocidad a la que las páginas se cargan, se vuelven interactivas y se estabilizan visualmente para los usuarios reales que interactúan con ellas. Los sitios web que no cumplan con la prueba Core Web Vitals se clasificarán por debajo de lo que actualmente tienen a principios de 2021.

CWV consiste en métricas de 3 velocidades que se ha encontrado que tienen un impacto significativo en la experiencia percibida de un usuario. Estos incluyen la Pintura Contenida (LCP) más grande para medir los tiempos de carga, el primer retardo de entrada (FID) para medir la interactividad y la capacidad de respuesta, y el cambio de diseño acumulativo (CLS) para medir la estabilidad visual. Si bien la velocidad del sitio web ha estado a la vanguardia para muchas empresas de comercio electrónico, está a punto de convertirse en uno de los factores más importantes en el panorama en línea. Aquí están las métricas en las que debe centrarse y cómo mejorar la velocidad para cada uno.

¿Cuáles son los principales Web Vitals

Hacer una buena primera impresión en línea es crítico. Los compradores quieren ver los productos de inmediato, navegar rápidamente y realizar el pago fácilmente, sin interrupciones. Si sus expectativas no se cumplen, rebotarán y nunca regresarán. Core Web Vitals ayuda a abordar este problema al medir la experiencia que las páginas proporcionan a los compradores móviles mientras navegan a través de un sitio en tiempo real.

Mientras que la mayoría de las herramientas de Google se basan en pruebas sintéticas en entornos simulados (conocidos como datos de laboratorio), los Core Web Vitals se miden utilizando datos de campo recopilados de Google Chrome User Experience (CRUX), una base de datos de usuarios de Chrome del mundo real. Los datos de campo capturan los efectos dramáticos de las variables de usuario real, como el dispositivo, las condiciones de red y/o la configuración. Dependiendo de las condiciones de un usuario, el rendimiento de un sitio puede variar drásticamente e impactar sus puntuaciones vitales de Core Web.

Cada métrica de CWV tiene diferentes umbrales para ser considerada buena, moderada o pobre. Sin embargo, todos tienen una cosa en común: Google utiliza el percentil 75 al clasificar las páginas en estos grupos: Una página que llega al umbral para ser considerada rápida durante el 75% de las cargas de página o más es una buena experiencia.

No puedes optimizar lo que no sabes, así que vamos a conocer cada una de las tres métricas que componen los Core Web Vitals.

Fuente: https://web.dev/vitals/

La pintura más grande con contenido (LCP)

Los usuarios suelen sentir que la página se ha cargado cuando el elemento de contenido más grande está completamente visible en la pantalla, es decir, por la velocidad de la pintura de contenido más grande, o LCP. Los elementos de contenido pueden incluir elementos de nivel de bloque, imágenes (incluidas imágenes dentro de archivos SVG) y videos. Para el comercio electrónico, los LCP suelen medir la velocidad a la que se carga la imagen del producto/la imagen del héroe. Si esto es lento, los usuarios asumen que toda la experiencia será similar, lo que los lleva a salir al sitio de un competidor.

Los LCPS de 2,5 segundos o menos se consideran rápidos, las páginas con LCP de entre 2,6 y 4,0 segundos necesitan mejoras, y los LCP de más de 4,0 segundos son lentos.

TheTieBar.comcargas LCP en 800 ms en Layer0 (Edgio)

En el ejemplo anterior, el LCP de Tie Bar está marcado a 900 ms cuando la imagen principal está completamente pintada. Tie Bar ofrece constantemente cargas de página de sub-segundo a los compradores móviles mientras ofrece personalización, búsquedas de inventario en tiempo real y precios dinámicos en sus miles de páginas en Edgio.

Típicamente, LCP se ve afectado por uno de los siguientes:

  • Tiempos de respuesta del servidor lentos
  • Bloqueo de renderizado JavaScript y CSS
  • Largos tiempos de carga de recursos
  • Problemas de renderizado del lado del cliente

Para optimizar su LCP, considere lo siguiente:

  1. Optimice los tiempos de respuesta del servidor enrutando el tráfico a la CDN pop más cercana disponible, almacenando en caché activos, utilizando un service worker y estableciendo conexiones de terceros temprano con “rel=”preconnect”.”
  2. Reduzca el tiempo de bloqueo de JavaScript minimizando código (por ejemplo, eliminando espacios en blanco), comprimiendo datos con herramientas como Broti o Gzip, dividiendo paquetes y enviando solo lo necesario al principio, y sirviendo código con sintaxis más reciente con herramientas como Babel. Reduzca el CSS eliminando cualquier CSS no utilizado o caracteres innecesarios como espaciado, sangría o comentarios, e incorporando CSS crítico al incluirlo directamente en la cabecera de la página.
  3. Para reducir los tiempos de carga de recursos, optimice y comprima archivos de imagen y texto, cargue previamente los recursos esenciales y entregue diferentes activos basados en la conexión de red y los activos de caché utilizando un service worker.
  4. Optimice el renderizado del lado del cliente reduciendo el tiempo de bloqueo de JavaScript (consulte # 2 para optimizar para esto), utilizando el renderizado del lado del servidor (SSR) y el pre-renderizado.

Primer retardo de entrada (FID)

Si bien la primera impresión de un usuario se ve afectada por la velocidad a la que se procesa la imagen más grande, es igualmente crucial que tu sitio responda una vez que el usuario intenta interactuar con él. El primer retraso de entrada, o FID, mide el tiempo desde que un usuario interactúa por primera vez con una página (hace clic, toca o presiona una tecla) hasta el momento en que el navegador puede responder a esa interacción.

Normalmente, se produce un retardo de entrada porque JavaScript se ejecuta en el subproceso principal, y todo JavaScript está bloqueando de forma predeterminada. Esto significa que cuando el navegador se encuentra con un archivo JavaScript, debe pausar lo que está haciendo para descargar, analizar, compilar y ejecutar ese JavaScript. Cuanto más tiempo dure esto, más retraso tendrá la experiencia del usuario y menos verá Google la página como utilizable.

Google considera un FID de 100 milisegundos o menos tan rápido, entre 1,1 y 3,0 segundos como que necesita mejora, y más de 3,0 segundos como lento. Si bien es importante esforzarse por alcanzar el percentil 75 para todos los Core Web Vitals, Google recomienda mirar los percentiles 95–99 para FID en dispositivos móviles y de escritorio, ya que esto representará las peores experiencias de usuario y verificará las áreas que necesitan mayor mejora (ya que se centrará en el FID para más del 95% de las cargas de página).

También es importante tener en cuenta que, a diferencia de LCP y CLS, el FID solo se puede medir en el campo (y no se encontrará en los datos de laboratorio), ya que requiere una interacción real del usuario. ‍

Las razones comunes para los FIDs lentos incluyen:

  1. Tareas largas que bloquean el hilo principal durante 50 milisegundos o más
  2. Ejecución de script de primera parte que retrasa la preparación de la interacción
  3. Tiempo de ejecución de JavaScript pesado

‍How Para optime para FID:

  1. Descompone el código de larga duración en tareas más pequeñas y asíncronas y utilice la división de código.
  2. Mueva la carga (y la ejecución) pesada de scripts para componentes no esenciales fuera de la ruta crítica y minimice la obtención de datos en cascada y la cantidad de datos que se deben postprocesar en el lado del cliente.
  3. Utilice un trabajador web, como Comlink, Workway o Workerize, que hace posible ejecutar JavaScript en un hilo de fondo, dividir código su paquete de JavaScript en varios fragmentos (también conocidos como lazy-loading), y cargar todos los scripts de terceros con diferir o async.

Cambio de diseño acumulativo (CLS)

La estabilidad visual de una página es otro factor que contribuye a la experiencia del usuario y puede impedir que los compradores continúen por el camino hacia la compra. La tercera y última métrica en Core Web Vitals es el cambio de diseño acumulativo, o CLS, que mide la frecuencia con la que los usuarios experimentan cambios de diseño inesperados.

Has experimentado estos casos: Estás a punto de tocar un enlace o una imagen de producto, pero justo antes de tocar la pantalla, la página se mueve, y bam, haces clic en otra cosa sin querer. En el mejor de los casos, estas situaciones son una leve molestia, pero en el peor de los casos, envías a los compradores en busca de una experiencia más suave y menos torpe en la web.

Google calcula estos movimientos de página multiplicando la fracción de impacto, o la cantidad de contenido visible desplazado en el visor, por la fracción de distancia , o la distancia que un elemento inestable ha movido en el fotograma dividido por la dimensión más grande de la pantalla (altura o ancho). El total de todas las puntuaciones individuales ( fracción de impacto x fracción de distancia ) para cada cambio de diseño inesperado que ocurre mientras un comprador explora los resultados en el CLS de una página.

Google considera un CLS inferior a 0,1 como bueno, entre 0,1 y 0,25 como moderado, y mayor a 0,25 como pobre. ‍

Si encuentra un CLS pobre, es probable que se deba a uno de los siguientes:

  1. Una imagen o vídeo que se redimensiona a sí mismo
  2. Redimensionamiento de anuncios
  3. Una fuente que se carga tarde y se muestra más grande o más pequeño de lo previsto

Para mejorar esta métrica, considere lo siguiente:

  1. Incluye las dimensiones exactas de tus imágenes y elementos de vídeo.
  2. Evita anuncios emergentes o banners. En su lugar, reserve estáticamente un gran espacio para la ranura de anuncios.
  3. Evite los flashes de texto sin estilo o invisible (FOIT/FOUT) con herramientas como la pantalla de fuente y la API de carga de fuentes .

Cómo Layer0 ayuda a optimizar la velocidad para cada métrica de Core Web Vitals

Los sitios web de comercio electrónico grandes y complejos con millones de páginas, 1000s de SKU, pruebas A/B y personalización, precios dinámicos y búsquedas de inventario en tiempo real pueden alcanzar velocidades de sub-segundos con Layer0. De hecho, Layer0 es la única plataforma en el mercado que garantiza LCP medianos inferiores a 500 ms.

En Layer0, el contenido se renderiza instantáneamente, o pinta, en una página y se vuelve inmediatamente tocable debido a nuestra CDN configurable de JavaScript que conoce la aplicación, llamada CDN-as-JavaScript. Utiliza prefetching predictivo avanzado y computación perimetral para transmitir contenido dinámico (JSON/SSR/HTML) desde el perímetro hasta el navegador del usuario, incluso antes de que se solicite. Esto mantiene los sitios 5 segundos por delante de los golpes de los compradores en todo momento.

Los sitios web en Layer0 tienen una relación de aciertos de caché de más del 95% para los datos HTML y JSON en el perímetro, mientras que los sitios en CDN tradicionales promedian un 6%. Esta es una gran diferencia en la entrega del contenido que normalmente hace que un sitio web sea lento.

Conclusión

Las cargas de página rápidas diferencian entre deleitar a los compradores y asustarlos para el sitio de tu competencia. Core Web Vitals Considera la primera impresión de velocidad, interactividad y estabilidad visual de un usuario midiendo la Pintura Contenida más grande, el primer retardo de entrada y el cambio de diseño acumulativo. Si las velocidades son superiores a 2,5 segundos para LCP, 100 ms para FID o .1 para CLS, puede asumir que tanto los usuarios como Google perciben su sitio como lento. Google bajará tu rango, y los consumidores rebotarán y nunca volverán.

En solo un par de meses, una mala experiencia de página dañará la reputación de tu marca e impactará tu ranking SEO. Proteja su SEO duramente ganado utilizando las tácticas de optimización ofrecidas anteriormente, o vaya instantáneamente con Layer0 (ahora Edgio).

Layer0 es su solución todo en uno para desarrollar, implementar, previsualizar, experimentar, monitorear y ejecutar su frontend. Shoe Carnival, REVOLVE y 1-800-Flowers, son solo algunos ejemplos de sitios web de comercio electrónico que ofrecen velocidades de menos de segundos y están cosechando los beneficios de ella. Si tiene alguna pregunta sobre la actualización de la experiencia de página o cómo acelerar su sitio, estaremos encantados de ponerle en contacto con un experto en velocidad de sitio hoy mismo.

La próxima actualización de Google Page Experience introduce señales derivadas de Core Web Vitals (CWV) en el algoritmo de clasificación oficial. Core Web Vitals son un conjunto de métricas que miden la velocidad a la que las páginas se cargan, se vuelven interactivas y se estabilizan visualmente para los usuarios reales que interactúan con ellas. Los sitios web que no cumplan con la prueba Core Web Vitals se clasificarán por debajo de lo que actualmente tienen a principios de 2021.