Core Web Vitals: ¿qué son y cómo afectan al SEO?

Desde su presentación, los Core Web Vitals de Google se han vuelto una pieza fundamental para el posicionamiento SEO de cualquier navegador, sobre todo al momento de decidir cuál será el posicionamiento de los resultados. Es necesario saber qué son y cómo afectan al SEO.

Hace relativamente poco tiempo, Google presentó el nuevo esquema de métricas para los reportes de la Google Search Console. A estas se les denominó Core Web Vitals y su influencia va más allá que simplemente ser una métrica

La compañía también anunció que estas iban a unificar el resto de señales del sistema de clasificación de la experiencia de usuario, lo que es clave para determinar el posicionamiento de los resultados en las búsquedas.

A efectos prácticos, no es necesario crear alarma, pues los elementos más importantes para el correcto posicionamiento SEO son la relevancia del contenido que compartas y la calidad.

No obstante, si tu sitio web no carga lo suficientemente rápido, puede que los algoritmos de Google pongan a otros sitios con mejor optimización por encima del tuyo.

Sin embargo, si tu sitio web posee las optimizaciones necesarias, recibe mantenimiento constante y es fluida, es probable que no debas hacer ninguna modificación. Lo único en lo que debes fijarte es que ingreses a la zona verde de los puntos de Google. Pero si la página carga muy lentamente, entonces esta es la oportunidad para mejorarla inmediatamente.

La implementación de los Core Web Vitals le brinda importancia a un elemento del marketing SEO que en el pasado no era tan relevante, salvo para los desarrolladores web.

Y es que estos ya conocían sobre algunas de las nuevas métricas que fueron introducidas, como lo son el Largest Contentful Paint y First Input Delay. Pero el Cumulative Layout Shift es una nueva medición que debe estar presente durante la optimización del sitio.

Afortunadamente, si usas herramientas como Google Analytics y Google PageSpeed podrás ver el reporte de estas mediciones puestas en práctica. Estos Core Web Vitals son una forma de normalizar el buen desempeño de los sitios web y que todos puedan acceder a este.

¿Qué son los Core Web Vitals?

Es imposible obtener solo un criterio que sea funcional para medir todos los sitios web, por ello, Google creó nuevas métricas que ayude con el trabajo y son los Core Web Vitals.

En otras palabras, son métricas que sirven para reflejar algunos elementos que juegan un papel fundamental en la experiencia de usuario de los visitantes. Estas se ven favorecidas por los algoritmos de Google y se aplican del mismo modo para todas las páginas de internet.

Las tres métricas que introdujo Google son:

• Largest Contentful Paint: se encarga de medir la velocidad de carga que percibe el usuario sobre el objeto más importante del sitio.
• First Input Delay: es el parámetro que mide el tiempo que pasa antes de que el visitante pueda finalmente interactuar con el sitio web.
• Cumulative layout Shift: mide la frecuencia con la que cambia inesperadamente la distribución visual del sitio web.

Importancia de los Core Web Vitals

Estos nuevos parámetros juegan un papel sumamente importante para el posicionamiento web entre los resultados, por lo que es indispensable mejorarlos en la medida de lo posible.

Debido a que Google ha introducido un nuevo elemento que actúa como factor en el proceso de ranking, que es la experiencia de la página, y que fue anunciado con la presentación de los Core Web Vitals, entonces estos son parte de la misma medición.

Es necesario señalar que no solo por mejorar los Core Web Vitals vas a escalar drásticamente a las primeras posiciones, pues Google ha aclarado que la experiencia de la página solo forma parte de los 200 factores que están en juego.

Sigue siendo esencial tener contenido relevante y de calidad junto a un SEO muy bien pensado. No obstante, aprovechar los Core Web Vitals y sus optimizaciones es una oportunidad para que tu sitio mejore con el paso del tiempo.

¿Cómo se analizan los Core Web Vitals?

Para poder analizar las estadísticas de estos parámetros en móvil y escritorio, debes hacer uso de las herramientas de Google, que son Search Console y Analytics.

De hecho, con Google Analytics puedes analizar y visualizar la información de los Core Web Vitals, mientras que el Search Console te va a ofrecer métricas relacionadas a los visitantes de tu sitio.

¿Cuáles son los Core Web Vitals introducidos por Google?

