PageSpeed Insights (PSI)

TL;DR — PageSpeed Insights (PSI) é uma ferramenta gratuita de Google que evalúa uma página de dos formas distintas: como um experimentaron realmente os visitantes reais (dados de campo) e como salió uma única teste simulada (um puntuação de laboratorio de 0–100). O número de 0–100 é o que obsesiona um todo o mundo — e não é o que Google usa para posicionar. Assim que não se alarme por uma puntuação em rojo.

O que é PageSpeed Insights

PageSpeed Insights está em pagespeed.web.dev. É gratuito, não requiere iniciar sesión e funciona com qualquer URL pública — incluidas as de um competencia. Se pega uma URL e um ferramenta um teste tanto em Mobile como em Desktop (Mobile é um pestaña predeterminada e as puntuações de Mobile casi sempre são mas bajas).

As dos cosas que PSI lhe mostra

esta é um parte que confunde um todo o mundo, assim que o diré de forma sencilla. PSI mostra dos relatórios separados de um mesma página:

1. Dados de campo — o que experimentaron as personas reais. Provienen do Chrome UX Relatório (CrUX), ou seja, usuários reais de Chrome que visitaron seu página durante os últimos 28 dias. É um secção etiquetada como «Descubra o que estão experimentando seus usuários reais». Ahí é onde se obtiene um evaluação de Core Web Vitals: um simple Aprobada ou Reprobada.
2. Dados de laboratorio — uma única teste simulada. PSI também ejecuta Google Lighthouse uma vez, sobre um teléfono e uma red simulados, e retorna um puntuação Desempenho de 0–100 mas uma lista de correcções sugeridas.

O único que há que recordar

UM puntuação de 0–100 não é um fator de posicionamiento. Google posiciona em função de as Core Web Vitals (Métricas web esenciales) de campo — Largest Contentful Paint, Interaction para Next Paint e Cumulative Layout Shift, medidas em usuários reais. UM puntuação de laboratorio de 0–100 é um número distinto que procede de um sistema distinto. É possível sacar um 72 e aun assim superar as Core Web Vitals.

Algumas cosas mas que suelen despistar:

• UM puntuação altera sempre que se ejecuta. É uma única teste simulada, assim que o número oscila. Ejecútela varias veces e não lea nada em uma variação de 3–5 puntos.
• Não faz falta um 100. Casi nadie saca 100. O objetivo é superar as Core Web Vitals, não alcanzar um número perfecto.
• Uma buena puntuação não garantiza uma página rápida para os usuários reais, e uma puntuação “mala” não significa que os usuários reais estén sufriendo.

Sinceramente, salvo que seu site seja realmente lento, não é por aqui por onde eu empezaría. ¿Quiere o desglose completo — campo frente um laboratorio, os umbrales de p75, os mecanismos de reserva de dados e em o que se diferencia PSI de Lighthouse e de Pesquisa Console? Cambie um pestaña Avanzado.

TL;DR — PSI (pagespeed.web.dev) presenta dos análisis independientes de uma mesma URL: dados de campo do Chrome UX Relatório — usuários reais em uma ventana móvil de 28 dias, que determina um Core Web Vitals Assessment Passed/Failed em o percentil 75 — e dados de laboratorio, uma única ejecução de Lighthouse que da um puntuação Desempenho de 0–100 mas os diagnósticos. UM puntuação de 0–100 é um dado de laboratorio e não é um fator de posicionamiento; o posicionamiento usa as Core Web Vitals (Métricas web esenciales) de campo (LCP/INP/CLS). Os dados de campo precisam suficientes muestras de CrUX (um nível de URL, com reserva um nível de origen e, se não, “Não dados”). UM puntuação de laboratorio também varía entre ejecuções — ejecútela varias veces. PSI é um interfaz web; Lighthouse é o motor; o relatório de Pesquisa Console é outra vista mas de CrUX.

PSI são dos ferramentas sob um mesmo abrigo

O mas importante que há que entender sobre PageSpeed Insights é que não é um análisis, e sim dos, presentados em uma sola interfaz. web.dev o expresa com claridade: “PSI é um ferramenta que relatórios campo dados de CrUX e lab de Lighthouse para um fornecido página.” (traducção) «PSI é uma ferramenta que informa de os dados de campo de CrUX e de os de laboratorio de Lighthouse para uma página determinada.» Essas dos mitades provienen de sistemas distintos, miden cosas distintas e importan por razones distintas. Se se confunden, casi qualquer pergunta sobre PSI se vuelve confusa; se se mantienen separadas, todo encaja.

