PageSpeed Insights (PSI)

TL;DR — PageSpeed Insights (PSI) es una herramienta gratuita de Google que evalúa una página de dos formas distintas: cómo la experimentaron realmente los visitantes reales (datos de campo) y cómo salió una única prueba simulada (la puntuación de laboratorio de 0–100). El número de 0–100 es el que obsesiona a todo el mundo — y no es lo que Google usa para posicionar. Así que no se alarme por una puntuación en rojo.

Qué es PageSpeed Insights

PageSpeed Insights está en pagespeed.web.dev. Es gratuito, no requiere iniciar sesión y funciona con cualquier URL pública — incluidas las de la competencia. Se pega una URL y la herramienta la prueba tanto en Mobile como en Desktop (Mobile es la pestaña predeterminada y las puntuaciones de Mobile casi siempre son más bajas).

Las dos cosas que PSI le muestra

Esta es la parte que confunde a todo el mundo, así que lo diré de forma sencilla. PSI muestra dos informes separados de la misma página:

1. Datos de campo — lo que experimentaron las personas reales. Provienen del Chrome UX Report (CrUX), es decir, usuarios reales de Chrome que visitaron su página durante los últimos 28 días. Es la sección etiquetada como «Descubra lo que están experimentando sus usuarios reales». Ahí es donde se obtiene la evaluación de Core Web Vitals: un simple Aprobada o Reprobada.
2. Datos de laboratorio — una única prueba simulada. PSI también ejecuta Google Lighthouse una vez, sobre un teléfono y una red simulados, y devuelve la puntuación Performance de 0–100 más una lista de correcciones sugeridas.

Lo único que hay que recordar

La puntuación de 0–100 no es un factor de posicionamiento. Google posiciona en función de las Core Web Vitals (Métricas web esenciales) de campo — Largest Contentful Paint, Interaction to Next Paint y Cumulative Layout Shift, medidas en usuarios reales. La puntuación de laboratorio de 0–100 es un número distinto que procede de un sistema distinto. Se puede sacar un 72 y aun así superar las Core Web Vitals.

Algunas cosas más que suelen despistar:

• La puntuación cambia cada vez que se ejecuta. Es una única prueba simulada, así que el número oscila. Ejecútela varias veces y no lea nada en una variación de 3–5 puntos.
• No hace falta un 100. Casi nadie saca 100. El objetivo es superar las Core Web Vitals, no alcanzar un número perfecto.
• Una buena puntuación no garantiza una página rápida para los usuarios reales, y una puntuación “mala” no significa que los usuarios reales estén sufriendo.

Sinceramente, salvo que su sitio sea realmente lento, no es por aquí por donde yo empezaría. ¿Quiere el desglose completo — campo frente a laboratorio, los umbrales de p75, los mecanismos de reserva de datos y en qué se diferencia PSI de Lighthouse y de Search Console? Cambie a la pestaña Avanzado.

TL;DR — PSI (pagespeed.web.dev) presenta dos análisis independientes de una misma URL: datos de campo del Chrome UX Report — usuarios reales en una ventana móvil de 28 días, que determina la Core Web Vitals Assessment Passed/Failed en el percentil 75 — y datos de laboratorio, una única ejecución de Lighthouse que da la puntuación Performance de 0–100 más los diagnósticos. La puntuación de 0–100 es un dato de laboratorio y no es un factor de posicionamiento; el posicionamiento usa las Core Web Vitals (Métricas web esenciales) de campo (LCP/INP/CLS). Los datos de campo necesitan suficientes muestras de CrUX (a nivel de URL, con reserva a nivel de origen y, si no, “No data”). La puntuación de laboratorio también varía entre ejecuciones — ejecútela varias veces. PSI es la interfaz web; Lighthouse es el motor; el informe de Search Console es otra vista más de CrUX.

PSI son dos herramientas bajo un mismo abrigo

Lo más importante que hay que entender sobre PageSpeed Insights es que no es un análisis, sino dos, presentados en una sola interfaz. web.dev lo expresa con claridad: “PSI is a tool that reports field data from CrUX and lab from Lighthouse for a given page.” (traducción) «PSI es una herramienta que informa de los datos de campo de CrUX y de los de laboratorio de Lighthouse para una página determinada.» Esas dos mitades provienen de sistemas distintos, miden cosas distintas e importan por razones distintas. Si se confunden, casi cualquier pregunta sobre PSI se vuelve confusa; si se mantienen separadas, todo encaja.

