← Volver al blog
Resumir en: ChatGPT Google AI Claude Perplexity

Core Web Vitals en los sitios de tus clientes: cómo seguir los datos de laboratorio y de campo

· · Redactado con IA, revisado por Pavol Bincik · Cómo escribimos

Resumen

Las Core Web Vitals cambian cada vez que cambia un plugin, un tema o una etiqueta, así que una auditoría del día del lanzamiento se queda obsoleta. Lighthouse ofrece una medición de laboratorio repetible que muestra una regresión en la siguiente ejecución. CrUX muestra lo que vivieron los usuarios reales de Chrome, como media móvil de 28 días, así que reacciona despacio en ambos sentidos. Google usa las Core Web Vitals en el posicionamiento, pero dice que la relevancia va primero. Sigue ambos tipos de datos en las páginas que importan. Una comprobación de disponibilidad no hace ninguna de las dos cosas: mide lo rápido que responde el servidor, no cómo se renderiza la página.

La mayoría de los sitios de clientes pasan una vez por PageSpeed Insights en el lanzamiento y nadie vuelve a mirar. Luego una actualización de un plugin añade un script, el cliente sube una imagen principal enorme, marketing añade un widget de chat a través del gestor de etiquetas. Nada de eso dispara una alerta de disponibilidad, y todo ello puede ralentizar la página.

Las tres Core Web Vitals y sus umbrales

  • Largest Contentful Paint (LCP): cuándo aparece la imagen o el bloque de texto más grande. Bueno: 2,5 segundos o menos.
  • Interaction to Next Paint (INP): qué tan rápido reacciona la página a clics, toques y pulsaciones de teclas. Bueno: 200 milisegundos o menos; deficiente: más de 500. INP reemplazó a First Input Delay como Core Web Vital el 12 de marzo de 2024.
  • Cumulative Layout Shift (CLS): cuánto salta el diseño durante la carga. Bueno: 0,1 o menos.

Una página cumple un umbral cuando al menos el 75 % de las cargas de página lo cumplen, medido por separado para móvil y escritorio.

Cuánto importan para el posicionamiento

Google afirma que sus sistemas de clasificación usan las Core Web Vitals. También dice que la Búsqueda sigue mostrando la página más relevante aunque su experiencia de página sea mala, y que unos buenos resultados en sus informes no garantizan las primeras posiciones. Para el sitio de un cliente, eso significa que la velocidad no salvará un contenido flojo, pero una página lenta regala una ventaja que no tenía por qué perder.

Los datos de laboratorio y los de campo son mediciones distintas

Los datos de laboratorio vienen de Lighthouse, el motor detrás de PageSpeed Insights. Lighthouse carga la página una vez en un entorno controlado y simulado. Eso los hace repetibles, útiles para depurar y para detectar una regresión justo después de un cambio. Tienen límites:

  • No pueden medir INP, porque nadie interactúa con la página. Total Blocking Time (TBT) es una aproximación razonable, pero no un sustituto.
  • Las puntuaciones varían entre ejecuciones, por ejemplo por anuncios, pruebas A/B o el enrutamiento de red, así que fíjate en la tendencia, no en un solo número.
  • La puntuación de rendimiento tiene tres franjas: de 0 a 49 deficiente, de 50 a 89 necesita mejora, de 90 a 100 buena.

Los datos de campo vienen del Chrome UX Report (CrUX): usuarios reales de Chrome que han aceptado enviar estadísticas de uso y han activado la sincronización del historial. No vienen de rastreadores. Importan dos propiedades:

  • Es una media móvil de 28 días que se actualiza a diario. Una regresión publicada hoy aparece poco a poco durante las próximas semanas, y una corrección tarda lo mismo en notarse.
  • Una página necesita suficiente tráfico de Chrome para tener datos propios. Sin ellos, PageSpeed Insights recurre a los datos de todo el origen, y un sitio pequeño puede no tener ningún dato de campo.

Así, los datos de laboratorio te dicen rápido que algo cambió; los datos de campo te dicen lo que los visitantes vivieron de verdad.

Por qué una comprobación de disponibilidad no ayuda aquí

Una comprobación de disponibilidad mide lo rápido que responde el servidor a la solicitud. No renderiza la página, no carga imágenes ni ejecuta scripts, así que no puede ver LCP, INP ni CLS.

Sí ve un dato de entrada: el tiempo de respuesta del servidor. Time to First Byte va antes de First Contentful Paint y de LCP, así que un servidor que se vuelve más lento arrastra todo lo que viene después. Un buen TTFB es de 0,8 segundos o menos. Si el tiempo de respuesta tiende a subir después de un cambio de hosting, vale la pena ejecutar Lighthouse.

Lo que suele ralentizar los sitios de clientes

Estos son los sospechosos habituales, no mediciones:

  • Actualizaciones de plugins y temas que añaden scripts, estilos o fuentes web.
  • Etiquetas nuevas en el gestor de etiquetas: widgets de chat, píxeles, mapas de calor.
  • Imágenes y vídeos que el cliente sube a tamaño completo.
  • Sliders y maquetadores visuales (page builders) que se cargan en todas las páginas.
  • Cambios de hosting: un plan más barato, un servidor nuevo, una caché que falta.

Una rutina que no se queda atrás

  1. Elige dos o tres páginas por cliente: la página de inicio y las páginas que traen consultas o ventas.
  2. Registra una línea base en PageSpeed Insights: la puntuación de laboratorio, LCP, TBT y CLS, y los datos de campo si los hay.
  3. Vuelve a ejecutar Lighthouse después de cada actualización y, entre medias, según un calendario fijo.
  4. Revisa los datos de campo una vez al mes. Recuerda que van semanas por detrás de los cambios.
  5. Cada pocos meses, revisa el gestor de etiquetas con el cliente y elimina lo que nadie usa.

Cómo lo sigue Baromio

  • Lighthouse de forma programada: activa Monitorear Velocidad de Página en un monitor HTTP o de palabra clave. Baromio ejecuta Lighthouse a través de Google PageSpeed Insights (móvil) y registra la puntuación de rendimiento, LCP, FCP, TBT, CLS, Speed Index y el peso de la página por tipo de recurso. Free: 1 URL, semanal. Pro (9 EUR al mes): 5 URL, a diario. Business (29 EUR al mes): 15 URL, a diario. El historial se conserva 7, 30 o 90 días según el plan.
  • Alertas: recibes una alerta cuando la puntuación baja de 50, la franja "deficiente" de Lighthouse, y otra solo si cae 15 puntos más. Una alerta de recuperación llega cuando la puntuación vuelve a 50 o más y está al menos 15 puntos más alta.
  • Datos de campo de CrUX: para esos mismos monitores, Baromio guarda cada día una instantánea de CrUX para esa URL exacta, para teléfonos, escritorio y todos los dispositivos juntos: p75 de LCP, FCP, CLS, INP y TTFB, cada uno con su reparto bueno / necesita mejora / deficiente. Si CrUX no tiene datos para la URL, no se guarda ninguna instantánea y la pestaña Velocidad de Página lo indica; es normal en páginas con poco tráfico.
  • Desde un asistente de IA: los mismos datos de campo están disponibles a través del servidor MCP de Baromio (get-crux-data).

Fuentes

Usamos cookies para entender cómo se usa Baromio y mejorar el producto. Puedes aceptar o rechazar las cookies analíticas en cualquier momento. Más información