Dados de campo: o que experimentaron os usuários reais

UM secção superior — «Descubra o que estão experimentando seus usuários reais» — se alimenta do Chrome UX Relatório (CrUX). web.dev describe um CrUX API como algo que oferece “low-latency access para aggregated real-user experience dados em página e origin granularity” (traducção) «acceso de baja latencia um dados agregados de experiencia de usuários reais com granularidade de página e de origen» em forma de “28-dia rolling average.” (traducção) «media móvil de 28 dias». PSI se actualiza um diario; o conjunto de dados de CrUX em BigQuery se publica mensualmente.

Alguns mecanismos que importan:

• UM evaluação de Core Web Vitals se aprueba ou reprueba em p75. UM documentação de Chrome indica que o percentil deve quedar em um categoria «buena» em as tres Core Web Vitals para aprobar; de o contrario, um evaluação se mostra como reprobada. As tres são Largest Contentful Paint (bueno < 2,5s), Interaction para Next Paint (bueno < 200ms) e Cumulative Layout Shift (bueno < 0,1). PSI também mostra FCP e TTFB em «Otras métricas» — informativos, mas não forman parte do veredicto.
• Há uma única excepção documentada, e somente afecta um INP. Se uma página não tem suficientes muestras de CrUX para informar específicamente de INP, um guía real de PSI indica que ainda pode emitir um veredicto Pass/Fail um partir de alguns valores de p75 buenos de LCP e CLS por sí solos. Não existe uma excepção equivalente para LCP nem para CLS — se é um alguna de essas dos um que lhe faltan dados suficientes, não interprete como um aprobado; um falta de dados não é um aprobado automático documentado em nenhuma métrica salvo INP.
• p75 significa o percentil 75. O valor mostrado é um experiencia que o 75 % de as visualizações de página superó em rapidez. web.dev eligió o percentil 75 para que o número seja “resistant para outliers” (traducção) «resistente um valores atípicos» — um objetivo mas estricto que uma mediana.
• INP sustituyó um FID em marzo de 2024. Se consulta capturas antiguas ou guías antiguas (incluidos mis textos mas antiguos em Ahrefs sobre PageSpeed Insights e Core Web Vitals), podem seguir mostrando FID; um evaluação agora usa INP.
• Reserva URL → origen → “Não dados”. Se não há suficientes dados de CrUX para um URL concreta, PSI recurre um os dados um nível de origen (agregados de todo o site). Se não há nenhum dado de CrUX, verá “Não dados”, mas Lighthouse se ejecuta igualmente. Como señala web.dev, “CrUX dados é somente disponível quando sites meet certain eligibility criteria” (traducção) «os dados de CrUX somente estão disponíveis quando os sites cumplen ciertos criterios de elegibilidade» e “PSI é somente disponível para público URLs.” (traducção) «PSI somente está disponível para URL públicas». As páginas com poco tráfico e as páginas totalmente novas com frecuencia não têm dados de campo um nível de URL.

Lea um etiqueta de alcance antes de redactar um conclusión. O CrUX um nível de URL describe um mostra de campo elegible atribuida um essa URL. UM reserva um nível de origen é uma sinal útil de todo o site, mas por sí sola não pode diagnosticar um página probada. “Não dados” significa que um mostra de campo não está disponível ou é insuficiente, não que um página aprobara, suspendiera ou não recibiera tráfico. O resultado de Lighthouse que aparece mas abajo sí pode diagnosticar essa ejecução de laboratorio controlada, mas não cubre o hueco que dejan os dados de campo ausentes.

Dados de laboratorio: um puntuação de 0–100 de Lighthouse

UM secção inferior é uma única ejecução de Lighthouse em um dispositivo e uma red simulados, que produce um puntuação Desempenho e uma lista de oportunidades e diagnósticos. Os tramos de Google: “UM score de 90 ou above é considered good. 50 para 89 é um score que precisa improvement, e below 50 é considered poor.” (traducção) «Uma puntuação de 90 ou superior se considera buena. De 50 um 89 é uma puntuação que precisa melhorar, e por debajo de 50 se considera deficiente.»

