Análisis de las Web Vitals.

Core Web Vitals

Gracias a su conexión con la API de PageSpeed Insights, Screaming Frog SEO Spider te permite medir fácilmente las Core Web Vitals (CWV) de cada página de tu sitio.

Las Core Web Vitals son un conjunto de métricas que Google introdujo en mayo de 2021 para medir aspectos clave de la experiencia del usuario durante la carga de una página. Son una auténtica revolución que ayuda a Google a evaluar las páginas y asignar su posicionamiento en los resultados.

Hoy las métricas son tres: LCP (carga), INP (capacidad de respuesta) y CLS (estabilidad visual). Google las actualiza con el tiempo: en marzo de 2024 el INP sustituyó al FID como métrica de capacidad de respuesta.

LCP: Largest Contentful Paint

El Largest Contentful Paint (LCP) indica el tiempo de renderizado de la imagen o el bloque de texto más grande visible en el viewport, desde que la página empezó a cargarse. Google fija un máximo de 2,5 segundos para garantizar una buena experiencia de usuario.

Para alcanzar este objetivo con la mayoría de tus usuarios, un buen umbral es el percentil 75 de las cargas de página, segmentadas entre móvil y escritorio.

12

1FCPEl primer contenido visible.2LCPEl elemento más grande del viewport, aquí la imagen.

INP: Interaction to Next Paint

El Interaction to Next Paint (INP) mide la capacidad de respuesta de una página: cuánto tiempo pasa desde una interacción del usuario (un clic, un toque, una tecla) hasta que el navegador muestra la respuesta en pantalla, es decir, el siguiente «paint».

Desde el 12 de marzo de 2024 el INP ha sustituido al First Input Delay (FID) entre las Core Web Vitals. El FID tenía dos límites importantes:

• solo medía la primera interacción con la página e ignoraba todas las siguientes;
• solo medía el retraso de entrada, es decir, la espera antes de que el navegador empezara a gestionar el evento, y no el tiempo para procesarlo y actualizar la página.

El INP, en cambio, observa todas las interacciones durante la visita y, para cada una, suma tres fases:

1. Input delay: la espera antes de que arranquen los gestores del evento, normalmente porque el hilo principal está ocupado con otros scripts;
2. Processing time: el tiempo de ejecución del JavaScript asociado a la interacción;
3. Presentation delay: el tiempo que necesita el navegador para recalcular el diseño y pintar el nuevo fotograma.

El valor final es la interacción más lenta de la visita (en páginas con muchísimas interacciones, Google descarta los valores atípicos). Es, por tanto, una métrica mucho más exigente y realista que el FID: una página puede responder bien al primer clic pero bloquearse cuando el usuario abre un filtro o añade un producto al carrito.

Las interacciones se ralentizan sobre todo cuando el navegador está ocupado con otras tareas. En la cronología de abajo aparecen resaltadas las long tasks, tareas que ocupan el hilo principal más de 50 ms: si el usuario hace clic mientras hay una en curso, la respuesta solo llega cuando termina.

12

1Long TasksLos scripts largos que bloquean el navegador.2CPULa actividad del procesador durante la carga.

Para ofrecer una buena experiencia de navegación, Google indica que el INP debería ser igual o inferior a 200 milisegundos; entre 200 y 500 ms la página debe mejorar, y por encima de 500 ms la capacidad de respuesta es mala. Para alcanzar este objetivo con la mayoría de tus usuarios, un buen umbral es el percentil 75 de las cargas de página, segmentadas entre móvil y escritorio.

CLS: Cumulative Layout Shift

El Cumulative Layout Shift (CLS) es una métrica centrada en el usuario muy importante, que mide la estabilidad visual del diseño durante la carga de una página HTML. Se introdujo para limitar los molestos cambios inesperados causados, por ejemplo, por banners publicitarios. Todos hemos vivido la frustración de leer una noticia y ver cómo el texto salta hacia abajo mientras la página se carga; el CLS mide precisamente esa inestabilidad.

