Análisis Vitals Web

Análisis de Core Web Vitals y seguimiento de las oportunidades de optimización onpage

Core Web Vitals

Screaming Frog SEO Spider a través de su conexión con PageSpeed Insights API te permite medir fácilmente el Core Web Vitals (CWV) para cada página de tu sitio web.

Las Core Web Vitals son un conjunto de métricas que Google introdujo a partir de mayo de 2021 para medir aspectos clave de la experiencia del usuario al cargar una página web. Core Web Vitals es una revolución que ayuda a Google a evaluar las páginas web y a clasificarlas en los resultados de búsqueda.

De momento, son esencialmente tres, pero creo que más adelante se introducirán otras métricas, además del perfeccionamiento de éstas, para garantizar una experiencia de navegación más satisfactoria.

LCP: Pintura de mayor contenido

La métrica Pintura de contenido más grande (LCP) informa del tiempo de renderizado de la imagen o bloque de texto más grande visible dentro de la ventana gráfica, en relación con el momento en que la página comenzó a cargarse. Como parámetro de evaluación, Google considera un tiempo máximo de 2,5 segundos para garantizar una experiencia de usuario buena y satisfactoria.

Para asegurarte de que lo consigues para la mayoría de tus usuarios, un buen umbral a tener en cuenta es el percentil 75 de cargas de página, segmentado entre dispositivos móviles y de escritorio.

Analisi Core web vitals LCP con screaming frog

FID: Retardo de la primera entrada

El Retraso en la Primera Entrada (FID) de una página mide su capacidad de respuesta a las interacciones del usuario. Por ejemplo, si un usuario hace clic en un enlace o selecciona un menú desplegable, el FID evalúa la rapidez con que se realiza esta acción en la página.

Normalmente, las interacciones del usuario se retrasan cuando el navegador está ocupado realizando otras tareas.

Por ejemplo, al analizar la línea de tiempo de carga que aparece a continuación, vemos barras azules que identifican el tiempo que tarda en cargarse un recurso (como un archivo JavaScript) que requiere bastante tiempo.

Si un usuario hacía clic en algo dentro de la página HTML durante este tiempo, la interacción se retrasaría hasta que el navegador hubiera completado el proceso anterior.

Como parámetro de evaluación, para proporcionar una buena experiencia de usuario, Google indica que la métrica Retraso en la primera entrada debe ser de 100 milisegundos o menos. Para asegurarte de que lo consigues para la mayoría de tus usuarios, un buen umbral a medir es el percentil 75 de cargas de página, segmentado entre dispositivos móviles y de escritorio.

CLS: Desplazamiento de disposición acumulativo

El Desplazamiento acumulativo del diseño (CLS) es una métrica muy importante centrada en la experiencia del usuario que mide la estabilidad visual de un diseño mientras se carga una página HTML. Este índice se introdujo para limitar los desagradables cambios inesperados debidos, por ejemplo, a banners publicitarios u otros. Todos hemos tenido la frustrante experiencia de leer un sitio de noticias y que el texto del artículo salte hacia abajo mientras se carga la navegación; CLS mide precisamente esta inestabilidad de la navegación.

A continuación puedes ver este fenómeno mientras el navegador carga la página. A través de cada pantalla, se añade contenido, haciendo que los elementos anteriores se muevan hacia arriba y hacia abajo.

Para proporcionar una buena experiencia al usuario, los sitios deben esforzarse por tener una puntuación CLS de 0,1 o inferior. Para asegurarte de que lo consigues para la mayoría de tus usuarios, un buen umbral a medir es el percentil 75 de cargas de página, segmentado entre dispositivos móviles y de escritorio.

Las Core Web Vitals son métricas basadas en datos reales del Informe de la Experiencia de Usuario de Chrome (CrUX) de los últimos 28 días y basadas en las visitas de los usuarios a una página.

Cada Web Vital se califica según tres clasificaciones: Bueno, Necesita mejorar y Malo.

Para que una página sea validada por la Evaluación Vital Web Básica, debe considerarse “Buena” en las tres métricas.

Google proporcionó una cómoda ilustración de los umbrales de cada métrica.

Análisis de Parámetros Core Web Vitals

Las Core Web Vitals de los sitios web se registran y almacenan dentro del Informe de experiencia de usuario de Chrome y puedes verlas esencialmente de dos maneras.

Para una única URL, puedes utilizar PageSpeed Insights (PSI), que te indica si la página ha superado o no las comprobaciones.

Analisi PSI di un sito web

La segunda solución es consultar Search Console en la sección “Core Vitals”, que informa del rendimiento de la página, errores y advertencias en relación con estas métricas.

