Novedades de la actualización Google CORE WEB VITALS (mayo de 2021) y consejos para acelerar Magento 2

En mayo de 2021, Google presentará métricas de Core Web Vitals (CWV) para que formen parte de su algoritmo de clasificación de búsqueda. Por tanto, existen algunas operaciones que debes conocer y que debes realizar antes de esta fecha.

Todos sabemos que tener un sitio rápido es esencial para el éxito de un comercio electrónico. De hecho, un sitio con alto rendimiento crea una mejor experiencia de usuario, lo que resulta en un aumento en las tasas de conversión. Este hecho también está ligado al posicionamiento en búsqueda móvil en Google junto a otras métricas sobre la experiencia de la página como la optimización para dispositivos móviles.

Pero Google no se detiene ahí. En mayo de 2020, nos hablaron de Core Web Vitals y el 10 de noviembre de 2020 anunció que en mayo de 2021 Core Web Vitals se incorporará como una señal de búsqueda en el algoritmo de clasificación general.

Además, planean "probar un indicador visual que resalte las páginas en los resultados de búsqueda que tengan una gran experiencia en la página". Entonces, no solo tenemos una mayor probabilidad de obtener clasificaciones más altas a través de la optimización CWV, sino que también tenemos la posibilidad de aumentar las tasas de clics en las páginas de resultados de los motores de búsqueda.

Tomar medidas ahora para verificar y abordar cualquier problema potencial señalado en el marco de estas nuevas métricas de CWV brindará a nuestros sitios una mejor oportunidad de obtener una clasificación más alta que Google cuando este cambio entre en vigencia a mediados de este año 2021.

¿Qué es Core Web Vitals?

Los principales parámetros vitales de la web son un conjunto de 3 nuevas métricas de experiencia de página que se incluyen en las puntuaciones generales de velocidad del sitio . Estas métricas ya juegan un papel destacado en la herramienta PSI de PageSpeed ​​Insights de Google y en el monitoreo de las prestaciones Lighthouse en otros lugares.

Las nuevas métricas de CWV incluyen las siguientes:

• carga (LCP)
• interactividad (FID)
• estabilidad visual (CLS)

Las métricas de Core Web Vitals para Google se basan en estos criterios:

• ¿Qué tan rápido aparece el contenido en la pantalla? (LCP)
• ¿Qué tan rápido reacciona la página a la interacción del usuario? (FID)
• ¿El contenido se mueve por la pantalla mientras se carga el sitio? (CLS)

Largest Contentful Paint (LCP)

Este es el tiempo que tarda el contenido más pesado del sitio en aparecer en la pantalla. Básicamente, cuando ingresamos a un sitio de comercio electrónico y hacemos clic en un artículo, lo que aparece es la página del producto. Dentro de esta encontramos elementos específicos, como logo, texto e imágenes. Generalmente, las imágenes son los elementos más pesados. Luego, el LCP indicaría el tiempo que tardan las imágenes en cargarse.

Representa el 25% del mecanismo de puntuación de velocidad general y, por lo tanto, es vital para simplificar la entrega del artículo más grande en 2,5 segundos o menos en dispositivos móviles.

Numerosos factores contribuyen a un LCP alto, incluida la capacidad de respuesta del servidor, los estilos de bloque de secuencias de comandos y renderizado, el script, la complejidad de CSS, las fuentes y las imágenes.

Cómo optimizar el LCP de Google Core Web Vitals

Primero, primero debes verificar la velocidad real de tu sitio y cualquier problema crítico. Hay muchas herramientas para hacer esto, incluida la prueba de velocidad de nuestro partner de hosting Hostgento .

Solicita ya tu prueba >>

Después de esto, puedes intentar optimizar el LCP siguiendo estos sencillos consejos:

• Optimiza las imágenes. Precarga, comprime y reduce el peso de todos los elementos visuales que están presentes en tu sitio. Cuanto menor sea el número de MB, menos tiempo tardará en cargarse.
• Optimiza el servidor. Almacena en caché todos los archivos estáticos o utiliza soluciones CDN listas para usar. La ventaja de la CDN es que entrega contenido desde el servidor más cercano al usuario. Por tanto, las imágenes y descripciones de los productos se cargarán más rápido.
• Optimice JavaScript y CSS. Revisa y elimina cualquier código innecesario de archivos CSS o JS. Es mejor dedicar un archivo CSS / JS separado para cada bloque en lugar de escribir toda la lógica y los estilos JS en un archivo voluminoso.
• Optimiza el rendering del lado del cliente. No utilices muchas operaciones de anidamiento de componentes en el árbol DOM. Intenta usar menos funciones setTimeout para renderizar y agregar elementos al DOM en el caso de los eventos "document.ready" y "window.onload".

First Input Delay (FID)

Esta métrica refleja la capacidad de respuesta de tu sitio; básicamente, mide el tiempo que tarda en responder a cualquier interacción del usuario. La velocidad objetivo a la que el navegador responde a la primera entrada debe ser de 100 ms o menos.

Si el navegador está analizando o ejecutando mucho JavaScript mientras se carga la página, esto bloqueará la CPU o bloqueará el "hilo principal", haciendo que los dispositivos sean menos reactivos al input. Un FID alto suele ser un indicador de JavaScript complejo. Puede tratarse de un solo script o función o varios scripts.

Las métricas de PSI existentes para el tiempo de interactividad y el tiempo de bloque total están relacionadas con la FID y, en conjunto, representan un enorme 35% de las puntuaciones de velocidad generales.

Cumulative Layout Shift (CLS)

De hecho, el CLS mide todos los cambios de diseño de tu sitio durante la carga. Si bien solo representa el 5% de la puntuación de velocidad general, aún vale la pena considerarlo en el panorama general. Un CLS alto a menudo puede indicar uno o más cambios en el diseño visual durante la carga de la página, por ejemplo, cuando los banners se cargan moviendo el contenido de la página hacia abajo.

Cómo se reparte la puntuación de velocidad

El siguiente diagrama muestra un desglose de la puntuación de velocidad general y el importante papel que juegan estas nuevas métricas de CWV en las puntuaciones de GPSI.

Si bien las métricas que no son de CWV también forman la puntuación general, que incluye First Content Paint (FCP), Time to Interactive (TTI) y Total Blocking Time (TBT), centrarse en las tres métricas de CWV tendrá un impacto directo en las demás. El LCP rápido no es posible, por ejemplo, sin FCP rápido y los puntajes altos de FID se ven afectados directamente por TBT y TTI.

Consigli per migliorare la Largest Contentful Paint

La métrica LCP se compone de numerosos factores individuales y está directamente influenciada por un FCP alto. Si el FCP está marcado como malo, es posible que desees comenzar aquí. Cualquier cosa, desde la conectividad de red, a la capacidad de respuesta del servidor, al TTFB (Time To First Byte) y a los archivos de bloquean el rendering, afectará el valor de FCP.

Si el valor de LCP es mucho más alto que FCP, entonces necesitamos ver cómo podemos simplificar mejor la visualización de este elemento más grande.

Determinar el elemento más grande

Lo primera cosa que probablemente querrás hacer es determinar cuál es el elemento más grande. El elemento más grande depende del área de píxeles, que puede cambiar en diferentes puntos de interrupción, por lo que un escaneo visual puede no identificar necesariamente el elemento correcto.
En PSI, debería haber un panel "Largest Contentful Paint" en la sección Diagnóstico. Alternativamente, puedes ver el LCP colocando el cursor sobre el indicador en la herramienta de monitoreo de rendimiento de Chrome.

¿Las fuentes están optimizadas?

Si el elemento más importante está relacionado con la tipografía, debemos asegurarnos de que el problema relacionado con la tipografía sea lo más sencillo posible. Esto incluye:

• Utilizar la fuente CSS-display: swap; para asegurarse de que las fuentes se muestren inmediatamente al cargar el archivo de fuentes. Tanto Google Fonts como Adobe Typekit tienen la capacidad de establecer el parámetro de "display" de la fuente.
• Intentar alojar los archivos de fuentes .woff y .woff2 localmente en el servidor en lugar de realizar solicitudes entre dominios a fuentes de terceros. Google Fonts es bastante rápido, las fuentes Typekit son más lentas y algunas fundiciones de fuentes de terceros pueden ser menos confiables.
• Precargar los archivos de fuentes puede ayudar. Las fuentes alojadas localmente a menudo se incluirán en la hoja de estilo principal del sitio web, pero esta hoja de estilo debe descargarse y analizarse antes de realizar una solicitud adicional a la fuente que contiene. La precarga le dice al navegador que comience a descargar la fuente primero, sin esperar a que se analice el CSS.
• Utilizar preconnect y dns-prefetch para fundiciones de fuentes de terceros. Estas directivas ayudarán a establecer conexiones DNS, TLS y TCP entre dominios de terceros antes de que se realice la solicitud a los caracteres.
• Incluir solo los archivos de fuentes tipográficas necesarios por encima del display plegable. Los recursos de fuentes para bibliotecas de iconos como Font Awesome son notoriamente pesados, pero las solicitudes para ellos (y la biblioteca de iconos CSS correspondiente) generalmente se pueden diferir y cargar después del elemento <head>.
• No realizar solicitudes entre dominios para archivos de fuentes dentro de la hoja de estilo del sitio principal, ya que depende de la conectividad y la búsqueda adicional de un dominio de terceros.
• Considerar las fuentes seguras para la Web, que no requieren ninguna solicitud de archivo de fuentes, aunque pueden ser muy limitadas en términos de estética.

¿Están optimizadas las imágenes?

Muy a menudo, el elemento más grande será una imagen y, por lo tanto, es crucial asegurarse de que las imágenes estén optimizadas. La siguiente es una buena práctica en general, pero particularmente importante para el elemento LCP.

• Utilizar el tipo de archivo de imagen correcto. Las imágenes JPG deben usarse para fotografías, SVG para gráficos vectoriales e iconos o PNG para imágenes más complejas, no fotográficas y si se requiere transparencia.
• Asegurarse de que las imágenes JPG estén guardadas o tengan una calidad de entre el 50 y el 60%. En este nivel, no debería haber una pérdida perceptible de calidad. Además, asegurarse de que los metadatos se hayan eliminado de las imágenes.
• Los plugin de compresión o servicios similares pueden optimizar automáticamente imágenes en bloque y eliminar metadatos innecesarios.
• Las imágenes deben tener el tamaño adecuado para el área en la que se muestran. No reproducir la imagen de desktop de alta calidad en dispositivos móviles.
• Las imágenes deben producirse utilizando la etiqueta <img> estándar con el atributo "srcset" para las imágenes receptivas.
• Las imágenes debajo del pliegue o fuera de la pantalla deben usar el atributo loading = "lazy".
• Utiliza el formato de archivo de imagen .web de nueva generación para lograr tasas de compresión aún mejores. Esto puede ahorrar fácilmente un 30% y, en muchos casos, mucho más.
• Considere la posibilidad de precargar la imagen above the fold más grande para comenzar a descargar más rápido antes que otro contenido potencialmente menos crítico.

Minimizar los archivos que bloquean el rendering

Cualquier archivo JavaScript o CSS cargado en el elemento <head> </head> se considera que bloquea el rendering ya que estos archivos deben descargarse antes de que la página pueda comenzar a mostrarse. Esto puede tener un gran impacto en las métricas de FCP y LCP. Los archivos de bloqueo de rendering en el encabezado solo deben usarse si son críticos para la visualización inicial above the fold en la página.

Eliminar archivos no utilizados en <head>, cargar archivos no críticos en el pie de página o combinar varios archivos en menos archivos reducirá la cantidad de recursos que bloquean el rendering.

No utilizar JavaScript para visualizar el LCPN

Antes de la CWV, esto no era gran cosa. Es común que JavaScript se utilice para animar o mostrar elementos, por ejemplo con texto que se desvanece o carruseles, a menudo con poco o ningún impacto en las puntuaciones de velocidad.

Si la visualización del elemento más grande se basa en JavaScript, esto a menudo puede causar una gran demora, ya que JavaScript debe descargarse, analizarse y ejecutarse antes de que se muestre el elemento. Los archivos JavaScript generalmente (y con razón) se cargan después del elemento <head> para que no sean "bloqueadores del rendering", pero esto significa que aún pueden bloquear eficazmente el renderizado del LCP.

Las técnicas de JavaScript como esta pueden reducir instantáneamente las puntuaciones generales de velocidad en un 25% y no deben usarse para obstaculizar o evitar que el elemento más grande se cargue de ninguna manera.

Activar el LCP

No importa qué tan optimizada sea una imagen, casi siempre llevará más tiempo descargarla y mostrarla que un elemento tipográfico. Si bien es totalmente posible obtener puntuaciones LCP rápidas para las imágenes, a veces un ajuste para reducir el elemento de imagen más grande de modo que sea más pequeño que el elemento de texto más grande significa que el texto se puede usar en su lugar para el LCP.

