Conocimiento QueenPC
PageSpeed Insights: por qué los datos de campo y laboratorio no coinciden
PageSpeed Insights puede mostrar una buena puntuación de rendimiento y una evaluación negativa de experiencia real sin que exista un error. Combina mediciones distintas: visitas reales y una prueba controlada. Aprenderás a distinguirlas y decidir qué revisar antes de modificar tu web, siguiendo la documentación de Google.
- Los datos de campo describen experiencias reales; el laboratorio permite investigar problemas en condiciones controladas.
- La puntuación de Lighthouse no equivale a la evaluación de Core Web Vitals.
- Comprueba dispositivo, periodo y alcance antes de comparar resultados, como explica Google sobre PageSpeed Insights.
Qué mide cada bloque de PageSpeed Insights
Los datos de campo proceden del Informe sobre la experiencia de usuario de Chrome, conocido como CrUX. Recogen experiencias durante los últimos 28 días. Si faltan datos suficientes para una URL, PageSpeed Insights puede mostrar información del origen: no debes interpretarla como una medición exclusiva de esa página. Consulta el alcance indicado en el informe de Google.
Los datos de laboratorio se generan mediante Lighthouse al cargar la página en unas condiciones determinadas. Sirven para diagnosticar, pero no reproducen todas las conexiones, dispositivos e interacciones de tus visitantes. Por eso ambos bloques pueden discrepar, según la explicación técnica de web.dev.
Cómo investigar la diferencia paso a paso
Te proponemos este procedimiento para evitar cambios basados únicamente en el color de una puntuación:
- Delimita la comparación. Anota la URL, el dispositivo seleccionado y si el bloque real corresponde a la página o al origen.
- Identifica la métrica problemática. No redactes un diagnóstico genérico de «web lenta»: apunta qué indicador falla y dónde aparece.
- Repite la prueba de laboratorio. Conserva las condiciones y busca problemas recurrentes, en lugar de escoger únicamente el mejor resultado.
- Prueba una visita completa. Abre el menú, desplázate, utiliza filtros y completa el formulario. Registra qué interacción produce la dificultad.
- Aplica un cambio verificable. Documenta qué has modificado y comprueba tanto el rendimiento como el funcionamiento.
Ejemplo: buena carga inicial, mala estabilidad visual
Imagina una tienda cuya prueba inicial no detecta movimientos, pero cuyo contenido se desplaza al bajar por una categoría. Es un ejemplo hipotético compatible con la diferencia de medición: el CLS de campo puede recoger desplazamientos posteriores a la carga que una prueba inicial no captura. web.dev documenta este comportamiento.
En ese caso, proponemos reproducir el desplazamiento y revisar los elementos que aparecen en ese momento antes de cambiar todo el sistema de caché.
Qué priorizar y qué no puedes concluir
Utiliza el campo para valorar la experiencia observada y el laboratorio para investigar causas. Tampoco confundas TBT, el tiempo total de bloqueo, con INP: puede ayudar a diagnosticar problemas de respuesta, pero no es una medición equivalente, como aclara la guía de medición de Web Vitals.
La conclusión práctica: prepara una lista de problemas reproducibles y valida cada solución; no plantees la optimización como una carrera hacia una puntuación aislada.
Preguntas frecuentes
¿Qué bloque debo mirar primero?
Empieza por la experiencia real disponible y utiliza después el laboratorio para investigar sus posibles causas.
¿Por qué faltan datos de campo?
Puede no haber suficientes muestras elegibles, según los requisitos de PageSpeed Insights. Eso no demuestra buen ni mal rendimiento.
¿Debo analizar solo la portada?
Te recomendamos incluir también una categoría, una ficha y una página de captación representativas.
¿Qué conviene guardar después de cada cambio?
La modificación realizada, las condiciones de prueba, las métricas y cualquier incidencia funcional detectada.
