Core Web Vitals 101 y guía de desarrollo

¿Qué está pasando y cambiando?

En mayo de 2021, Google inició el lanzamiento de una actualización de algoritmo central que agrega un factor adicional a las señales de clasificación de páginas, en lo que respecta a la velocidad de la página y la experiencia del usuario. El lanzamiento de la actualización principal se prolongó hasta junio de 2021 y también convirtió a este en uno de los cambios principales más importantes de la historia. Core Web Vitals se unirá a las señales de clasificación más antiguas, como un sitio seguro HTTPS, compatibilidad con dispositivos móviles e intersticiales no intrusivos como señales de búsqueda en el factor de clasificación general de la experiencia de la página.

Los tres componentes de Core Web Vitals incluyen lo siguiente:

• Pintura con contenido más grande (LCP) : mide la velocidad de carga percibida y marca el punto en la línea de tiempo de carga de la página cuando es probable que se haya cargado el contenido principal de la página. Para proporcionar una buena experiencia de usuario, los sitios deben esforzarse para que LCP ocurra dentro de los primeros 2,5 segundos desde que la página comienza a cargarse.
• First Input Delay (FID) : mide la capacidad de respuesta y cuantifica la experiencia que sienten los usuarios cuando intentan interactuar por primera vez con la página. Para proporcionar una buena experiencia de usuario, los sitios deben esforzarse por tener un FID de menos de 100 milisegundos .
• Cambio de diseño acumulativo (CLS) : mide la estabilidad visual y cuantifica la cantidad de cambio de diseño inesperado del contenido de la página visible. Para proporcionar una buena experiencia de usuario, los sitios deben esforzarse por tener una puntuación CLS inferior a 0,1 .

Declaración de lanzamiento oficial de Google sobre esta actualización de algoritmo: https://developers.google.com/search/blog/2020/11/timing-for-page-experience

Además, Google publicó más información sobre el cambio de CLS mientras continuaban monitoreando el desempeño durante la implementación. Como resultado, muchos sitios recibieron una puntuación más favorable debido a los cambios recientes y evitaron mucho trabajo de desarrollo para ajustar los diseños de sus sitios. Como siempre, estos cambios están sujetos a cambios, por lo que recomendamos monitorear los CWV como parte de una lista de verificación semanal o mensual.

¿Qué sabemos sobre la actualización del ranking?

Al igual que con la mayoría de las actualizaciones de algoritmos de Google, hay mucho que se desconoce en términos de cómo afectará el panorama de búsqueda actual. Sabemos que esto será un factor en la clasificación de las páginas. Sin embargo, no sabemos qué porcentaje de un factor o qué impacto tendrá dentro del algoritmo. Otro factor desconocido será si los competidores directos se adaptan o toman medidas para actualizar su(s) sitio(s) para adherirse a los nuevos factores. Con base en el comportamiento de la competencia, esto a su vez podría tener un impacto positivo o negativo en la clasificación de su sitio, en comparación con esos pares. Lo que sí sabemos es que Google continuará priorizando el contenido de clasificación que considera valioso o relevante para los usuarios sobre sitios web más rápidos con contenido débil.

De hecho, a medida que Google ofrece más información sobre la actualización, confirmaron que el contenido relevante sigue siendo uno de los elementos más importantes en las clasificaciones de búsqueda.

“Nuestros sistemas continuarán priorizando las páginas con la mejor información en general, incluso si algunos aspectos de la experiencia de la página son deficientes. Una buena experiencia en la página no reemplaza tener contenido excelente y relevante”.

¿Cómo prepararse para la actualización del ranking de la experiencia de la página de Google?

Debido a los factores desconocidos relacionados con esta actualización y la ventana de aviso de 6 meses de Google, el cambio parece indicar que esto se convertirá en un factor de clasificación. Por lo tanto, se recomienda encarecidamente que tanto los equipos de SEO como los de desarrollo revisen el rendimiento actual de Core Web Vitals de su sitio y tomen medidas rápidamente para revisar y actualizar los problemas relacionados con la actualización de la señal de clasificación. Es importante asegurarse de ser proactivo en lugar de reactivo, ya que cualquier disminución en la clasificación puede llevar bastante tiempo para recuperarse. ¡Todos sabemos que el SEO es un juego largo!