Anteriormente, te mencionamos que Google introdujo tres Core Web Vitals para mejorar la optimización y la experiencia de usuario. Estos son los siguientes.

Largest Contentful Paint (Tiempo de carga)

Abreviado como LCP, es un factor que mide la manera en la que carga un sitio web para los usuarios. Esta métrica evalúa el tiempo que le toma cargar al objeto más grande del sitio web y, a menudo, este será una imagen o video.

Según Google, el LCP óptimo debe durar un poco menos de 2,5 segundos para ser considerado como algo bueno. Y si supera este límite, entonces entrará en el segmento de “Necesita mejorar”.

Es necesario añadir que el LCP no es el tiempo de carga para un sitio web completo, sino el plazo que tarda en cargar los objetos más importantes para el usuario.

First Input Delay (Interactividad)

Abreviado como FID, es el factor que determina la interactividad de una página o qué tan rápido reacciona ante las interacciones de los usuarios. Concretamente, el tiempo que le toma en ofrecerle respuesta cuando el visitante interactúa con ella.

Estas interacciones van a abarcar los elementos HTML, como escribir en comentarios, abrir menús de cascada, hacer clic en botones, marcar casillas, entre otras.

Para ser considerado bueno, debe durar menos de 100 milisegundos. Pero si llega hasta 300, entonces deberá mejorar y si lo supera, quedará en color rojo para Google.

Cumulative Layout Shift (Estabilidad visual)

Abreviado como CLS, es un parámetro nuevo y su misión es evaluar la estabilidad de tipo visual que tiene una página web.

Si un sitio tiene una pésima estabilidad visual o baja, va a ocasionar una impresión negativa para los usuarios. Un ejemplo de esto es cuando el usuario intenta hacer clic en algún botón y repentinamente se mueve y el clic se ejecuta a una publicidad que recién cargó.

Esto perjudica al sitio web, por lo que el CLS otorgará puntaje de acuerdo al número e impacto de cambios visuales que son inesperados. Si la puntuación es menor de 0,1 entonces será bueno, si es menos de 0,25 deberá mejorar y si lo supera, quedará en casilla roja.

¿Cómo se pueden mejorar los Core Web Vitals?

Antes de plantear esta pregunta, es necesario conocer el estado de los Core Web Vitals actualmente mediante reporte y para ello se usan las herramientas como Google Analytics o Search Console.

Una vez determinas que hay métricas que puedes mejorar, entonces sugerimos las siguientes acciones.

Cómo mejorar el LCP

Tendrás que reducir el número de elementos que se muestran al comienzo del sitio web y dejar únicamente lo que sea importante. Debes plantearte qué es lo que desea obtener el usuario cuando ingresa a tu página y cómo le podrías ayudar. Por ello, debes escoger el contenido manualmente que sientas que le ayuda y que no sean muy pesados.

Cómo mejorar el FID

Para lograr esto, tendrás que disminuir el impacto de los códigos externos, pues en ocasiones hay muchos procesos que se ejecutan al mismo tiempo y ralentizan las acciones.

También debes disminuir el tiempo que se ejecuta el JavaScript y cerciorarte que únicamente envíe lo esencial. Además, debes reducir la carga del main thread o disminuir el grado de complejidad de estilos y layouts de tu sitio.

Debes mantener el tamaño de las transferencias bajo, pues los archivos pesados hacen que las reacciones del sitio sean más lentas.

Cómo mejorar el CLS

Para mejorar esta métrica y no tener problemas, debes cerciorarte que todos los elementos tengan atributos de tamaño indicados. Debes tener presente que algunas animaciones pueden generar cambios en el layout del sitio, así que debes limitarlas si causan problemas.

Es necesario evaluar si tu página web necesita mejorar los Core Web Vitals y si resulta que sí, entonces debes ponerte en ello cuanto antes para evitar que tu sitio sea penalizado o enviado al final de los resultados por ser poco fluido.

Preguntas frecuentes sobre Web Vitals

A partir del mes de mayo del 2021, Google comenzará a emplear los Core Web Vitals como una parte esencial de sus rankings. Por ende, a continuación vamos a repasar las preguntas más frecuentes que existen en relación a los Core Web Vitals y la manera en que estos van a afectar a las clasificaciones.