Abajo puedes ver este fenómeno mientras el navegador carga la página. En cada fotograma se añade contenido que desplaza hacia arriba y hacia abajo los elementos anteriores.

12

1Banner de cookiesUn elemento que aparece y luego desaparece.2Banner promocionalEmpuja hacia abajo el contenido de la página.

Para ofrecer una buena experiencia, los sitios deberían aspirar a un CLS de 0,1 o inferior. Para alcanzar este objetivo con la mayoría de tus usuarios, un buen umbral es el percentil 75 de las cargas de página, segmentadas entre móvil y escritorio.

Las Core Web Vitals se basan en los datos reales del Chrome User Experience Report (CrUX) de los últimos 28 días, obtenidos de las visitas de los usuarios a una página.

Cada Web Vital se clasifica en una de tres categorías: Good, Needs Improvement y Poor.

Para superar el Core Web Vitals Assessment, una página debe ser «Good» en las tres métricas.

Estos son los umbrales de cada métrica, medidos en el percentil 75:

Métrica	Good	Needs Improvement	Poor
LCP (carga)	≤ 2,5 s	2,5 – 4 s	> 4 s
INP (capacidad de respuesta)	≤ 200 ms	200 – 500 ms	> 500 ms
CLS (estabilidad visual)	≤ 0,1	0,1 – 0,25	> 0,25

Analizar las Core Web Vitals

Las Core Web Vitals de los sitios se registran en el Chrome User Experience Report y puedes consultarlas básicamente de dos formas.

Para una sola URL puedes usar PageSpeed Insights (PSI), que te indica si la página ha superado o no los controles.

1234

1Evaluación de las Core Web VitalsSuperada si LCP, INP y CLS son todos Good.2INP130 ms: por debajo del umbral Good de 200 ms.3Otras métricasFCP y TTFB ayudan a diagnosticar la carga.4Fuente de los datosChrome UX Report, últimos 28 días, usuarios reales.

La segunda opción es la sección «Core Web Vitals» de Search Console, que muestra el rendimiento de las páginas, los errores y los avisos de estas métricas.

123

1Core web vitalsEl informe de la sección Enhancements.2MobileURL poor, que mejorar y good en móvil.3DesktopLos mismos datos para escritorio.

Aunque ambos controles funcionan, también son muy limitados: el primero solo revisa una URL cada vez, mientras que GSC agrupa varias URL (patrones de URL) y no da puntuaciones individuales.

Análisis de las Web Vitals con Screaming Frog

Gracias a su conexión con la API de PageSpeed Insights, Screaming Frog SEO Spider recoge fácilmente los datos de las Web Vitals y te da datos concretos de cada URL, basados en los datos reales de CrUX y en los de laboratorio. Configurarlo lleva unos pocos pasos sencillos.

• 1. Conexión con la API de PageSpeed: ve a 1Configuration›2API Access›3PageSpeed Insights, introduce tu Secret Key y haz clic en Connect.

123

1Account InformationLa pestaña para conectar la API.2Secret KeyLa clave API creada en la Google Cloud Console.3ConnectConecta SEO Spider a la API.

• 2. Elección de las métricas.

Una vez conectado a PSI, haz clic en la pestaña «Metrics» y elige cuáles incluir en el análisis. En tus primeros rastreos de las Core Web Vitals te aconsejo la selección predeterminada, porque incluye los datos del informe CrUX, los datos de laboratorio de Google Lighthouse y las oportunidades de mejora.

123

1MetricsLa pestaña de las métricas que recoger.2DeviceMobile o Desktop.3CrUX MetricsLos datos reales, como el Core Web Vitals Assessment.

• 3. Ejecución del rastreo.

Con las métricas de la API configuradas, lanza el rastreador y espera a que el sitio se rastree y se rellene con los datos de las Core Web Vitals.

• 4. Análisis de los datos

Solo queda hacer clic en la pestaña PageSpeed para ver todos los detalles del rastreo: qué URL han superado la prueba, cuáles deben mejorar y cuáles tienen problemas graves.

