Se hai cercato «valutazione Core Web Vitals non superata» dopo aver visto un punteggio di velocità verde, inizia verificando a quali dati si riferisce ciascun risultato. PageSpeed Insights (PSI) combina dati di visite reali e un test controllato separato. Annota indirizzo, dispositivo, ambito dei dati e metrica problematica prima di acquistare uno strumento o chiedere di rifare il sito.
Partiamo da questo registro perché «portare il punteggio sul verde» lascia troppe questioni aperte. Lo sviluppatore deve sapere quale esperienza richiede attenzione e quali prove permetteranno di considerare utile l’intervento.
Valutazione Core Web Vitals non superata: cosa ha misurato il report?
La valutazione descrive esperienze registrate dei visitatori, mentre la sezione Lighthouse esegue un test diagnostico. La documentazione Google di PageSpeed Insights spiega che i dati sul campo provengono dal Chrome User Experience Report, o CrUX, e coprono un periodo mobile di raccolta di 28 giorni. Un nuovo test diagnostico e quei dati storici possono quindi dare risultati diversi.
Le condizioni del test sono diverse. Un’esecuzione controllata non può coprire tutti i dispositivi, le connessioni e le azioni delle visite reali. Usala per indagare una possibile causa; affiancale i dati dei visitatori quando decidi cosa resta da risolvere.
Il risultato può riguardare un ambito più ampio. Se i dati della pagina esatta sono troppo pochi, PSI può ripiegare sull’origine: in termini generali, l’indirizzo del sito comprensivo di protocollo e nome host. Il risultato dell’origine riunisce visite a pagine diverse. Leggi l’ambito indicato prima di considerarlo una prova su una specifica pagina di prodotto o servizio.
Il periodo comprende visite precedenti. Una modifica di oggi non riscrive le osservazioni di ieri. Conserva la data di rilascio per distinguere il controllo immediato dell’intervento dai dati successivi sui visitatori.
Queste differenze assegnano ai report compiti distinti: i dati dei visitatori individuano un’esperienza da indagare; un test controllato aiuta a riprodurla ed esaminarla.
Quale metrica richiede attenzione?
Esamina LCP, INP e CLS separatamente prima di scegliere l’intervento. La guida Google ai Web Vitals distingue caricamento, reattività e stabilità visiva. La tabella riporta le soglie per il giudizio Buono indicate dalla guida, valutate al 75° percentile per la popolazione relativa al dispositivo. La guida Google alle soglie spiega il 75° percentile: almeno il 75% delle visualizzazioni di pagina misurate deve rispettare la soglia Buono per quella metrica. È diverso da una media o dal punteggio complessivo di Lighthouse.
| Metrica | Cosa descrive | Soglia Buono | Cosa chiedere a chi gestisce il sito |
|---|---|---|---|
| LCP, Largest Contentful Paint | Quando appare il più grande elemento di contenuto visibile | Al massimo 2,5 secondi | Quale elemento arriva in ritardo, e in quale fase del caricamento? |
| INP, Interaction to Next Paint | Quanto prontamente la pagina risponde alle interazioni | Al massimo 200 millisecondi | Quale tocco, clic o pressione di un tasto risulta lento nelle condizioni interessate? |
| CLS, Cumulative Layout Shift | Spostamenti imprevisti del layout | Al massimo 0,1 | Quale elemento si sposta, e quando durante la visita? |
Quando tutte queste metriche hanno dati sufficienti, per superare la valutazione PSI richiede che i loro valori al 75° percentile siano buoni. Se i dati INP sono insufficienti, LCP e CLS buoni possono comunque consentire di superarla. Se sono insufficienti i dati LCP o CLS, PSI non può valutare quella pagina o quell’origine.
Considera i dati mancanti un’incertezza. La metodologia CrUX di Google richiede visite idonee e una popolarità sufficiente; non pubblica un numero minimo universale di visitatori. Un risultato assente non indica che nessuno visiti il sito, che l’esperienza sia buona o che un intervento sia fallito.
Cosa puoi verificare prima di pagare il lavoro?
Salva un report di riferimento e segui lo stesso percorso del cliente su uno smartphone prima di scegliere uno strumento. Ti serve una descrizione chiara del problema: la pagina, i dati alla base dell’avviso e il comportamento che riesci a riprodurre. Se non riesci a riprodurlo, annota questo limite anziché colmare la lacuna con un’ipotesi.
- Apri in PSI la pagina esatta rilevante per l’attività. Conserva indirizzo e data del report. Includi la pagina di destinazione o il modello di pagina che conta per la richiesta o l’acquisto che stai esaminando.
- Annota la scelta mobile o desktop e l’ambito dei dati. Riporta se la sezione dei dati sul campo rappresenta l’URL, l’origine o dati insufficienti. Mantieni la stessa selezione per i confronti successivi.
- Indica la metrica che richiede attenzione. Usa i singoli risultati Core Web Vitals, poi cerca indizi nella sezione diagnostica. Lascia visibili i campioni mancanti.
- Esegui un’attività reale sullo smartphone. Apri il menu, usa il filtro pertinente o compila il modulo interessato. Annota cosa si carica in ritardo, risponde lentamente o si sposta in modo imprevisto.
- Collega un indizio a un test. Chiedi a chi gestisce il sito di riprodurre l’azione interessata o il ritardo di caricamento e di spiegare cosa può dimostrare il test.
Per controlli più ampi su immagini, widget, cache e hosting, usa la nostra guida alle cause comuni di un sito lento. Mantieni il lavoro attuale concentrato sulla valutazione non superata e sulle prove necessarie a verificare l’intervento.
Cosa deve includere l’intervento?
Scegli la modifica più piccola sostenuta dalla diagnosi, poi concorda come verificarla. Parti dai report e dalle funzionalità che hai già. Il lavoro tecnico è più facile da valutare quando chi gestisce il sito indica la pagina o il modello interessato, spiega il collo di bottiglia e mantiene comparabili le condizioni prima e dopo.
- Collega la proposta alla metrica. La guida LCP di web.dev distingue i ritardi di risposta, individuazione, caricamento e rendering dell’elemento più grande. La guida INP concentra l’indagine sulle interazioni lente. Quella CLS comprende gli spostamenti dopo il caricamento iniziale. Chiedi prove pertinenti invece di una promessa generica di migliorare la velocità.
- Modifica la causa individuata e riprova il comportamento. Una correzione mirata a una risorsa o a un modello può rientrare nello sviluppo e nella manutenzione del sito web. Registra cosa è cambiato e quando, e annota come annullare la modifica dove possibile.
- Controlla che l’attività del cliente funzioni ancora. Prova navigazione, moduli e passaggi d’acquisto rilevanti per la pagina. Mantieni operativi i controlli del consenso; indagane comportamento e layout preservando un consenso conforme alla legge.
- Decidi se servono altre prove. Se i report disponibili non identificano l’interazione o la pagina interessata, ulteriori misurazioni possono aiutare. Prima di aggiungere un servizio a pagamento, chiedi a quale domanda risponde il monitoraggio proposto.
Se la priorità tecnica non è chiara, il lavoro di SEO tecnica può iniziare con una diagnosi e un elenco di interventi verificabile. Un restyling o un pacchetto di ottimizzazione richiede una giustificazione propria.
Puoi copiare questa scheda e lasciare vuoti i campi sconosciuti:
Pagina e attività aziendale:
Dispositivo e ambito dei dati sul campo:
Metrica che richiede attenzione:
Comportamento osservato e condizioni del test:
Causa e modifica proposte:
Data di rilascio:
Controllo comparabile dopo la modifica:
Osservazioni successive sul campo e incertezza residua:Come verifichi che il lavoro sia servito?
Esamina prima il comportamento modificato, poi confronta i dati sul campo successivi nello stesso ambito. Secondo la documentazione, PSI aggiorna i dati sul campo ogni giorno, mantenendo una finestra mobile di raccolta. Conserva la data di rilascio nel registro. Quella finestra non è un conto alla rovescia garantito verso una valutazione superata.
Confronta la metrica scelta e l’attività del cliente in condizioni di test simili. Se il sintomo persiste, riprendi la diagnosi. Se il test migliora ma i dati sul campo successivi non confermano la modifica, indaga di nuovo le pagine e le condizioni dei visitatori interessati. L’assenza di dati sul campo deve restare un limite esplicito.
Come possiamo aiutarti
Partiamo dal report, dalle pagine importanti e da un’attività che possiamo riprodurre. Teniamo distinti l’intervento proposto, la sua verifica e i dati successivi dei visitatori, perché ogni decisione abbia una base che puoi esaminare. Un brief sulle prestazioni del sito web può partire dalla scheda qui sopra; lascia visibili i campi sconosciuti.