Todas las respuestas que se ofrecerán corresponden a lo dicho por John Mueller desde Google. Sin embargo, las citas que se encontrarán en este artículo, han sido editadas para hacer que su lectura y entendimiento sea más claro, pues en los videos son citas directas. Aunque en caso de ser necesario, cada respuesta va a enlazar con el video en el que la pregunta es respondida.

¿Google utiliza los datos de campo o los datos de laboratorio en las clasificaciones?

 

Usamos los datos de campo, los cuales se basan en lo que los usuarios ven en realidad. Por ende, estos se basan en sus conexiones, dispositivos y su ubicación. Además, esto suele ser algo que refleja con mayor exactitud lo que el público normal puede ver.

¿En qué medida influyen los Web Vitals en los rankings?

 

La experiencia de la página es un factor fundamental adicional para la clasificación y las Web Vitals forman parte de esta.

La relevancia continua siendo importante, y por mucho. Por esto, solo considerando el hecho de que si tu página web es más rápida con respecto a los Core Web Vitals que las de tu competencia, no necesariamente significa que vas a escalar en las SERP hasta alcanzar el número uno entre los resultados de búsqueda.

Tendría sentido para nosotros mostrar este sitio entre los resultados de búsqueda, pues como puedes imaginar, una página web muy rápida podría estar vacía. Sin embargo, esto no es de mucha utilidad para los usuarios. Por ello, esto es importante de considerar cuando se trata de los Core Web Vitals.

Esto es algo que los usuarios notan y es algo que vamos a comenzar a utilizar para hacer la clasificación, aunque no cambiará todo completamente. Esto significa que no destruirá tu sitio web ni lo eliminará del índice si lo tienes mal, pero tampoco te llevará desde la página 10 hasta la primera si lo tienes bien.

¿Qué ocurre si una métrica no refleja exactamente la experiencia de una página?

Las métricas de rendimiento automáticas procuran evaluar la experiencia de los usuarios dentro de una página web, aunque no siempre van a coincidir con la experiencia real que se pueda tener. Sin embargo, Google se encuentra trabajando para mejorar las métricas con el paso del tiempo. Aquí puedes encontrar más información acerca de esto.

Además de esto, en caso de que el navegador malinterprete la experiencia de la página, John sugiere a los usuarios ponerse en contacto con el equipo de Google.

 

Para las cosas en las que notes que los cálculos se estén realizando de una manera que no tiene sentido, me pondría en contacto con el equipo de Chrome. Sobre todo con Annie Sullivan, quien se encuentra trabajando para mejorar la parte de Cambio de Disposición Acumulado (Cumulative Layout Shift).

Solo debes asegurarte de que ellos vean estos ejemplos. Y si te topas con algo que consideras que no tiene ningún sentido, entonces debes hacérselos saber.

También puedes esperar que las señales de experiencia de la página constantemente se actualicen, pero con previo aviso.

Nuestro objetivo con las Core Web Vitales y la experiencia de página en general, es que sean actualizadas constantemente. Creo que anunciamos que teníamos intención de actualizarlos al menos una vez al año y que las personas puedan saber con antelación lo que ocurre. Así que espero que esto también mejore con el tiempo.

En la actualidad, Google tarda 28 días en mostrar datos CrUX fiables ¿Podría actualizar entonces los datos de Web Vitals con mayor rapidez?

 

Después de realizar mejoras en el rendimiento de un sitio, los cambios pueden tardar un poco en reflejarse en Search Console. ¿Google puede acelerar este proceso?

 

No lo sé. Lo pongo en duda. Los datos que mostramos en la Search Console se basan en los datos del Reporte de Experiencia de Usuario de Chrome, el cual se emite luego de 28 días. Así que a esto se debe el retraso.

Tampoco es que Search Console sea lento procesando los datos ni nada parecido. Es solo que la manera en la que se recopilan y añaden los datos toma tiempo.

Entonces, ¿Cómo podemos detectar con antelación las regresiones y realizar un seguimiento de las mejores del rendimiento?

Lo que recomiendo, cuando las personas quieren conocer temprano si algo se rompe, es que deben cerciorarse por propia cuenta realizando pruebas exhaustivas de forma paralela para sus sitios más importantes. Además, existen un montón de herramientas de terceros que permiten realizar esto automáticamente.

