Lee PageSpeed Insights en tres pasadas: identifica el alcance del campo y el indicador problemático, examina la prueba de laboratorio y elige un diagnóstico que explique el problema. La evaluación real y la puntuación Lighthouse responden a preguntas distintas. Un círculo verde no anula un problema en otra sección.
Empieza con una URL pública representativa. Confirma el destino tras las redirecciones y selecciona móvil o escritorio. Guarda las condiciones antes de modificar nada para comparar después la misma página y estrategia.
Confirma la página y las condiciones
Una prueba ejecutada correctamente puede describir una experiencia equivocada. Comprueba redirecciones, contenido devuelto, restricciones, protección contra bots y errores. Una pantalla de verificación rápida no demuestra que el artículo cargue rápido.
Prueba plantillas representativas, no solo la portada. Artículos, categorías, productos y búsquedas pueden utilizar recursos distintos. Empieza donde exista un problema conocido y revisa otros ejemplos antes de dar por terminada una reparación compartida.
Anota fecha, estrategia y URL final; conserva versión de Lighthouse y entorno. Los nombres y agrupaciones de auditorías cambian, por lo que conviene entender su función en lugar de depender de una captura antigua.
La descripción oficial de PageSpeed Insights explica su combinación de campo y laboratorio. El informe inicia una investigación, no ordena aplicar todas sus sugerencias indiscriminadamente.
Lee primero la sección de usuarios reales
CrUX recoge visitas aptas de usuarios reales de Chrome durante los 28 días anteriores y se actualiza diariamente. Comprueba si el panel describe la URL probada o el origen completo.
El origen combina protocolo, host y puerto, y puede reunir tipos de página diferentes. No demuestra que el artículo concreto tenga la misma distribución. Conserva la etiqueta de alcance al compartir capturas o métricas.
LCP trata la carga, INP la respuesta a interacciones y CLS la estabilidad. En p75, son buenos LCP de hasta 2,5 segundos, INP de hasta 200 milisegundos y CLS de hasta 0,1. CLS no tiene unidad temporal. No sumes ni promedies valores con unidades distintas.
Con datos suficientes para los tres, todos deben ser buenos para aprobar. PSI permite evaluar LCP y CLS cuando faltan observaciones suficientes de INP. Si faltan LCP o CLS, no puede evaluar la agregación. INP ausente no equivale a cero ni a un buen resultado medido.
Interpreta las barras y los indicadores adicionales
Las barras muestran proporciones de experiencias buenas, mejorables y deficientes. No representan el porcentaje de recursos que supera una auditoría. El p75 es un percentil de visitas, no su media aritmética.
Una página hipotética con p75 bueno puede conservar una cola lenta visible. Quizá merezca investigar país, capacidad del dispositivo o plantilla mediante seguimiento propio. La barra pública no identifica por sí sola la causa.
FCP y TTFB pueden aparecer como datos adicionales de carga, pero no son otros Core Web Vitals. Un primer byte lento puede retrasar lo siguiente; eso no demuestra que haga falta un servidor mayor. Investiga redirecciones, conexiones, aplicación y caché.
Conserva unidades al copiar a una hoja o incidencia. Confundir milisegundos con segundos convierte un error de informe en una aparente regresión enorme. Mantén CLS sin añadir “ms”.
Trata móvil y escritorio por separado
El selector cambia la estrategia de laboratorio y el tipo de dispositivo de campo. El móvil real difiere del simulado, pero ambos pueden revelar problemas ocultos en un ordenador potente. No promedies las puntuaciones para fabricar una nota global.
También importa el diseño: puede cambiar la imagen principal, la altura de cabecera, el menú o el componente inicializado. Si cambia LCP, identifica el elemento mayor en cada versión antes de decidir qué optimizar.
Prueba recorridos pertinentes en ambos formatos. Un diseño que cabe en pantalla puede seguir teniendo un menú lento o publicidad inestable. Adaptación visual y capacidad de respuesta medida por INP no son lo mismo.
La introducción a Core Web Vitals conecta estos conceptos con el uso real. Guarda referencias separadas para que una mejora no oculte una regresión del otro formato.
Entiende Lighthouse como resumen de laboratorio
La sección de diagnóstico ejecuta Lighthouse en condiciones configuradas. La puntuación va de 0 a 100: desde 90 es buena, de 50 a 89 necesita mejorar y por debajo de 50 es deficiente. Esas bandas no son los umbrales de campo.
La nota combina puntuaciones ponderadas de métricas. Las recomendaciones ayudan a diagnosticar, pero resolver una auditoría no concede puntos fijos. La curva y configuración dependen de Lighthouse; compara versiones y tiempos individuales además del círculo.
Un pequeño cambio temporal puede mover la nota y una reparación útil puede dejarla redondeada igual. Examina la mejora repetible del indicador afectado y el funcionamiento, no solo el entero.
Accesibilidad, Buenas prácticas y SEO cubren comprobaciones distintas y limitadas. Una buena nota SEO no promete posiciones y una puntuación automática de accesibilidad no sustituye una auditoría completa. Explícalo al presentar resultados.
Relaciona cada métrica con su investigación
Una navegación mide carga, incluidos LCP y CLS durante su observación. Puede omitir desplazamientos muy posteriores y no proporciona la distribución de INP real. Para interacciones se necesita una prueba adecuada.
Esta tabla orienta la investigación sin intercambiar indicadores.
| Medición | Qué ayuda a investigar | Qué no demuestra |
|---|---|---|
| LCP | Entrega y renderizado del contenido mayor | Que las interacciones posteriores sean rápidas |
| CLS | Movimiento observado en la prueba | Ausencia de cambios posteriores |
| FCP | Aparición del primer contenido | Que el contenido principal esté listo |
| TBT | Bloqueo del hilo principal durante carga | El INP real |
| Speed Index | Progreso de completitud visual | Aprobación independiente de Core Web Vitals |
Con TBT alto, inspecciona tareas largas y scripts. Con INP real malo, reproduce escritura, menús y cambios de opciones. TBT puede orientar, pero etiquetarlo como INP falsea la medición.
Si difieren los CLS, prolonga la grabación y revisa contenido tardío. La guía de campo y laboratorio explica estas discrepancias antes de concluir que una fuente está equivocada.
Prioriza diagnósticos según el problema que explican
Abre las recomendaciones asociadas al indicador deficiente. Aunque cambien los nombres, las preguntas siguen siendo qué retrasó descubrimiento, transferencia o renderizado, qué bloqueó el hilo principal y qué alteró el diseño.
Para LCP, sigue el elemento en la cascada de solicitudes. Una imagen grande puede descubrirse tarde, esperar por prioridades o terminar de descargarse antes de poder mostrarse. Corrige la fase dominante, no solo el tamaño.
En recursos que bloquean renderizado, distingue estilos y scripts necesarios al principio. Aplazarlo todo puede mostrar contenido sin estilos o romper dependencias. La guía de recursos que bloquean el renderizado explica cómo decidirlo.
Los ahorros estimados son resultados de un modelo para ese escenario, no garantías por visitante. Algunas recomendaciones se solapan; no sumes sus cifras para prometer un ahorro total. Aplica un cambio justificable y vuelve a medir.
Convierte el hallazgo en una tarea reproducible
Una buena incidencia identifica página, dispositivo, indicador, evidencia y cambio propuesto. Incluye la solicitud o script pertinente, no solo el informe entero con la orden de “ponerlo verde”. Añade una comprobación funcional para evitar aprobar eliminando una función necesaria.
Por ejemplo, una tarea de imagen puede pedir que el recurso inicial sea descubrible en HTML y que se compruebe la variante adaptable seleccionada. La aceptación incluiría LCP y representación correcta a varias anchuras. Es un ejemplo de proceso, no un diagnóstico de tu sitio.
Prioriza componentes comunes si existe evidencia. Un script de cabecera compartido puede importar más que un adorno único, pero colores parecidos no prueban una causa común. Conserva una forma de revertir cambios que afecten al renderizado o la aplicación.
Distingue las causas de datos ausentes
Una URL nueva, poco observada o no públicamente descubrible puede carecer de campo. El origen ofrece contexto, pero no rellena el registro de la URL. Las aplicaciones privadas requieren otro seguimiento.
Una integración API también puede omitir campo por cambios de respuesta, configuración o errores. Distingue “sin registro CrUX”, “solicitud fallida” e “integración sin campo”. No deberían mostrarse como el mismo fallo rojo.
Continúa con pruebas adecuadas y considera RUM respetuoso con la privacidad si operas el sitio. No inventes un percentil a partir de una ejecución ni conviertas una ausencia en aprobado.
Usa la API con estrategia y control de errores
La API v5 permite análisis Lighthouse programáticos. Este comando solicita rendimiento para una URL pública ilustrativa y guarda JSON. Requiere curl; siguen aplicándose acceso, cuotas y configuración del servicio.
curl --fail-with-body --get \
'https://www.googleapis.com/pagespeedonline/v5/runPagespeed' \
--data-urlencode 'url=https://example.com/' \
--data-urlencode 'strategy=mobile' \
--data-urlencode 'category=performance' \
--output pagespeed-mobile.jsonPara automatización, configura clave y cuotas siguiendo Google. No expongas credenciales sin restricciones en código público. Comprueba HTTP y errores JSON antes de leer lighthouseResult; guarda hora, URL final, versión y ajustes pertinentes.
Google anuncia que planea retirar CrUX de la API de PSI y recomienda CrUX API o CrUX History API. No diseñes un sistema nuevo suponiendo permanencia de loadingExperience y originLoadingExperience. Separa recuperación de campo y laboratorio y trata campos ausentes explícitamente.
La API no da permiso para probar URLs privadas. Evita tokens y datos personales en direcciones enviadas. En un servicio público, valida destinos y controla abusos desde el servidor.
Repite después de un cambio útil y sigue la tendencia
Tras un cambio específico, repite pruebas comparables y conserva métricas individuales. Comprueba la función afectada además de la navegación. Repetir sin cambios muestra sobre todo variabilidad; no crea visitas para la ventana de campo.
Revisa mediciones recientes disponibles y la tendencia conforme entran nuevas visitas en los 28 días. Anota versiones y cambios de audiencia. La consistencia entre escenarios vale más que una ejecución extraordinariamente favorable.
Abre el analizador PageSpeed cuando esté habilitado y las guías de velocidad para la causa identificada. Termina con una acción medible, un responsable y una condición de nueva prueba, no una lista de avisos sin explicar.
