performance

PageSpeed Insights non disponibile

Avviso informativo quando Google PageSpeed Insights non ha restituito dati. Ogni altro controllo di performance dipende da PSI — se va al buio, anche loro.

Cosa verifica questo controllo

Segnala gli audit dove l’API di PageSpeed Insights ha restituito un errore o un payload vuoto invece di un’esecuzione Lighthouse. È un controllo informativo, non pass/fail.

Quando PSI non è disponibile, ogni metrica di performance a valle — punteggio Lighthouse, LCP, INP, CLS, tempo di risposta server — non ha dati su cui calcolarsi e viene saltata.

Perché è importante

La performance è la metà dell’audit che mappa direttamente all’esperienza utente e al posizionamento Core Web Vitals. Se PSI non riesce a caricare la tua pagina, l’audit va al buio sull’intero modulo Performance. Peggio, la causa è di solito qualcosa che colpisce anche il crawler di Google — quindi lo stesso fallimento che ha bloccato PSI probabilmente sta danneggiando indicizzazione, crawler AI e utenti reali.

Tratta questo avviso come l’apertura di una checklist, non come un singhiozzo API una tantum.

Come sistemarlo

Esegui la checklist diagnostica in ordine. La prima corrispondenza è di solito la causa.

1. Riproduci a mano.

Apri pagespeed.web.dev, incolla l’URL esatto che MetricSpot ha auditato e lancialo. Tre esiti:

  • PSI funziona nel browser. Probabile timeout o rate limit transitorio. Riprova l’audit MetricSpot dopo 30 minuti.
  • PSI mostra lo stesso errore. L’infrastruttura di Google non riesce a caricare la pagina. Prosegui nella checklist.
  • PSI restituisce un URL diverso (dopo i redirect). Il tuo canonical potrebbe stare in un loop o atterrare su un 404. Vedi causa #2.

2. Controlla robots.txt per blocchi.

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

PSI si identifica come Chrome-Lighthouse. Se il tuo robots.txt lo blocca (o blocca * dal percorso auditato), PSI fallisce in silenzio. Vedi il controllo file robots.txt per la configurazione sicura.

3. Controlla loop o catene di redirect.

curl -sIL https://tuodominio.com/page | grep -E "^HTTP|^location:"

PSI segue al massimo qualche redirect prima di arrendersi. Colpevoli comuni: catene HTTP→HTTPS→www→non-www, redirect di locale che rimbalzano all’infinito, redirect di marketing verso /landing/$utm_source. Risolvi con i controlli catene di redirect e redirect HTTP a HTTPS.

4. Controlla auth wall e geo-block IP.

PSI gira dai data center di Google. Se la pagina richiede login, sta dietro un bot challenge di Cloudflare, è geo-ristretta a un paese o il tuo WAF rate-limita gli IP di Google, PSI prende un 401/403/429 e fallisce.

curl -sI -H "User-Agent: Chrome-Lighthouse" https://tuodominio.com/page

Un 200 qui significa che lo user-agent PSI passa. Un 403 o un header cf-mitigated: challenge è il tuo colpevole.

5. Controlla status di risposta e timeout.

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

PSI considera qualunque non-2xx un fallimento. I timeout server sopra i ~30 secondi falliscono anch’essi. Se la pagina è lenta al primo byte, sistema il tempo di risposta server prima di riprovare.

6. Quando riprovare vs investigare.

Riprova una volta dopo 30 minuti se:

  • PSI funziona nel browser per lo stesso URL.
  • curl -I restituisce 200 con lo user-agent Lighthouse.
  • Nessun cambio recente a robots.txt, regole WAF o DNS.

Investiga subito se:

  • PSI fallisce per lo stesso URL anche nel browser.
  • curl -I restituisce 4xx/5xx per Chrome-Lighthouse.
  • Il fallimento persiste su più audit.

Domande frequenti

Perché PSI fallisce a intermittenza su pagine che di solito funzionano?

L’API pubblica PSI ha un rate limit per IP (circa 25.000 query al giorno con una API key, molte meno senza). Traffico di audit a raffiche — il tuo più quello di altri strumenti che condividono lo stesso IP di uscita — può esaurire la quota per breve tempo. Un singolo retry 15–30 minuti dopo quasi sempre passa.

PSI non disponibile danneggia il mio posizionamento?

L’indisponibilità di PSI in sé no. Ma le cause — blocco da robots.txt, loop di redirect, auth wall, geo-block, TTFB lenti — di solito sì, perché Googlebot sbatte sullo stesso muro. Tratta l’avviso come “forse Google non riesce neanche a renderizzare questa pagina” e controlla tempo di risposta server, HTTPS e i risultati di robots.txt prima di qualunque altra cosa.

Posso avere dati di performance senza PSI?

Per una singola pagina, lancia Lighthouse direttamente nei Chrome DevTools — bypassa del tutto l’API. Per il monitoring continuo, il Chrome User Experience Report (CrUX) espone dati di campo reali via BigQuery e API CrUX anche quando i lab run PSI falliscono. MetricSpot oggi consuma solo PSI, quindi l’audit salta lo stesso quelle metriche; il dato esiste, ma non in questo report.

Fonti

Ultimo aggiornamento 2026-05-11