Los Core Web Vitals son la forma en que Google mide la experiencia de usuario de una página, llamados de manera general Web Vitals. Hay tres elementos básicos y que gravitan fuertemente el score definitivo, que son lo conocidos como Core Web Vitals, o Web Vitals básicos:
- Largest Contentful Paint – LCP: notifica el tiempo de procesamiento de la imagen o bloque de texto más grande visible dentro de la ventana gráfica, en relación con cuando la página comenzó a cargarse por primera vez.
- First Input Delay – FID: ayuda a medir la primera impresión del usuario de la interactividad y la capacidad de respuesta de su sitio.
- Cumulative Layout Shift – CLS: mide el total de suma de todas las puntuaciones de desplazamiento de diseño individuales para cada cambio de diseño inesperado que se produce durante toda la vida útil de la página.
A partir de mayo de 2021, Google comenzará a usar Core Web Vitals como señal de posicionamiento. Pero ese no es el final, es sólo el principio. Los Core Web Vitals serán más importantes de aquí en adelante.
En este artículo, veremos cómo medir, interpretar y mejorar tus Core Web Vitals para ofrecer una mejor experiencia de usuario, mejorarlos hace que la experiencia de usuario sea mejor, y además, a partir de mayo de 2021 se convertirá en un factor de posicionamiento para la Búsqueda de Google en móvil. Este cambio probablemente se implementará a nivel mundial, de una sola vez.
A lo largo de este artículo, hablaremos con frecuencia sobre datos de campo y datos de laboratorio. Debido a que estos a menudo se malinterpretan, necesitamos explicar la diferencia desde un principio:
- Los datos de campo se recopilan de usuarios reales a través del Informe de experiencia de usuario de Chrome («CrUX» para abreviar).
- Los datos de laboratorio se recopilan dentro de un entorno controlado sin ninguna participación de usuarios reales.
Ahora que tenemos despejados estos términos, ¿dónde encajan los Core Web Vitals en los algoritmos de búsqueda de Google?
Actualmente, Google mide la experiencia del usuario en función de si un sitio:
- Es compatible con dispositivos móviles
- Ofrece una navegación segura
- Se ejecuta bajo HTTPS
- Está libre de intersticials intrusivos
Ahora, además de estos cuatro factores, se suma un quinto, los Core Web Vitals, y juntos se convertirán en parte de un grupo de señales que Google utiliza para calificar «Page Experience«, como muestra esta ilustración:
Es importante tener en cuenta que los Core Web Vitals, tanto los datos de campo como las métricas de datos de laboratorio, están enfocado principalmente a dispositivos móviles: son un proxy para medir la experiencia del usuario, y debido a que la web y sus usuarios están en constante evolución, es natural que los Core Web Vitals también evolucionen.
¿Por qué esta guía sobre Core Web Vitals?
Porque hay mucha desinformación sobre los Web Vitals, y la información correcta está dispersa por todas partes. Incluso Google no puede mantener todo en un solo lugar. Al crear esta guía, el objetivo es proporcionar un recurso perenne con información correcta sobre los Core Web Vitals y a dónde ir si deseas profundizar.
Recursos útiles
- Anuncio de Experiencia de página de Google del 10 de noviembre de 2020
- Page Experience será una señal de posicionamiento solo para búsqueda móvil
- Es probable que la experiencia de la página se despliegue globalmente de una sola vez
¿Qué vas a leer?
- ¿Qué son los Core Web Vitals?
- ¿Por qué deberías preocuparte por Core Web Vitals?
- Core Web Vitals en detalle
- Comparación de versiones
- Herramientas para medir sus Core Web Vitals
- ¿Cómo se calcula su puntuación de rendimiento de Lighthouse?
- Recursos para continuar aprendiendo
- Preguntas frecuentes sobre Core Web Vitals
- 1. ¿Qué tan grande será el impacto SEO de los Core Web Vitals tendrá a partir de mayo de 2021?
- 2. ¿Cómo paso la evaluación de Core Web Vitals?
- 3. ¿Por qué los datos de laboratorio y las puntuaciones de datos de campo son tan diferentes?
- 4. ¿Por qué no hay datos de campo para mi URL o Resumen de Origen?
- 5. ¿Las páginas no indexables afectan a mis Core Web Vitals?
¿Qué son los Core Web Vitals?
Puede que la primera impresión sea asociar los CWV con la velocidad de una página, pero las métricas de Core Web Vitals son más que solo velocidad.
Core Web Vitals es un conjunto de métricas orientadas al usuario relacionadas con la velocidad, la capacidad de respuesta y la estabilidad visual, para ayudar a los propietarios de sitios a medir la experiencia del usuario en la web.
Las métricas de Web Vitals se dividen en Core Web Vitals y Web Vitals no básicos.
Los Core Web Vitals son:
- Largest Contentful Paint (LCP)
- First Input Delay (FID)
- Content layout Shift (CLS)
Y los Web Vitals no Básicos son:
- Total Blocking Time (TBT)
- Total Blocking Time (FCP)
- Speed Index (SI)
- Time to Interactive (TTI)
Cada métrica mide cuán «buena» es una parte de la experiencia de página. La siguiente ilustración muestra cómo se carga una página y dónde entran en juego las diferentes métricas, y que mejor que recurrir a Addy Osmani, ingeniero de Chrome en Google, para entenderlos de manera visual:
Pero antes de revisar todos los Web Vitals, primero necesitamos explicar por qué son importantes.
¿Por qué deberías preocuparte por Core Web Vitals?
Estas son las tres razones principales por las que tu (y todo el mundo) deben preocuparse por Core Web Vitals:
- A los visitantes les encantan los sitios rápidos que son fáciles y agradables de usar, en cualquier dispositivo, desde cualquier ubicación. La conclusión es: tu tasa de conversión aumentará si es fácil para los usuarios navegar por tu web
- Como se mencioné en la introducción, Google ha anunciado que los Core Web Vitals se convertirá en un factor de clasificación a partir de mayo de 2021. Si bien no se espera ver un gran cambios en los rankings en mayo y la relevancia sigue siendo mucho más importante, y se especula en el mundo SEO que su importancia crezca con el tiempo.
- Pasar la evaluación de Core Web Vitals es probable que resulte en que menos usuarios se se marchen de nuevo a la SERPs de donde hav llegado a tu web, porque estás proporcionando una buena experiencia de usuario, y Google ha insinuado que pueden comenzar a mostrar una insignia de «Buena experiencia de página» en sus resultados de búsqueda. Llamamos a estos «factores de clasificación indirectos», porque influyen en el comportamiento de los buscadores (por ejemplo, más clics para las páginas que tienen este indicador), que se retroalimenta en los algoritmos de Google. En febrero de 2021, JR Oakes estaba hojeando el código fuente de Google Search Console cuando se dio cuenta de que Google ya puede haber hecho algunos preparativos en esta área:
Así que, en resumen: a pesar de que el impacto de Core Web Vitals como señal de clasificación es probable que se exagere, verás el retorno de la inversión para cualquier mejora de la experiencia del usuario, porque una mejor experiencia de usuario conduce a visitantes más felices y más conversiones.
Profundiza usando estos recursos:
- En 2018, Google descubrió que la probabilidad de que la tasa de rebote aumente un 32% si el tiempo de carga de la página pasa de 1s a 3s.
- En 2017, Akamai descubrió que un retraso de 100 ms en el tiempo de carga puede dañar las tasas de conversión en un 7 por ciento.
- Y Cloudflare ha recopilado varios estudios más de este tipo.
- Hace 15 años, Amazon se enteró de que sus ingresos aumentaron un 1% por cada disminución de 100 ms en el tiempo de carga.
- Ganar en SEO con una gran experiencia de usuario
Core Web Vitals en detalle
Sin más preámbulos, ¡nos sumergamos en cada una de las métricas de Web Vitals, comenzando con los Core Web Vitals!
Largest Contentful Paint (LCP)
Largest Contentful Paint (LCP) es un Core Web Vital que mide el tiempo en segundos desde que la página comienza a cargarse hasta cuando se renderiza el bloque de texto o elemento de imagen más grande en port view.
Su objetivo es medir cuándo se han terminado de cargar los contenidos principales de la página. Cuanto más bajo sea el LCP, mejor. Un LCP rápido asegura a los usuarios que una página es útil, porque es una métrica que mide la velocidad de carga percibida. LCP está disponible tanto en datos de campo como en datos de laboratorio.
En el campo, el navegador dejará de informar a los nuevos candidatos de LCP tan pronto como el usuario interactúe con la página (a través de tocar, desplazarse, presionar la tecla, cambiar de pestaña o cerrar la pestaña). En el laboratorio, no está del todo claro cuándo está terminado el LCP. Esperamos que este momento sea cuando la página se acerque a Time to Interactive (TTI).
Consideraciones importantes
Mientras se carga una página, el bloque de texto o la imagen más grande puede cambiar, y el elemento más reciente se utiliza al medir el LCP.
Por ejemplo, considera cuando al principio un encabezado H1 es el bloque de texto más grande, pero más tarde se carga una imagen más grande aún. La imagen más grande es entonces el elemento líder en la medición del LCP.
Ten en cuenta qué elementos actualmente no se consideran para medir la LCP. Así que si estás cargando un logotipo grande como un elemento «< svg >», no se considerará un elemento LCP. Esto se decidió para mantener las cosas simples, y puede cambiar en el futuro.
Cómo interpretar su puntuación LCP
He aquí cómo interpretar su puntuación de LCP:
- Bueno:
<= 2.5s(2.5 s) - Necesita mejorar:
> 2.5s <= 4s(between 2.5 and 4 seconds) - Pobre:
> 4s(more than 4 seconds)
¿Qué podría estar causando una mala puntuación de LCP?
Podría haber una de una miles de causas para una mala puntuación de LCP, por ejemplo, tiempos de respuesta lentos del servidor, JavaScript y CSS bloqueando el renderizado y tener los recursos de contenido muy grandes y que sean demasiado pesados, lo que requiere demasiado tiempo para cargarse.
Mejorar su puntuación de LCP
Puede hacer muchas cosas para mejorar su puntuación de LCP, por ejemplo, optimizar su ruta de renderizado crítica, CSS e imágenes. Describirlos todos está mucho más allá del alcance de este artículo. Así que recomendamos revisar los recursos de web.dev sobre la optimización de las puntuaciones de LCP.
Más información sobre LCP
- Explicación de la pintura contenta más grande (LCP) por web.dev.
First Input Delay (FID)
First Input Delay (FID) es un CWV que mide el tiempo en milisegundos desde que un usuario interactúa por primera vez con su sitio (es decir, cuando hace clic en un enlace, toca un botón o presiona una tecla) hasta cuando el navegador es capaz de responder a esa interacción.
El FID subyace a la primera impresión de un usuario de la interactividad y capacidad de respuesta de su sitio. ¡Mejor que sea una buena impresión!
Como sugiere la descripción de esta métrica, solo se puede medir en el campo, ya que se basa en la interacción del usuario. Por lo tanto, el FID solo está disponible en datos de campo. Cuanto más bajo sea el FID, mejor.
Para las pruebas dentro del laboratorio, se utiliza la métrica Tiempo de bloqueo total, ya que se correlaciona estrechamente con el retraso de la primera entrada.
Consideraciones importantes
El FID no mide el tiempo que tarda el navegador en procesar un evento (por ejemplo, un toque en un botón), ni el tiempo que tarda en actualizar la interfaz de usuario después de eso.
Interacciones como el desplazamiento y el zoom no se cuentan como acciones, porque son de naturaleza continua y tienen restricciones de rendimiento muy diferentes.
Cómo interpretar su puntuación FID
Aquí está cómo interpretar su puntaje FID:
- Bueno:
<= 100ms - Necesita mejorar:
> 100ms and <= 300ms - Pobre:
> 300ms
¿Qué podría estar causando una mala puntuación FID?
Una razón común para una mala puntuación FID es que el hilo principal de un navegador está ocupado analizando y ejecutando código JavaScript. Cuando el hilo principal está ocupado, todavía no puede responder a la interacción de un usuario.
Mejorar su puntaje FID
Si quieres mejorar tu puntuación FID, debes mirar de cerca lo que impide que al navegador que la página sea interactiva. Ejemplos de cosas que puede hacer para mejorar su puntaje FID son:
- Reducción del tiempo de ejecución de JavaScript.
- Minimizar el trabajo realizado en el hilo principal.
- Reducir el impacto del código de terceros.
Describir los pormenores de cómo mejorar el puntaje FID está más allá de este artículo. Así que es mejor revisar los recursos de web.dev sobre la optimización de las puntuaciones FID.
Más información sobre FID
- Explicación del primer retraso de entrada (FID) por web.dev.
Cumulative Layout Shift (CLS)
El Cumulative Layout Shift (CLS) es un CWV que mide la puntuación acumulada de todos los cambios de diseño inesperados dentro de la ventana gráfica que se producen durante todo el ciclo de vida de una página.
Su objetivo es medir la «estabilidad visual» de una página, ya que eso influye en gran medida en la experiencia del usuario. CLS está disponible tanto en datos de campo como en datos de laboratorio. Cuanto menor sea la puntuación CLS, mejor será la estabilidad visual.
CLS no se mide en segundos como la mayoría de las otras métricas. Funciona desde el tamaño de la ventana gráfica, se relaciona con elementos que se mueven entre dos marcos, llamados elementos inestables, y mide su movimiento en la ventana gráfica. La puntuación de cambio de diseño es un producto de dos componentes: la «fracción de impacto» y la «fracción de distancia».
La «fracción de impacto» es el área de la ventana gráfica que el elemento inestable ocupa en ambos marcos:
La «fracción de distancia» es la mayor distancia que el elemento inestable se mueve entre ambos marcos, dividida por la dimensión más grande de la ventana gráfica (ancho o alto):
Encontrará varios ejemplos para construir una comprensión aún mejor de cómo se calcula CLS aquí (se abre en una nueva pestaña).
Consideraciones importantes
«Todo el ciclo de vida de una página» significa que cuando la página permanece abierta durante días, o incluso semanas, el CLS se mide todo el tiempo. Obviamente, aquí es donde los datos de campo de CLS y los datos de laboratorio reportarán diferencias, porque las herramientas solo recopilan datos de laboratorio durante un período muy breve.
Probar correctamente los cambios de diseño inesperados en entornos de prueba puede resultar complicado, porque algunas funcionalidades pueden estar deshabilitadas o funcionar de manera diferente allí. Algunos ejemplos: es posible que no se muestren notificaciones de cookies, que se desactive el soporte de chat en vivo y que no se cargue contenido personalizado.
Cómo interpretar su puntuación CLS
He aquí cómo interpretar su puntuación CLS:
- Bueno:
<= 0.1 - Necesita mejorar:
> 0.1 <= 0.25 - Pobre:
> 0.25
¿Qué podría estar causando una mala puntuación de CLS?
Los cambios de diseño inesperados a menudo ocurren debido a imágenes o anuncios con dimensiones indefinidas, recursos que se cargan asíncronamente y situaciones en las que se agregan nuevos elementos DOM dinámicamente a una página, por encima del contenido existente que ya se ha cargado. Esto resulta en que el contenido que ya se ha cargado se elimine.
Mejorar su puntuación CLS
Puedes evitar cambios de diseño inesperados, por ejemplo, incluyendo siempre atributos de tamaño para tus imágenes y videos y no insertando contenido por encima de otro contenido que ya está cargado. Es muy recomendable revisar el artículo de web.dev sobre la optimización de las puntuaciones de CLS para aprender la gama completa de mejoras que puede hacer.
Más información sobre CLS
- Cambio de diseño acumulativo (CLS) explicado por web.dev.
- Buscar y corregir cambios de diseño con Chrome DevTools de Upbuild
Total Blocking Time (TBT)
El Total Blocking Time (TBT, o tiempo total de bloqueo) es un Web Vital no básico que mide el tiempo total en milisegundos entre First Contentful Paint (FCP) y Time To Interactive (TTI) donde el hilo principal se bloquea el tiempo suficiente para que no responda a la entrada del usuario.
TBT se correlaciona directamente con First Input Delay (FID), y por lo tanto se considera la mejor alternativa cuando se prueba en un entorno de laboratorio donde la interacción real del usuario no es posible. Si bien el TBT se puede recopilar en el campo, está fácilmente influenciado por la interacción del usuario y no es una métrica confiable para medir cuánto tiempo tarda una página en responder a la entrada del usuario. Por lo tanto, TBT solo se utiliza en datos de laboratorio.
Cualquier tarea que tarde más de 50 ms en ejecutarse se considera una tarea larga, y el tiempo por encima de los 50 ms se considera el «tiempo de bloqueo». TBT se calcula tomando la suma de la parte de bloqueo de todas las tareas largas. Por ejemplo, si hay tres tareas largas:
- La tarea A tarda 75 ms (25 ms más que 50 ms)
- La tarea B tarda 60 ms (10 ms más que 50 ms)
- La tarea C tarda 85 ms (35 ms más que 50 ms)
El TBT es entonces: 70ms (25+10+35). Cuanto más bajo sea el TBT, mejor.
Cómo interpretar tu puntuación de TBT
Aquí está cómo interpretar tu puntuación de TBT:
- Bueno:
< 300ms - Necesidades de mejora: entre
300ms y 600ms - Pobre:
> 600ms
Causas de una mala puntuación de TBT y cómo mejorarla
Debes seguir las mismas recomendaciones de la sección anterior y Cómo mejorar su puntaje de TBT explicado en detalle por web.de, sobre qué causa un puntaje de TBT pobre y cómo mejorarlo.
Más información sobre TBT
- Tiempo total de bloqueo (TBT) explicado por web.dev.
First Contentful Paint (FCP)
First Contentful Paint (FCP) es una Web Vital no básico que mide el tiempo desde que una página comienza a cargarse hasta que se representa cualquier parte del contenido de esa página en la pantalla. Tener un FCP rápido tranquiliza a los usuarios de que algo está sucediendo. En este contexto, el contenido significa texto, imágenes (incluidas imágenes de fondo < svg >), y elementos de < canvas >.
El FCP está disponible tanto en datos de campo como en datos de laboratorio, y cuanto menor sea el FCP, mejor.
Cómo interpretar su puntuación FCP
He aquí cómo interpretar su puntuación FCP:
- Bueno:
< 1s - Necesita mejorar:
>= 1s < 3s - Pobre:
>= 3s
¿Qué podría estar causando una mala puntuación de FCP?
Las causas comunes de una puntuación FCP pobre son los altos tiempos de respuesta del servidor y los recursos de bloqueo de renderizado.
Mejorar su puntuación de FCP
Puede haber muchas cosas para mejorar tu puntuación de FCP, por ejemplo, eliminar recursos de bloqueo de renderizado, eliminar CSS no utilizado, minimizar CSS y usar una CDN.
Más información sobre FCP
- First Contentful Paint (FCP) explicado por web.dev.
- 10 maneras de mejorar la First Contentful Paint por WP Rocket.
- Recursos de web.dev sobre la optimización de las puntuaciones de FCP.
Speed Index (SI)
Speed Index (SI o el índice de velocidad) es un Web Vital no básico que mide la rapidez con la que se rellena visiblemente el contenido de una página durante la carga. Se calcula utilizando el análisis fotograma por fotograma del comportamiento de carga de tu página, contando la progresión visual entre fotogramas capturados cada 100 ms.
El SI está disponible tanto en datos de campo como en datos de laboratorio.
Cómo interpretar su puntuación SI
Aquí está cómo interpretar su puntaje SI:
- Bueno:
<= 4.3s - Necesita mejorar:
> 4.3s <= 5.8s - Pobre:
> 5.8s
¿Qué podría estar causando una mala puntuación de SI?
Cualquier cosa que impida que la página se cargue rápidamente dañará su puntuación SI. Algunas de las causas que se mencionan para las otras métricas, como por ejemplo el hilo principal que se bloquea, también se aplican aquí.
Mejorar su puntuación SI
Si te centras en mejorar el rendimiento general de la carga de la página, también verás que tu puntuación SI mejora. Recomendamos revisar el recurso de web.dev sobre esto aquí.
Más información sobre SI
- Índice de velocidad (SI) explicado por web.dev.
Time to Interactive (TTI)
Time to Interactive (TTI) es un Web Vital no básico que mide el tiempo desde que la página comienza a cargarse hasta cuando es totalmente interactiva.
Para que sea totalmente interactivo, necesita:
- Mostrar contenido útil (medido por First Contentful Paint).
- Tener renderizados los elementos de página más visibles.
- Responder a las interacciones del usuario dentro de los 50 ms.
Si bien es posible medir TTI en el campo, no se recomienda, porque la interacción del usuario puede influir en gran medida en el TTI de su página. Por lo tanto, solo se debe utilizar TTI desde un entorno de datos de laboratorio.
Cómo interpretar tu puntuación de TTI
Aquí está cómo interpretar tu puntuación de TTI:
- Bueno:
<= 3.8s - Necesita mejorar:
> 3.9s <= 7.3s - Pobre:
> 7.3s
¿Qué podría estar causando una mala puntuación de TTI?
De manera similar a la métrica Índice de velocidad anterior, muchas de las cosas que causan malas puntuaciones en las otras métricas que describimos también se aplican a TTI, porque es una métrica que abarca esas otras métricas.
Mejorar su puntuación de TTI
Puedes revisar este artículo de web.dev para conocer los próximos pasos sobre cómo mejorar TTI.
Más información sobre TTI
- Tiempo para Interactivo (Explicación general) por web.dev.
- Tiempo para Interactivo (métrica Lighthouse) explicado por web.dev.
Comparación de versiones
Cuando se trata de datos de Core Web Vitals, es esencial que comparemos una versión con la otra. Es por eso que necesitamos resolver las diferencias entre los datos de campo y los datos de laboratorio, así como los datos móviles y los datos de escritorio.
Datos de campo frente a datos de laboratorio
Una vez más, cuando se trata de Web Vitals, hay dos tipos de datos: datos de campo y datos de laboratorio:
- Los datos de campo se recopilan de usuarios reales, cada uno con su dispositivo único y conexión de red, a través del Informe de experiencia de usuario de Chrome («Informe CrUX» para abreviar).
- Los datos de laboratorio se recopilan dentro de un entorno controlado con una configuración de conexión de red y dispositivo predefinidos, sin ninguna participación de usuarios reales (ya se encarga Google de realizar los test y de recopilar toda la información de laboratorio).
Es esencial que se entienda la diferencia entre estos dos tipos de datos, ya que es quizás el aspecto que más confunde de las métricas de Core Web Vital.
Puede que estés obteniendo grandes puntuaciones en Lighthouse (datos de laboratorio), mientras que tus usuarios reales están teniendo una mala experiencia de usuario (datos de campo). Alternativamente, puedes tener lo mismo a la inversa: ¡grandes puntuaciones basadas en datos de campo y puntuaciones deficientes de datos de laboratorio!
Luego está el «Resumen de Origen», que se basa en datos de campo que representan la experiencia agregada de todas las páginas servidas desde su sitio. Ten en cuenta que si tienes algunas plantillas específicas que se cargan notoriamente lentas, esto dañará su puntuación de Resumen de Origen. Supervisar los datos de Origin Summary de tu sitio
Métricas y disponibilidad de Web Vitals
Aquí hay una descripción general de la disponibilidad de las métricas de Web Vitals en datos de campo y de laboratorio:
| Datos de campo | Datos de laboratorio | |
|---|---|---|
| Pintura Contentful más grande (LCP) |  | |
| Retraso de primera entrada (FID) | |  |
| Cambio de diseño acumulativo (CLS) | | |
| Tiempo total de bloqueo (TBT) | | |
| Primera pintura contenta (FCP) | | |
| Índice de velocidad (SI) | | |
| Tiempo para Interactivar (TTI) | | |
Qué más necesitas saber sobre los datos de campo
Datos de campo:
- Puede que no esté disponible para tus páginas si no están recibiendo suficientes visitantes, lo que significa que no hay suficientes datos de CrUX. Esto va tanto para las URL individuales como para su Resumen de Origen.
- Es menos útil para la depuración, porque después de hacer algunas mejoras, tendrás que esperar a que lleguen nuevos datos de CrUX. Por lo tanto, es mejor confiar en los datos de laboratorio para fines de depuración.
- También incluye datos de mercados a los que no necesariamente estás atendiendo. Por ejemplo, si te diriges principalmente a los Estados Unidos, pero recibes mucho tráfico de mercados emergentes que no tienen el mismo acceso a Internet rápido y hardware, verás datos de campo muy mixtos, simplemente porque la audiencia de la que se recopilan tus datos de campo también es muy mixta.
- También puede incluir datos de páginas no indexables como páginas de destino de PPC (fuente).
¿Qué más necesitas saber sobre los datos de laboratorio?
Datos de laboratorio:
- Se recoge (a partir de marzo de 2021) emulando un móvil Moto G4 con una conexión 3G rápida.
- No incluye datos de interacción del usuario, porque los datos de laboratorio se simulan. Es por eso que First Input Delay (FID) no está disponible en entornos de laboratorio.
- Produce resultados reproducibles.
Datos de campo vs. Datos de laboratorio resumidos
| Datos de campo | Datos de laboratorio | |
|---|---|---|
| Origen de los datos | Usuarios reales | Usuario simulado |
| Frescura de los datos | Reunidos en los últimos 28 días | Recopilado en tiempo real |
| Dispositivo | Único para cada usuario | Un dispositivo (por defecto: Moto G4) |
| Conexión de red | Único, en todos los usuarios | Una velocidad de conexión de red (por defecto: 3G rápido) |
| Ubicaciones | Único, en todos los usuarios | Una ubicación |
| Propósito principal | Obtenga información sobre experiencias de usuario reales | Depurar y probar |
Más información sobre los datos de campo y los datos de laboratorio
Datos móviles frente a datos de escritorio
Te encontrarás con datos móviles, datos de escritorio y una mezcla de ambos cuando investigues las puntuaciones de tus Core Web Vitals.
Puedes ver los datos de campo para móviles y escritorios por separado en PageSpeed Insights y Google Search Console y explorando los datos de CrUX a través de BigQuery y el Panel de CrUX.
Es común ver que las puntuaciones de tu escritorio son mejores que las puntuaciones de tu móvil. Simplemente tiene sentido, teniendo en cuenta que un dispositivo de escritorio a menudo tiene mejor hardware y una conexión a Internet más rápida y confiable.
Herramientas para medir sus Core Web Vitals
Ahora que se ha explicado las métricas de Web Vitals y las diferencias entre los datos de campo y los datos de laboratorio, y los datos de escritorio y móviles, revisemos las herramientas más populares y veamos cómo se ven nuestros Web Vitals a través de:
Lighthouse
Lighthouse (se abre en una nueva pestaña) es una iniciativa de código abierto que diagnostica páginas, ayudándote a mejorar su rendimiento basado en datos de laboratorio. Lighthouse es utilizado por varias herramientas de rendimiento web (como PageSpeed Insights y Web.dev Measure), y está incluido en Chrome DevTools, por lo que no necesitará instalar ninguna extensión.
Ten en cuenta que Lighthouse se actualiza con frecuencia, y las actualizaciones se combinan con nuevas versiones de Chromium (que impulsa Google Chrome).
Para ejecutar Lighthouse desde Chrome DevTools, solicita una página en tu navegador y presiona Command + Option + I en Mac, o Control + Shift+ I en Windows y Linux. A continuación, vaya a la pestaña Lighthouse. Esto es lo que vemos para nuestra página de inicio:
After we hit Generate report, Lighthouse fires up, and after 10-15 seconds we see the report:
Debajo de las puntuaciones de rendimiento, Lighthouse sugiere mejoras y da una explicación más detallada de cómo se construye cada una de las puntuaciones.
El uso de Lighthouse de Chrome DevTools es fácil y rápido para comprobaciones únicas, pero no está diseñado para que ejecute un lote de URL a través de él. Por otra parte, recuerda que las extensiones del navegador pueden afectar las métricas CWV en Lighthouse. Si te dedicas al SEO, es mejor realizar el análisis en una ventana de Invitados.
Más información sobre los datos de campo y los datos de laboratorio
PageSpeed Insights (PSI)
La herramienta PageSpeed Insights de Google («PSI» para abreviar) le permite enviar una URL, y luego hará tres cosas:
- Extraiga los datos de campo (si hay suficiente disponible).
- Recopila datos de laboratorio ejecutando Lighthouse (se abre en una pestaña nueva).
- Sugerir mejoras en «Oportunidades» y «Diagnósticos».
Enviamos nuestra página de inicio de nuevo, y estos son los datos de campo que obtenemos:
Debajo de esto, podemos elegir si queremos mostrar el «Resumen de Origen» (la experiencia de usuario agregada de todas las páginas servidas desde nuestro sitio):
Tenga en cuenta que el Resumen de Origen pinta una imagen diferente de nuestro rendimiento. Nuestro rendimiento lateral es menor que el rendimiento de la página de inicio, lo que significa que las páginas distintas de la página de inicio están arrastrando nuestro rendimiento general hacia abajo.
Si te desplazas un poco más hacia abajo, verás los datos de laboratorio:
Si comparas los datos de laboratorio, resultados de PageSpeed Insights vs. Lighthouse, encontrarás que son diferentes. A pesar de que estamos probando usando la misma configuración, no estamos:
- En la misma ubicación (nuestra ubicación física frente a la ubicación utilizada por PSI).
- Ejecutar el mismo hardware (un MacBook 2018 versus la configuración de PSI (se abre en una pestaña nueva)).
- Utilizando la misma conexión de red (configuración de Wi-Fi vs PSI (se abre en una pestaña nueva)).
medida web.dev
web.dev Measure (se abre en una pestaña nueva) es una alternativa a PageSpeed Insights. Envíe una URL y Measure informará de sus productos Core Web Vitals en los datos de laboratorio recopilados con Lighthouse, en una interfaz que es ligeramente más fácil de navegar. Esto es lo que informa para nuestra página de inicio:
Como era de esperar, estamos viendo de nuevo diferentes métricas reportadas, a pesar de que las mismas pruebas se realizaron usando la misma configuración. Una vez más, esto se reduce al hecho de que no puede crear exactamente las mismas condiciones cuando se ejecuta Lighthouse desde una ubicación diferente, en hardware diferente, en una conexión de red diferente.
GoogleS Search Console
Google Search Console proporciona datos de campo para los dos tipos de dispositivos, desktop y móviles. Cuando entras en Enhancements > Core Web Vitals, veencontrarás lo siguiente:
Si haces clic en Open report en cuanquiera de las dos versiones, Móvil o Escritorio, esto muestra una vista más detallada del rendimiento de Core Web Vitals para ese tipo de dispositivo. Si hacemos clic en Móvil, esto es lo que vemos:
¡Parece que lo estamos haciendo bastante bien!
Al hacer clic en cualquiera de las filas de la tabla Detalles para obtener información general con URLs de ejemplo. Las URLs que Google considera similares se agrupan. Para este sitio, por ejemplo, algunas de las diferentes plantillas se agrupan. Tiene sentido que Google agrupe estas URLs, ya que a menudo sufren de los mismos problemas para frenar el rendimiento de la carga de la página.
Resumen de qué datos se ofrecen por qué herramientas
| Datos de campo | Datos de laboratorio | |
|---|---|---|
| Lighthouse | | (Ambos tipos de dispositivos) |
| PageSpeed Insights | (Ambos tipos de dispositivos) | (Ambos tipos de dispositivos) |
| medida web.dev | | (Sólo para móviles) |
| Consola de búsqueda de Google | (Ambos tipos de dispositivos) | |
¿Cómo se calcula su puntuación de rendimiento de Lighthouse?
Hemos cubierto las puntuaciones de Web Vitals con gran detalle, pero aún no hemos tocado cómo se calcula la puntuación general de rendimiento de Lighthouse. En primer lugar, la puntuación de rendimiento de Lighthouse se basa en datos de laboratorio. Es un valor en una escala de 4 (muy malo) a 100 (increíble). Es un promedio ponderado de las puntuaciones de las métricas de Web Vitals, y las puntuaciones no están ponderadas de la misma manera.
En la versión actual de Lighthouse (v6), los pesos son los siguientes:
| Peso (Lighthouse v6) | |
|---|---|
| Largest Contentful Paint | 25% |
| Total Blocking Time | 25% |
| First Contentful Paint | 15% |
| Speed Index | 15% |
| Time to Interactive | 15% |
| Cumulative Layout Shift | 5% |
Llama la atención aquí que que mientras que el CSL tiene un valor ponderado de sólo el 5% respecto del total de los CWV, la más mínima variación de esta métrica significa un incremento, o una mejora llegado el caso, sobre el resultado final del CWV
Notas importantes:
- La puntuación de rendimiento que encontrarás en Lighthouse, y otras herramientas que dependen de los datos de Lighthouse, siempre se basa en datos de laboratorio.
- En la tabla anterior, solo se muestran dos métricas de Core Web Vitals, CLS y LCP. Eso se debe a que el tercero, First Input Delay, no se puede medir en un entorno de laboratorio.
Las puntuaciones en las métricas de Web Vitals se calculan en función de su rendimiento en relación con los datos reales de rendimiento del sitio web del Archivo HTTP.
Por ejemplo: un valor de LCP de 1.220 ms se asigna a una puntuación ponderada de 99 basada en datos de HTTP Archive.
Lighthouse luego utiliza los siguientes rangos codificados por colores para «juzgar» su puntuación:
- Rojo (pobre): 0 a 49
- Naranja (necesita mejorar): de 50 a 89
- Verde (bueno): de 90 a 100
We highly recommend playing around with the Lighthouse Scoring Calculator(opens in a new tab), which immediately updates the score when you change the metrics. To save time configuring the calculator, plug in a URL in PageSpeed Insights and click the See calculator link beneath the table with the lab data:
En el caso de que los que estás reslizando no te permitan mejorar el resultado final en las métricas de CWV, siempre puedes jugar con la calculadora de puntuación lighthouse, que actualiza inmediatamente la puntuación cuando cambia las métricas. Para ahorrar tiempo en configurar la calculadora, conecte una dirección URL en PageSpeed Insights y haz clic en el vínculo Ver calculadora debajo de la tabla con los datos de laboratorio:
No olvides que para pasar la evaluación de Core Web Vitals, tu página debe mostrar que está puntuando en verde para los tres Core Web Vitals:
- Largest Contentful Paint (LCP)
- First Input Delay (FID)
- Cumulative Layout Shift (CLS)
Recursos útiles
Recursos para continuar aprendiendo
Recursos útiles
- Optimizar para Core Web Vitals por Addy Osmani.
- Core Web Vitals de los CMSs más populares de agosto de 2020
- Core Web Vitals de las plataformas de e-commerce más populares en agosto de 2020
Preguntas frecuentes sobre Core Web Vitals
1. ¿Qué tan grande será el impacto SEO de los Core Web Vitals tendrá a partir de mayo de 2021?
Google ha dicho que Core Web Vitals probablemente solo tendrá un pequeño impacto a partir de mayo de 2021, pero es de esperar que Core Web Vitals se convierta en un factor de posicionamiento más importante en el futuro. ¿La razón? A todo el mundo le encantan que los sitios que proporcionan una buena experiencia de usuario. Y las métricas de Core Web Vitals tienen como objetivo medir esa experiencia de usuario.
Por otra parte, es probable que los usuarios tengan menos probabilidades de volver a hacer clic en la SERP si está proporcionando una buena experiencia de usuario. Este comportamiento se retroalimenta en el algoritmo de Google y afectará positivamente el rendimiento SEO de su página.
2. ¿Cómo paso la evaluación de Core Web Vitals?
Pasarás la evaluación de Core Web Vitals si obtienes una puntuación verde («bueno») para los tres Core Web Vitals: Largest Contentful Paint (LCP), First Input Delay (FID) y Cumulative Layout Shift (CLS) según los datos reales del usuario, llamados «datos de campo».
3. ¿Por qué los datos de laboratorio y las puntuaciones de datos de campo son tan diferentes?
Los datos de laboratorio se recopilan en un entorno simulado que tiene como objetivo ejecutar de forma confiable las mismas pruebas, utilizando la misma configuración, mientras que los datos de campo se recopilan del comportamiento real del usuario utilizando diferentes dispositivos, con diferentes conexiones a Internet, desde diferentes ubicaciones.
4. ¿Por qué no hay datos de campo para mi URL o Resumen de Origen?
Para URLs individuales, puedes ver el aviso «Datos de campo – El informe de experiencia de usuario de Chrome no tiene suficientes datos de velocidad del mundo real para esta página», y para el resumen de origen, «El informe de experiencia de usuario de Chrome no tiene suficientes datos de velocidad del mundo real para este origen». Esto significa que no hay suficientes datos CrUX disponibles para generar una vista anónima representativa de su rendimiento.
En pocas palabras, para que los datos de CrUX estén disponibles, ¡necesitas tener más visitantes en su sitio! Es probable que primero obtenga acceso al Resumen de Origen.
Recursos útiles
5. ¿Las páginas no indexables afectan a mis Core Web Vitals?
Es posible que las páginas que no son accesibles y/o indexables para los motores de búsqueda influyan en sus puntuaciones de Core Web Vitals. Cuando se le preguntó en febrero de 2021, John Mueller de Google dijo que pueden tener un impacto.