O que conviene saber sobre um ejecução de laboratorio:

• É simulada, e um ejecução de Mobile é lenta um propósito. Mobile emula um teléfono de gama media com uma conexión limitada artificialmente; Desktop usa um perfil emulado mas rápido. por eso seu puntuação de Mobile casi sempre é mas baja que um de Desktop — e por eso os dados de campo de usuários reais um menudo se ven melhor de o que sugieren os diagnósticos de laboratorio.
• UM puntuação é variable. cada ejecução é uma auditoria nova de Lighthouse em o lado do servidor: um página, o centro de dados de Google, as condições de red e incluso um versión de Chrome/Lighthouse podem mover o número entre ejecuções. Recomiendo ejecutarla varias veces (3–5) e mirar o rango em vez de tomar qualquer ejecução concreta como palabra sagrada. Uma variação de alguns pocos puntos é ruido.
• Se va um comparar ejecuções, guarde algo mas que um puntuação. UM resposta de um API inclui uma marca de tempo, um URL solicitada e um final, o fator de forma, o entorno emulado, um versión de Lighthouse e qualquer advertencia — conserve todo eso junto um cada puntuação. Dos “72” não são comparables se uma se ejecutó com uma versión distinta de Lighthouse ou encontró uma redirecionamento que um outra não. Não promedie puntuações sem etiquetar; etiquételas ou não as compare.
• As versiones de Lighthouse avanzan de forma independiente de um PSI API. PSI se mantuvo em um versión v5 de um API, mas o motor de Lighthouse que há debajo sigue publicando novas versiones (um mas reciente indicada em as notas de lanzamiento de Google em o momento de esta revisión é Lighthouse 13.0, com fecha 2025-10-20) — os campos de auditoria, os pesos e os tramos podem alterar com um versión do motor embora o contrato de um API não cambie.
• Os “Estimated savings” não são aditivos. Os segundos que aparecem junto um cada diagnóstico dan por supuesto que essa correcção se aplica de forma aislada. Os problemas interactúan entre sí; as mejoras reais casi sempre são menores que um suma de as estimações individuales. Tómelos como orientação, não como um presupuesto que se pueda sumar.
• Os pesos de as métricas alteram com as versiones de Lighthouse. UM puntuação Desempenho é uma mezcla ponderada de métricas de laboratorio (as métricas de tempo de carregamento, Total Blocking Tempo e CLS são as que mas peso têm), mas os pesos exactos varían entre versiones de Lighthouse — consulte um calculadora de puntuação real em vez de confiar em um reparto fijo.

O mito que mas daño causa: “um puntuação é um fator de posicionamiento”

Não é. UM puntuação Desempenho de 0–100 é um número de laboratorio de Lighthouse, e não he encontrado nenhuma fuente oficial real de Google pesquisa que documente essa puntuação em sí como uma sinal de posicionamiento nem que vincule um alteração de puntuação com um alteração de posições. por outro lado, um documentação de página experience de Google apunta um as Core Web Vitals (Métricas web esenciales) de campo: dados de usuários reais basados em CrUX, o mesmo tipo de dados que mostra um secção de campo de PSI em p75. (Um matiz que conviene precisar: um visualização pública de dados de campo de PSI é uma superficie de relatórios com seus propias regras de elegibilidade e de reserva; Google não ha publicado o proceso interno exacto que alimenta o posicionamiento, assim que trate os “dados de campo” como o mesmo tipo de sinal em vez de dar por supuesta uma identidade exacta com o que PSI lhe mostra.) Uma página pode quedarse em 72 em laboratorio e aun assim superar um Core Web Vitals Assessment porque seus dados de usuários reais são buenos: números distintos de sistemas distintos. O mito derivado — “uma buena puntuação de laboratorio equivale um uma buena experiência do usuário real” — falla por um mesma razón: as condições de laboratorio não são as condições de seus visitantes. Quando campo e laboratorio divergen, os dados de campo são os mas relevantes para o SEO.

E incluso as Core Web Vitals de campo são uma sinal de posicionamiento bastante pequeña. Os propios empleados de Google lhes han quitado importancia: Gary Illyes ha descrito página experience como algo mas cercano um criterio de desempate que um uma sinal importante. Mi postura sincera não ha cambiado: não creo que as Core Web Vitals tengan muito impacto em o SEO e, salvo que um site seja extremadamente lento, por o general não priorizaré corregirlas por encima do conteúdo e os links. Corríjalas por os usuários e para o caso de uma lentitud real, não por pánico ante um número em rojo.