¿Cómo identificar los problemas del sitio, los próximos pasos en función de los problemas y los consejos adicionales?

Core Web Vitals se describen en la cuenta de Google Search Console de su sitio en "Mejoras". Además, hay un aspecto general dentro de la sección "Descripción general" de la cuenta, que se verá similar al ejemplo a continuación (es probable que ocurra alguna variación ya que su cuenta depende de los problemas potenciales específicos de su sitio). También hay una sección descrita tanto para escritorio como para dispositivos móviles. En este ejemplo, estamos analizando problemas relacionados con dispositivos móviles.

Debido a que todos los sitios se indexaron primero para dispositivos móviles a partir de septiembre de 2020 , recomendamos que el tiempo de desarrollo se dedique primero a los problemas de dispositivos móviles. Dicho esto, si su sitio responde, es probable que las actualizaciones que realice en dispositivos móviles también tengan un impacto positivo en el escritorio. Además, según el tamaño del sitio, puede haber una variedad de problemas "pobres" y "que necesitan mejorar". Recomendamos encarecidamente centrarse en las URL "pobres", ya que los elementos que "necesitan mejorar" pueden no valer la pena el esfuerzo frente al impacto, o la regla 80/20, que veremos más adelante.

Al revisar las URL descritas en Google Search Console que muestran un rendimiento inferior al óptimo, es importante tener en cuenta lo que John Mueller de Google reveló sobre cómo Google puede, en algunos casos, calcular la puntuación de los signos vitales de la web principal como un promedio de varias páginas:

Esta es la pregunta:

"Cuando esto se convierta en una señal de clasificación... ¿será a nivel de página o de dominio?"

Müller respondió:

“…Lo que sucede con los datos de campo es que no tenemos puntos de datos para cada página.

Entonces, en su mayor parte, necesitamos tener una especie de agrupaciones de páginas individuales.

Y dependiendo de la cantidad de datos que tengamos, eso puede ser una agrupación de todo el sitio web (tipo de dominio).

…Creo que en el Informe de experiencia de usuario de Chrome usan el origen que sería el subdominio y el protocolo allí.

Así que ese sería el tipo de agrupación general.

Y si tenemos más datos para partes individuales de un sitio web, intentaremos usarlos.

Y creo que eso es algo que también se ve en la consola de búsqueda donde mostraremos una URL y diremos... hay muchas otras páginas asociadas con eso. Y ese es el tipo de agrupación que usaríamos allí”.

Quizás se esté preguntando, ¿por qué mencionamos esto al comienzo de la conversación sobre Core Web Vitals? Mueller explica que el informe de Google Search Console que describe los problemas de URL intenta categorizar e informar páginas con los mismos problemas en una agrupación. Desafortunadamente, en la práctica, estas agrupaciones de URL han sido menos que útiles para algunos sitios web según nuestra experiencia.

De vez en cuando, revisaremos las URL indicadas como de rendimiento "pobre" en el informe de Google Search Console, solo para descubrir que las mismas páginas parecen tener un certificado de salud limpio cuando se prueban con Lighthouse y Page Speed ​​Insights.

En resumen, al revisar los problemas de URL descritos en el informe de Google Search Console, recomendamos "tomarlo con cautela". Nuestra mejor conjetura es que Google tiene la intención de clasificar el puntaje de "elementos vitales web" para las páginas en función de un historial de 28 días de datos de navegación reales ("datos de campo" en Google-speak). Sin embargo, es probable que los datos del mundo real se agreguen de todo el dominio (u "origen" en Google-speak) si la página no tiene mucho tráfico. Si bien Search Console será útil para identificar el hecho de que sus datos vitales web necesitan atención, no confíe en ellos para su auditoría. Además, tenga cuidado de revisar los datos de laboratorio (resultados individuales de las páginas probadas en tiempo real) en lugar de los datos de campo (que pueden ser de varias páginas y siempre tienen una ventana retrospectiva de 28 días) al realizar y auditar o validar correcciones.