123

1PageSpeedLa pestaña con los datos de PageSpeed Insights.2PSI StatusSuccess si la API ha devuelto los datos.3MétricasPerformance Score, FCP, Speed Index, LCP.

En el ejemplo de arriba (ajustes por defecto), la primera columna muestra las URL y la segunda el estado del «Core Web Vitals Assessment». El estado PSI aparece como «Pass» o «Fail» según si la página es buena en las tres Web Vitals.

En la captura se ve que la URL de arriba tiene un LCP de 1,99 s (por debajo de 2,5 s), una capacidad de respuesta de 37 ms (entonces el FID, hoy sustituido por el INP con umbral de 200 ms) y un CLS de 0,06 (por debajo de 0,1), así que ha superado la validación de las CWV.

Con esta visión de conjunto ves al instante qué páginas no han superado la prueba y en qué métricas CWV intervenir.

Puede que algunas URL no tengan datos de CWV: ocurre cuando CrUX no tiene suficientes datos de velocidad porque la página no recibe bastantes visitas. Normalmente solo las páginas más populares tienen datos suficientes para el Chrome UX Report.

• 5. Segmentación de los patrones de error

Con los datos en la mano puedes examinar cada métrica CWV con distintos filtros, aislar los problemas que optimizar y obtener todas las URL que comparten el mismo problema.

12

1FiltrosLas oportunidades de Lighthouse como filtros.2Performance ScoreLa puntuación de cada URL.

Si seleccionas una URL en la ventana superior y haces clic en la pestaña «PageSpeed Details» (ventana inferior), encontrarás una serie de detalles adicionales y oportunidades para corregir los errores o avisos detectados.

123

1OpportunitiesLas optimizaciones con el ahorro estimado.2RecursosLas URL de los recursos y el ahorro en bytes.3PageSpeed DetailsLa pestaña de la ventana inferior.

Optimizar el LCP

Empecemos por definir qué áreas influyen en el LCP y qué factores se pueden optimizar para mejorar la métrica.

• Properly Size Images.
• Defer Offscreen Images.
• Efficiently Encode Images.
• Serve Images in Next-Gen Formats.

El punto de partida son las imágenes, uno de los pilares del rendimiento de las páginas HTML. Para mejorar el LCP, asegúrate de que cada imagen tenga el tamaño correcto y usa el lazy loading cuando proceda.

Conviene usar formatos de imagen nuevos y más eficientes como WebP y mejorar la codificación de las imágenes existentes.

Otro aspecto con mucho impacto es el tiempo de respuesta del servidor. Un servidor poco potente da respuestas lentas y tiempos de carga más largos; por eso te aconsejo un hosting más rápido o usar CDN (Content Delivery Networks) para reducir los tiempos de respuesta y mejorar el TTFB.

Entre las optimizaciones posibles, presta mucha atención a los recursos que bloquean el renderizado. Mientras se analiza el HTML, cada referencia a hojas de estilo puede pausar el parser y retrasar el LCP.

Lo ideal es aplazar cualquier CSS y JavaScript no crítico para acelerar la carga del contenido principal y usar el «preload» para los recursos críticos. Otro consejo es minificar CSS y JavaScript y quitar los archivos innecesarios de la carga; plantéate también el «preconnect» para recursos de terceros (p. ej. Google Analytics, Tag Manager).

• Minify CSS.
• Minify JavaScript.
• Remove Unused CSS.
• Remove Unused JavaScript.
• Enable Text Compression.
• Preconnect to Required Origins.
• Preload key Requests.
• Use Video Formats for Animated Content.

Optimizar el INP

En la mayoría de los casos el INP empeora por los largos tiempos de ejecución de scripts grandes, que ocupan el hilo principal justo cuando el usuario interactúa. Lo primero es minificar y eliminar las partes de los scripts que no se usan (o scripts enteros), reduciendo el tiempo de ejecución y renderizado de esos archivos.

