Un punteggio può dirti che una pagina è lenta. WebPageTest diventa particolarmente utile quando vuoi capire perché lo è, in quali condizioni emerge il problema e quali risorse stanno rallentando realmente il caricamento.
Con WebPageTest puoi eseguire test controllati scegliendo posizione geografica, browser, tipo di connessione e altre condizioni, per poi analizzare waterfall, filmstrip, metriche di caricamento, audit Lighthouse e opportunità di ottimizzazione. La documentazione corrente permette anche di eseguire più run, confrontare First View e Repeat View e configurare test avanzati o script.
Il punto importante è usarlo nel modo corretto: WebPageTest non sostituisce i dati degli utenti reali e non va ridotto a un semplice “speed score”. Il suo vantaggio principale è la capacità di creare uno scenario di laboratorio ripetibile e di mostrarti cosa succede durante il caricamento della pagina.
In questa guida vediamo come configurare un test, quali parti del report leggere per prime, come interpretare waterfall e filmstrip, quali metriche contano davvero e quando affiancare WebPageTest a PageSpeed Insights o GTmetrix.
Cos’è WebPageTest e quando conviene usarlo
WebPageTest è uno strumento di analisi delle performance web che permette di caricare una pagina in un ambiente controllato e osservare in dettaglio come il browser riceve, elabora e visualizza le sue risorse.
Non si limita quindi alla domanda:
“Quanto è veloce questa pagina?”
Permette di arrivare a domande molto più utili:
- dove viene speso il tempo durante il caricamento?
- il problema nasce dal server, dalle immagini, dai font, dal JavaScript o da servizi esterni?
- cosa vede concretamente l’utente nei primi secondi?
- la cache modifica sensibilmente il risultato?
- una determinata ottimizzazione cambia davvero il comportamento della pagina?
La documentazione di WebPageTest mostra infatti un report che combina metriche, waterfall delle singole richieste, filmstrip, dati CrUX quando disponibili, risultati Lighthouse, Opportunities ed Experiments.
Questa profondità lo rende particolarmente utile quando devi diagnosticare un problema di performance, non soltanto rilevarlo.
WebPageTest lavora soprattutto in laboratorio: synthetic test e dati reali non sono la stessa cosa
Qui c’è una distinzione che conviene chiarire subito.
Il test che configuri in WebPageTest è principalmente un synthetic test, cioè un caricamento eseguito in condizioni stabilite in anticipo: browser, posizione, connessione, numero di run e altre impostazioni.
Questo permette di isolare le variabili.
Se oggi testi una pagina da una determinata località con una certa connessione e domani ripeti il test mantenendo quelle condizioni, il confronto ha molto più significato rispetto a due misurazioni eseguite in scenari completamente differenti.
I field data, invece, descrivono ciò che è successo a utenti reali con dispositivi, connessioni, luoghi e comportamenti differenti.
WebPageTest può mostrare nel report dati provenienti dal Chrome User Experience Report (CrUX), quando sono disponibili, così da confrontare il test sintetico con un campione aggregato di esperienze reali. Nei livelli più avanzati dell’ecosistema Catchpoint entra inoltre in gioco il Real User Monitoring.
La distinzione pratica è questa:
lab data → ottimi per diagnosticare e riprodurre un problema
field data → fondamentali per capire cosa sperimentano realmente gli utenti
Se i due raccontano storie diverse, non significa necessariamente che uno dei due sia sbagliato. Significa che stanno osservando il sito da prospettive diverse.
Quando scegliere WebPageTest invece di un controllo rapido
WebPageTest ha senso soprattutto quando:
- PageSpeed Insights segnala un problema ma vuoi capire quali richieste ne sono responsabili;
- devi confrontare il comportamento prima e dopo una modifica;
- vuoi analizzare cache, risorse di terze parti, immagini, font o JavaScript;
- devi osservare la sequenza visiva del caricamento;
- vuoi testare da condizioni geografiche o di rete specifiche;
- devi integrare i test in un workflow di sviluppo o monitoraggio.
Per un controllo occasionale può bastare uno strumento più immediato. Per una diagnosi tecnica, invece, la granularità del test conta più della semplicità del punteggio finale.
Come eseguire un test con WebPageTest
La qualità del risultato dipende prima di tutto da come imposti il test.
Uno degli errori più comuni nelle analisi di performance è confrontare numeri ottenuti in condizioni diverse come se fossero direttamente equivalenti.
URL, località, browser, dispositivo e connessione
Il primo passaggio consiste nell’inserire l’URL della pagina da analizzare e scegliere le condizioni che devono rappresentare lo scenario.
Tra le configurazioni disponibili rientrano la connessione, browser e caratteristiche dell’ambiente di test; le opzioni avanzate permettono inoltre di intervenire su user agent, header, tracing, HAR, JavaScript personalizzato e altre variabili.
La domanda da farti non è quindi “qual è la configurazione migliore?”, ma:
quale scenario voglio riprodurre?
Se il pubblico principale è italiano e mobile, ha poco senso utilizzare come riferimento principale un test desktop eseguito da un’area geografica lontana con una rete molto veloce.
Allo stesso modo, se stai cercando un problema specifico del desktop, simulare uno smartphone aggiunge rumore anziché informazione.
L’obiettivo è creare un baseline coerente con il caso che stai studiando.
Numero di run, First View e Repeat View
Un singolo caricamento può essere influenzato da variabilità di rete, server e risorse esterne.
WebPageTest permette di eseguire più run proprio per ottenere un campione più utile. La documentazione specifica inoltre che l’opzione Repeat View provoca un secondo caricamento della pagina all’interno del run.
Questo permette di osservare due situazioni diverse:
First View
Rappresenta il caricamento iniziale, dove il browser non dispone ancora delle risorse memorizzate da quella sessione.
Repeat View
Permette di vedere cosa cambia al caricamento successivo, quando cache e altre condizioni possono ridurre il lavoro necessario.
Se il primo caricamento è molto lento ma il Repeat View migliora drasticamente, la cache sta giocando un ruolo importante. Se entrambi restano problematici, conviene cercare altrove.
Per confronti prima/dopo, eviterei di basarmi su un singolo test: è più utile osservare più run mantenendo identiche le condizioni.
Come creare un test davvero confrontabile
Se vuoi sapere se un intervento ha funzionato, devi cambiare una variabile alla volta quando possibile.
Immagina di:
- cambiare hosting;
- sostituire il plugin di cache;
- convertire tutte le immagini;
- eliminare alcuni script;
- attivare una CDN.
Se rifai il test e LCP migliora, sai che il sito è più veloce, ma non sai quale intervento abbia prodotto il risultato.
Un workflow più pulito è:
baseline → singola modifica → stesso test → confronto → nuova modifica
Questa disciplina è molto più utile di inseguire continuamente un punteggio.
Come leggere un report WebPageTest
Quando il test termina, non partirei dal tentativo di interpretare ogni valore contemporaneamente.
Il report corrente mette a disposizione Summary, Filmstrip, Waterfall, Lighthouse, Opportunities, Experiments e altre viste. La Summary mostra anche la configurazione usata, così puoi verificare subito se stai osservando lo scenario giusto.
Un buon ordine di lettura è:
Summary → Filmstrip → Waterfall → metriche → Opportunities → approfondimenti specifici
Performance Summary: da dove partire
La Summary offre una fotografia iniziale del test.
Tra le metriche mostrate compaiono TTFB, Start Render, FCP, LCP, Speed Index, TBT, CLS e peso complessivo della pagina.
Non leggere però questi valori come voti indipendenti.
Devi cercare relazioni.
Per esempio:
- TTFB elevato + waterfall fermo prima dell’arrivo dell’HTML → possibile problema nella fase iniziale della risposta;
- TTFB accettabile + LCP molto tardivo → il collo di bottiglia potrebbe trovarsi dopo la risposta iniziale;
- TBT elevato → il main thread potrebbe essere impegnato da attività JavaScript;
- CLS elevato → alcuni elementi stanno spostando il layout;
- pagina molto pesante → immagini, font, script o altri asset meritano un controllo.
La Summary ti dice dove guardare. Il waterfall e gli altri dettagli aiutano a capire perché.
Waterfall: capire dove si accumula l’attesa
Il waterfall è probabilmente la parte più importante di WebPageTest quando devi diagnosticare un caricamento lento.
È una rappresentazione temporale delle richieste effettuate dal browser. Ogni riga corrisponde a una risorsa: documento HTML, CSS, JavaScript, immagini, font, chiamate a servizi esterni e così via.
WebPageTest lo descrive come un diagramma di tipo Gantt che mostra l’impatto delle singole richieste sul caricamento complessivo.
Il vantaggio è che smetti di vedere “la pagina è lenta” come un singolo problema e inizi a osservare una catena di eventi.
Puoi individuare, ad esempio:
- una risposta HTML iniziale troppo lenta;
- una risorsa che blocca quelle successive;
- font caricati tardi;
- immagini molto pesanti;
- script di terze parti;
- numerose richieste verso domini differenti;
- file che partono solo dopo una lunga dipendenza;
- risorse che richiedono molto tempo prima di iniziare il download.
Per approfondire il primo tratto della catena, può essere utile leggere anche la guida al Time to First Byte.
Un TTFB alto, comunque, non dimostra automaticamente che “l’hosting è lento”. Il tempo può dipendere da elaborazione applicativa, database, cache, rete, infrastruttura e altre condizioni. Il waterfall serve proprio a evitare diagnosi troppo rapide.
Filmstrip e video: leggere la progressione visiva
Una pagina può iniziare a scaricare risorse molto presto e apparire comunque vuota per parecchio tempo.
Il Filmstrip risponde a una domanda diversa rispetto al waterfall:
cosa stava vedendo l’utente in quel momento?
WebPageTest costruisce una sequenza di screenshot durante il caricamento e permette di confrontare visivamente più run.
È particolarmente utile quando devi distinguere tra:
- pagina tecnicamente attiva ma ancora bianca;
- comparsa dei primi contenuti;
- comparsa dell’elemento principale;
- caricamento progressivo di immagini;
- spostamenti del layout;
- elementi che arrivano molto tardi.
Qui lo Speed Index può essere un indicatore sintetico della velocità con cui il contenuto visibile viene popolato, ma il filmstrip ti permette di vedere il comportamento, non soltanto il numero.
Nota editoriale: prima della pubblicazione non lascerei il link generico precedente alla home: sostituirlo con il futuro contenuto specifico sullo Speed Index se presente in sitemap, oppure rimuoverlo. Non va pubblicato come link generico.
Assets, domini esterni e JavaScript
Una volta identificato il tratto problematico, conviene restringere l’analisi.
Se il waterfall mostra molte richieste provenienti da servizi esterni, chiediti quali siano realmente necessarie.
Tag di advertising, analytics, video embed, chat, mappe, widget social e altri script possono aggiungere:
- nuove connessioni;
- DNS e TLS aggiuntivi;
- download;
- elaborazione JavaScript;
- dipendenze da infrastrutture che non controlli.
Questo non significa che ogni risorsa di terze parti debba essere eliminata. Significa che il suo costo deve essere proporzionato al valore che porta alla pagina.
Lo stesso ragionamento vale per il JavaScript proprietario: se il download è modesto ma TBT rimane elevato, il problema potrebbe essere il tempo di esecuzione e non soltanto il peso trasferito.
Metriche WebPageTest: cosa guardare davvero
WebPageTest mette a disposizione molte metriche. L’errore sarebbe trattarle tutte come se rappresentassero la stessa cosa.
Alcune misurano la risposta iniziale, altre la comparsa visiva, altre la stabilità, altre ancora il lavoro che può ostacolare la responsività.
LCP, CLS e INP: cosa sono davvero i Core Web Vitals
I Core Web Vitals correnti sono:
| Metrica | Cosa descrive |
|---|---|
| LCP — Largest Contentful Paint | Quanto rapidamente viene visualizzato il principale elemento di contenuto |
| INP — Interaction to Next Paint | Responsività della pagina alle interazioni dell’utente |
| CLS — Cumulative Layout Shift | Stabilità visiva del layout |
Google conferma che i Core Web Vitals vengono utilizzati dai suoi sistemi di ranking, ma chiarisce anche che ottenere buoni risultati non garantisce di raggiungere le prime posizioni e che la page experience non si riduce a un singolo segnale o punteggio.
Questa distinzione è importante: migliorare le performance può migliorare concretamente l’esperienza delle persone e rientra nel quadro della page experience, ma non esiste una relazione valida del tipo:
“guadagno X millisecondi → guadagno Y posizioni su Google”.
Per approfondire le singole metriche puoi consultare le guide a Largest Contentful Paint, Cumulative Layout Shift e Interaction to Next Paint.
TTFB, FCP, Speed Index e TBT non sono Core Web Vitals
Sono metriche molto utili, ma appartengono a funzioni diagnostiche differenti.
TTFB — Time to First Byte
Indica quanto tempo trascorre prima che inizi ad arrivare la risposta dal server.
FCP — First Contentful Paint
Indica quando compare il primo contenuto significativo come testo o immagine. Abbiamo approfondito il meccanismo nella guida al First Contentful Paint.
Speed Index
Descrive quanto rapidamente viene popolata visivamente la parte visibile della pagina.
TBT — Total Blocking Time
Misura nel laboratorio quanto il main thread rimane bloccato da long task durante il periodo osservato.
Dire che tutte queste metriche sono “Core Web Vitals” crea confusione. È più utile capire quale fase del caricamento descrivono.
Perché TBT e INP non sono la stessa cosa
Questa distinzione merita particolare attenzione.
TBT viene misurato bene in laboratorio. INP nasce invece per descrivere la responsività sperimentata attraverso interazioni reali.
Web.dev considera TBT un indicatore che può essere utile per individuare possibili problemi collegati a INP, soprattutto nei test di laboratorio, ma specifica che non è un sostituto di INP. Un TBT elevato può segnalare main-thread congestion anche quando l’utente non interagisce proprio in quel momento; allo stesso tempo un page-load test può non riprodurre l’interazione che genera un cattivo INP nel mondo reale.
In pratica:
TBT alto → indaga il lavoro sul main thread
INP alto nei dati reali → indaga le interazioni problematiche
Le due analisi possono convergere, ma non vanno sovrapposte.
Lab data e field data: perché possono divergere
Immagina una pagina con dati reali discreti ma un test WebPageTest molto lento.
Potresti aver scelto:
- una rete più lenta;
- un’area geografica differente;
- un dispositivo più limitato;
- un caricamento senza cache;
- una condizione che rappresenta soltanto una parte degli utenti.
Può succedere anche l’opposto: un test sintetico pulito e veloce mentre i dati reali mostrano difficoltà.
PageSpeed Insights spiega lo stesso principio: i dati lab provengono da un ambiente simulato e controllato, mentre i dati CrUX descrivono esperienze aggregate di utenti reali; per questo i risultati possono differire.
Non chiederti quindi quale valore “sia quello vero”.
Chiediti:
quale problema sta mostrando ciascun dataset?
È proprio la combinazione dei due che permette una diagnosi migliore.
Opportunities ed Experiments: dalla diagnosi alla verifica
Una delle aree più interessanti dell’attuale WebPageTest è il passaggio dalla semplice rilevazione del problema alla verifica di possibili interventi.
Opportunities: capire dove intervenire
La sezione Opportunities raccoglie indicazioni sulle aree che possono essere migliorate. È disponibile anche nel piano Starter.
Non la userei però come lista di istruzioni da applicare automaticamente.
Una raccomandazione è un punto di partenza.
Se un audit suggerisce, per esempio, di ridurre un determinato asset, devi ancora chiederti:
- quell’asset è effettivamente responsabile del collo di bottiglia che stai osservando?
- quanto incide sul caso reale?
- l’intervento ha conseguenze funzionali o visive?
- stai ottimizzando ciò che conta o soltanto ciò che è facile misurare?
La qualità dell’analisi sta nel collegare opportunity → evidenza nel report → intervento concreto.
Experiments: simulare una modifica prima di implementarla
Experiments, disponibile nel livello Pro, permette di provare alcune ottimizzazioni nel sandbox di WebPageTest e confrontare il risultato con un controllo. La documentazione corrente descrive proprio un confronto side-by-side tra test di controllo e modifica.
Questo cambia il workflow:
“il tool suggerisce X”
diventa:
“simuliamo X e vediamo se modifica realmente ciò che ci interessa”.
È un passaggio importante perché riduce il rischio di applicare indiscriminatamente tutte le raccomandazioni generate da un audit.
Lighthouse dentro WebPageTest: come usarlo senza inseguire il punteggio
WebPageTest può eseguire Site Performance, Lighthouse oppure entrambi.
Lighthouse aggiunge audit su performance, accessibilità, best practice e SEO. Ma non sostituisce gli strumenti diagnostici che rendono WebPageTest particolarmente interessante.
Pensa ai due livelli così:
Lighthouse → segnala pattern e opportunità
Waterfall + Filmstrip + dettagli WebPageTest → aiutano a ricostruire cosa sta accadendo durante quel test
Se Lighthouse segnala JavaScript eccessivo, per esempio, il passo successivo non dovrebbe essere semplicemente “riduci JavaScript”.
Serve capire:
- quale script;
- quando parte;
- quanto pesa;
- quanto occupa il main thread;
- se è first-party o third-party;
- se è necessario;
- se può essere differito o rimosso.
Il punteggio è quindi utile come orientamento, non come obiettivo autonomo.
Lo stesso vale quando utilizzi Google Lighthouse direttamente: un 100 non è una certificazione che il sito sia veloce per tutti gli utenti.
Scripting, API e automazione
L’utilità di WebPageTest cresce quando passi dal controllo occasionale a un processo ripetibile.
Scripted tests
Le opzioni avanzate consentono di inserire script e configurazioni personalizzate. La documentazione corrente prevede anche opzioni per nascondere script contenenti dati sensibili e per controllare header e altre informazioni raccolte.
Gli script sono utili quando un semplice caricamento dell’URL non rappresenta il percorso che vuoi misurare.
Puoi avere, ad esempio:
- una pagina che richiede autenticazione;
- un flusso in più passaggi;
- un’interazione necessaria prima di raggiungere lo stato da analizzare;
- una condizione applicativa specifica.
In questi casi il test deve modellare il comportamento che ti interessa, non limitarsi alla home page.
API e CI/CD
L’API di WebPageTest consente di portare i test dentro workflow automatizzati e pipeline di sviluppo. Catchpoint documenta integrazioni per CI/CD, ambienti di sviluppo, alerting e visualizzazione dei dati.
Questo permette di trasformare il controllo delle performance da attività manuale a controllo continuo.
Un esempio concettuale:
modifica al codice → deploy di test → WebPageTest → verifica soglia/variazione → decisione
Il vantaggio non è “avere più metriche”, ma scoprire una regressione prima che diventi un problema stabile in produzione.
Scheduled tests, alert e monitoraggio
Il piano Professional aggiunge test programmati, alert personalizzabili, API, integrazioni, test privati/bulk, Smartboards ed Experiments.
Qui WebPageTest cambia ruolo.
Non è più soltanto:
“il sito oggi è veloce?”
Diventa:
“come stanno evolvendo le performance nel tempo e quando qualcosa peggiora?”
Questo è particolarmente utile su siti che cambiano continuamente: ecommerce, portali editoriali, applicazioni web o progetti con molte release.
WebPageTest Starter, Professional ed Expert: cosa cambia
Le caratteristiche dei piani possono cambiare, quindi eviterei di costruire l’articolo attorno a prezzi destinati a diventare rapidamente obsoleti. Per cifre e limiti aggiornati conviene verificare sempre la pagina pricing ufficiale.
La differenza funzionale, al momento della verifica, può essere sintetizzata così:
| Piano | Per chi ha più senso | Caratteristiche distintive |
|---|---|---|
| Starter | Test occasionali e analisi manuale | Metriche principali, filmstrip/video, Lighthouse, Opportunities, script limitati, più località e più run per test |
| Professional | Team e workflow continuativi | Scheduled tests, alert, Smartboards, API, integrazioni, bulk/private testing, Experiments, maggiore retention |
| Expert | Organizzazioni con esigenze di monitoring più ampie | RUM, synthetic testing su scala enterprise, user journey, SSO e integrazione con capacità più ampie di Internet Performance Monitoring |
Starter non è quindi soltanto una demo: permette già di utilizzare il nucleo diagnostico dello strumento. Professional ha senso quando vuoi automatizzare, monitorare o sperimentare, mentre Expert appartiene a uno scenario di osservabilità e monitoring più esteso.
WebPageTest vs PageSpeed Insights e GTmetrix: quale usare
Non esiste un vincitore universale, perché oggi questi strumenti si sovrappongono in diverse aree.
La scelta diventa più chiara se parti dal task.
| Criterio | WebPageTest | PageSpeed Insights | GTmetrix |
|---|---|---|---|
| Uso ideale | Diagnosi tecnica controllata e confronti approfonditi | Valutazione rapida lab + dati CrUX | Analisi performance e monitoraggio in un’interfaccia più guidata |
| Dati sintetici | Molto configurabili | Lighthouse in ambiente simulato | Lighthouse con opzioni di analisi |
| Dati real-user | CrUX nel report quando disponibile; RUM nei livelli avanzati | CrUX integrato | CrUX integrato |
| Waterfall | Molto dettagliato e centrale nel workflow | Non è il fulcro di PSI | Disponibile |
| Filmstrip/video | Elemento centrale | Più limitato rispetto a WPT | Disponibili |
| Controllo ambiente | Molto elevato | Più standardizzato | Buono, variabile in base al piano |
| Experimentation | Experiments nel piano Professional | Non è la funzione principale | Non è il principale elemento distintivo |
| Automazione/monitoraggio | API, scheduled tests, alert e integrazioni | Non nasce come piattaforma di monitoring | Monitoring e alert integrati |
PageSpeed Insights usa Lighthouse per i dati lab e CrUX per i dati reali quando disponibili. GTmetrix offre attualmente Lighthouse, Web Vitals, CrUX, waterfall, video/filmstrip, località multiple e monitoraggio programmato.
Quando sceglierei PageSpeed Insights
Quando voglio una risposta veloce a due domande:
- come si comporta la pagina nei dati real-user disponibili?
- cosa mostra un audit Lighthouse standard?
È un ottimo punto di partenza e abbiamo approfondito il suo utilizzo nella guida a PageSpeed Insights.
Quando sceglierei WebPageTest
Quando la domanda diventa:
“perché succede?”
Soprattutto se devo controllare:
- rete;
- località;
- browser;
- cache;
- sequenza delle richieste;
- rendering visivo;
- dipendenze esterne;
- regressioni prima/dopo una modifica.
Quando sceglierei GTmetrix
Quando voglio un compromesso tra analisi tecnica, storico e monitoring in un’interfaccia molto orientata alla lettura del report.
La nostra guida a GTmetrix entra più nel dettaglio delle sue funzioni.
In pratica, questi strumenti possono tranquillamente convivere. Nella guida ai tool per testare la velocità di un sito trovi il confronto più ampio tra soluzioni diverse.
Questa separazione è importante anche editorialmente: questa pagina resta focalizzata su WebPageTest, mentre il confronto generale tra strumenti appartiene all’articolo dedicato ai test di velocità.
Errori da evitare quando testi le performance
Confrontare test eseguiti in condizioni differenti
Cambiare contemporaneamente località, connessione e browser rende molto più difficile attribuire una variazione alla modifica del sito.
Prima di guardare i numeri, controlla sempre la configurazione.
Fidarsi di un singolo run
Una misura isolata può essere influenzata da variabilità temporanea.
Se la decisione è importante, usa più osservazioni e cerca un pattern.
Confondere lab e field data
Un test sintetico non rappresenta automaticamente tutti i tuoi utenti.
E i dati reali non ti permettono sempre di riprodurre facilmente il problema.
Usali insieme.
Ottimizzare soltanto il punteggio
Ridurre un numero non è necessariamente equivalente a migliorare il sito.
Una modifica può migliorare Lighthouse senza intervenire sul collo di bottiglia che interessa davvero il tuo pubblico.
Dare automaticamente la colpa all’hosting
Un TTFB elevato merita indagine, ma il server è soltanto una parte della catena.
Cache applicativa, database, backend, rete, CDN e altre condizioni possono contribuire.
Trattare TBT come se fosse INP
TBT è una metrica di laboratorio utile per indagare blocchi del main thread. INP riguarda la responsività osservata attraverso le interazioni.
Sono collegati, non intercambiabili.
Cambiare molte cose prima di rifare il test
Se vuoi sapere cosa ha funzionato, mantieni il test stabile e modifica il minor numero possibile di variabili per volta.
Il valore di WebPageTest emerge soprattutto nella ripetibilità del confronto.
Un workflow pratico: misura, diagnostica, modifica, verifica
Il modo più utile di integrare WebPageTest in un lavoro di ottimizzazione è evitare la sequenza:
test → punteggio → lista di raccomandazioni → modifica di tutto
Preferisco questo workflow:
- Definisci lo scenario. Quale pagina, quale device, quale rete, quale area geografica?
- Crea una baseline. Esegui un test ripetibile e conserva il risultato.
- Individua il sintomo. TTFB? LCP? TBT? CLS? caricamento visivo?
- Segui il problema nel waterfall, nel filmstrip o nei dettagli.
- Formula un’ipotesi. Quale risorsa o meccanismo sta causando il problema?
- Modifica una variabile significativa.
- Ripeti lo stesso test.
- Confronta non soltanto il punteggio, ma il meccanismo che volevi correggere.
- Controlla i field data quando disponibili per capire se il miglioramento si riflette anche sull’esperienza reale.
Questo approccio evita molta ottimizzazione “a checklist”.
Se durante l’analisi emergono problemi strutturali di caching, JavaScript, immagini, backend o configurazione WordPress che richiedono un intervento più ampio, puoi valutare un lavoro di ottimizzazione del sito web costruito sui colli di bottiglia reali invece che su un punteggio generico.
Conclusione
WebPageTest ha più valore quando smetti di usarlo come un altro strumento per sapere se il sito è “verde” o “rosso”.
Il suo punto forte è la possibilità di creare uno scenario controllato, osservare come nasce il caricamento e verificare se una modifica interviene davvero sul problema che hai individuato.
Per un controllo rapido partirei spesso da PageSpeed Insights. Se devo capire perché LCP arriva tardi, quale script blocca il main thread, cosa succede tra First View e Repeat View o quale richiesta rallenta la pagina, WebPageTest diventa molto più interessante.
Il limite da ricordare è altrettanto importante: un synthetic test non descrive automaticamente l’esperienza di tutti gli utenti. Per questo la diagnosi migliore arriva quando metti insieme lab data, waterfall e filmstrip con i dati real-user disponibili.
Il risultato che conta non è ottenere un voto perfetto. È sapere cosa rallenta la pagina, perché succede e quale intervento migliora realmente il comportamento del sito.