También puedes usar directamente la API de Información de velocidad de las páginas (PageSpeed Insights). Eliges una muestra pequeña de tus sitios web más importantes y las pones a prueba diariamente. Solo así podrás conocer si ha ocurrido alguna regresión en alguna de las configuraciones que hiciste con rapidez.

Evidentemente, una prueba de laboratorio no es igual a los datos de campo. Por lo que existirá una diferencia allí. Aunque si notas que los resultados de la prueba de laboratorio se mantienen estables durante un tiempo, pero repentinamente se comportan extraño, entonces es probable que estés ante un indicador de algo en el diseño de tu sitio de ha roto.

¿Con qué frecuencia son actualizados los datos de Web Vitals?

 

El informe UX (Experiencia de Usuario) de Chrome se actualiza de forma diaria y se añaden los datos procedentes de los últimos 28 días. Por ende, si llevas a cabo una mejora, luego de un día, te encontrarás a 1 de 28 de ver los resultados en práctica.

¿Qué pasa si arreglas el rendimiento unos días antes de que se lance la actualización del ranking de la experiencia de la página?

Es muy probable que no lo notemos. Si realizas un cambio a corto plazo, no lo veremos en un primer momento, es lo más probable. Sin embargo, con el paso del tiempo, lo veremos. No se trata de una fecha en la que tomaremos medidas y las aplicaremos.

Si necesitas un par de semanas más antes de que todo se propague y se vea para nosotros también, entonces debes tomarte ese tiempo para hacerlo bien y hallar soluciones para hacer que todo funcione correctamente.

La parte complicada con respecto a los datos de laboratorio y de campo, es que puedes trabajar con la información del laboratorio gradualmente y probar cosas, viendo qué funciona mejor. Aunque será necesario recopilar la confirmación de los usuarios con los datos de campo.

¿Los cambios de posiciones se aplican tanto en desktop como a los móvil?

De momento, solo a los móviles.

 

Ya anunciamos que el factor de clasificación de la experiencia de la página se va a aplicar a los móviles, pero no a los ordenadores de escritorio.

Esto es así, al menos en un principio, pues desconozco cuáles serán los planes a largo plazo. Supongo que eventualmente vamos a resolver las cosas detalladamente y nos encargaremos de ello. Pero de momento, el anuncio que realizamos aplica únicamente a los móviles.

Es ahí donde yacen las barreras más complicadas, pues en los ordenadores de escritorio suelen tener procesadores potentes y, por lo general, conexiones por cable. Mientras que en el móvil, el procesador tiende a tener menos capacidad, y está acompañado de una pantalla más reducida y conexiones lentas, en ocasiones. Es por ello que en esos dispositivos es primordial solucionar para que las páginas carguen rápidamente.

¿Cómo hace Google para clasificar las páginas?

Google no dispone de datos reales relacionados al rendimiento de los usuarios para cada una de las páginas indexadas en la búsqueda. Pero, ¿Cómo clasifica las páginas?

 

Para ello, usamos los datos del informe de experiencia de usuario en Chrome como una referencia. Luego segmentamos el sitio en varias partes, que podemos reconocer desde el mencionado informe y que también se reflejará en el informe de la Consola de Búsqueda.

Basándonos en estas secciones, al menos con respecto a URLs específicas, intentamos hallar el grupo más adecuado en el que encajarlas. De esta manera, por ejemplo, si un usuario busca páginas AMP en tu sitio, tienes una sección separada de AMP o una plantilla que podamos identificar, entonces esas serán las métricas que usaremos.

Tampoco significa que si hay unas páginas lentas dentro de tu sitio web, entonces todo será etiquetado como lento. Se trata realmente de enfocar en ese grupo de páginas que asumimos que, cuando un usuario las visita, tendrá una experiencia similar, por lo que las tratamos como grupo.

Así que, si estas son buenas, entonces la página caerá esencialmente en los grupos que son buenos.

Con respecto a los sitios AMP, John señala que el informe AMP no considera el tráfico. Una página que visitan muchos usuarios y tiene una buena experiencia, puede incluso parecer lenta si hay otras páginas más lentas que se visitan con menor frecuencia.