• Minify JavaScript.
• Remove Unused JavaScript.
• Reduce the Number of Third-Party Scripts Used.

Para encontrar la lista de recursos de terceros, consulta tu documento HTML en la pestaña PageSpeed Details.

Otra optimización tiene que ver con el trabajo del hilo principal. Si el navegador está ocupado renderizando en el hilo principal, el usuario no podrá interactuar con la página hasta que termine. Si reduces el tiempo de ejecución del hilo principal, las interacciones serán más rápidas e inmediatas.

Las soluciones principales consisten en reducir la ejecución de JavaScript y el trabajo en el main thread. Para el INP en particular:

• divide las long tasks en tareas más cortas cediendo el control al navegador (por ejemplo con scheduler.yield() o setTimeout), para que las interacciones no se queden en cola;

• mantén ligeros los gestores de eventos y aplaza el trabajo no urgente hasta después del paint;

• reduce el tamaño del DOM, porque un DOM muy grande alarga el recálculo del diseño tras cada interacción (Avoid Excessive DOM Size).

• Minimise Main-Thread Work

• Reduce JavaScript Execution Time

Ten en cuenta también que cada recurso que necesita una página tarda en pedirse, descargarse y ejecutarse. Reduciendo tanto el número de peticiones como el tamaño total de la descarga, mejorarás los tiempos de ejecución.

Las acciones útiles son minificar CSS y JavaScript, eliminar hojas de estilo y JavaScript sin usar y comprimir el texto.

• Lower Resource Counts & Sizes.
• Minify CSS.
• Minify JavaScript.
• Remove Unused CSS.
• Remove Unused JavaScript.
• Enable Text Compression.

Optimizar el CLS

Como ya hemos visto, la estabilidad del diseño es la clave del CLS y de una buena experiencia: céntrate en servir la página en el orden adecuado y con un espacio definido para cada recurso, para que la navegación no dé saltos.

Para obtener buenos resultados, asegúrate de que todas las imágenes, anuncios, vídeos e iframes tengan los atributos <height> y <width>, para que las páginas se carguen con el espacio adecuado y los demás contenidos no se muevan al añadirse. Otra consideración para el CLS es priorizar la carga de los recursos de arriba abajo, para no devolver hacia arriba al usuario que ya ha bajado por la página.

Asegúrate de que las fuentes personalizadas no provoquen el efecto FOIT/FOUT: si se aplican tarde, el texto puede parpadear al sustituirse (FOUT) o quedar invisible hasta que se renderiza la fuente (FOIT). Para evitar este retraso, te aconsejo el «preload» de los recursos críticos.

Screaming Frog y las Web Vitals

Si tus URL no muestran datos de CrUX y el estado PSI indica ‘success’, probablemente la URL no recibe suficientes visitas reales para generar datos de velocidad para el informe CrUX. Si te encuentras en esta situación tras rastrear con Screaming Frog, puedes analizar una página con un diseño parecido que sí tenga datos CrUX, o usar los datos de laboratorio simulados (incluidos por defecto en la configuración de SEO Spider).

Con los datos de laboratorio, la única métrica que no está disponible es el INP, porque Lighthouse no simula las interacciones de un usuario real. En ese caso usa como indicador el Total Blocking Time (TBT): mide cuánto tiempo queda bloqueado el hilo principal por las long tasks durante la carga y está muy relacionado con el INP, así que los recursos que lo hacen crecer son los primeros que optimizar.

Si tienes que analizar un sitio muy grande, podrías superar la cuota de PageSpeed Insights. En ese caso te aconsejo analizar una muestra significativa o esperar a que se reinicie la cuota.

No olvides que los datos de CrUX se basan en los últimos 28 días de interacciones, así que cualquier cambio en el sitio tardará 28 días en reflejarse en CrUX.

Vídeo tutorial sobre las Web Vitals (en italiano)

VideotutorialScreaming Frog: análisis de las Core Web VitalsVer el vídeo3:43