PageSpeed Insights no disponible

Què comprova aquesta auditoria

Marca les auditories on l’API de PageSpeed Insights ha retornat un error o un payload buit en comptes d’una execució de Lighthouse. Aquesta és una comprovació informativa, no un passa/falla.

Quan PSI no està disponible, totes les mètriques de rendiment downstream, puntuació de Lighthouse, LCP, INP, CLS, temps de resposta del servidor, no tenen dades per puntuar i es salten.

Per què importa

El rendiment és la meitat d’una auditoria que mapeja directament a l’experiència d’usuari i al posicionament per Core Web Vitals. Si PSI no pot carregar la teva pàgina, l’auditoria s’apaga a tot el mòdul de Rendiment. Pitjor encara: la causa sol ser una cosa amb què el mateix crawler de Google també topa, vol dir que la mateixa fallada que ha bloquejat PSI probablement està perjudicant la indexació, els rastrejadors d’IA i els usuaris reals.

Tracta aquest avís com el principi d’una checklist, no com un hipo puntual de l’API.

Com solucionar-ho

Repassa la checklist de diagnòstic per ordre. La primera coincidència sol ser la causa.

1. Reprodueix-ho manualment.

Obre pagespeed.web.dev, enganxa la URL exacta que ha auditat MetricSpot i executa-ho. Tres resultats possibles:

PSI funciona al navegador. Probablement un timeout transitori o un límit de ràtio. Reintenta l’auditoria a MetricSpot en 30 minuts.
PSI mostra el mateix error. La mateixa infraestructura de Google tampoc pot carregar la pàgina. Continua per la checklist.
PSI retorna una URL diferent (després de redireccions). El teu canonical podria estar redirigint en bucle o cap a un 404. Mira la causa #2.

2. Comprova robots.txt per veure si bloqueja.

curl -sI https://elteudomini.com/robots.txt
curl -s https://elteudomini.com/robots.txt | grep -i -E "user-agent|disallow"

PSI s’identifica com a Chrome-Lighthouse. Si el teu robots.txt el bloqueja (o bloqueja * del camí auditat), PSI falla silenciosament. Mira la comprovació de robots.txt per a la configuració segura.

3. Comprova si hi ha bucles o cadenes de redireccions.

curl -sIL https://elteudomini.com/pagina | grep -E "^HTTP|^location:"

PSI segueix com a màxim unes poques redireccions abans de rendir-se. Ofensors habituals: cadenes HTTP→HTTPS→www→no-www, redireccions de locale que reboten indefinidament, redireccions de pàgines de marketing cap a /landing/$utm_source. Arregla-ho amb les comprovacions de cadenes de redireccions i redirigir HTTP a HTTPS.

4. Comprova si hi ha murs d’autenticació i geo-blocs per IP.

PSI s’executa des dels datacenters de Google. Si la teva pàgina requereix login, està darrere un challenge de bots de Cloudflare, està geo-restringida a un país, o el teu WAF limita la ràtio d’IPs de Google, PSI rep un 401/403/429 i falla.

curl -sI -H "User-Agent: Chrome-Lighthouse" https://elteudomini.com/pagina

Un 200 aquí vol dir que el user-agent de PSI passa. Un 403 o una capçalera cf-mitigated: challenge és el teu culpable.

5. Comprova l’estat de la resposta i el timeout.

curl -sI -o /dev/null -w "%{http_code} %{time_total}s\n" https://elteudomini.com/pagina

PSI considera qualsevol cosa que no sigui 2xx com a fallada. Els timeouts del servidor per sobre de ~30 segons també fallen. Si la pàgina és lenta al primer byte, arregla el problema de temps de resposta del servidor abans de reintentar.

6. Quan reintentar vs investigar.

Reintenta una vegada al cap de 30 minuts si:

PSI funciona al navegador per a la mateixa URL.
curl -I retorna 200 amb el user-agent de Lighthouse.
No hi ha canvis recents al robots.txt, regles de WAF o DNS.

Investiga immediatament si:

PSI falla per a la mateixa URL al navegador.
curl -I retorna 4xx/5xx per a Chrome-Lighthouse.
La fallada persisteix a múltiples auditories.

Preguntes freqüents

Per què PSI falla intermitentment a pàgines que normalment funcionen?

L’API pública de PSI té un límit de ràtio per IP (al voltant de 25.000 consultes diàries amb una clau d’API, molt menys sense autenticar). El tràfic d’auditories amb pics, el teu més el d’altres eines compartint la mateixa IP de sortida, pot esgotar breument la quota. Reintents 15–30 minuts més tard gairebé sempre funcionen.

Que PSI no estigui disponible perjudica el meu posicionament?

La indisponibilitat de PSI per ella mateixa, no. Però les causes (bloqueig per robots.txt, bucles de redirecció, murs d’autenticació, geo-blocs, TTFB lent) sí que ho fan, perquè Googlebot topa amb la mateixa paret. Tracta l’avís com a “Google potser tampoc pot renderitzar aquesta pàgina” i comprova el temps de resposta del servidor, l’HTTPS i les troballes de robots.txt abans que res.

Puc obtenir dades de rendiment sense PSI?

Per a una sola pàgina, executa Lighthouse directament a Chrome DevTools: salta l’API completament. Per a monitorització contínua, el Chrome User Experience Report (CrUX) exposa dades de camp d’usuaris reals via BigQuery i l’API de CrUX, fins i tot quan les execucions de laboratori de PSI fallen. MetricSpot només consumeix PSI avui, així que l’auditoria continua saltant aquestes mètriques; les dades existeixen, però no en aquest informe.