Datos de campo: lo que experimentaron los usuarios reales

La sección superior — «Descubra lo que están experimentando sus usuarios reales» — se alimenta del Chrome UX Report (CrUX). web.dev describe la CrUX API como algo que ofrece “low-latency access to aggregated real-user experience data at page and origin granularity” (traducción) «acceso de baja latencia a datos agregados de experiencia de usuarios reales con granularidad de página y de origen» en forma de “28-day rolling average.” (traducción) «media móvil de 28 días». PSI se actualiza a diario; el conjunto de datos de CrUX en BigQuery se publica mensualmente.

Algunos mecanismos que importan:

• La evaluación de Core Web Vitals se aprueba o reprueba en p75. La documentación de Chrome indica que el percentil debe quedar en la categoría «buena» en las tres Core Web Vitals para aprobar; de lo contrario, la evaluación se muestra como reprobada. Las tres son Largest Contentful Paint (bueno < 2,5s), Interaction to Next Paint (bueno < 200ms) y Cumulative Layout Shift (bueno < 0,1). PSI también muestra FCP y TTFB en «Otras métricas» — informativos, pero no forman parte del veredicto.
• Hay una única excepción documentada, y solo afecta a INP. Si una página no tiene suficientes muestras de CrUX para informar específicamente de INP, la guía actual de PSI indica que aún puede emitir un veredicto Pass/Fail a partir de unos valores de p75 buenos de LCP y CLS por sí solos. No existe una excepción equivalente para LCP ni para CLS — si es a alguna de esas dos a la que le faltan datos suficientes, no lo interprete como un aprobado; la falta de datos no es un aprobado automático documentado en ninguna métrica salvo INP.
• p75 significa el percentil 75. El valor mostrado es la experiencia que el 75 % de las visualizaciones de página superó en rapidez. web.dev eligió el percentil 75 para que el número sea “resistant to outliers” (traducción) «resistente a valores atípicos» — un objetivo más estricto que una mediana.
• INP sustituyó a FID en marzo de 2024. Si consulta capturas antiguas o guías antiguas (incluidos mis textos más antiguos en Ahrefs sobre PageSpeed Insights y Core Web Vitals), pueden seguir mostrando FID; la evaluación ahora usa INP.
• Reserva URL → origen → “No data”. Si no hay suficientes datos de CrUX para la URL concreta, PSI recurre a los datos a nivel de origen (agregados de todo el sitio). Si no hay ningún dato de CrUX, verá “No data”, pero Lighthouse se ejecuta igualmente. Como señala web.dev, “CrUX data is only available when sites meet certain eligibility criteria” (traducción) «los datos de CrUX solo están disponibles cuando los sitios cumplen ciertos criterios de elegibilidad» y “PSI is only available for public URLs.” (traducción) «PSI solo está disponible para URL públicas». Las páginas con poco tráfico y las páginas totalmente nuevas con frecuencia no tienen datos de campo a nivel de URL.

Lea la etiqueta de alcance antes de redactar la conclusión. El CrUX a nivel de URL describe la muestra de campo elegible atribuida a esa URL. La reserva a nivel de origen es una señal útil de todo el sitio, pero por sí sola no puede diagnosticar la página probada. “No data” significa que la muestra de campo no está disponible o es insuficiente, no que la página aprobara, suspendiera o no recibiera tráfico. El resultado de Lighthouse que aparece más abajo sí puede diagnosticar esa ejecución de laboratorio controlada, pero no cubre el hueco que dejan los datos de campo ausentes.

Datos de laboratorio: la puntuación de 0–100 de Lighthouse

La sección inferior es una única ejecución de Lighthouse en un dispositivo y una red simulados, que produce la puntuación Performance y una lista de oportunidades y diagnósticos. Los tramos de Google: “A score of 90 or above is considered good. 50 to 89 is a score that needs improvement, and below 50 is considered poor.” (traducción) «Una puntuación de 90 o superior se considera buena. De 50 a 89 es una puntuación que necesita mejorar, y por debajo de 50 se considera deficiente.»

Lo que conviene saber sobre la ejecución de laboratorio:

• Es simulada, y la ejecución de Mobile es lenta a propósito. Mobile emula un teléfono de gama media con una conexión limitada artificialmente; Desktop usa un perfil emulado más rápido. Por eso su puntuación de Mobile casi siempre es más baja que la de Desktop — y por eso los datos de campo de usuarios reales a menudo se ven mejor de lo que sugieren los diagnósticos de laboratorio.
• La puntuación es variable. Cada ejecución es una auditoría nueva de Lighthouse en el lado del servidor: la página, el centro de datos de Google, las condiciones de red e incluso la versión de Chrome/Lighthouse pueden mover el número entre ejecuciones. Recomiendo ejecutarla varias veces (3–5) y mirar el rango en lugar de tomar cualquier ejecución concreta como palabra sagrada. Una variación de unos pocos puntos es ruido.
• Si va a comparar ejecuciones, guarde algo más que la puntuación. La respuesta de la API incluye una marca de tiempo, la URL solicitada y la final, el factor de forma, el entorno emulado, la versión de Lighthouse y cualquier advertencia — conserve todo eso junto a cada puntuación. Dos “72” no son comparables si una se ejecutó con una versión distinta de Lighthouse o encontró una redirección que la otra no. No promedie puntuaciones sin etiquetar; etiquételas o no las compare.
• Las versiones de Lighthouse avanzan de forma independiente de la PSI API. PSI se mantuvo en la versión v5 de la API, pero el motor de Lighthouse que hay debajo sigue publicando nuevas versiones (la más reciente indicada en las notas de lanzamiento de Google en el momento de esta revisión es Lighthouse 13.0, con fecha 2025-10-20) — los campos de auditoría, los pesos y los tramos pueden cambiar con la versión del motor aunque el contrato de la API no cambie.
• Los “Estimated savings” no son aditivos. Los segundos que aparecen junto a cada diagnóstico dan por supuesto que esa corrección se aplica de forma aislada. Los problemas interactúan entre sí; las mejoras reales casi siempre son menores que la suma de las estimaciones individuales. Tómelos como orientación, no como un presupuesto que se pueda sumar.
• Los pesos de las métricas cambian con las versiones de Lighthouse. La puntuación Performance es una mezcla ponderada de métricas de laboratorio (las métricas de tiempo de carga, Total Blocking Time y CLS son las que más peso tienen), pero los pesos exactos varían entre versiones de Lighthouse — consulte la calculadora de puntuación actual en lugar de confiar en un reparto fijo.

El mito que más daño causa: “la puntuación es un factor de posicionamiento”

No lo es. La puntuación Performance de 0–100 es un número de laboratorio de Lighthouse, y no he encontrado ninguna fuente oficial actual de Google Search que documente esa puntuación en sí como una señal de posicionamiento ni que vincule un cambio de puntuación con un cambio de posiciones. En cambio, la documentación de page experience de Google apunta a las Core Web Vitals (Métricas web esenciales) de campo: datos de usuarios reales basados en CrUX, el mismo tipo de datos que muestra la sección de campo de PSI en p75. (Un matiz que conviene precisar: la visualización pública de datos de campo de PSI es una superficie de informes con sus propias reglas de elegibilidad y de reserva; Google no ha publicado el proceso interno exacto que alimenta el posicionamiento, así que trate los “datos de campo” como el mismo tipo de señal en lugar de dar por supuesta una identidad exacta con lo que PSI le muestra.) Una página puede quedarse en 72 en laboratorio y aun así superar la Core Web Vitals Assessment porque sus datos de usuarios reales son buenos: números distintos de sistemas distintos. El mito derivado — “una buena puntuación de laboratorio equivale a una buena experiencia de usuario real” — falla por la misma razón: las condiciones de laboratorio no son las condiciones de sus visitantes. Cuando campo y laboratorio divergen, los datos de campo son los más relevantes para el SEO.

E incluso las Core Web Vitals de campo son una señal de posicionamiento bastante pequeña. Los propios empleados de Google les han quitado importancia: Gary Illyes ha descrito page experience como algo más cercano a un criterio de desempate que a una señal importante. Mi postura sincera no ha cambiado: no creo que las Core Web Vitals tengan mucho impacto en el SEO y, salvo que un sitio sea extremadamente lento, por lo general no priorizaré corregirlas por encima del contenido y los enlaces. Corríjalas por los usuarios y para el caso de una lentitud real, no por pánico ante un número en rojo.

