PageSpeed y Search Console no coinciden: cómo leer los datos de laboratorio y de campo

Hay dos situaciones que se repiten una y otra vez. En la primera, el informe de PageSpeed está en verde mientras Search Console lista cientos de URL con el estado «Deficiente» en móvil. En la segunda, aún más frecuente en sitios cuyos visitantes navegan con buenas conexiones, PageSpeed muestra una puntuación naranja o roja mientras Search Console indica que todas las URL tienen el estado «Bueno». ¿Cuál de los dos miente?

Ninguno. No miden lo mismo. Una vez que sabe lo que ve cada uno, la diferencia entre ellos le indica en qué caso se encuentra y qué hacer al respecto.

Dos tipos de medición

Los datos de laboratorio son la puntuación y las métricas de la parte inferior del informe. Es una visita simulada: un teléfono emulado, una conexión limitada, una caché vacía, desde un centro de datos de Google, y nadie que toque la página. Es repetible, lo que la hace útil para depurar, y termina cuando la página ha cargado.

Los datos de campo son los que usa Search Console, y los que muestra la parte superior del informe de PageSpeed en la sección de usuarios reales. Proceden del Chrome User Experience Report: visitantes reales de Chrome, sus dispositivos, sus redes, durante un periodo móvil de 28 días. Una página aprueba cuando el 75 % de las visitas son buenas, así que decide el cuarto más lento de su audiencia.

Caso 1: laboratorio en verde, campo deficiente

Aquí la prueba es más benévola que la realidad. Seis razones lo explican:

1. El INP no existe en el laboratorio. Interaction to Next Paint mide la rapidez con que la página reacciona a clics y toques. El laboratorio nunca hace clic. Peor aún, una optimización que aplaza JavaScript hasta la primera interacción mejora el laboratorio y puede hacer más lento el primer toque real. Vea la guía sobre el retraso de JavaScript.

2. El laboratorio se detiene en la carga, el CLS no. El campo cuenta los desplazamientos de diseño durante toda la visita: al hacer scroll, cuando aparece un banner, cuando un anuncio o un contenido incrustado cambia de tamaño. Un CLS de laboratorio de cero no dice nada de lo que pasa más abajo en la página. Los culpables habituales en los maquetadores visuales están en nuestra guía sobre el CLS.

3. Los dispositivos reales son más lentos. El percentil 75 de su audiencia puede ser un teléfono antiguo con una conexión débil, muy por debajo del perfil de laboratorio. Una página que aprueba por los pelos en el laboratorio suspende para ellos.

4. Las visitas reales no dan con su caché. El laboratorio suele encontrar una caché de página ya caliente. El tráfico real incluye páginas sin caché: primeras visitas tras una purga, clientes con sesión iniciada y URL con parámetros de seguimiento como utm_source, gclid o fbclid, que muchas cachés tratan como páginas nuevas. Su tiempo de respuesta del servidor acaba en el LCP de campo.

5. Search Console agrupa las URL. El informe muestra grupos de páginas similares, y las páginas sin tráfico suficiente heredan los datos de su grupo o de todo el sitio. La URL que usted prueba puede no ser la que hunde al grupo.

6. La ventana es de 28 días. Una corrección publicada hoy se refleja por completo en unas cuatro semanas. Volver a mirar Search Console a la mañana siguiente muestra los datos antiguos.

Caso 2: laboratorio mediocre, campo en verde

Aquí la prueba es más dura que la realidad. La prueba de laboratorio móvil emula un teléfono de gama media con una CPU ralentizada cuatro veces y una conexión móvil limitada a unos 1,6 Mbit/s con 150 ms de latencia. Ese perfil es deliberadamente pesimista, y muchas audiencias reales son mucho más rápidas:

• Redes y teléfonos más rápidos. Los visitantes con fibra, 4G rápido o 5G y teléfonos recientes terminan de cargar mucho antes que el dispositivo emulado. En el percentil 75, se mantienen en verde.
• Visitas en caliente. Los visitantes recurrentes y la navegación de una página a otra reutilizan archivos en caché y conexiones abiertas. El laboratorio siempre empieza en frío, sin nada en caché.
• Los scripts cuestan menos en hardware real. Un script pesado que bloquea la CPU emulada durante segundos tarda una fracción de ese tiempo en un teléfono reciente, por lo que el tiempo de bloqueo del laboratorio exagera lo que perciben los visitantes.

Dónde están sus visitantes decide en qué caso se encuentra. Una audiencia en países donde las conexiones móviles son lentas se comporta como el laboratorio o peor: es el caso 1. Una audiencia con redes rápidas se comporta mejor que el laboratorio: es el caso 2. Search Console y PageSpeed muestran una sola cifra para todos sus visitantes juntos; si su audiencia es internacional, los datos públicos del Chrome UX Report pueden desglosarse por país.

Qué hacer en el caso 2. Las señales de experiencia en la página de Google usan los datos de campo, así que lo que cuenta es un campo en verde. No rompa un sitio que funciona para perseguir una puntuación de laboratorio. Conserve el laboratorio como diagnóstico: muestra lo que viven sus visitantes más lentos y detecta las regresiones antes de que lleguen al campo. Mejore lo que señala, un cambio seguro cada vez, como en nuestro método para optimizar sin romper.

Paso 1: leer lo que dice realmente Search Console

• Qué métrica: LCP, INP o CLS. El método es completamente distinto para cada una.
• Qué dispositivo: móvil y escritorio son informes separados.
• Qué grupo: abra el problema y mire las URL de ejemplo. Casi siempre apuntan a una plantilla: páginas de producto, artículos, páginas de categoría, la página de inicio.

Después abra una URL de ejemplo en PageSpeed y mire primero la sección de usuarios reales. Si muestra datos para esa URL, tiene las cifras de campo propias de la página; si muestra el origen entero, la página se evalúa junto con el resto del sitio.

Paso 2: reproducir el problema de campo en su navegador

Para el INP: abra DevTools, panel Performance, ponga la limitación de CPU en 4x o 6x, grabe e interactúe como lo haría un visitante: abrir el menú, cambiar una variante, añadir al carrito, aceptar el banner de cookies. Los bloques amarillos largos tras su clic son el retraso. Las versiones recientes de Chrome también muestran en ese panel los valores de LCP, CLS e INP en directo.

Para el CLS: recargue con limitación, luego recorra toda la página despacio e interactúe. En la pestaña Rendering, «Layout Shift Regions» resalta cada desplazamiento en el momento en que ocurre.

Para el LCP: pruebe la plantilla en emulación móvil, con una URL que no esté en caché (añada un parámetro aleatorio), y fíjese en el tiempo de respuesta del servidor y en el momento en que se descubre el elemento LCP.

new PerformanceObserver(l => l.getEntries().forEach(e =>
  console.log('LCP', Math.round(e.startTime), e.element))).observe({ type: 'largest-contentful-paint', buffered: true });
new PerformanceObserver(l => l.getEntries().forEach(e => !e.hadRecentInput &&
  console.log('CLS', e.value.toFixed(3), e.sources?.map(s => s.node)))).observe({ type: 'layout-shift', buffered: true });

Paso 3: nunca concluir a partir de una sola prueba

La puntuación de laboratorio varía de una prueba a otra, a veces diez puntos en móvil, porque la página, la red y la máquina de prueba cambian. Para comparar dos versiones:

• pruebe cada versión varias veces y compare medianas, no la mejor prueba;
• espacie las pruebas, ya que un resultado solicitado de nuevo al poco tiempo puede servirse desde una caché y repetir la misma cifra;
• compare la misma URL, el mismo dispositivo y las mismas condiciones, con y sin el cambio.

Paso 4: validar y esperar

Cuando la corrección esté publicada, haga clic en «Validar corrección» en el problema de Search Console. La validación sigue la ventana de 28 días, así que cuente con un mes aproximadamente. Mientras tanto, el laboratorio y las mediciones en su propio navegador son lo que le indica que la corrección funciona.

Con Mantys Core

En resumen

• La puntuación de PageSpeed es una carga simulada; Search Console son 28 días de visitas reales en el percentil 75.
• Laboratorio en verde y campo deficiente: el problema es una interacción, un desplazamiento tras la carga, un dispositivo lento, una URL sin caché u otra plantilla.
• Laboratorio mediocre y campo en verde: sus visitantes son más rápidos que el perfil pesimista de la prueba; lo que cuenta es el campo.
• Parta de Search Console: métrica, dispositivo, grupo de URL, plantilla.
• Reprodúzcalo en DevTools con limitación e interacciones reales, y luego compare varias pruebas de laboratorio, nunca una sola.
• Valide la corrección y dele cuatro semanas.