Aunque estas dos comprobaciones son eficaces, también son extremadamente reductoras, porque la primera solución permite una comprobación unitaria de las URL, mientras que la segunda con GSC agrega múltiples URL (plantillas de URL) y no proporciona puntuaciones unitarias de calidad.

Análisis de Screaming Frog Web Vitals

La conexión de Screaming Frog SEO Spider con la API PageSpeed Insights facilita la recopilación de datos sobre Web Vital y devuelve datos específicos de URL basados en datos reales de CrUX y de laboratorio. Para configurarlo, sólo tienes que seguir unos sencillos pasos.

  • 1. Conexión a la API de PageSpeed.
  • 2. Ajustes de las métricas a considerar.

Una vez conectado a PSI, tienes que hacer clic en la pestaña “Métricas” y elegir cuáles quieres introducir como parámetros de análisis. En las primeras exploraciones del Core Web Vitals, recomiendo utilizar la selección por defecto, ya que incluye datos del informe CrUX, datos de laboratorio de Google Lighthouse y datos de oportunidades de las áreas de mejora.

Metriche web vitals analizzate dal seo spider
  • 3. Realiza el escaneado.

Una vez que hayas completado las configuraciones de las métricas de la API, puedes iniciar el rastreador y esperar a que el sitio web sea escaneado y rellenado con los datos de Core Web Vitals.

  • 4. Análisis de datos

Sólo tienes que hacer clic en la pestaña PageSpeed para ver todos los detalles del rastreo y qué URLs han superado la prueba, cuáles necesitan mejorar y cuáles tienen errores graves.

El ejemplo anterior (con la configuración por defecto) presenta las URL en la primera columna y la “Evaluación de las Vitales Web Básicas” en la segunda. El estado de la ISP se marca como “Apto” o “No apto” en función de si se considera válida en los tres Web Vitals.

En la captura de pantalla puedes ver que la URL de la parte superior tiene un LCP de 1,99s (menos de 2,5s), un FID de 37ms (menos de 100ms) y un CLS de 0,06 (menos de 0,1), por lo que pasó la validación CWV.

A través de esta visión general, puedes examinar inmediatamente qué páginas no han superado la prueba y sobre qué métricas CWV concretas actuar.

Puede ocurrir que algunas URL no obtengan datos CWV, esta condición se produce cuando no hay suficientes datos sobre la velocidad en CrUX, o porque la página no tiene suficientes visitantes. Por lo general, sólo las páginas más populares tienen datos suficientes para el informe UX de Chrome.

  • 5. Segmentación de patrones de error

Una vez que tengas los datos, puedes examinar el rendimiento de cada CWV individual utilizando diferentes filtros y aislar los problemas que hay que optimizar haciendo que cada URL tenga los mismos problemas críticos.

Si seleccionas una URL en la ventana superior y haces clic en la pestaña “Detalles de PageSpeed” (ventana inferior), encontrarás toda una serie de detalles adicionales y la posibilidad de revisar los errores o advertencias encontrados.

Optimizar las métricas LCP

Empecemos por definir qué áreas pueden afectar al PCL y qué factores pueden optimizarse para mejorar el índice métrico.

  • Dimensiona correctamente las imágenes.
  • Aplazar imágenes fuera de pantalla.
  • Codifica eficazmente las imágenes.
  • Sirve imágenes en formatos Next-Gen.

El punto de partida son las imágenes, que son uno de los elementos clave para el rendimiento de las páginas html. Para mejorar las métricas LCP, asegúrate de que cada imagen tiene el tamaño correcto, y utiliza “Carga perezosa” cuando proceda.

Es aconsejable utilizar nuevos formatos de imagen más eficaces, como WebP, y mejorar la codificación de los archivos de imagen existentes.

Otro aspecto muy impactante tiene que ver con los tiempos de respuesta del servidor. Un servidor poco potente provoca respuestas lentas y tiempos de carga más largos, por lo que recomiendo elegir un alojamiento de mayor rendimiento o utilizar CDN -Content Delivery Networks- para reducir los tiempos de respuesta y mejorar el TTFB.

Entre las posibles optimizaciones a considerar, presta mucha atención a la gestión de los recursos que bloquean la renderización de la página. Como sabes, mientras se analiza el HTML, cualquier referencia a hojas de estilo o CSS puede hacer que el “analizador” se detenga, retrasando el LCP.

Lo ideal es posponer cualquier CSS y JavaScript no críticos para acelerar la carga de tu contenido principal y utilizar la “precarga” para los recursos críticos. Otro consejo es minificar CSS y Javascript y eliminar todos los archivos innecesarios de la carga de tu página; considera también la posibilidad de utilizar “preconectar” recursos de terceros (por ejemplo, Google Analytics, Tag Manager, etc.).

  • Reducir CSS.
  • Reducir JavaScript.
  • Eliminar CSS no utilizado.
  • Elimina el JavaScript no utilizado.
  • Activar la compresión de texto.
  • Preconectar a los orígenes requeridos.
  • Precarga la llave Peticiones.
  • Utiliza formatos de vídeo para contenidos animados.

Optimizar el FID

En la mayoría de los casos, el FID se ve afectado negativamente por los largos tiempos de ejecución de grandes scripts. La primera medida a tomar es minificar y eliminar las partes no utilizadas de los scripts, (o scripts enteros) reduciendo el tiempo empleado en ejecutar y renderizar estos archivos.

  • Reducir JavaScript.
  • Elimina el JavaScript no utilizado.
  • Reduce el número de scripts de terceros utilizados.

Puedes encontrar la lista de recursos de terceros en tu documento HTML, en la pestaña Detalles de PageSpeed.

Otra optimización a tener en cuenta se refiere al trabajo del hilo principal. Si un navegador está ocupado renderizando el hilo principal, el usuario no podrá interactuar con la página hasta que esto se complete. Si reduces el tiempo de ejecución del hilo principal, las interacciones del usuario serán más receptivas e inmediatas.

Las principales soluciones se refieren a la reducción de la ejecución de scripts Javascript y a la reducción del Hilo Principal.

  • Minimizar el trabajo del hilo principal
  • Reduce el tiempo de ejecución de JavaScript

Luego considera que cada recurso necesario para una página tarda en solicitarse, descargarse y ejecutarse. Al reducir tanto el número de peticiones necesarias como el tamaño total de la descarga, ayudarás a mejorar los tiempos de ejecución de la página.

Actividades útiles son la minificación de CSS y Javascript, la eliminación de hojas de estilo/CSS y Javascript no utilizados, y la compresión de texto.

  • Recuentos y tamaños de recursos más bajos.
  • Reducir CSS.
  • Reducir JavaScript.
  • Eliminar CSS no utilizado.
  • Elimina el JavaScript no utilizado.
  • Activar la compresión de texto.

Optimizar el CLS

Como ya se ha mencionado, la estabilidad de la maquetación es el componente principal para que el CLS garantice una experiencia relevante para el navegante, este aspecto debe hacer que te centres en servir la página en el orden adecuado y con un espaciado definido para cada recurso con el fin de no crear sacudidas en la navegación.

<> <> Para obtener resultados satisfactorios, debes asegurarte de que todas las imágenes, anuncios, vídeos e iframes tienen los atributos de altura y anchura para permitir que las páginas se carguen con el espaciado adecuado y evitar que se desplacen otros contenidos cuando se añadan. Otra consideración desde el punto de vista del CLS es dar prioridad a la carga de recursos de arriba abajo para no hacer rebotar hacia arriba al usuario que haya alcanzado cierto nivel de profundidad de navegación.

Asegúrate de que las fuentes personalizadas no provocan el efecto FOIT/FOUT, ya que si las fuentes personalizadas se aplican tarde en la carga de una página, puede ocurrir que el texto parpadee mientras se sustituye (FOUT), o que se muestre texto invisible hasta que se renderice la fuente personalizada (FOIT). Para sortear esta latencia, recomiendo utilizar la “precarga” de recursos críticos.

Screaming Frog y Web Vitals

Si tus URL no muestran ningún dato CrUX y el estado PSI indica “correcto”, es probable que la URL no reciba suficientes visitas de usuarios reales para generar suficientes datos de velocidad para el informe CrUX. Si te encuentras en esta situación tras el rastreo con Screaming Frog, podrías utilizar una página con un diseño similar con datos CrUX para el análisis, o utilizar datos de laboratorio simulados (presentes por defecto en la configuración de Seo Spider).

Cuando tienes que utilizar datos de laboratorio, la única métrica que no está disponible es FID – Retraso en la Primera Entrada, debido a la falta de interacción solicitada por el usuario. En este caso, puedes utilizar el Tiempo Total de Bloqueo (TBT) como indicador para ver qué recursos se están bloqueando y, en consecuencia, considerarlos como críticos, lo que puede aumentar el FID.

Si tienes que analizar un sitio grande, puedes superar el límite de cuota de PageSpeed Insight. Si te encuentras en esta situación, te aconsejo que analices una muestra significativa o esperes a que la cuota llegue a cero.

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

Vídeo tutorial de Web Vitals

Ficha Seo Spider