Home Artículos técnicos Cómo Optimizar Core Web Vitals para Sitios Web de Comercio Electrónico
Applications

Cómo Optimizar Core Web Vitals para Sitios Web de Comercio Electrónico

About The Author

Outline

La próxima actualización de Page Experience de Google introduce señales derivadas de Core Web Vitals (CWV) en el algoritmo de clasificación oficial. Core Web Vitals es 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 fallan en la prueba Core Web Vitals se clasificarán más bajo que en la actualidad a principios de 2021.

CWV consiste en métricas de 3 velocidades que tienen un impacto significativo en la experiencia percibida por un usuario. Estos incluyen la pintura contentful más grande (LCP) para medir los tiempos de carga, el primer retraso 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 Core Web Vitals

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

Si bien la mayoría de las herramientas de Google se basan en pruebas sintéticas en entornos simulados (conocidos como datos de laboratorio), Core Web Vitals se mide utilizando datos de campo recopilados de Google Chrome User Experience (CREX), 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 y afectar sus puntuaciones vitales de Core Web.

Cada métrica de CWV tiene diferentes umbrales para ser considerado bueno, moderado o pobre. Sin embargo, todos tienen una cosa en común: Google usa el percentil 75 al clasificar las páginas en estos grupos: Una página que alcanza el umbral para ser considerada rápida para 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 el Core Web Vitals.

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

Pintura contentful más grande (LCP)

Los usuarios normalmente sienten que la página se ha cargado cuando el elemento de contenido más grande es 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 a 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 de producto/imagen de héroe. Si esto es lento, los usuarios asumen que toda la experiencia será similar, lo que los lleva a irse al sitio de un competidor.

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

TheTieBar.comcargas LCP en 800ms 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áginas de subsegundos a los compradores móviles, al tiempo que ofrece personalización, búsquedas de inventario en tiempo real y precios dinámicos en sus miles de páginas en Edgio.

Típicamente, el 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 renderización del lado del cliente

Para optimizar su LCP, considere lo siguiente:

  1. Optimice los tiempos de respuesta del servidor enrutando el tráfico al pop CDN más cercano disponible, almacenando activos en caché, utilizando un service worker y estableciendo conexiones de terceros con “rel=”preconnect”.
  2. Reduzca el tiempo de bloqueo de JavaScript minificando 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 CSS eliminando cualquier CSS no utilizado o caracteres innecesarios, como espaciado, sangría o comentarios, e inlindando CSS crítico incluyéndolo 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, precargue 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 esto), utilizando el renderizado del lado del servidor (SSR) y el pre-renderizado.

Primer retraso de entrada (FID)

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

Por lo general, se produce un retraso de entrada porque JavaScript se ejecuta en el hilo principal, y todo JavaScript está bloqueando el renderizado 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 se tarda, más retraso experimentará el usuario y menos Google verá la página como utilizable.

Google considera que un FID de 100 milisegundos o menos es tan rápido, entre 1,1 y 3,0 segundos como necesario mejorar, 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 a 99 para FID en dispositivos móviles y de escritorio, ya que esto representará las peores experiencias de usuario y verificará las áreas que más necesitan mejoras (ya que se centrará en el FID para el 95% + de las cargas de página).

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

Las razones comunes para los FID 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 para la interacción
  3. Tiempo de ejecución de JavaScript pesado

‍How a optime para FID:

  1. Divide el código de larga duración en tareas asíncronas más pequeñas y utiliza la división de código.
  2. Mueva la carga (y ejecución) de scripts pesados 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 deben procesarse después del lado del cliente.
  3. Utilice un trabajador web, como Comlink, Workway o Workerize, que permite ejecutar JavaScript en un hilo de fondo, dividir en código su paquete JavaScript en varios fragmentos (también conocidos como lazy-loading), y cargar todos los scripts de terceros con defer o async.

Cambio de diseño acumulativo (CLS)

La estabilidad visual de una página es otro factor que influye en la experiencia del usuario y puede impedir que los compradores continúen por el camino de compra. La tercera y última métrica de Core Web Vitals es 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 ligera molestia, pero en el peor de los casos, se envía a los compradores que buscan una experiencia más suave y menos anodina en la web.

Google calcula estos movimientos de página multiplicando la fracción de impacto, o cuánto contenido visible se desplazó en la vista, por la fracción de distancia, o la distancia que un elemento inestable se ha movido en el marco 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 navega resulta 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 de 0,25 como pobre.

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

  1. Una imagen o video redimensionándose a sí mismo
  2. Redimensionamiento de anuncios
  3. Una fuente que se carga tarde y se muestra más grande o más pequeña 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. Evite los anuncios popup o banners. En su lugar, reserve estáticamente un gran espacio para el espacio publicitario.
  3. Evite los flashes de texto sin estilo o invisible (FOIT/FOUT) con herramientas como la visualización de fuentes 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 LCPs medianos por debajo de 500 ms.

En Layer0, el contenido se reproduce instantáneamente, o pinta, en una página y se vuelve inmediatamente seleccionable debido a nuestra CDN configurable en JavaScript, que conoce la aplicación, llamada CDN-AS-JavaScript. Utiliza la preobtención predictiva avanzada y la computación de borde para transmitir contenido dinámico (JSON/SSR/HTML) desde el borde al navegador del usuario, incluso antes de que se solicite. Esto mantiene a los sitios 5 segundos por delante de los golpecitos de los compradores en todo momento.

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

En resumen

Las cargas de página rápidas diferencian entre deleitar a los compradores y asustarlos para el sitio de tu competidor. Core Web Vitals Considera la primera impresión de velocidad, interactividad y estabilidad visual de un usuario midiendo la pintura contentful más grande, el retraso de la primera entrada y el cambio de diseño acumulativo. Si las velocidades son superiores a 2.5 s para LCP, 100 ms para FID o .1 para CLS, puedes asumir que tanto los usuarios como Google perciben tu sitio como lento. Google reducirá tu rango, y los consumidores rebotarán y nunca regresarán.

En solo un par de meses, una mala experiencia de página dañará la reputación de tu marca e impactará en tu ranking SEO. Proteja su SEO duramente ganado usando 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 ejecuta tu frontend. Shoe Carnival, REVOLVE, y 1-800-Flowers, son solo algunos ejemplos de sitios web de comercio electrónico que ofrecen velocidades inferiores a segundos y están cosechando los beneficios de ello. Si tiene alguna pregunta sobre la actualización de la experiencia de página o cómo acelerar su sitio, estaremos encantados de ponerlo en contacto con un experto en velocidad del sitio hoy mismo.

La próxima actualización de Page Experience de Google introduce señales derivadas de Core Web Vitals (CWV) en el algoritmo de clasificación oficial. Core Web Vitals es 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 fallan en la prueba Core Web Vitals se clasificarán más bajo que en la actualidad a principios de 2021.