Cómo leer de verdad un informe de PSI

1. Lea primero los datos de campo. ¿La página obtuvo Passed o Failed en la Core Web Vitals Assessment? Ese es el veredicto relevante para el SEO. Si dice “No data”, todavía no hay suficiente tráfico en CrUX — se trabaja solo con datos de laboratorio.
2. Revise Mobile y Desktop por separado. Mobile es la opción predeterminada y normalmente la más débil; también es la que más importa, ya que Google usa indexación mobile-first.
3. Después use los diagnósticos de laboratorio para encontrar la causa. Los datos de laboratorio son su ciclo rápido de retroalimentación para localizar y corregir el problema de fondo: recursos que bloquean el renderizado, imágenes demasiado grandes, orígenes de cambios de diseño, tareas largas.
4. Corrija y luego espere. Los datos de campo son una ventana móvil de 28 días, así que una corrección que publique hoy puede tardar hasta 28 días en reflejarse por completo en la Core Web Vitals Assessment. Use los datos de laboratorio para confirmar la corrección de inmediato; use los datos de campo para confirmar que realmente movió a los usuarios reales.
5. Compare con la competencia. Como PSI funciona con cualquier URL pública, puede analizar las páginas de un competidor y comparar sus Core Web Vitals de campo con las suyas — un caso de uso que casi ninguna guía menciona.

PSI frente a las herramientas con las que se confunde

• PSI frente a Lighthouse. Lighthouse es el motor; PSI es una interfaz web que ejecuta Lighthouse y, además, superpone los datos de campo de CrUX. Si ejecuta Lighthouse por su cuenta (en Chrome DevTools o desde la CLI) obtiene la auditoría de laboratorio, pero en su equipo y su red, sin datos de campo.
• PSI frente al informe Core Web Vitals de Search Console. Ambos se basan en CrUX, así que ambos reflejan usuarios reales. La diferencia: Search Console agrupa URL similares e informa a escala de toda la propiedad, mientras que PSI trabaja por URL (o con la reserva a nivel de origen). Si GSC y PSI parecen no coincidir, normalmente es cosa de la agrupación.
• PSI frente a Chrome DevTools / WebPageTest / DebugBear / Ahrefs Site Audit. Estas herramientas ofrecen más configuración (dispositivos personalizados, ubicaciones, limitación artificial) y, en algunos casos, monitorización de usuarios reales. El punto fuerte de PSI es ser gratuito, no requerir configuración y estar ligado al propio conjunto de datos de CrUX de Google.

La PSI API (para pruebas masivas)

No hace falta usar la interfaz web de una URL en una URL. La PageSpeed Insights API (base https://www.googleapis.com/pagespeedonline/v5) devuelve los mismos datos de forma programática. Parámetros clave: url (obligatorio), strategy (mobile o desktop) y category (performance, accessibility, best-practices, seo). La respuesta se divide igual que la interfaz: loadingExperience (datos de campo a nivel de URL), originLoadingExperience (datos de campo a nivel de origen) y lighthouseResult (la auditoría de laboratorio). Así es como se probaría un lote de URL de forma programada en lugar de ir haciendo clic una a una.

No construya una automatización duradera de datos de campo sobre esta API. La propia documentación de la API de Google abre ahora con un aviso de que planea dejar de incluir los datos de usuarios reales de CrUX en la PSI API, y remite a quienes automatizan a la CrUX API o a la CrUX History API específicas. Siga usando la PSI API para la auditoría de laboratorio de Lighthouse — esa parte no se ve afectada —, pero si programa extracciones masivas de datos de campo, desarrolle contra una API específica de CrUX y no contra loadingExperience/originLoadingExperience en la respuesta de PSI.

Dónde encaja esto en el rendimiento web

PSI es una herramienta de medición, no el destino. Las métricas que expone — Largest Contentful Paint, Interaction to Next Paint, Cumulative Layout Shift — son las Core Web Vitals (Métricas web esenciales), y el eje temático dedicado a ellas (umbrales, qué significa cada una y cómo mejorarlas) es el siguiente paso. Lighthouse es el motor de laboratorio sobre el que se ejecuta PSI; CrUX (el Chrome UX Report) es la fuente de datos de campo que alimenta la parte superior de todo informe de PSI. Entienda esos tres y PSI deja de ser una caja misteriosa.

Resumen con IA

Una versión condensada del contenido de Advanced:

• PSI = dos herramientas en una sola interfaz. Datos de campo del Chrome UX Report (usuarios reales) y datos de laboratorio de una única ejecución de Lighthouse, para la misma URL, en pagespeed.web.dev. Gratuito, sin inicio de sesión, cualquier URL pública, Mobile + Desktop.
• Los datos de campo determinan la Core Web Vitals Assessment — Passed/Failed, en el percentil 75, sobre LCP (<2,5s), INP (<200ms) y CLS (<0,1). Ventana móvil de 28 días, actualizada a diario. FCP y TTFB se muestran, pero no cuentan para el veredicto.
• Los datos de laboratorio son la puntuación Performance de 0–100 (90+ buena, 50–89 necesita mejorar, <50 deficiente) más los diagnósticos. Mobile se ejecuta con limitación artificial y puntúa por debajo de Desktop.
• La puntuación de 0–100 NO está documentada como factor de posicionamiento. Los sistemas de posicionamiento de Google usan las Core Web Vitals de campo (datos de usuarios reales basados en CrUX: el mismo tipo de datos que muestra la sección de campo de PSI, aunque Google no ha publicado que el proceso interno exacto sea idéntico a la visualización pública de PSI). Una página puede sacar 72 y aun así superar las CWV: números distintos de sistemas distintos.
• Reserva de CrUX: a nivel de URL → a nivel de origen → “No data” (Lighthouse se ejecuta igualmente). Las páginas con poco tráfico y las nuevas a menudo no tienen datos de campo a nivel de URL.
• La puntuación es variable entre ejecuciones — ejecútela de 3 a 5 veces. Los “Estimated savings” no son aditivos. No hace falta un 100.
• Lea primero los datos de campo (Passed/Failed) y luego use los diagnósticos de laboratorio para encontrar la causa; publique la corrección y espere hasta 28 días a que los datos de campo lo reflejen.
• PSI frente a Lighthouse (motor frente a interfaz + campo) y frente al informe de CWV de Search Console (también CrUX, pero agrupado a escala). En conjunto, las CWV son una señal de posicionamiento menor.

Documentación oficial

Documentación de fuentes primarias de Google y de los equipos de Chrome / web.dev.

Google / PageSpeed Insights

• PageSpeed Insights tool — la herramienta en sí.
• PageSpeed Insights API — About — qué hace PSI, los dos tipos de datos y los tramos de la puntuación de 0–100.
• PSI API — runPagespeed reference — parámetros (url, strategy, category) y la estructura de la respuesta.

Chrome UX Report (la fuente de los datos de campo)

• Uso de CrUX en PageSpeed Insights — cómo funciona la sección de campo y la evaluación aprobada/reprobada.
• Metodología de CrUX — elegibilidad, participación y qué páginas se incluyen.
• CrUX API — la media móvil de 28 días que alimenta los datos de campo de PSI.
• Descripción general de CrUX — cómo alimenta CrUX la señal de experiencia de página para el posicionamiento.

web.dev / Core Web Vitals

• ¿Cuáles son las herramientas de Core Web Vitals? — dónde encaja PSI entre las herramientas de CrUX/Lighthouse.
• Core Web Vitals — los umbrales de LCP/INP/CLS y la regla del percentil 75.
• Definición de los umbrales de Core Web Vitals — por qué p75.
• Core Web Vitals y la Búsqueda de Google — el contexto de la señal de posicionamiento.

Citas de la fuente

Declaraciones textuales, cada una enlazada al pasaje en la página de origen.

Google / Chrome / web.dev — cómo funciona PSI

• “PSI is a tool that reports field data from CrUX and lab from Lighthouse for a given page.” (traducción) «PSI es una herramienta que informa de los datos de campo de CrUX y de los de laboratorio de Lighthouse para una página determinada.» — web.dev. Ir a la cita
• “PSI is only available for public URLs. It cannot be used on development sites that are not publicly accessible.” (traducción) «PSI solo está disponible para URL públicas. No se puede usar en sitios de desarrollo que no sean accesibles públicamente.» — web.dev. Ir a la cita
• La sección de campo se describe como “Discover what your real users are experiencing.” (traducción) «Descubra lo que están experimentando sus usuarios reales.» — Chrome para desarrolladores, CrUX en PSI. Ir a la cita
• “To pass, the percentile must be categorized as ‘good’ in all three Core Web Vitals. Otherwise, the assessment appears as ‘failed’.” (traducción) «Para aprobar, el percentil debe estar categorizado como ‘good’ en las tres Core Web Vitals. De lo contrario, la evaluación aparece como ‘failed’.» — Chrome para desarrolladores, CrUX en PSI. Ir a la cita
• La CrUX API ofrece “low-latency access to aggregated real-user experience data at page and origin granularity” en forma de “28-day rolling average.” (traducción) «acceso de baja latencia a datos agregados de experiencia de usuarios reales con granularidad de página y de origen» en forma de «media móvil de 28 días». — Chrome para desarrolladores, API de CrUX. Ir a la cita

web.dev — umbrales

• “a good threshold to measure is the 75th percentile of page loads, segmented across mobile and desktop devices.” (traducción) «un buen umbral que medir es el percentil 75 de las cargas de página, segmentado entre dispositivos móviles y de escritorio.» — web.dev, Core Web Vitals. Ir a la cita
• “if at least 75 percent of page views to a site meet the ‘good’ threshold, the site is classified as having ‘good’ performance.” (traducción) «si al menos el 75 por ciento de las visualizaciones de página de un sitio alcanzan el umbral ‘good’, el sitio se clasifica como de rendimiento ‘good’.» — web.dev, definición de los umbrales. Ir a la cita

Del sector — la distinción entre puntuación y posicionamiento (transmitido, no de Google)

• “The Performance score on PageSpeed Insights does not impact SEO directly. However, the real-user Core Web Vitals assessment does impact Google rankings.” (traducción) «La puntuación Performance de PageSpeed Insights no afecta directamente al SEO. Sin embargo, la evaluación de Core Web Vitals con usuarios reales sí afecta a las posiciones en Google.» — Matt Zeunert, DebugBear. Fuente
• “Core Web Vitals are the only metrics Google explicitly uses for grading.” (traducción) «Las Core Web Vitals son las únicas métricas que Google usa explícitamente para calificar.» Y “Running the same URL just minutes apart can yield different scores.” (traducción) «Ejecutar la misma URL con solo unos minutos de diferencia puede dar puntuaciones distintas.» — Ryan Sullivan, SiteCare. Fuente

Hoja de referencia rápida del informe de PSI

Cada sección de PSI: campo frente a laboratorio, y qué significa

Umbrales “good” de las Core Web Vitals (campo, p75)

Tramos de la puntuación de Lighthouse (laboratorio)

• 90–100 — buena · 50–89 — necesita mejorar · <50 — deficiente

Reserva de datos de campo

• CrUX a nivel de URL → si no hay suficientes, a nivel de origen → si no hay ninguno, “No data” (Lighthouse se ejecuta igualmente).

Datos rápidos

• Datos de campo = 28 días móviles, actualizados a diario → una corrección puede tardar hasta 28 días en verse.
• La puntuación de 0–100 es variable — ejecútela de 3 a 5 veces e ignore una variación de 3–5 puntos.
• Los “Estimated savings” no se suman — dan por supuesto que cada corrección se aplica sola.
• Mobile es la pestaña predeterminada y normalmente puntúa por debajo de Desktop.
• INP sustituyó a FID en marzo de 2024.

Herramientas en torno a PSI

• PageSpeed Insights (pagespeed.web.dev) — la herramienta en sí: campo (CrUX) + laboratorio (Lighthouse), Mobile y Desktop, cualquier URL pública.
• Google Lighthouse — el motor de laboratorio que ejecuta PSI. Ejecútelo en local desde Chrome DevTools (panel Lighthouse) o mediante la CLI para obtener la auditoría de laboratorio en su propio dispositivo/red (sin datos de campo).
• Google Search Console — informe Core Web Vitals — la otra vista basada en CrUX; agrupa URL similares e informa de los datos de campo de toda la propiedad.
• CrUX Vis / CrUX API / BigQuery — vaya directamente a los datos de campo que hay detrás de PSI para ver tendencias a lo largo del tiempo. (El antiguo CrUX Dashboard de Looker Studio quedó obsoleto a finales de noviembre de 2025 — las propias notas de lanzamiento de Google y su publicación específica sobre la retirada confirman la fecha y señalan CrUX Vis (cruxvis.withgoogle.com) como sustituto. Si una guía todavía le dice que use el Dashboard, está desactualizada.)
• PSI API — pruebe muchas URL de forma masiva y programática (url, strategy, category); la respuesta se divide en loadingExperience, originLoadingExperience y lighthouseResult. Google ha anunciado que planea dejar de incluir los datos de usuarios reales de CrUX en esta API y ahora recomienda la CrUX API o la CrUX History API específicas para una automatización duradera de datos de campo — no construya un proceso que dé por supuesto que los objetos de campo de la PSI API van a seguir existiendo a largo plazo.
• Ahrefs Site Audit y WebPageTest / DebugBear — más configuración y, en algunos casos, monitorización de usuarios reales más allá de una única ejecución de Lighthouse.

Errores con PageSpeed Insights que distorsionan las prioridades

• Tratar la puntuación de 0–100 como un factor de posicionamiento. La puntuación es una única ejecución de laboratorio de Lighthouse. La evaluación de Core Web Vitals relevante para el posicionamiento procede de los datos de campo de CrUX.
• Leer la reserva de origen como el rendimiento de la URL. Cuando una URL no tiene suficientes muestras, PSI puede mostrar datos a nivel de origen. Revise la etiqueta de alcance antes de afirmar que la página en sí aprobó o suspendió.
• Reaccionar a una única ejecución de laboratorio. La respuesta del servidor y el entorno sintético varían. Repita ejecuciones equiparables y use el rango o la mediana para distinguir la señal del ruido.
• Sumar los ahorros de las oportunidades. Las estimaciones de la auditoría se solapan y dan por supuesto que cada corrección ocurre de forma independiente. Tómelas como pistas orientativas, no como un total prometido.
• Esperar que un despliegue cambie los datos de campo de inmediato. CrUX es una vista móvil de 28 días. Use la sección de laboratorio para el diagnóstico inmediato y la de campo para confirmarlo con el tiempo.
• Comparar las puntuaciones de Mobile y Desktop como si las condiciones coincidieran. Evalúe cada perfil frente a sí mismo y frente a su audiencia en lugar de tratar los números como una sola escala.

PSI muestra “No data”

Síntoma: La sección de campo no tiene ningún resultado de CrUX, pero el informe de Lighthouse sí se ejecuta.

Causa probable: La URL y el origen no cumplen los requisitos de elegibilidad ni de volumen de muestras de CrUX, o la página es nueva o tiene poco tráfico.

Solución y confirmación: No fabrique una conclusión de campo. Use los diagnósticos de laboratorio para el trabajo inmediato, revise plantillas representativas con más tráfico y vuelva más adelante para ver si aparece un resultado de campo a nivel de URL o de origen.

PSI y Search Console no coinciden

Síntoma: Una URL parece correcta en PSI mientras su grupo en Search Console aparece como deficiente, o al contrario.

Causa probable: PSI puede mostrar datos a nivel de URL o de origen, mientras que Search Console agrupa URL similares. El dispositivo, el alcance y el momento de la ventana móvil también pueden diferir.

Solución y confirmación: Haga coincidir Mobile/Desktop, revise el alcance de los datos de PSI y muestree varias URL del grupo de Search Console antes de concluir que alguno de los dos informes está equivocado.

La puntuación de laboratorio oscila entre ejecuciones

Síntoma: Repetir PSI produce puntuaciones o valores de métricas notablemente distintos.

Causa probable: Una respuesta variable del servidor, una solicitud de terceros o el ruido normal de laboratorio de una sola ejecución cambiaron la traza.

Solución y confirmación: Ejecute la misma estrategia varias veces, compare las métricas individuales y las cascadas de solicitudes, e investigue un cuello de botella que se repita en lugar de solo la puntuación.

Una corrección se ve en Lighthouse pero no en los datos de campo

Síntoma: La métrica de laboratorio mejora de inmediato, mientras que la evaluación de Core Web Vitals de campo sigue igual.

Causa probable: CrUX sigue incluyendo visitas anteriores a la publicación en su ventana móvil de 28 días, o la corrección no ayudó a los usuarios y las plantillas representados en el conjunto de datos de campo.

Solución y confirmación: Verifique ahora el despliegue y la traza de laboratorio, anote la fecha de publicación y después observe la distribución de campo durante toda la ventana de informes.

Obtener un resultado de PSI desde la API

La API expone las secciones de campo y de laboratorio por separado. Indique su propia clave de API y su URL:

curl --get 'https://www.googleapis.com/pagespeedonline/v5/runPagespeed' \
  --data-urlencode "url=$TARGET_URL" \
  --data 'strategy=mobile' \
  --data-urlencode "key=$PSI_KEY" \
  --output psi.json

Conserve la respuesta sin procesar para que la fecha de la prueba, la estrategia y el alcance de los datos sigan siendo auditables.

Separar el alcance de campo de la puntuación de laboratorio

Con jq, extraiga la categoría de campo de la URL, la categoría de reserva de origen y la puntuación de Lighthouse en lugar de reducirlas a un solo número:

jq '{
  url_field: .loadingExperience.overall_category,
  origin_field: .originLoadingExperience.overall_category,
  lab_score: (.lighthouseResult.categories.performance.score * 100)
}' psi.json

Un valor de campo ausente no es un cero; significa que ese alcance no estaba disponible en la respuesta.

Repetir la ejecución de laboratorio sin ocultar las muestras

for run in 1 2 3; do
  curl --silent --get 'https://www.googleapis.com/pagespeedonline/v5/runPagespeed' \
    --data-urlencode "url=$TARGET_URL" \
    --data 'strategy=mobile' \
    --data-urlencode "key=$PSI_KEY" \
  | jq -r "[$run, (.lighthouseResult.categories.performance.score * 100)] | @tsv"
done

Informe de todas las muestras o de un resumen documentado; no seleccione solo la mejor puntuación.

Ponga a prueba sus conocimientos: PageSpeed Insights

Cinco preguntas rápidas sobre cómo leer PSI correctamente. Elija una respuesta para cada una y luego compruébelas.

Recursos que merecen su tiempo

Mis textos relacionados

• Google PageSpeed Insights: A Beginner-Friendly Guide — mi guía paso a paso en Ahrefs (nota: es anterior al cambio FID→INP).
• Core Web Vitals: A Complete Guide — campo frente a laboratorio y mi opinión sobre cuánto importan realmente las CWV.
• The Beginner’s Guide to Technical SEO — dónde encaja el rendimiento en el panorama general.

Oficial

