Due situazioni si ripresentano di continuo. Nella prima, il report di PageSpeed è verde mentre Search Console elenca centinaia di URL «Scarso» su mobile. Nella seconda, ancora più frequente sui siti i cui visitatori navigano con buone connessioni, PageSpeed mostra un punteggio arancione o rosso mentre Search Console indica tutti gli URL come «Buono». Quale dei due mente?

Nessuno dei due. Non misurano la stessa cosa. Una volta capito che cosa vede ciascuno, lo scarto tra i due Le dice in quale caso si trova e che cosa fare.

Due tipi di misura

I dati di laboratorio sono il punteggio e le metriche in fondo al report. Sono una sola visita simulata: un telefono emulato, una connessione rallentata, una cache vuota, da un data center di Google, e nessuno che tocca la pagina. Sono ripetibili, il che li rende utili per il debug, e finiscono quando la pagina ha terminato il caricamento.

I dati reali sono quelli che usa Search Console, e quelli che la parte alta del report PageSpeed mostra nella sezione dedicata agli utenti reali. Provengono dal Chrome User Experience Report: visitatori reali di Chrome, con i loro dispositivi e le loro reti, su 28 giorni mobili. Una pagina supera la verifica quando il 75% delle visite è buono, quindi a decidere è il quarto più lento del suo pubblico.

In breve

Laboratorio: un solo caricamento simulato, nessuna interazione, ripetibile.
Dati reali: visite reali su 28 giorni, giudicate al 75° percentile.
I segnali di esperienza sulla pagina di Google usano i dati reali, non il punteggio di laboratorio.

Caso 1: laboratorio verde, campo scarso

Qui il test è più indulgente della realtà. Sei motivi lo spiegano:

1. L'INP non esiste in laboratorio. L'Interaction to Next Paint misura quanto velocemente la pagina reagisce a clic e tocchi. Il laboratorio non clicca mai. Peggio ancora, un'ottimizzazione che rimanda JavaScript fino alla prima interazione migliora il laboratorio e può rendere più lento il primo tocco reale. Veda la guida sul ritardo di JavaScript.

2. Il laboratorio si ferma al caricamento, il CLS no. I dati reali contano gli spostamenti del layout durante tutta la visita: durante lo scorrimento, quando entra un banner, quando un annuncio o un contenuto incorporato cambia dimensione. Un CLS di laboratorio pari a zero non dice nulla di ciò che succede più in basso nella pagina. I colpevoli abituali sui page builder sono descritti nella nostra guida sul CLS.

3. I dispositivi reali sono più lenti. Il 75° percentile del suo pubblico può essere un telefono datato su una connessione debole, ben al di sotto del profilo di laboratorio. Una pagina che in laboratorio passa a malapena, per loro non passa.

4. Le visite reali mancano la cache. Il laboratorio trova spesso una cache di pagina già calda. Il traffico reale include pagine non in cache: prime visite dopo uno svuotamento, clienti connessi e URL con parametri di tracciamento come utm_source, gclid o fbclid, che molte cache trattano come pagine nuove. Il loro tempo di risposta del server finisce nell'LCP dei dati reali.

5. Search Console raggruppa gli URL. Il report mostra gruppi di pagine simili, e le pagine senza abbastanza traffico ereditano i dati del loro gruppo o dell'intero sito. L'URL che sta testando potrebbe non essere quello che trascina giù il gruppo.

6. La finestra è di 28 giorni. Una correzione pubblicata oggi si riflette per intero in circa quattro settimane. Ricontrollare Search Console la mattina dopo mostra i vecchi dati.

Caso 2: laboratorio mediocre, campo verde

Qui il test è più severo della realtà. Il test di laboratorio mobile emula un telefono di fascia media con la CPU rallentata quattro volte e una connessione mobile limitata a circa 1,6 Mbit/s con 150 ms di latenza. Questo profilo è volutamente pessimista, e molti pubblici reali sono molto più veloci:

Reti e telefoni più veloci. I visitatori in fibra, in 4G veloce o in 5G, con telefoni recenti, finiscono di caricare ben prima del dispositivo emulato. Al 75° percentile restano nel verde.
Visite a caldo. I visitatori di ritorno e la navigazione da una pagina all'altra riutilizzano i file in cache e le connessioni aperte. Il laboratorio parte sempre a freddo, senza nulla in cache.
Gli script costano meno su hardware reale. Uno script pesante che blocca la CPU emulata per alcuni secondi ne richiede una frazione su un telefono recente, quindi il tempo di blocco del laboratorio sovrastima ciò che percepiscono i visitatori.

Il luogo in cui si trovano i Suoi visitatori decide in quale caso si trova. Un pubblico in paesi dove le connessioni mobili sono lente si comporta come il laboratorio o peggio: è il caso 1. Un pubblico su reti veloci si comporta meglio del laboratorio: è il caso 2. Search Console e PageSpeed mostrano un unico dato per tutti i Suoi visitatori insieme; se il Suo pubblico è internazionale, i dati pubblici del Chrome UX Report possono essere suddivisi per paese.

Che cosa fare nel caso 2. I segnali di esperienza sulla pagina di Google usano i dati sul campo, quindi è un campo verde a contare. Non rompa un sito che funziona per inseguire un punteggio di laboratorio. Tenga il laboratorio come strumento di diagnosi: mostra ciò che vivono i Suoi visitatori più lenti e intercetta le regressioni prima che arrivino sul campo. Migliori ciò che segnala, una modifica sicura alla volta, seguendo il nostro metodo per ottimizzare senza rompere.