Una vez que sepa que tiene un problema, si no puede determinar las páginas de origen, comience con las páginas de ejemplo de pruebas de laboratorio para cada una de sus plantillas principales. Por ejemplo, la página de inicio, una página de producto, una página de categoría, un artículo de blog, etc. A menudo, los problemas estructurales se pueden encontrar en cada instancia de un tipo de página en particular y un desarrollador web los corrige una vez a través de una actualización de la plantilla subyacente. código. Si esto no funciona, considere un análisis similar de un subconjunto de páginas individuales comenzando con aquellas que son más visitadas. Una herramienta que hemos encontrado útil en este proceso es la auditoría de Core Web Vitals a través de Screaming Frog .

Guía de mejora del cambio de diseño acumulativo (CLS)

El cambio de diseño acumulativo (CLS) mide la suma total de todos los puntajes de cambio de diseño individuales para cada cambio de diseño inesperado que ocurre durante toda la vida útil de la página. Un cambio de diseño ocurre cada vez que un elemento visible cambia su posición de un cuadro renderizado al siguiente.

Google recomienda la siguiente guía sobre cómo mejorar CLS para la mayoría de los sitios web siguiendo algunos principios rectores:

• Incluya siempre atributos de tamaño en sus imágenes y elementos de video o, de lo contrario, reserve el espacio requerido con cuadros de relación de aspecto CSS . Este enfoque garantiza que el navegador pueda asignar la cantidad correcta de espacio en el documento mientras se carga la imagen. Tenga en cuenta que también puede usar la política de características de medios sin tamaño para forzar este comportamiento en navegadores que admitan políticas de características.
• Nunca inserte contenido sobre contenido existente, excepto en respuesta a una interacción del usuario. Esto garantiza que se esperan los cambios de diseño que se produzcan.
• Prefiere las animaciones de transformación a las animaciones de propiedades que desencadenan cambios de diseño. Anime las transiciones de una manera que proporcione contexto y continuidad de un estado a otro.

Google recomienda utilizar el siguiente curso de acción para analizar, probar e implementar actualizaciones en todo el sitio:

• Una vez que haya identificado las páginas que necesitan trabajo (descrito anteriormente), use PageSpeed ​​Insights para diagnosticar problemas de laboratorio y de campo en una página.
• ¿Listo para optimizar su sitio localmente en el laboratorio? Use Lighthouse y Chrome DevTools para medir Core Web Vitals y obtener orientación práctica sobre qué corregir exactamente. La extensión de Chrome Web Vitals puede brindarle una vista en tiempo real de las métricas en el escritorio.
• ¿Buscas orientación? web.dev/measure puede medir su página y mostrarle un conjunto priorizado de guías y codelabs para la optimización, utilizando datos de PSI.
• Por último, use Lighthouse CI en las solicitudes de incorporación de cambios para asegurarse de que no haya regresiones en Core Web Vitals antes de implementar un cambio en la producción.

Para obtener información detallada sobre cómo mejorar CLS, consulte Optimize CLS .

Guía de mejora de mayor contenido de pintura (LCP)

La métrica de pintura con contenido más grande (LCP) informa el tiempo de procesamiento de la imagen o el bloque de texto más grande visible dentro de la ventana gráfica.

Tal como se especifica actualmente en la API de pintura con contenido más grande , los tipos de elementos considerados para la pintura con contenido más grande son:

• <img> elementos
• Elementos <image> dentro de un elemento < svg>
• <video> elementos (se utiliza la imagen del póster)
• Un elemento con una imagen de fondo cargada a través de la función url() (a diferencia de un degradado CSS )
• Elementos de nivel de bloque que contienen nodos de texto u otros elementos secundarios de texto de nivel en línea

Google recomienda la siguiente guía sobre cómo mejorar LCP, que se ve afectada principalmente por cuatro factores:

• Tiempos de respuesta del servidor lentos
• JavaScript y CSS que bloquean el renderizado
• Tiempos de carga de recursos
• Representación del lado del cliente

Para obtener información detallada sobre cómo mejorar LCP, consulte Optimizar LCP . Para obtener orientación adicional sobre técnicas de rendimiento individuales que también pueden mejorar LCP, consulte:

• Aplicar carga instantánea con el patrón PRPL
• Optimización de la ruta de representación crítica
• Optimiza tu CSS
• Optimiza tus Imágenes
• Optimizar fuentes web

Optimice su JavaScript (para sitios renderizados por el cliente)

