PageSpeed Insights: cómo interpretar los datos de campo y laboratorio

Abre PageSpeed Insights y verás dos informes del mismo sitio que no coinciden: uno mide a tus usuarios reales, el otro simula una carga. Si no sabes cuál manda, vas a optimizar lo que no era.

Arriba está el bloque de datos de campo; abajo, el de laboratorio. Aquí tienes de dónde sale cada número y en qué orden arreglar lo que aparece en rojo.

Qué mide PageSpeed Insights y de dónde sale cada número

Para la documentación oficial, el laboratorio sirve para depurar porque su dato se recoge "in a controlled environment", aunque puede no capturar los cuellos de botella reales; el campo captura la experiencia real, con "a more limited set of metrics".

El bloque de campo muestra cinco métricas con umbrales oficiales: FCP (1.800 / 3.000 ms), LCP (2.500 / 4.000 ms), CLS (0,1 / 0,25), INP (200 / 500 ms) y TTFB, experimental (800 / 1.800 ms). El laboratorio trae otro conjunto (FCP, LCP, Speed Index, CLS, Time to Interactive y TBT), así que no se comparan de uno a uno. Y todo cambia según el interruptor Móvil/Escritorio.

Un aviso que ahorra confusión: "the API is versioned as v5, however the Lighthouse version is independent and updated regularly". El motor pasó a Lighthouse 13.0 en octubre de 2025 y hoy va por la 13.5.0: antes de dramatizar un score que bajó solo, mira qué versión firmó el informe.

Datos de campo (CrUX): usuarios reales, 28 días y percentil 75

El campo lo alimenta Chrome UX Report: "Real-user experience data in PSI is powered by the Chrome User Experience Report (CrUX) dataset". Son los 28 días anteriores de FCP, INP, LCP y CLS.

El número grande es el percentil 75: "The 75th percentile is selected so that developers can understand the most frustrating user experiences on their site". No es la media: es el valor que empeora el 25% de las cargas. Las barras reparten todas las cargas y el p75 va por encima: un p75 verde con barra ámbar ancha cuenta otra historia.

Para que existan datos de campo hacen falta tres condiciones. Primera, la página debe ser públicamente descubrible: "A page must be publicly discoverable to be considered for inclusion in the CrUX dataset", con HTTP 200 y sin noindex. Segunda, debe tener tráfico suficiente: "An exact number is not disclosed" y no se puede enviar a mano. Tercera, el usuario debe ser elegible, y aquí está el detalle que casi nadie conoce: Chrome en iOS, las apps Android con WebView y otros navegadores Chromium como Edge no aportan datos. Si tu audiencia es iPhone, CrUX no la mide.

Con poco tráfico, "PSI will fall back to origin-level granularity, which encompasses all user experiences on all pages of the website": el número mezcla todo el dominio.

El caso de las SPA y las navegaciones suaves

CrUX documenta otra limitación: en una SPA, los cambios de ruta por JavaScript "appear as new page views to the user, but to Chrome and the underlying platform APIs the entire experience is attributed to the initial page view".

Datos de laboratorio (Lighthouse): una sola carga, simulada

PSI "uses Lighthouse to analyze the given URL in a simulated environment", en un datacenter de Google. Como corre en un servidor, tu conexión no influye.

Las condiciones están fijadas: "Lighthouse applies network throttling to emulate the ~85th percentile mobile connection speed", con el preset Slow 4G (150 ms de latencia y 1,6 Mbps de bajada / 750 Kbps de subida) y "a constant 4x CPU multiplier" para emular un móvil de gama media. Con el throttling simulado, Lighthouse "uses a simulation of a page load, based on the data observed in the initial unthrottled load": primero carga rápido y después calcula cuánto habría tardado en Slow 4G.

El score se lee tal cual: "A score of 90 or above is considered good. 50 to 89 is a score that needs improvement, and below 50 is considered poor". Es una media ponderada (LCP 25%, TBT 30%, CLS 25%, FCP 10% y Speed Index 10%) según la doc de scoring. El TBT es el proxy de laboratorio del INP, que no se puede medir sin usuario.

Por qué campo y laboratorio se contradicen (y cuál manda)

La regla corta: el campo decide si hay un problema real; el laboratorio explica la causa. Si no puedes tener los dos en verde, prioriza el campo. "The field data is a historical report about how a particular URL has performed. The lab data is based on a simulated load of a page on a single device and fixed set of network conditions."

