La fuente de confusión más típica en auditorías de velocidad
Abres PageSpeed Insights, introduces tu URL, esperas el análisis. Te aparecen dos secciones:
- “Encontrar los datos de campo”
- “Diagnosticar problemas de rendimiento” (datos de laboratorio)
A veces los números no coinciden. Tu LCP de campo es 1,8 s (bueno) pero tu LCP de lab es 4,2 s (malo). O al revés. ¿Cuál importa? ¿Cuál usa Google?
Esta guía aclara la diferencia y te enseña a interpretar los dos correctamente.
Datos de campo (CrUX)
Qué son
CrUX = Chrome User Experience Report. Es la métrica real de tu web, medida en los navegadores Chrome de tus usuarios reales durante los últimos 28 días.
Cuando un usuario visita tu web con Chrome (que es el 65 % del tráfico web mundial), su navegador anónimamente reporta a Google métricas de rendimiento. Esos datos se agregan a un dataset llamado CrUX.
Qué información incluye
- LCP, INP, CLS, TTFB, FCP medidos en condiciones reales
- Distribución por dispositivo (móvil vs desktop)
- Percentiles (P75 es el que Google usa: el 75 % de tus visitas)
Por qué es lo más importante
Google usa CrUX para rankear. Lo confirmó oficialmente en 2021 cuando los Core Web Vitals pasaron a ser factor de ranking.
Si tu CrUX dice que tu LCP P75 es 2,8 s, Google considera que tu LCP es “Mejorable” y lo usa para decidir tu posición.
Cuándo no tienes datos de CrUX
Tu web necesita tráfico mínimo para tener datos de CrUX. Si tienes menos de ~1.000 visitas/mes desde Chrome, probablemente no aparecen datos de campo. PageSpeed lo indica:
“No se han recogido suficientes datos de Chrome User Experience Report para esta URL/origen.”
Esto es lo más común en pymes nuevas o webs pequeñas. No es problema técnico, es que necesitas más tráfico.
Cómo acceder a los datos de CrUX
Tres opciones:
- PageSpeed Insights: muestra los datos si los hay
- Google Search Console → “Experiencia” → “Core Web Vitals”: muestra todos tus datos de campo agregados
- CrUX BigQuery dataset: si eres muy técnico, puedes consultar los datos brutos en BigQuery
Datos de laboratorio (Lighthouse)
Qué son
Lighthouse es una herramienta open-source de Google. Cuando ejecutas PageSpeed Insights, lanza Lighthouse en un servidor de Google contra tu URL en condiciones controladas:
- Dispositivo simulado: Moto G4 / Moto G Power (móvil de gama media)
- Red simulada: 4G “Slow” (1.6 Mbps de descarga)
- Procesador throttled: 4x más lento que un escritorio normal
Y mide qué pasa.
Qué información incluye
- LCP, FCP, TBT, CLS, Speed Index medidos en una simulación
- Score de Performance sobre 100
- Oportunidades específicas con código (qué archivos optimizar)
- Diagnósticos detallados
Por qué no es lo que importa para SEO
Lighthouse es una simulación. Por muy buena que sea:
- No refleja tu hosting real bajo carga real
- No refleja la diversidad de tus usuarios (algunos en 5G, otros en 3G)
- No refleja errores intermitentes
- Es un punto en el tiempo, no una media
Lighthouse es útil para debugging (te dice exactamente qué arreglar) pero no para medir el estado real.
Cuándo Lighthouse es útil
- Webs nuevas sin tráfico de CrUX: es lo único disponible
- Validar mejoras antes de deployar: ejecutas antes y después de cambios para verificar impacto
- Auditorías técnicas detalladas: muestra el código exacto que está frenando tu web
- Comparar competidores: como todos se miden en las mismas condiciones, es comparable
La discrepancia típica: por qué CrUX y Lab no coinciden
Es muy común ver:
- CrUX bueno + Lab malo: tu web es lenta en condiciones extremas pero tus usuarios reales tienen mejores condiciones (banda ancha, buenos dispositivos).
- CrUX malo + Lab bueno: tus usuarios reales tienen peor red de la que Lighthouse simula. Quizá tienes mucho tráfico móvil en 3G, o desde zonas rurales con cobertura mala.
- Diferencia grande en CLS: en lab, Lighthouse mide CLS solo durante la carga inicial. En CrUX se mide durante toda la sesión, incluyendo interacciones del usuario.
Cuál usar según la situación
Tu web está madura con tráfico estable
Mira primero los datos de CrUX. Son los reales. Si CrUX dice “Bueno”, tu SEO está bien. Si dice “Malo”, urge arreglar.
Lighthouse úsalo para identificar QUÉ arreglar exactamente.
Tu web es nueva o tiene poco tráfico
Solo tienes datos de laboratorio. Optimiza Lighthouse hasta que el score esté alto y todos los Core Web Vitals en verde.
Cuando ganes tráfico, los datos de CrUX te dirán si tu Lighthouse era representativo o no.
Tu sector tiene usuarios muy específicos
Si vendes a usuarios B2B en oficinas (banda ancha) o B2C en gama alta (fibra + iPhones nuevos), tu CrUX será mejor que Lighthouse.
Si vendes a usuarios en zonas rurales, móviles antiguos, o internacional con conexiones malas, tu CrUX será peor que Lighthouse.
Ajusta tu objetivo a tu audiencia real.
Cómo monitorizar en producción
Una vez con CrUX disponible, monitoriza así:
Search Console (lo básico)
- Sección “Experiencia” → “Core Web Vitals”
- Verás tres categorías: Bueno / Mejorable / Malo
- Para cada categoría, número de URLs y problemas detectados
- Comprueba semanalmente
web-vitals.js (lo profesional)
Librería JavaScript de Google que mide Core Web Vitals en tiempo real en TU web:
import { onCLS, onINP, onLCP } from 'web-vitals';
onCLS(console.log);
onINP(console.log);
onLCP(console.log);Estos eventos se mandan a GA4 o tu sistema de analítica. Ventaja: los tienes en tu propia base, no agregados de Google.
Real User Monitoring (RUM)
Servicios pagos como SpeedCurve, Sentry Performance, NewRelic. Tracking detallado por usuario, sesión, página, dispositivo.
Solo necesario si tu web es grande o crítica.
El truco para empezar con datos limitados
Si tu web no tiene aún datos de CrUX porque acabas de lanzarla:
- Optimiza Lighthouse hasta 90+ en móvil
- Implementa web-vitals.js para empezar a recolectar tus propios datos
- Pasa al menos 3 meses recogiendo
- Después, compara tus datos propios con CrUX cuando aparezca
Esto te da control total y no dependes de que Google decida cuándo darte datos.
Métricas adicionales más allá de LCP/INP/CLS
CrUX y Lighthouse miden otras métricas útiles:
- TTFB (Time To First Byte): cuánto tarda tu servidor en empezar a responder. Bueno: menos de 600 ms.
- FCP (First Contentful Paint): cuándo aparece cualquier contenido. Bueno: menos de 1,8 s.
- TBT (Total Blocking Time): cuánto tiempo total se bloquea el thread principal por JS. Bueno: menos de 200 ms.
- Speed Index: cómo de rápido se renderiza el contenido visible. Bueno: menos de 3,4 s.
Estos no son Core Web Vitals oficiales pero ayudan a debugging.
Siguientes pasos
- Mide tus Core Web Vitals con nuestro Test de Velocidad Web gratuito.
- Lee Core Web Vitals explicado para no técnicos si necesitas los conceptos básicos.
- Sigue la guía completa de auditoría web para el contexto.
- Profundiza en Cómo auditar la velocidad.
Aplicable a estos sectores
Esta guía aplica especialmente a estos sectores donde trabajamos: