Una nota alta en PageSpeed y una web lenta pueden coexistir. La puntuación resume una prueba de carga; quien visita el sitio también abre menús, rellena campos y espera respuestas. Antes de instalar otro plugin o cambiar de alojamiento, identifica cuándo aparece la lentitud.
La clave es separar tres preguntas: ¿hablamos de esa página o del origen, de laboratorio o de usuarios reales, de carga o de interacción? Esta guía de Desarrollo web y rendimiento muestra cómo pasar de una nota a una decisión verificable.
En este artículo
La nota y los datos reales responden a preguntas distintas
La puntuación de rendimiento resume una ejecución de Lighthouse. Sirve para localizar problemas y comparar pruebas bajo condiciones similares. La red, el contenido y el entorno cambian el resultado; registra las métricas y las condiciones junto con la nota.
La experiencia real procede de CrUX y agrupa los últimos 28 días. Comprueba si el informe representa la URL o el origen. Si no hay suficientes muestras de la página, PageSpeed puede mostrar el origen; si tampoco hay datos allí, no hay evaluación. La ausencia de datos no equivale a aprobar ni suspender.
Las Core Web Vitals son LCP, INP y CLS. En el percentil 75, los umbrales buenos son hasta 2,5 segundos, 200 milisegundos y 0,1, respectivamente. Ese percentil no es una media: observa también la distribución para no perder de vista las peores experiencias.
La documentación de PageSpeed Insights aclara el alcance de la nota y de los datos de campo. Consúltala antes de comparar resultados que responden a preguntas diferentes.
Encuentra el momento en que la página se vuelve lenta
¿Tarda en aparecer el contenido principal? Examina la carga. ¿El menú responde tarde cuando la página ya está visible? Reproduce el clic. ¿La búsqueda reacciona al toque pero tarda en devolver resultados? Mide la petición y la finalización de la tarea. Cada síntoma requiere una investigación distinta.
INP mide la respuesta visual a clics, toques y teclas. Por sí solo no cubre todo el tiempo de una operación asíncrona. Un indicador de carga puede aparecer enseguida mientras el servidor tarda en responder; mide también esa espera.
Un TBT bajo durante la carga no descarta interacciones lentas después. Anota la acción, el dispositivo y las condiciones. Usa datos de campo para orientar la reproducción; si no existen, prueba los flujos habituales de la página.
La guía de web.dev para investigar interacciones lentas explica cómo registrar el flujo y contrastarlo con los datos de campo disponibles.
Una lectura aplicada al sitio en producción
El 1 de noviembre de 2026, a las 00:48 CET, una prueba online del artículo sobre llms.txt de este blog obtuvo 99 puntos en móvil. El informe empleó Lighthouse 13.6.0, un Moto G Power emulado y limitación de red 4G lenta. Fue una ejecución de carga inicial, no un seguimiento de visitantes.
La prueba registró LCP de 1,1 segundos, TBT de 0 ms y CLS de 0,053. En la experiencia real aparecía «No hay datos». Los números de laboratorio fueron buenos en esa ejecución; faltan datos de campo para evaluar a los visitantes.
La captura del test móvil muestra rendimiento 99 y las demás notas en 100, sin datos de campo disponibles. Se conserva la interfaz original en español para que puedas contrastar el informe.
El ejemplo no demuestra que el sitio sea lento. Muestra el límite de una nota alta: el 99 no completa la información ausente sobre uso real. Tampoco un TBT de 0 ms garantiza que menús, búsqueda y formularios respondan bien en cualquier situación.
Aunque la nota sea 99, el informe señala recursos que bloquean el renderizado y estima un ahorro de 840 ms. Es una estimación, no una mejora conseguida. Examina los recursos, propone un cambio y compara antes y después. Aquí se documentó el diagnóstico; no se modificó el sitio ni se midió una mejora.
La segunda captura amplía ese diagnóstico. La lista de recursos ofrece una hipótesis de optimización que todavía necesita una prueba. No atribuyas a la intervención un ahorro que aún no se ha observado.
Registraría la medición y probaría los flujos relevantes antes de perseguir el punto que falta. Una queja necesita URL, acción, dispositivo y red para poder reproducirse. Otra ejecución puede arrojar cifras distintas; esta puntuación no es permanente.
Los números y las condiciones figuran en el informe online de la demostración. Consulta la ejecución original antes de extrapolar su resultado a otros visitantes.
Elige la siguiente acción según lo que encuentres
Nota alta y campo malo: verifica que comparas el mismo alcance y tipo de dispositivo. Después reproduce la métrica problemática en condiciones parecidas a las de los visitantes. El contraste puede revelar una experiencia que el laboratorio no representó.
Nota baja y campo bueno: revisa los diagnósticos y la variación entre pruebas. Quizá exista una oportunidad importante para dispositivos o redes limitados. Antes de aceptar una intervención grande, identifica a quién beneficia y qué comportamiento debería mejorar.
Sin datos de campo: usa el laboratorio para orientar la investigación y prueba las tareas principales. Si necesitas seguir la experiencia de visitantes, considera una medición propia con un alcance y tratamiento de datos adecuados. Hasta entonces, limita la conclusión a lo observado.
Lentitud después del clic: graba el flujo con el panel Performance de Chrome DevTools. Determina si la espera ocurre antes del procesamiento, en JavaScript, al presentar el siguiente fotograma o en la respuesta de red. Investiga la etapa observada.
La explicación de web.dev sobre las diferencias entre laboratorio y campo ayuda a interpretar estos escenarios sin equiparar condiciones controladas con experiencias reales.
Convierte la queja en una tarea verificable
Sustituye «mejora PageSpeed» por un síntoma reproducible: «En esta URL, al abrir la búsqueda en el móvil, hay una pausa antes de que aparezca el campo». Anota dispositivo, red, sesión iniciada o no y pasos para repetirlo. No hace falta recoger datos personales.
Define la evidencia esperada: grabaciones del mismo flujo antes y después, en condiciones comparables. Identifica el tramo responsable y conserva la búsqueda, la navegación por teclado y las integraciones. Una nota mejor no compensa una tarea rota.
En el laboratorio, repite la prueba y registra la variación sin elegir solo el mejor resultado. En el campo, anota la fecha del cambio: la ventana móvil todavía mezclará experiencias anteriores y posteriores.
La guía del panel Performance de Chrome DevTools explica cómo grabar el flujo y localizar la etapa responsable si la demora empieza después del clic.
Cuándo dejar de perseguir la puntuación
Prioriza una corrección cuando puedas conectar un síntoma con una causa y un beneficio verificable para el visitante. Si los flujos importantes funcionan bien y la propuesta solo promete cambiar el número, exige una justificación acorde con su coste y riesgo.
La misma prudencia vale para SEO. Google indica que utiliza las Core Web Vitals en sus sistemas, pero unos buenos resultados no garantizan las primeras posiciones. Su documentación advierte que buscar una puntuación perfecta solo por SEO quizá no sea el mejor uso del tiempo.
La orientación de Google sobre experiencia de página permite entender el papel de las Core Web Vitals en la búsqueda sin prometer posiciones.
¿Quieres decidir qué investigación de rendimiento priorizar en tu sitio? Puedes hablar conmigo por WhatsApp e indicar la URL y la tarea afectada.
Nota metodológica: análisis documental y una ejecución online en el sitio en producción, con investigación, redacción e ilustración asistidas por IA. No se midieron mejoras de conversión, posicionamiento ni INP de visitantes. La portada es una ilustración basada en fotografías del autor.