La parte más complicada del informe AMP es que mostramos los sitios web, pero no incluimos la información relacionada al tráfico que va a cada una de estas.

En ese sentido, puede que tengas 100 páginas que aparecen allí, por ejemplo, y tu tráfico principal se enfoca en 10 de estas. Entonces esto da la impresión de que el 90% de tus páginas son lentas y solo las 10 que visitan los usuarios son rápidas. No obstante, en realidad, las personas visitarán en su mayoría los sitios web rápidos, por lo que lo tendremos en cuenta.

¿Los datos de rendimiento se comparten entre subdominios?

 

Por lo que recuerdo, los datos de CrUX se mantienen igual a nivel de origen. En el caso de Chrome, el origen es el nombre del host, que se encontraría a nivel de protocolo y subdominio. Por ende, si tienes varios subdominios, estos se tratan por separado.

 

¿Las páginas no indexadas afectan a los Web Vitals?

Muchos de los sitios poseen páginas lentas y complejas, las cuales no están incluidas en el índice de búsqueda. Entonces, ¿Esto afecta al rendimiento de las páginas en el ranking?

Esto va a depender si Google clasifica las páginas en conjunto con las que se encuentran indexadas en la búsqueda. Sobre todo si no hay otros datos, entonces Google usa la información recopilada del rendimiento para las páginas no indexadas.

Si es un sitio web pequeño, del que no tenemos muchas señales, entonces estas páginas que no están indexadas pueden desempeñar una función. Por ello, tengo entendido, aunque no estoy completamente seguro, que en el informe de UX de Chrome incluimos todas las páginas que visitan los usuarios.

Tampoco hay una comprobación específica sobre si una página se indexará o no, pues la capacidad de indexación en ocasiones es complejo con respecto a los canónicos y todo lo demás. Así que no es trivial intentar determinar, desde la perspectiva de Chrome, si un sitio será indexado o no.

Es posible que ocurra un caso en que, si un sitio tiene claro un no-índice, seremos capaces de reconocerlo en Chrome. Pero no estoy totalmente seguro si realmente hacemos eso.

¿Las páginas tras un inicio de sesión afectan a los Web Vitals?

A menudo, las páginas cargan contenido y funciones adicionales para los usuarios que iniciaron sesión. Todo este contenido es capaz de ralentizar la página. ¿Van a afectar las páginas con sesión iniciada en el ranking?

Si la misma URL es de público acceso, entonces es altamente probable que se pueda incluir en los datos agregados de las Core Web Vitals, justo en el lado de las métricas de los usuarios reales. Por lo que podríamos contarla también.

Pero si esta página de inicio de sesión existe en un foro público, también contaremos las métricas. Mientras que si tienes la URLs separadas y no somos capaces de indexar direcciones separadas, entonces eso será algo que tenemos y podemos separar.

No obstante, desconozco cuál es la orientación exacta de las Core Web Vitals. En mi caso, volvería a comprobarlo, específicamente lo que respecta a Chrome, en las páginas de ayuda de CrUX para determinar cómo influiría en ese concreto caso.

¿Por qué Google Search Console muestra grandes fluctuaciones en los Web Vitals?

¿Por qué las valoraciones de un conjunto de páginas bajan y suben repetidamente? ¿Qué debo hacer si las valoraciones de mi sitio cambian entre amarillo y verde constantemente?

Lo que ocurre con estos informes, en ocasiones, es que una métrica está justo en el borde entre el amarillo y verde.

Si, durante un periodo de tiempo específico, las mediciones tienen tendencia por debajo del borde, entonces cambiará a amarillo y te sorprenderás de cómo el verde ha desaparecido. Pero cuando las métricas suben un poco en dirección al verde, vuelven a cambiar completamente.

Estos cambios pueden ocurrir al momento de hacer las mediciones. Para mí, esta fluctuación de ida y vuelta, apunta a que la dirección está justo en el borde. Por lo que para mejorarlo, es darle ese empujón que le falta en la dirección que deseas.

¿La clasificación amarilla “necesita mejorar” es lo suficientemente buena para clasificar bien, o se necesita que esta sea “buena”?

Intenta conseguir una clasificación “Buena” marcada con verde.

Según tengo entendido, cuando vemos que está en verde, asumimos que está bien, pero si está en amarillo, entonces significa que no es lo eficiente.

