Un punteggio basso in PageSpeed Insights non significa automaticamente che il tuo sito sia “lento” per tutti gli utenti. Prima di intervenire bisogna distinguere dati reali, test di laboratorio e percezione effettiva durante la navigazione.

La domanda utile non è “quanto fa il sito su PageSpeed?”, ma quale problema stanno vivendo gli utenti e da cosa dipende.

PageSpeed Insights mostra due tipi di dati

Quando disponibili, PageSpeed Insights mostra i dati reali raccolti dal Chrome User Experience Report (CrUX). Sono i cosiddetti field data: raccontano come utenti reali hanno vissuto quella pagina o quel sito.

Accanto a questi trovi i lab data, ottenuti da una simulazione Lighthouse. Sono molto utili per diagnosticare problemi tecnici, ma rappresentano una singola esecuzione in condizioni controllate.

Per questo può capitare che il test Lighthouse sia rosso mentre i dati reali siano buoni, oppure il contrario.

Le metriche da guardare oggi

I Core Web Vitals attuali sono:

• LCP: quanto velocemente compare il contenuto principale;
• INP: quanto rapidamente la pagina risponde alle interazioni;
• CLS: quanto il layout resta stabile durante il caricamento.

FID non è più un Core Web Vital: dal 2024 è stato sostituito da INP. Ho raccolto metriche, soglie e interventi nella guida aggiornata ai Core Web Vitals.

Quando un sito è davvero lento?

Più che fissarsi su un numero unico, cerca segnali concreti:

• il contenuto principale compare tardi;
• bottoni e menu reagiscono con ritardo;
• il layout si sposta mentre l’utente sta leggendo o cliccando;
• il server impiega troppo a iniziare a rispondere;
• la navigazione peggiora sensibilmente da mobile;
• alcune pagine sono molto più lente di altre.

Non ottimizzare tutto allo stesso modo

Problemi diversi richiedono interventi diversi.

• LCP alto: controlla immagine hero, TTFB, CSS bloccante, font e risorse critiche.
• INP alto: guarda JavaScript, widget pesanti, script di terze parti e task lunghi.
• CLS alto: verifica dimensioni delle immagini, font, banner e contenuti inseriti dopo il caricamento.
• TTFB alto: analizza hosting, database, PHP, cache server e query lente.

Strumenti utili

• PageSpeed Insights per field data e Lighthouse;
• WebPageTest per waterfall e confronti;
• GTmetrix per una seconda analisi tecnica;
• Chrome DevTools per Performance, Network e layout shift;
• Query Monitor su WordPress per query, hook e richieste lente lato applicazione.

Attenzione agli “errori” che non sono necessariamente la priorità

Un audit automatico può segnalare decine di opportunità. Non tutte hanno lo stesso impatto reale.

Prima di installare un plugin, eliminare una funzionalità o riscrivere il frontend, chiediti quanto quella voce incide sulla metrica problematica e sull’esperienza reale. Ottimizzare significa ridurre il collo di bottiglia principale, non inseguire ogni warning.

Come partire su WordPress

Su WordPress controllerei nell’ordine:

• hosting e tempo di risposta del server;
• immagini principali;
• plugin e addon realmente usati;
• CSS e JavaScript caricati nella pagina;
• font e script di terze parti;
• cache e CDN;
• database e query lente.

Per gli interventi pratici puoi leggere anche come velocizzare WordPress senza plugin inutili.

Conclusione

La performance non è un voto da inseguire, ma un problema da diagnosticare. Parti dai dati reali quando esistono, usa i test di laboratorio per capire la causa e intervieni sulla metrica che sta davvero peggiorando l’esperienza.

Se vuoi un’analisi tecnica del sito puoi vedere il servizio di performance e ottimizzazione WordPress oppure contattarmi.