Actualización de mayo de 2021 de Google: una mirada más cercana a Core Web Vitals

ACTUALIZACIÓN: El mundo del marketing digital cambia constantemente, pero no te preocupes, estamos al tanto. Google ha cambiado de opinión sobre el próximo algoritmo.

Lea los cambios recientes aquí en nuestra actualización, pero no dude en leer este blog también.

En mayo de 2021, Google presentará métricas de Core Web Vitals (CWV) para formar parte de su algoritmo de clasificación de búsqueda. Esto es lo que necesita saber y hacer antes ...

Todos sabemos que los sitios rápidos son importantes. Crean una mejor experiencia de usuario, lo que resulta en un aumento de las tasas de conversión y ya tienen en cuenta el ranking de búsqueda móvil en Google junto con otras métricas de experiencia de la página como la compatibilidad con dispositivos móviles.

Pero Google no se detiene ahí. En mayo de 2020, nos hablaron sobre Core Web Vitals y el 10 de noviembre de 2020, anunciaron 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 excelente experiencia en la página". Por lo tanto, 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.

Actuar ahora para auditar y solucionar cualquier problema potencial señalado con estas nuevas métricas de CWV brindará a nuestros sitios una mejor oportunidad de obtener clasificaciones de Google más altas cuando este cambio entre en vigencia en 2021.

Pero primero, un resumen ...

Recapitulación: ¿qué son los elementos fundamentales de la Web?

Core Web Vitals es 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 tienen un papel destacado en la herramienta de PSI PageSpeed ​​Insights de Google y en el monitoreo de Lighthouse Performance en otros lugares.

Las nuevas métricas de CWV comprenden lo siguiente:

Pintura con contenido más grande (LCP)

Este es el tiempo que se tarda antes de que se muestre al usuario el elemento de mayor tamaño por encima del pliegue. Representa el 25% del mecanismo de puntuación de velocidad general y, por lo tanto, es de vital importancia para agilizar la entrega del artículo más grande a 2,5 segundos o menos en dispositivos móviles.

Numerosos factores contribuyen a un alto LCP, incluida la capacidad de respuesta del servidor, los scripts y estilos de bloqueo de renderizado, la complejidad de CSS, fuentes e imágenes.

Retardo de la primera entrada (FID)

Esto mide la interactividad; qué tan receptiva es la página a la entrada del usuario, por ejemplo, a través de toques o clics. 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 una gran cantidad de JavaScript durante la carga de la página, esto inmovilizará la CPU o bloqueará el "hilo principal", lo que hará que los dispositivos respondan menos a la entrada. Un FID alto suele ser un indicador de JavaScript complejo. Esto podría ser un solo script o función o varios scripts.

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

Cambio de diseño acumulativo (CLS)

Esta es una medida de la estabilidad visual del contenido por encima del pliegue. Si bien solo comprende el 5% de las puntuaciones de velocidad generales, 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 desplazando el contenido de la página hacia abajo.

Desglose de la puntuación de velocidad

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

Datos de origen de la actualización de la puntuación de Lighthouse

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. Un LCP rápido no es posible, por ejemplo, sin un FCP rápido y las puntuaciones FID altas se ven directamente afectadas por TBT y TTI.

Consejos para optimizar la pintura con mayor contenido

La métrica LCP se compone de numerosos factores individuales y se ve afectada directamente por un FCP alto. Si el FCP se marca como deficiente, es posible que desee comenzar aquí. Cualquier cosa, desde la conectividad de red, la capacidad de respuesta del servidor, el tiempo hasta el primer byte TTFB y los archivos de bloqueo de procesamiento, afectarán el valor de FCP. Para una inmersión más profunda en algunas de estas recomendaciones de velocidad de página más genéricas, consulte nuestro libro electrónico de velocidad de página sobre el tema, además de los consejos específicos de LCP a continuación.

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

Determinar el elemento más grande

Lo primero que probablemente querrá hacer es determinar cuál es el elemento más grande. El elemento más grande se basa en el área de píxeles que puede cambiar en diferentes puntos de interrupción, por lo que un escaneo visual no necesariamente identifica el elemento correcto.

En PSI, debería haber un panel de 'Elemento de pintura con contenido más grande' en la sección Diagnóstico. Alternativamente, puede ver el LCP colocando el cursor sobre el indicador en la herramienta de monitoreo de rendimiento de Chrome como se muestra a continuación.

En el sitio de Hallam en el ejemplo anterior, el Monitor de rendimiento muestra el LCP como el encabezado principal 'Prosperar en línea'. Idealmente, LCP debería seguir inmediatamente a FCP como en este ejemplo y si hay una brecha entre los dos, debemos intentar comprender por qué.

¿Están optimizadas las fuentes?