Como leer de verdad um relatório de PSI

1. Lea primeiro os dados de campo. ¿UM página obtuvo Passed ou Failed em um Core Web Vitals Assessment? Esse é o veredicto relevante para o SEO. Se dice “Não dados”, todavía não há suficiente tráfico em CrUX — se trabaja somente com dados de laboratorio.
2. Revise Mobile e Desktop por separado. Mobile é um opção predeterminada e normalmente um mas débil; também é um que mas importa, porque Google usa indexação mobile-first.
3. Depois use os diagnósticos de laboratorio para encontrar um causa. Os dados de laboratorio são seu ciclo rápido de retroalimentação para localizar e corregir o problema de fondo: recursos que bloquean o renderizado, imagens demasiado grandes, orígenes de alterações de diseño, tareas largas.
4. Corrija e depois espere. Os dados de campo são uma ventana móvil de 28 dias, assim que uma correcção que publique hoy pode tardar até 28 dias em reflejarse por completo em um Core Web Vitals Assessment. use os dados de laboratorio para confirmar um correcção de inmediato; use os dados de campo para confirmar que realmente movió um os usuários reais.
5. compare com um competencia. Como PSI funciona com qualquer URL pública, pode analizar as páginas de um competidor e comparar seus Core Web Vitals de campo com as suyas — um caso de uso que casi nenhuma guía menciona.

PSI frente um as ferramentas com as que se confunde

• PSI frente um Lighthouse. Lighthouse é o motor; PSI é uma interfaz web que ejecuta Lighthouse e, además, superpone os dados de campo de CrUX. Se ejecuta Lighthouse por seu conta (em Chrome DevTools ou desde um CLI) obtiene um auditoria de laboratorio, mas em seu equipo e seu red, sem dados de campo.
• PSI frente ao relatório Core Web Vitals de Pesquisa Console. Ambos se basan em CrUX, assim que ambos reflejan usuários reais. UM diferencia: Pesquisa Console agrupa URL similares e informa um escala de toda um propiedad, enquanto que PSI trabaja por URL (ou com um reserva um nível de origen). Se GSC e PSI parecen não coincidir, normalmente é cosa de um agrupação.
• PSI frente um Chrome DevTools / WebPageTest / DebugBear / Ahrefs site Auditoria. estas ferramentas oferecem mas configuração (dispositivos personalizados, ubicações, limitação artificial) e, em alguns casos, monitorização de usuários reais. O punto fuerte de PSI é ser gratuito, não requerir configuração e estar ligado ao próprio conjunto de dados de CrUX de Google.

UM PSI API (para testes masivas)