De ahí la frase clave: "having good lab data does not necessarily mean real-user experiences will also be good". Un 98 de laboratorio con el campo en rojo se explica por los terceros (analítica, consentimiento, vídeo, publicidad) que en la simulación no pesan igual, por los dispositivos reales que Slow 4G solo aproxima, y por el fallback a nivel de origen. También pasa lo contrario: campo verde con laboratorio rojo.

Cómo leer un informe de PageSpeed Insights en 5 pasos

1. Mira si hay datos de campo. Si PSI avisa de que faltan y muestra el nivel de origen, el número mezcla todas las páginas.
2. Mira la evaluación de Core Web Vitals, no la puntuación. "The aggregation passes the Core Web Vitals assessment if the 75th percentiles of all three metrics are Good"; si falta LCP o CLS no hay evaluación.
3. Lee las barras antes que el percentil: un p75 verde con barra ámbar ancha significa que una parte relevante de usuarios lo pasa mal.
4. Baja al laboratorio para el por qué (TBT, LCP simulado y auditorías). Orden: interactividad, LCP y CLS.
5. Vuelve a medir el campo 28 días después: es una media móvil y no cambia de un día para otro.

La puntuación de Lighthouse no es un factor de ranking

Google Search dice: "Core Web Vitals are used by our ranking systems". Y añade el matiz que casi nadie cita: "getting good results in reports like Search Console's Core Web Vitals report or third-party tools doesn't guarantee that your pages will rank at the top... trying to get a perfect score just for SEO reasons may not be the best use of your time".

También dice que la evaluación es por página y que "there is no single signal", según la guía de page experience. En la práctica, el score de laboratorio no entra en el ranking: lo que entra son las Core Web Vitals medidas con datos de campo. Optimizarlo sirve porque suele arrastrar al campo, no porque sea el objetivo.

Cómo monitorizar sin volverte loco

El informe de Core Web Vitals de Search Console es gratis y su fuente es CrUX. Se lee por grupos de URLs, con móvil y escritorio separados, el estado del grupo es el de su peor métrica, y "if a URL group does not have a minimum amount of reporting data for LCP and CLS, the URL is omitted from the report".

La API de PageSpeed Insights v5 devuelve campo y laboratorio en una llamada ("a key is recommended for frequent, automated queries"): la respuesta trae loadingExperience, originLoadingExperience y lighthouseResult.

curl -s "https://www.googleapis.com/pagespeedonline/v5/runPagespeed?url=https://example.com/&strategy=mobile" \
  | python3 -c "import json,sys; d=json.load(sys.stdin); print(d['lighthouseResult']['categories']['performance']['score'])"

Si solo necesitas campo, la CrUX API "will always show 28-days", con 150 consultas por minuto por proyecto. Y no rastrees el score a diario: es una sola carga simulada y varía entre ejecuciones ("Why does the performance score change from run to run?").

Errores frecuentes al interpretar estos datos

• Perseguir el 100 de laboratorio como objetivo de SEO.
• Leer el percentil 75 como una media.
• Usar datos de origen para juzgar una URL concreta.
• Tomar el TTFB como Core Web Vital.
• Auditar móvil y escritorio mezclados.
• Decidir con una sola corrida, cuando lo útil es pensar en "a distribution of scores, rather than a single number".
• Arreglar y no volver a medir el campo 28 días después.
• Olvidar que CrUX no ve iPhone.

Checklist: leer e interpretar PageSpeed Insights en 7 pasos

1. Abre la URL concreta, no la portada, y elige móvil.
2. Confirma si el bloque de campo es de página o de origen.
3. Mira la evaluación de Core Web Vitals antes que la puntuación.
4. Baja al laboratorio y anota el TBT y el LCP simulado.
5. Prioriza por métrica: interactividad, LCP y CLS.
6. Anota la versión de Lighthouse y la fecha del test.
7. Vuelve al campo 28 días después para confirmar la mejora.

Si no hay datos de campo, revisa noindex, código de estado HTTP y tráfico antes de sospechar de la herramienta. Los pasos técnicos están en las guías de hosting y servidor, CDN y resource hints.

PageSpeed Insights no es un examen que haya que aprobar con 100: es un panel de diagnóstico con dos termómetros. El de tus usuarios decide si hay fiebre; el simulado te dice dónde apretar. Lo que se mide de verdad, y lo que Google usa, es el primero.