Esto puede marcar una gran diferencia en las puntuaciones si el diseño lo permite, como se muestra en el siguiente ejemplo, donde el LCP se ha convertido en un elemento de texto.

Consejos para mejorar el First Input Delay

Como se mencionó anteriormente, el FID mide la capacidad de respuesta de la página a la entrada del usuario. Combine Time To Interactive TTI y Total Blocking Time TBT, que pueden representar hasta el 35% de las puntuaciones de velocidad generales.

Estas métricas se ven afectadas principalmente por el análisis y la ejecución de scripts durante la carga de la página; bloqueando el hilo principal de la CPU y potencialmente impactando la capacidad de respuesta del dispositivo, especialmente para los dispositivos smartphone de gama baja.

Es importante señalar que los "datos de laboratorio" que se muestran en PSI no miden directamente la FID. Esto se debe a la naturaleza interactiva de la medición del toque o clic del usuario, que es difícil de simular. En su lugar, se recopila mediante "Field Data"; mediciones recopiladas de usuarios reales durante un período de 28 días según el informe de experiencia del usuario de Chrome CrUX..

Por lo tanto, la optimización directa para FID es un poco más difícil, ya que no podemos cambiar algo y esperar 28 días para recopilar más datos. Por lo tanto, deberíamos usar las métricas TTI y TBT en los datos de laboratorio para esto, ya que los tiempos bajos para estas métricas estarán relacionados con un FID bajo.

Sin embargo, veamos cómo optimizar el FID.

Comprobar tu JavaScript

JavaScript puede venir en todas las formas y tamaños, y no es raro que un solo video integrado, widget de chat, script ReCaptcha o integración de HubSpot sea la única causa detrás de las métricas altas de FID, TTI y TBT.

Los paneles de diagnóstico de Page Speed ​​Insights son un buen lugar para comenzar. La sección "Minimizar el trabajo del thread principal" indicará cuánto tiempo de ejecución ocupa JavaScript, la sección "Reducir el tiempo de ejecución de JavaScript" indicará qué archivos tienen tiempos de ejecución y análisis altos, y "Reducir el impacto del código de terceros" resaltará y agrupará secuencias de comandos de terceros de alto impacto.

Cargar script en modo asíncrono

JavaScript de forma predeterminada se ejecutará secuencialmente. Si hay scripts que no dependen de la carga de otros, estos scripts deberían ser cargados con el atributo 'async' para que no bloqueen el análisis y la ejecución de otros scripts.

Cargar JavaScript en modo condicional

Un problema común que vemos en muchos sitios es que los scripts pesados ​​se cargan globalmente o en páginas cuando no se necesitan. Si necesita utilizar ReCaptcha, por ejemplo, para bloquear el correo no deseado en el envío de formularios, asegúrate de cargar scripts solo en páginas que contengan formularios.

Simplificar los paquetes JavaScript

Las bibliotecas de JavaScript como jQuery UI o Bootstrap se utilizan a menudo para proporcionar funcionalidades y funciones de JavaScript adicionales. Si está utilizando un paquete, asegúrese de incluir solo las funciones relevantes dentro del paquete para evitar que se descargue y analice JavaScript innecesario.

Script de carga lenta cuando sea necesario

Si bien JavaScript solo se carga en las páginas donde se necesita, el script en sí no tiene que ser analizado y ejecutado necesariamente durante la carga de la página o durante el evento de carga de la ventana. Cargar JavaScript solo cuando es realmente necesario puede marcar una gran diferencia para las métricas de TTI, TBT y FID. Aquí dejamos algunos ejemplos:

• Los videos incrustados como YouTube y Vimeo suelen tener un gran impacto. Considera cargar estos scripts solo cuando el usuario haga clic en la miniatura de un video.
• Las integraciones de módulos de terceros como HubSpot pueden ser intensas. Si el formulario aparece de forma modal o en la parte inferior de una página, considera cargar o insertar el script requerido durante el desplazamiento modal o la activación en lugar de cargar la página.
• Los widgets de chat en vivo pueden afectar las puntuaciones generales de velocidad hasta en un 35%. Considera mover el widget de chat en vivo a una página de contacto dedicada con soporte de llamada a la acción de "chat en vivo" global o inserta el script de chat en vivo solo cuando se haga clic en el botón "chatear con nosotros".
• Agregar el atributo "loading =” lazy "en el contenido incrustado basado en iFrame puede ayudar, pero esta es una nueva función del navegador y deberá probarse según la incrustación de iFrame utilizada.