Sin embargo, no sé cuál es el enfoque final. Esto debido a que existen varios factores que confluyen. Considero que la idea general es que, si reconoces que un sitio web coincide con los criterios establecidos, nos gustaría usarla en la búsqueda para el ranking.

Tampoco sé cuál sería el enfoque que se toma cuando las cosas parecen estar bien ni cuando no lo están, por lo que desconozco cómo equilibrar esto.

La orden general es que nos encantaría usar los criterios para mostrar una insignia entre los resultados de búsqueda; y esto es algo que creo que ya hemos experimentado. Pero para lograrlo, tenemos que saber que todos los factores son compatibles e importantes. Por ejemplo, si tu sitio web no está en HTTPS, pero todo lo demás está bien, en realidad no sería suficiente para ser considerado así.

¿Por qué en ocasiones las páginas AMP se muestran por separado de las que no lo son?

 

¿Qué ocurre si Search Console muestra una URL lenta en la página web, pero la versión AMP de esta se muestra cómo rápida?

No nos centramos en el aspecto teórico de que se trata de una página AMP y hay una canónica. Sino que, en su lugar, nos enfocamos en los datos que vemos de los usuarios reales y que van a estos sitios.

Esto es algo en lo que puedes notar un efecto de muchos usuarios que visitan tu sitio web, acudiendo a la URL y no al AMP, de acuerdo a cómo hayas configurado tu página.

En la búsqueda, tienes los URLs AMP, entonces es probable que tengamos señales suficientes para rastrear individualmente las dos versiones. Por lo que, por un lado, la gente que vaya a la búsqueda, irá a la versión AMP, y quienes vayan a tu sitio web directamente, entonces acudirán a la versión no AMP. En este caso, seríamos capaces de ver la información por separado de ambas versiones.

Mientras que, si has configurado tu sitio para que siempre funcione con la versión AMP, por lo que quizás la gran mayoría de usuarios visiten tu versión AMP desde el móvil, entonces podemos definir que esta es la versión principal y las señales las centraremos hacia ella.

Sin embargo, en la teórica situación de que tengamos los datos de la versión no AMP los de la versión AMP, pero sea esta última la que mostremos en los resultados de búsqueda, entonces usaríamos los datos de esta versión como base en el ranking de búsqueda.

¿Por qué veo diferentes valores para las Web Vitals en CrUX y en la Información de velocidad de las páginas?

Los datos de laboratorio de la Información de velocidad de páginas (PageSpeed Insights) frecuentemente serán distintos de los datos de campo. Por lo general, los primeros son más lentos, ya que Lighthouse simula un dispositivo que sea muy lento, cuyo ancho de banda es de 1,6 Mbps y 150 ms de latencia de red de ida y de vuelta.

Este es un ejemplo bastante común de la página de inicio de la BBC.

John también señala que la Información de velocidad de páginas (PageSpeed Insights) intenta comprimir todas las métricas de rendimiento en una puntuación única.

En la PageSpeed Insights tomamos varias métricas y tratamos de calcular un número a partir de estas. En ocasiones, esto es bastante útil para obtener una visión general de lo que vendría siendo una puntuación global, pero todo dependerá de la importancia que se le proporcione a los factores.

Es posible que se dé el caso en que un usuario vea un sitio web que es rápido y elegante, pero cuando nuestro sistema lo prueba, entonces descubre algunos problemas teóricos que podrían estar arruinando su situación.

La puntuación global es una excelente manera de obtener una estimación aproximada. Y los datos de campo reales también son una buena manera de ver lo que la gente ve en realidad.

¿Cómo se usan conjuntamente los datos de campo y de laboratorio?

 

Lo que yo recomiendo es usar los datos de campo como una base para determinar “¿Debo concentrarme en mejorar la velocidad del sitio web o no?”, luego usar las herramientas de prueba del laboratorio para determinar los valores métricos individuales y ajustarlos a medida que se va realizando el trabajo.

Usa los datos de laboratorio para corroborar que vas en la dirección adecuada, pues los datos de campo se retrasan por unos 30 días. De manera que cualquier tipo de cambio que realices, entonces los datos de campo tendrán siempre 30 días de retraso y si no estás seguro de que vas bien encaminado, entonces esperar todo un mes es un poco molesto.