Si el elemento más grande en la parte superior del pliegue es la tipografía, entonces debemos asegurarnos de que la entrega de fuentes sea lo más ágil posible. Esto incluye:

1. Utilice la fuente CSS-display: swap; para garantizar la visualización inmediata de la fuente mientras se carga el archivo de fuente. Tanto Google Fonts como Typekit de Adobe tienen la capacidad de establecer el parámetro de "visualización" de la fuente.
2. Intente alojar localmente archivos de fuentes .woff y .woff2 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.
3. La precarga de 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 antes, sin esperar a que se analice el CSS.
4. Utilice 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 las fuentes.
5. Solo incluya archivos de fuentes para la tipografía requerida para la parte superior de la pantalla plegable. Los recursos de fuentes para bibliotecas de íconos como Font Awesome son notoriamente pesados, pero las solicitudes a estos (y el CSS de la biblioteca de íconos correspondiente) generalmente se pueden diferir y cargar después del elemento <head>.
6. No realice solicitudes de dominios cruzados a archivos de fuentes dentro de la hoja de estilo del sitio principal, ya que esto depende de la conectividad y la búsqueda adicional de un dominio de terceros.
7. Considere fuentes seguras para la web. Estos no requieren ninguna solicitud de archivos de fuentes, aunque pueden ser muy limitados en términos de estética.

¿Están optimizadas las imágenes?

Muy a menudo, el elemento más grande por encima del pliegue será una imagen tan importante para garantizar que las imágenes estén optimizadas. La siguiente es una buena práctica en general, pero especialmente importante para el elemento LCP.

1. Utilice el tipo de archivo de imagen correcto. Las imágenes JPG deben usarse para fotografías, SVG para gráficos vectoriales e íconos o PNG para imágenes más complejas, no fotográficas y si se requiere transparencia.
2. Asegúrese de que las imágenes JPG se guarden 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, asegúrese de que se hayan eliminado los metadatos de las imágenes.
3. Los complementos o servicios de compresión como tinypng.com pueden optimizar automáticamente y en masa las imágenes y eliminar los metadatos innecesarios.
4. Las imágenes deben tener el tamaño adecuado para el área en la que se muestran. No reproduzca la imagen de escritorio de alta calidad en un dispositivo móvil.
5. Las imágenes deben generarse utilizando la etiqueta <img> estándar con el atributo 'srcset' para imágenes receptivas.
6. Las imágenes de la mitad inferior de la página o fuera de la pantalla deben usar el atributo loading = "lazy".
7. Utilice el formato de archivo de imagen .web de próxima generación para obtener tasas de compresión aún mejores. Esto puede ahorrar fácilmente un 30% y, en muchos casos, mucho más.
8. Considere la posibilidad de precargar la imagen superior más grande para iniciar la descarga más rápido antes que otro contenido potencialmente menos crítico.

Reducir los archivos que bloquean el procesamiento

Cualquier archivo JavaScript o CSS cargado en el elemento <head> </head> se considera un bloqueo de procesamiento, ya que estos archivos deben descargarse antes de que la página pueda comenzar a procesarse. Esto puede tener un gran impacto tanto en la métrica FCP como en la LCP. Los archivos de bloqueo de procesamiento en el encabezado solo deben usarse si son críticos para la visualización inicial en la parte superior de la página.

Eliminar cualquier archivo no utilizado en el <head>, cargar archivos no críticos en el pie de página o combinar varios archivos en menos archivos reducirá la cantidad de activos que bloquean el procesamiento.

No use JavaScript para mostrar el LCP

Antes de CWV, esto no era gran cosa. Es común que JavaScript se use para animar o mostrar elementos en la parte superior, como con texto que se desvanece o carruseles de héroes, a menudo con poco o ningún impacto en los puntajes 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 aparezca el elemento. Los archivos JavaScript se cargan normalmente (y con bastante razón) después del elemento <head>, por lo que no son "bloqueadores de renderizado", pero esto significa que aún pueden bloquear eficazmente el renderizado del LCP.

Mire el ejemplo a continuación (logotipo borroso y encabezado cambiado), esto es de un sitio de alta puntuación en PSI. El LCP (el texto del encabezado principal) está varios segundos más lejos del FCP, lo que se debe al requisito de JavaScript (representado por las bandas amarillas) para descargar, analizar y ejecutar antes de que el texto pueda aparecer.

El desvanecimiento del texto en sí mismo también puede ser un problema, provocando una visualización retrasada del elemento más grande.

Las técnicas de JavaScript como esta pueden reducir inmediatamente los puntajes de velocidad generales en un 25% y no deben usarse para obstaculizar o prevenir la carga del elemento más grande de ninguna manera.

Ejecutar secuencias de comandos al cargar la ventana