Não faz falta usar um interfaz web de uma URL em uma URL. UM PageSpeed Insights API (base https://www.googleapis.com/pagespeedonline/v5) retorna os mismos dados de forma programática. Parámetros clave: url (obligatorio), strategy (mobile ou desktop) e category (performance, accessibility, best-practices, seo). UM resposta se divide igual que um interfaz: loadingExperience (dados de campo um nível de URL), originLoadingExperience (dados de campo um nível de origen) e lighthouseResult (um auditoria de laboratorio). Assim é como se probaría um lote de URL de forma programada em vez de ir haciendo clic uma um uma.

Não construya uma automatização duradera de dados de campo sobre esta API. UM própria documentação de um API de Google abre agora com um aviso de que planea dejar de incluir os dados de usuários reais de CrUX em um PSI API, e remite um quienes automatizan um CrUX API ou um CrUX History API específicas. Siga usando um PSI API para um auditoria de laboratorio de Lighthouse — essa parte não se ve afectada —, mas se programa extracções masivas de dados de campo, desarrolle contra uma API específica de CrUX e não contra loadingExperience/originLoadingExperience em um resposta de PSI.

Onde encaja esto em o desempenho web

PSI é uma ferramenta de medição, não destino. As métricas que expone — Largest Contentful Paint, Interaction para Next Paint, Cumulative Layout Shift — são as Core Web Vitals (Métricas web esenciales), e o eje temático dedicado um elas (umbrales, o que significa cada uma e como mejorarlas) é o siguiente etapa. Lighthouse é o motor de laboratorio sobre o que se ejecuta PSI; CrUX (o Chrome UX Relatório) é um fuente de dados de campo que alimenta um parte superior de todo relatório de PSI. Entienda esses tres e PSI deja de ser uma caja misteriosa.

Resumen com IA

Uma versión condensada do conteúdo de Advanced:

• PSI = dos ferramentas em uma sola interfaz. Dados de campo do Chrome UX Relatório (usuários reais) e dados de laboratorio de uma única ejecução de Lighthouse, para um mesma URL, em pagespeed.web.dev. Gratuito, sem inicio de sesión, qualquer URL pública, Mobile + Desktop.
• Os dados de campo determinan um Core Web Vitals Assessment — Passed/Failed, em o percentil 75, sobre LCP (<2,5s), INP (<200ms) e CLS (<0,1). Ventana móvil de 28 dias, actualizada um diario. FCP e TTFB se mostram, mas não cuentan para o veredicto.
• Os dados de laboratorio são um puntuação Desempenho de 0–100 (90+ buena, 50–89 precisa melhorar, <50 deficiente) mas os diagnósticos. Mobile se ejecuta com limitação artificial e puntúa por debajo de Desktop.
• UM puntuação de 0–100 NÃO está documentada como fator de posicionamiento. Os sistemas de posicionamiento de Google usam as Core Web Vitals de campo (dados de usuários reais basados em CrUX: o mesmo tipo de dados que mostra um secção de campo de PSI, embora Google não ha publicado que o proceso interno exacto seja idéntico um visualização pública de PSI). Uma página pode sacar 72 e aun assim superar as CWV: números distintos de sistemas distintos.
• Reserva de CrUX: um nível de URL → um nível de origen → “Não dados” (Lighthouse se ejecuta igualmente). As páginas com poco tráfico e as novas um menudo não têm dados de campo um nível de URL.
• UM puntuação é variable entre ejecuções — ejecútela de 3 um 5 veces. Os “Estimated savings” não são aditivos. Não faz falta um 100.
• Lea primeiro os dados de campo (Passed/Failed) e depois use os diagnósticos de laboratorio para encontrar um causa; publique um correcção e espere até 28 dias um que os dados de campo o reflejen.
• PSI frente um Lighthouse (motor frente um interfaz + campo) e frente ao relatório de CWV de Pesquisa Console (também CrUX, mas agrupado um escala). Em conjunto, as CWV são uma sinal de posicionamiento menor.

Documentação oficial

Documentação de fuentes primarias de Google e de os equipos de Chrome / web.dev.

Google / PageSpeed Insights

• PageSpeed Insights ferramenta — um ferramenta em sí.
• PageSpeed Insights API — sobre — o que faz PSI, os dos tipos de dados e os tramos de um puntuação de 0–100.
• PSI API — runPagespeed reference — parámetros (url, strategy, category) e um estructura de um resposta.

Chrome UX Relatório (um fuente de os dados de campo)

• Uso de CrUX em PageSpeed Insights — como funciona um secção de campo e um evaluação aprobada/reprobada.
• Metodología de CrUX — elegibilidade, participação e o que páginas se incluem.
• CrUX API — um media móvil de 28 dias que alimenta os dados de campo de PSI.
• Descrição general de CrUX — como alimenta CrUX um sinal de experiencia de página para o posicionamiento.

web.dev / Core Web Vitals

• ¿Quais são as ferramentas de Core Web Vitals? — onde encaja PSI entre as ferramentas de CrUX/Lighthouse.
• Core Web Vitals — os umbrales de LCP/INP/CLS e um regra do percentil 75.
• Definição de os umbrales de Core Web Vitals — por o que p75.
• Core Web Vitals e um Pesquisa de Google — o contexto de um sinal de posicionamiento.

Citas de um fuente

Declarações textuales, cada uma enlazada ao pasagem em um página de origen.

Google / Chrome / web.dev — como funciona PSI

• “PSI é um ferramenta que relatórios campo dados de CrUX e lab de Lighthouse para um fornecido página.” (traducção) «PSI é uma ferramenta que informa de os dados de campo de CrUX e de os de laboratorio de Lighthouse para uma página determinada.» — web.dev. “PSI is a tool that reports field data from CrUX”
  (tradução) «o PSI é uma ferramenta que apresenta dados de campo do CrUX»
  Ir um cita
• “PSI é somente disponível para público URLs. Isso cannot ser usado em development sites que não são publicly accessible.” (traducção) «PSI somente está disponível para URL públicas. Não é possível usar em sites de desarrollo que não sejam accesibles públicamente.» — web.dev. “PSI is only available for public URLs”
  (tradução) «o PSI está disponível somente para URLs públicos»
  Ir um cita
• UM secção de campo se describe como “Discover o que seu real usuários são experiencing.” (traducção) «Descubra o que estão experimentando seus usuários reais.» — Chrome para desarrolladores, CrUX em PSI. “Discover what your real users are experiencing”
  (tradução) «descubra o que seus usuários reais estão vivenciando»
  Ir um cita
• “para pass, o percentile deve ser categorized as ‘good’ em todos three Core Web Vitals. Otherwise, o assessment appears as ‘failed’.” (traducção) «para aprobar, o percentil deve estar categorizado como ‘good’ em as tres Core Web Vitals. De o contrario, um evaluação aparece como ‘failed’.» — Chrome para desarrolladores, CrUX em PSI. Ir um cita
• UM CrUX API oferece “low-latency access para aggregated real-user experience dados em página e origin granularity” em forma de “28-dia rolling average.” (traducção) «acceso de baja latencia um dados agregados de experiencia de usuários reais com granularidade de página e de origen» em forma de «media móvil de 28 dias». — Chrome para desarrolladores, API de CrUX. “28-day rolling average”
  (tradução) «média móvel de 28 dias»
  Ir um cita

web.dev — umbrales

• “um good threshold para meça é o 75th percentile de página loads, segmented across mobile e desktop devices.” (traducção) «um buen umbral que medir é o percentil 75 de as cargas de página, segmentado entre dispositivos móviles e de escritorio.» — web.dev, Core Web Vitals. Ir um cita
• “se pelo menos 75 percent de página views para um site meet o ‘good’ threshold, o site é classified as having ‘good’ desempenho.” (traducção) «se ao menos o 75 por ciento de as visualizações de página de um site alcanzan o umbral ‘good’, o site se clasifica como de desempenho ‘good’.» — web.dev, definição de os umbrales. “75 percent of page views”
  (tradução) «75% das visualizações de página»
  Ir um cita

Do sector — um distinção entre puntuação e posicionamiento (transmitido, não de Google)

• “O Desempenho score em PageSpeed Insights faz não impact SEO diretamente. contudo, o real-user Core Web Vitals assessment faz impact Google rankings.” (traducção) «UM puntuação Desempenho de PageSpeed Insights não afecta diretamente ao SEO. Não entanto, um evaluação de Core Web Vitals com usuários reais sí afecta um as posições em Google.» — Matt Zeunert, DebugBear. Fuente
• “Core Web Vitals são somente métricas Google explicitly usa para grading.” (traducção) «As Core Web Vitals são as únicas métricas que Google usa explícitamente para calificar.» E “Running o mesmo URL just minutes apart pode yield diferente scores.” (traducção) «Ejecutar um mesma URL com somente alguns minutos de diferencia pode dar puntuações distintas.» — Ryan Sullivan, SiteCare. Fuente

Hoja de referencia rápida do relatório de PSI

cada secção de PSI: campo frente um laboratorio, e o que significa

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

Tramos de um puntuação de Lighthouse (laboratorio)

• 90–100 — buena · 50–89 — precisa melhorar · <50 — deficiente

Reserva de dados de campo

• CrUX um nível de URL → se não há suficientes, um nível de origen → se não há ninguno, “Não dados” (Lighthouse se ejecuta igualmente).

Dados rápidos

• Dados de campo = 28 dias móviles, actualizados um diario → uma correcção pode tardar até 28 dias em verse.
• UM puntuação de 0–100 é variable — ejecútela de 3 um 5 veces e ignore uma variação de 3–5 puntos.
• Os “Estimated savings” não se suman — dan por supuesto que cada correcção se aplica sola.
• Mobile é um pestaña predeterminada e normalmente puntúa por debajo de Desktop.
• INP sustituyó um FID em marzo de 2024.

Ferramentas em torno um PSI

• PageSpeed Insights (pagespeed.web.dev) — um ferramenta em sí: campo (CrUX) + laboratorio (Lighthouse), Mobile e Desktop, qualquer URL pública.
• Google Lighthouse — o motor de laboratorio que ejecuta PSI. Ejecútelo em local desde Chrome DevTools (panel Lighthouse) ou mediante um CLI para obtener um auditoria de laboratorio em seu próprio dispositivo/red (sem dados de campo).
• Google pesquisa Console — relatório Core Web Vitals — um outra vista basada em CrUX; agrupa URL similares e informa de os dados de campo de toda um propiedad.
• CrUX Vis / CrUX API / BigQuery — vaya diretamente um os dados de campo que há detrás de PSI para ver tendencias um o largo do tempo. (O antigo CrUX Dashboard de Looker Studio quedó obsoleto um finales de noviembre de 2025 — as propias notas de lanzamiento de Google e seu publicação específica sobre um retirada confirman um fecha e señalan CrUX Vis (cruxvis.withgoogle.com) como sustituto. Se uma guía todavía lhe dice que use o Dashboard, está desactualizada.)
• PSI API — pruebe muitas URL de forma masiva e programática (url, strategy, category); um resposta se divide em loadingExperience, originLoadingExperience e lighthouseResult. Google ha anunciado que planea dejar de incluir os dados de usuários reais de CrUX em esta API e agora recomienda um CrUX API ou um CrUX History API específicas para uma automatização duradera de dados de campo — não construya um proceso que dé por supuesto que os objetos de campo de um PSI API van um seguir existiendo um largo plazo.
• Ahrefs site Auditoria e WebPageTest / DebugBear — mas configuração e, em alguns casos, monitorização de usuários reais mas allá de uma única ejecução de Lighthouse.

Errores com PageSpeed Insights que distorsionan as prioridades

• Tratar um puntuação de 0–100 como um fator de posicionamiento. UM puntuação é uma única ejecução de laboratorio de Lighthouse. UM evaluação de Core Web Vitals relevante para o posicionamiento procede de os dados de campo de CrUX.
• Leer um reserva de origen como o desempenho de um URL. Quando uma URL não tem suficientes muestras, PSI pode mostrar dados um nível de origen. Revise um etiqueta de alcance antes de afirmar que um página em sí aprobó ou suspendió.
• Reaccionar um uma única ejecução de laboratorio. UM resposta do servidor e o entorno sintético varían. Repita ejecuções equiparables e use o rango ou um mediana para distinguir um sinal do ruido.
• Sumar os ahorros de as oportunidades. As estimações de um auditoria se solapan e dan por supuesto que cada correcção ocurre de forma independiente. Tómelas como pistas orientativas, não como um total prometido.
• Esperar que um despliegue cambie os dados de campo de inmediato. CrUX é uma vista móvil de 28 dias. use um secção de laboratorio para o diagnóstico inmediato e um de campo para confirmarlo com o tempo.
• Comparar as puntuações de Mobile e Desktop como se as condições coincidieran. Evalúe cada perfil frente um sí mesmo e frente um seu audiencia em lugar de tratar os números como uma sola escala.

PSI mostra “Não dados”

Síntoma: UM secção de campo não tem nenhum resultado de CrUX, mas o relatório de Lighthouse sí se ejecuta.

Causa probable: UM URL e o origen não cumplen os requisitos de elegibilidade nem de volumen de muestras de CrUX, ou um página é nova ou tem poco tráfico.

Solução e confirmação: Não fabrique uma conclusión de campo. use os diagnósticos de laboratorio para o trabajo inmediato, revise plantillas representativas com mas tráfico e vuelva mas adelante para ver se aparece um resultado de campo um nível de URL ou de origen.

PSI e Pesquisa Console não coinciden

Síntoma: Uma URL parece correcta em PSI enquanto seu grupo em Pesquisa Console aparece como deficiente, ou ao contrario.

Causa probable: PSI pode mostrar dados um nível de URL ou de origen, enquanto que Pesquisa Console agrupa URL similares. O dispositivo, o alcance e o momento de um ventana móvil também podem diferir.

Solução e confirmação: Haga coincidir Mobile/Desktop, revise o alcance de os dados de PSI e muestree varias URL do grupo de Pesquisa Console antes de concluir que alguno de os dos relatórios está equivocado.

UM puntuação de laboratorio oscila entre ejecuções

Síntoma: Repetir PSI produce puntuações ou valores de métricas notablemente distintos.

Causa probable: Uma resposta variable do servidor, uma solicitação de terceros ou o ruido normal de laboratorio de uma sola ejecução cambiaron um traza.

Solução e confirmação: Ejecute um mesma estrategia varias veces, compare as métricas individuales e as cascadas de solicitações, e investigue um cuello de botella que se repita em vez de somente um puntuação.

Uma correcção se ve em Lighthouse mas não em os dados de campo

Síntoma: UM métrica de laboratorio melhora de inmediato, enquanto que um evaluação de Core Web Vitals de campo sigue igual.

Causa probable: CrUX sigue incluyendo visitas anteriores um publicação em seu ventana móvil de 28 dias, ou um correcção não ayudó um os usuários e as plantillas representados em o conjunto de dados de campo.

Solução e confirmação: Verifique agora o despliegue e um traza de laboratorio, anote um fecha de publicação e depois observe um distribuição de campo durante toda um ventana de relatórios.

Obtener um resultado de PSI desde um API

UM API expone as secções de campo e de laboratorio por separado. Indique seu própria clave de API e seu 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 um resposta sem procesar para que um fecha de um teste, um estrategia e o alcance de os dados sigan siendo auditables.

Separar o alcance de campo de um puntuação de laboratorio

Com jq, extraiga um categoria de campo de um URL, um categoria de reserva de origen e um puntuação de Lighthouse em vez de reducirlas um somente número:

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

Um valor de campo ausente não é um cero; significa que esse alcance não estava disponível em um resposta.

Repetir um ejecução de laboratorio sem ocultar as 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

Relatório de todas as muestras ou de um resumen documentado; não seleccione somente um melhor puntuação.

Ponga um teste seus conocimientos: PageSpeed Insights

Cinco perguntas rápidas sobre como leer PSI correctamente. Elija uma resposta para cada uma e depois compruébelas.

Recursos que merecen seu tempo

Mis textos relacionados

• Google PageSpeed Insights: UM Beginner-Friendly Guide — mi guía etapa um etapa em Ahrefs (nota: é anterior ao alteração FID→INP).
• Core Web Vitals: UM Completo Guide — campo frente um laboratorio e mi opinión sobre quanto importan realmente as CWV.
• O Beginner’s Guide para técnico SEO — onde encaja o desempenho em o panorama general.

Oficial

• Uso de CrUX em PageSpeed Insights — um explicação de Chrome sobre um secção de campo.
• ¿Quais são as ferramentas de Core Web Vitals? — como se relacionan PSI, Lighthouse, CrUX e Pesquisa Console.

De otros autores

• Como use PageSpeed Insights — Matt Zeunert (DebugBear); muita profundidade técnica sobre um puntuação e os diagnósticos.
• PageSpeed Insights: Google’s Highly Misunderstood Diagnostic Ferramenta — Ryan Sullivan (SiteCare); buen desmontagem de mitos.
• Core Web Vitals Classificação Fator É mas Than UM Tiebreaker — cobertura de Mecanismo de busca Journal de os comentarios de Gary Illyes que ponen em contexto o impacto de as CWV.
• Google página Experience Update É mas Than UM Tie Breaker — SE Roundtable; o reportagem de Barry Schwartz sobre como os representantes de Google han caracterizado um sinal de página experience.

Estadísticas que merece um pena citar

• Casi nadie saca 100. Somente alrededor do 2 % de as páginas analizadas logra um 100 perfecto, e uma puntuação de 50 já um sitúa em o 25 % superior — um contexto útil para quien se alarme por um número por debajo de 90. Fuente
• Os dados de campo são uma media móvil de 28 dias. Uma correcção pode tardar até ~28 dias em reflejarse por completo em um Core Web Vitals Assessment — use os dados de laboratorio como retroalimentação rápida enquanto tanto. Fuente
• O umbral “good” é o percentil 75. Google califica em p75 para que “um majority de visits experienced o target nível de desempenho” (traducção) «um mayoría de as visitas experimentara o nível de desempenho objetivo» — o que significa que, incluso com um LCP aprobado de 2,5s, uma cuarta parte de os visitantes esperó mas. Fuente

Registro de alterações