In breve

Caso 1, laboratorio verde e campo scarso: il Suo pubblico è più lento del test, oppure il problema si verifica dopo il caricamento.
Caso 2, laboratorio mediocre e campo verde: il Suo pubblico è più veloce del test, che è volutamente pessimista.
Google usa i dati sul campo; il laboratorio è una diagnosi, non un verdetto.

Passo 1: leggere cosa dice davvero Search Console

Quale metrica: LCP, INP o CLS. Il metodo cambia completamente per ciascuna.
Quale dispositivo: mobile e desktop sono report separati.
Quale gruppo: apra il problema e guardi gli URL di esempio. Indicano quasi sempre un template: pagine prodotto, articoli, pagine di categoria, la home.

Poi apra un URL di esempio in PageSpeed e guardi prima la sezione degli utenti reali. Se mostra dati per quell'URL, ha i dati reali propri della pagina; se mostra l'intera origine, la pagina viene giudicata insieme al resto del sito.

Passo 2: riprodurre il problema reale nel browser

Per l'INP: apra i DevTools, pannello Performance, imposti il rallentamento della CPU a 4x o 6x, registri e interagisca come farebbe un visitatore: apra il menu, cambi una variante, aggiunga al carrello, accetti il banner dei cookie. I lunghi blocchi gialli dopo il clic sono il ritardo. Le versioni recenti di Chrome mostrano anche i valori LCP, CLS e INP in tempo reale in quel pannello.

Per il CLS: ricarichi con il rallentamento attivo, poi scorra lentamente tutta la pagina e interagisca. Nella scheda Rendering, «Layout Shift Regions» evidenzia ogni spostamento nel momento in cui avviene.

Per l'LCP: provi il template in emulazione mobile, con un URL non in cache (aggiunga un parametro casuale), e guardi il tempo di risposta del server e il momento in cui viene scoperto l'elemento LCP.

Console: registrare l'LCP e gli spostamenti del layout della pagina mentre avvengono

new PerformanceObserver(l => l.getEntries().forEach(e =>
  console.log('LCP', Math.round(e.startTime), e.element))).observe({ type: 'largest-contentful-paint', buffered: true });
new PerformanceObserver(l => l.getEntries().forEach(e => !e.hadRecentInput &&
  console.log('CLS', e.value.toFixed(3), e.sources?.map(s => s.node)))).observe({ type: 'layout-shift', buffered: true });

Passo 3: mai trarre conclusioni da un solo test

Il punteggio di laboratorio cambia da un test all'altro, a volte di dieci punti su mobile, perché la pagina, la rete e la macchina di test variano. Per confrontare due versioni:

esegua ogni versione più volte e confronti le mediane, non il test migliore;
distanzi i test, perché un risultato richiesto di nuovo a breve distanza può essere servito da una cache e ripetere lo stesso numero;
confronti lo stesso URL, lo stesso dispositivo, le stesse condizioni, con e senza la modifica.

Conclusione affidabile

Metrica reale individuata in Search Console, riprodotta nel browser, corretta, confermata su diversi test di laboratorio, poi convalidata in Search Console quattro settimane dopo.

Conclusione sbagliata

Un solo test PageSpeed verde il giorno dopo la modifica, preso come prova che il problema in Search Console è risolto.

Passo 4: convalidare e aspettare

Una volta pubblicata la correzione, clicchi «Convalida correzione» sul problema in Search Console. La convalida segue la finestra di 28 giorni, quindi preveda circa un mese. Nel frattempo, sono il laboratorio e le misure nel suo browser a dirle se la correzione funziona.

Con Mantys Core

Mantys Core non sostituisce i dati reali: Search Console e il report di Chrome restano il riferimento. Rende più pulito il lato laboratorio del metodo:

Un solo comando esegue PageSpeed sullo stesso URL prima senza e poi con le ottimizzazioni, su mobile, desktop o entrambi, così un prima e dopo viene misurato nelle stesse condizioni.
Il suo critical CSS viene catturato alle stesse dimensioni di schermo usate dal test di velocità, quindi ciò che il test vede al caricamento è ciò che è stato ottimizzato.
Un bypass in una sola richiesta mostra la pagina grezza accanto a quella ottimizzata nel suo browser, che è ciò che serve al passo 2.

I dati reali le dicono dove fa male. La piattaforma la aiuta a dimostrare, in laboratorio, che la modifica fatta è quella che aiuta.

In sintesi

Il punteggio di PageSpeed è un solo caricamento simulato; Search Console è 28 giorni di visite reali al 75° percentile.
Laboratorio verde e campo scarso: il problema è un'interazione, uno spostamento dopo il caricamento, un dispositivo lento, un URL non in cache o un altro template.
Laboratorio mediocre e campo verde: i Suoi visitatori sono più veloci del profilo di test pessimista; è il campo che conta.
Parta da Search Console: metrica, dispositivo, gruppo di URL, template.
Lo riproduca nei DevTools con il rallentamento e interazioni reali, poi confronti diversi test di laboratorio, mai uno solo.
Convalidi la correzione e le lasci quattro settimane.

Commenti

È bloccato su un problema simile? Descriva la sua configurazione e ciò che osserva. Leggiamo ogni commento e rispondiamo.

Ancora nessun commento. Condivida per primo il suo caso.