Evaluar herramientas de inteligencia empresarial

Analizar el comportamiento del usuario con herramientas como Hotjar o software de pruebas A / B como VWO es muy importante para la inteligencia empresarial y, en muchos casos, sus beneficios superarán el impacto en la velocidad del sitio.

Dicho esto, aún vale la pena evaluar la importancia de ejecutar estas herramientas las 24 horas del día, los 7 días de la semana, dependiendo de la frecuencia con la que se analizan los datos. Las pruebas A / B deben desactivarse si, por ejemplo, no se están ejecutando pruebas activas y las herramientas de análisis de comportamiento como Hotjar pueden desactivarse después de que se hayan recopilado y procesado suficientes datos.

Consejos para mejorar el Cumulative Layout Shift

Determinar el elemento CLS

A veces puede parecer obvio qué elemento o qué elementos causan un cambio en el contenido, pero siempre vale la pena verificar esto a través del panel Cambio de layout en PSI como se muestra a continuación.

La métrica CLS debe estar por debajo de 0.1, pero en el ejemplo anterior, se excede en más del 400% y costará una reducción del 5% en las puntuaciones. Si es un problema global, eso es 5% en cada página.

Los elementos móviles deben identificarse y tratarse en orden de impacto y pueden incluir elementos above e below the fold. A continuación, destacamos algunas de las causas y resoluciones más comunes del cambio de layout.

Atención al la animación

Es bastante común que se utilicen algunas técnicas de animación para cambiar la forma en que se presenta el contenido al usuario, por ejemplo, desvaneciendo o desplazando imágenes, texto o paneles de contenido a medida que el usuario se desplaza hacia abajo en una página. Si bien estos pueden ser estéticamente agradables (dependiendo de a quién le preguntes), es importante que estas técnicas no muevan ningún contenido mientras se carga la página.

Si necesitas ocultar y luego desvanecer el contenido del usuario, asegúrate de que el tamaño del contenedor o la altura total de la página no cambia cuando se carga el contenido. El contenido se puede ocultar (si es necesario) usando reglas de visibilidad CSS en lugar de mostrar: ninguno; lo que preservará la cantidad de espacio subyacente que necesita.

Especificar el tamaño de la imagen

Si la etiqueta <img> no tiene los atributos de ancho y alto establecidos, o si no está utilizando CSS para establecer el tamaño o la proporción de la imagen, los navegadores deberán descargar la imagen antes de poder determinar el área de píxeles de la que se necesita display in. Esto puede hacer que cualquier contenido renderizado se traslade a debajo de la imagen, a medida que se carga la imagen.

Especificar el ancho y alto de la imagen o establecer el tamaño o la proporción de la imagen (o contenedor principal) dentro del CSS antes de descargar la imagen garantizará que los navegadores conozcan el área donde se debe mostrar la imagen y evitarán posibles cambios de layout.

Banner

La publicidad, las ventanas emergentes de la política de cookies o cualquier otra información utilizada para mostrar información importante en un banner es probablemente una de las causas más comunes de un CLS alto.

Es común que el contenido del banner se cargue desde una fuente de datos externa o mediante JavaScript desde el mismo sitio, lo que significa que es posible que no sea posible calcular el tamaño del contenedor del banner hasta que se haya cargado el contenido. Cuando esto sucede, el contenido debajo del banner se moverá hacia abajo una vez que el contenido del banner se haya cargado y mostrado al usuario.

Hay una serie de resoluciones a esto:

• Establecer una altura mínima para el banner o contenedor de banner en CSS para que el navegador pueda mostrar un marcador de posición de manera efectiva. Aunque esto puede ser problemático si la cantidad de contenido es dinámica y desconocida.
• Fijar la posición del banner en la parte superior o inferior de la pantalla. Para los banners que se pueden cerrar o ignorar, esta es una buena consideración ya que los elementos fijos no afectarán la ubicación de otros elementos.
• Si es posible, observar el rendering del lado del servidor del contenido del banner, lo que significa que el contenido y las dimensiones del banner se pueden cargar por adelantado antes de que lleguen al usuario.

Fuente Hallam - Blog