• Uso de CrUX en PageSpeed Insights — la explicación de Chrome sobre la sección de campo.
• ¿Cuáles son las herramientas de Core Web Vitals? — cómo se relacionan PSI, Lighthouse, CrUX y Search Console.

De otros autores

• How To Use PageSpeed Insights — Matt Zeunert (DebugBear); mucha profundidad técnica sobre la puntuación y los diagnósticos.
• PageSpeed Insights: Google’s Highly Misunderstood Diagnostic Tool — Ryan Sullivan (SiteCare); buen desmontaje de mitos.
• Core Web Vitals Ranking Factor Is More Than A Tiebreaker — cobertura de Search Engine Journal de los comentarios de Gary Illyes que ponen en contexto el impacto de las CWV.
• Google Page Experience Update Is More Than A Tie Breaker — SE Roundtable; el reportaje de Barry Schwartz sobre cómo los representantes de Google han caracterizado la señal de page experience.

Estadísticas que merece la pena citar

• Casi nadie saca 100. Solo alrededor del 2 % de las páginas analizadas logra un 100 perfecto, y una puntuación de 50 ya la sitúa en el 25 % superior — un contexto útil para quien se alarme por un número por debajo de 90. Fuente
• Los datos de campo son una media móvil de 28 días. Una corrección puede tardar hasta ~28 días en reflejarse por completo en la Core Web Vitals Assessment — use los datos de laboratorio como retroalimentación rápida mientras tanto. Fuente
• El umbral “good” es el percentil 75. Google califica en p75 para que “a majority of visits experienced the target level of performance” (traducción) «la mayoría de las visitas experimentara el nivel de rendimiento objetivo» — lo que significa que, incluso con un LCP aprobado de 2,5s, una cuarta parte de los visitantes esperó más. Fuente

Registro de cambios