Hallazgos vitales de la Web principal del desarrollo hasta la fecha

Nuestro equipo de desarrollo ha visto que gran parte de la actualización de clasificación de Core Web Vitals requerirá pruebas exhaustivas en el lado del desarrollo para garantizar que las actualizaciones que se realicen cumplan con los estándares establecidos por Google.

En numerosos casos de sitios más pequeños, muchos de estos elementos estarán fuera del control de los desarrolladores web. Por ejemplo, la velocidad del servidor está controlada en gran medida por el proveedor de alojamiento, y para el alojamiento compartido (como WP Engine o Shopify), los desarrolladores no tendrán control. Del mismo modo, los temas de sitio listos para usar a menudo tendrán Javascript y CSS que bloquean el renderizado "horneados". En estos casos, puede que no sea práctico abordar muchos de los problemas informados. Por estas razones, se requiere un análisis crítico para determinar la intersección de (1) qué problemas tienen el mayor impacto y (2) qué problemas son causados ​​por el código que el equipo de desarrollo puede y debe cambiar.

Después de comenzar el proceso de revisión de los problemas de Core Web Vitals en varios de nuestros clientes, descubrimos que gran parte de las herramientas relacionadas proporcionadas por Google aún no están maduras, en la medida en que es capaz de identificar problemas (como cambios en la carga de contenido), pero no es siempre es útil para identificar la causa específica. Si bien esperamos que esto madure en las próximas iteraciones de esta herramienta (en particular, en Chrome Dev Tools), hemos descubierto que es posible que se requieran procesos de diagnóstico alternativos para identificar ciertos problemas.

También descubrimos que trabajar para mejorar estas métricas es de naturaleza similar a mejorar el rendimiento de la velocidad de la página en general. En cada caso, desaconsejamos la búsqueda de una “puntuación perfecta”. En su lugar, se aplica la regla 80/20. Si aborda la fruta al alcance de la mano, es probable que vea una mejora significativa en sus métricas. Después de eso, la mejora se vuelve más lenta, más costosa y menos impactante.

Una guía básica, como la sugerencia de Google de incluir marcas que preserven el espacio o CSS en todos los elementos de imágenes, videos y contenedores, generalmente es un buen consejo que es fácil de implementar. Otros problemas son más difíciles de rastrear y, a menos que tengan un impacto excesivo en sus métricas (como lo informan algunas de las herramientas sugeridas), puede ser mejor dejar esos problemas a un lado.

La arquitectura del sitio también desempeñará un papel importante en la relativa facilidad con la que se pueden abordar estos elementos. Las plataformas de sitios populares como Shopify y WordPress, junto con los creadores de páginas gráficas como WP Bakery y Shogun, manejan una parte del proceso de generación de HTML "entre bastidores". Es posible que los problemas ocultos por los componentes del creador de páginas (p. ej., cierta carga diferida de imágenes) no se solucionen fácilmente sin cambios fundamentales en el sitio o el soporte de la plataforma, el tema o el proveedor del complemento/aplicación.

El concepto anterior se extiende a terceros que usan javascript para cargar widgets de forma diferida en su página (por ejemplo, formularios de registro integrados de plataformas de correo electrónico como Klaviyo). En algunos casos, colocar un elemento contenedor de tamaño adecuado y explícito alrededor del código de inserción del componente infractor es una solución viable. En otros casos, es posible que el propio proveedor deba realizar un cambio.

Recomendamos comenzar cualquier proceso de remediación con problemas impactantes que se pueden abordar mediante cambios en las plantillas del sitio central de fácil acceso (por ejemplo, páginas de productos, páginas de colección de productos, etc.). Esto a menudo permitirá que un cambio de código mejore los resultados en decenas o cientos de páginas del sitio. A continuación, diríjase a la página de inicio, ya que casi siempre es la página más visitada del sitio. Finalmente, priorice otras páginas individuales que requieran corrección según la gravedad del problema y la visibilidad de la página.

Como es el caso de las mejoras en la velocidad de la página, la administración de Core Web Vitals es importante, pero es solo una variable entre muchas en el algoritmo de clasificación de Google, y el SEO también debe equilibrarse con otras prioridades comerciales y del sitio que compiten por el tiempo y el presupuesto.