Rara vez se requiere JavaScript (y no debería ser necesario) para mostrar contenido crítico en la mitad superior de la página, sin embargo, un problema común que vemos es que las funciones se pueden activar tan pronto como el DOM esté listo. En el popular framework jQuery, esto se hace a través del evento 'ready'. Google Tag Manager también puede activar funciones o 'etiquetas' en listo.

Considere activar todo JavaScript que no sea necesario para la visualización crítica de contenido en el evento de carga de la ventana, después de que se cargue el contenido de la página principal para evitar cualquier interferencia potencial con la reproducción del contenido de la mitad superior de la página y el elemento LCP.

Encienda el LCP

No importa qué tan bien optimizada y optimizada esté una imagen, casi siempre llevará más tiempo descargarla y mostrarla que un elemento tipográfico. Aunque es completamente posible lograr puntuaciones LCP rápidas para las imágenes, a veces un ajuste para reducir el elemento de imagen más grande para que sea más pequeño que el elemento de texto más grande significará que se puede usar texto 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 cambiado a un elemento de texto.

Consejos para la optimización del retardo de la primera entrada

Como mencionamos anteriormente, FID mide qué tan receptiva es la página a la entrada del usuario. Combina 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 a medida que se carga la página; bloqueando el hilo principal de la CPU y potencialmente afectando la capacidad de respuesta del dispositivo, especialmente para los dispositivos de teléfonos inteligentes de gama baja.

Es importante tener en cuenta que los 'Datos de laboratorio' que se muestran en PSI no miden la FID directamente. Esto se debe a la naturaleza interactiva de la medición de los toques o clics del usuario que es difícil de simular. En su lugar, se recopila mediante 'Datos de campo'; mediciones recopiladas de usuarios reales durante un período de 28 días según el Informe de experiencia del usuario de Chrome CrUX.

Como tal, optimizar para FID directamente es un poco más difícil, ya que no podemos cambiar algo y esperar 28 días para que se recopilen 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 se correlacionarán con un FID bajo.

Entonces, ¿cómo hacemos para optimizar estas métricas?

Audita tu JavaScript

JavaScript puede venir en todas las formas y tamaños y no es raro que una sola inserción de video, 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 subproceso principal' le dirá cuánto tiempo de ejecución ocupa JavaScript, la sección 'Reducir el tiempo de ejecución de JavaScript' indicará qué archivos tienen altos tiempos de análisis y ejecución y 'Reducir el impacto de terceros code 'resaltará y agrupará los scripts de terceros de alto impacto.

La captura de pantalla a continuación muestra un sitio que sufre de tener varios scripts pesados, con una métrica de Tiempo de interacción de 15 segundos. Muchos scripts son de terceros, incluidos HubSpot y Vimeo.

Para un análisis y una visualización más profundos de cómo estos scripts impactan en la carga de la página, la herramienta Performance Monitor de Chrome puede ser una excelente manera de profundizar en qué scripts y funciones se activan, el impacto relativo de estos scripts y en qué punto de la página los cargan. se están ejecutando largos scripts.

El siguiente ejemplo es del mismo sitio y muestra JavaScript representado por las barras amarillas, rosadas y naranjas, con barras más largas que muestran tareas de ejecución más largas. Cuando hacemos clic en estas tareas más largas, podemos ver que los scripts resaltados se correlacionan con los scripts grandes resaltados por PSI arriba.

Una vez que tengamos una mejor idea de qué secuencias de comandos están afectando el rendimiento, existen varias técnicas que podemos utilizar para minimizar su impacto, como se describe a continuación.

Cargar scripts de forma asincrónica

JavaScript de forma predeterminada se ejecutará en secuencia. Si hay scripts que no dependen de la carga de otros, estos scripts deben cargarse con el atributo 'async' para que no bloqueen el análisis y la ejecución de otros scripts.

Cargar JavaScript condicionalmente

Un problema común que vemos en muchos sitios es que los scripts pesados ​​se cargan globalmente o en páginas cuando no son necesarios. Si necesita utilizar ReCaptcha, por ejemplo, para ayudar a detener el spam en los envíos de formularios, asegúrese de cargar scripts solo en las páginas que tienen formularios.

Agilizar los paquetes de JavaScript

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

Scripts de carga diferida cuando sea necesario

Incluso si JavaScript solo se carga en las páginas en las que se necesita, el script en sí no necesariamente necesita analizarse y ejecutarse durante la carga de la página o el evento de carga de la ventana. Cargar JavaScript solo cuando es realmente necesario puede marcar una gran diferencia en las métricas de TTI, TBT y FID. Aquí hay unos ejemplos:

1. Las incrustaciones de videos como YouTube y Vimeo suelen tener un gran impacto. Considere solo cargar estos scripts cuando haga clic en la miniatura de un video.
2. Las integraciones de formularios de terceros, como HubSpot, pueden ser intensivas. Si el formulario aparece en un modal, o en la parte inferior de una página, considere cargar o inyectar el script requerido en el desplazamiento o activación modal en lugar de cargar la página.
3. Los widgets de chat en vivo pueden afectar las puntuaciones generales de velocidad hasta en un 35%. Considere mover el widget de chat en vivo a una página de contacto dedicada que admita CTA global de 'chat en vivo', o inyecte el script de chat en vivo solo cuando se haga clic en el botón 'chatear con nosotros'.
4. Agregar el atributo 'loading = ”lazy” en el contenido basado en iFrame incrustado puede ayudar, pero 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 el software de pruebas A / B como VWO es realmente 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 analicen los datos. Las pruebas A / B deben desactivarse si no se están ejecutando pruebas activas, por ejemplo, y las herramientas de análisis de comportamiento como Hotjar pueden desactivarse después de que se hayan recopilado y procesado suficientes datos.

Sugerencias para la optimización del cambio de diseño acumulativo

El cambio de diseño acumulativo (CLS) solo puede representar el 5% de las puntuaciones de velocidad generales, pero aún así, una parte importante de la imagen general, especialmente porque una gran cantidad de elementos cambiantes en la carga de la página puede ser una experiencia discordante para el usuario.

Determinar el elemento CLS

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

La métrica CLS debe estar por debajo de 0.1, pero en el ejemplo anterior, esto se excede en más de un 400% y costará una caída del 5% en los puntajes. Si este es un problema global, eso es 5% en cada página.

Los elementos cambiantes deben identificarse y abordarse en orden de impacto y pueden incluir elementos arriba y abajo del pliegue. A continuación, destacamos algunas de las causas y resoluciones más comunes de los cambios de diseño.

Cuidado con la animación

Es bastante común que se utilicen ciertas técnicas de animación para cambiar la forma en que se presenta el contenido al usuario, por ejemplo, desvaneciendo o deslizando 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 pregunte), es importante que estas técnicas no cambien ningún contenido durante la carga de la página.

Si tiene que ocultar y luego difuminar el contenido para el usuario, asegúrese de que el tamaño del contenedor o la altura total de la página no cambie a medida que 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 las dimensiones de la imagen

Si la etiqueta <img> no tiene establecido el atributo de ancho y alto, o no se usa CSS para establecer las dimensiones o la proporción de la imagen, los navegadores deberán descargar la imagen primero antes de poder determinar el área de píxeles que necesita. mostrar en. Esto puede provocar un desplazamiento de cualquier contenido renderizado debajo de la imagen, a medida que se carga la imagen.

Especificar el ancho y el alto de la imagen, o establecer las dimensiones o la proporción de la imagen (o el contenedor principal) dentro de CSS antes de descargar la imagen garantizará que los navegadores conozcan el área en la que la imagen debe mostrarse y evitará un posible diseño. cambiar.

Pancartas

Los anuncios, las barras de la ley de cookies o cualquier otra información utilizada para mostrar información importante en un banner son 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 se pueda calcular el tamaño del contenedor del banner hasta que se haya cargado el contenido. Cuando esto sucede, el contenido debajo del banner se desplazará hacia abajo una vez que el contenido del banner se cargue y se muestre al usuario.

Hay una serie de resoluciones para esto:

1. Establezca una altura mínima para el banner o contenedor de banner en CSS para que el navegador pueda representar un marcador de posición de manera efectiva. Aunque esto puede ser problemático si la cantidad de contenido es dinámica y desconocida.
2. Absolutamente o arregle la posición del banner en la parte superior o inferior de la pantalla. Para los banners que pueden cerrarse o descartarse, esto es una buena consideración ya que los elementos fijos no afectarán el posicionamiento de ningún otro elemento.
3. Si es posible, observe la representación del contenido del banner en el lado del servidor, lo que significa que el contenido y las dimensiones del banner se pueden cargar por adelantado antes de que llegue al usuario.

Resumen

Con suerte, encontrará algunas de las técnicas destacadas anteriormente útiles para diagnosticar y solucionar problemas de rendimiento relacionados con el nuevo Core Web Vitals de Google. Durante los últimos meses en Hallam, hemos ayudado a varios clientes a mejorar el rendimiento de su sitio web, tanto en términos de nuestras auditorías de velocidad como de las mejoras directas realizadas por nuestro equipo de desarrollo.

Si este artículo le resultó útil, también puede consultar nuestro libro electrónico sobre el rendimiento del sitio web, que profundiza en algunas de las recomendaciones más genéricas sobre la velocidad de la página de las que puede beneficiarse cualquier persona que cree o administre un sitio web.