WebPageTest

TL;DR — WebPageTest è uno strumento gratuito che carica la tua pagina su un browser reale in una posizione reale e ti mostra esattamente cosa è successo durante il caricamento — ogni file che ha scaricato, in che ordine, e un video fotogramma per fotogramma della pagina che appare. È lo strumento che usi quando PageSpeed Insights dice che una pagina è lenta ma vuoi vedere perché. Non è un prodotto Google, e i suoi punteggi non influenzano il tuo posizionamento — è uno strumento di diagnosi.

Cos’è WebPageTest

La maggior parte degli strumenti di velocità ti dà un numero. WebPageTest ti dà una storia — un’immagine dettagliata, passo dopo passo, di come la tua pagina è stata caricata.

Vai su webpagetest.org, inserisci un URL, scegli da dove nel mondo testare e su che tipo di dispositivo e connessione, e premi start. Un browser reale su una macchina reale carica la tua pagina, e WebPageTest registra tutto: ogni immagine, script e font che ha recuperato, quanto tempo ha impiegato ciascuno, e una striscia di film — un set reale di screenshot fotogramma per fotogramma della pagina che appare sullo schermo.

È gratuito e open source. È stato creato da uno sviluppatore di nome Patrick Meenan nel 2008, e una società chiamata Catchpoint lo ha acquistato nel 2020 — ma la versione pubblica gratuita su webpagetest.org è ancora lì per chiunque possa usarla.

Perché lo useresti invece di PageSpeed Insights

PageSpeed Insights (lo strumento di Google) è ottimo per dirti che una pagina è lenta e darti un punteggio. WebPageTest è migliore per dirti perché e dove. Se PSI dice “riduci le risorse che bloccano il rendering,” WebPageTest ti mostra il file esatto che sta bloccando, a quale secondo, in un grafico che puoi leggere come una timeline.

L’altra cosa che la gente sbaglia: i punteggi di WebPageTest non sono un fattore di ranking. Google classifica in parte in base alla velocità con cui i visitatori reali sperimentano il tuo sito (questo si chiama “dati di campo,” e proviene da utenti Chrome reali). WebPageTest è un test “di laboratorio” — una singola esecuzione controllata su una macchina. Serve per trovare e correggere problemi, non per il numero che Google vede effettivamente.

Le due viste con cui la maggior parte delle persone inizia

• Il waterfall. Un grafico con una riga per ogni file che la tua pagina ha caricato, impilati nell’ ordine in cui sono arrivati. Barre lunghe e file impilati all’inizio sono di solito dove vive la tua lentezza.
• La striscia di film. Una riga di screenshot che mostrano la pagina che si dipinge nel tempo. Puoi letteralmente guardare il momento in cui il tuo contenuto principale appare — o il momento in cui qualcosa salta in giro sulla pagina.

Vuoi la versione completa — la vista connessione, la ricetta esatta che uso per scovare il layout shift, come si confronta con Lighthouse e CrUX, e come lo uso per la SEO tecnica? Passa alla scheda Avanzate.

TL;DR — WebPageTest è uno strumento di performance di laboratorio (sintetico) gratuito e open source: un URL, una posizione di test distribuita reale, un browser e un profilo di rete in, diagnostica approfondita fuori — waterfall (flag di blocco del rendering, sequenziamento), striscia di film/video (fotogramma per fotogramma, con un’opzione Evidenzia spostamenti di layout per CLS), vista connessione (DNS/TCP/TLS/TTFB) e Core Web Vitals fotogramma per fotogramma. Patrick Meenan lo ha creato nel 2008 (uno strumento interno di AOL); Catchpoint lo ha acquisito nel 2020; il codice rimane aperto sotto la licenza Polyform Shield. La spina dorsale dell’accuratezza: produce dati di laboratorio, non dati di campo, quindi non alimenta il segnale di ranking CWV di Google (quello è CrUX con utenti reali). È uno strumento diagnostico, non il punteggio che Google vede — e non è un concorrente di Lighthouse, perché puoi eseguire Lighthouse al suo interno. Ricorri ad esso quando PageSpeed Insights ti dice che una pagina è lenta ma non perché o dove nel caricamento.

Cosa è realmente

Ogni risultato di WebPageTest è una singola esecuzione configurata: un URL, testato da una posizione specifica, su un browser e dispositivo specifici, su un profilo di connessione specifico, in un momento specifico. Non è una misurazione universale di “quanto è veloce il tuo sito” — è prova da quella esecuzione, e deve essere letta come tale.

In questa prospettiva, WebPageTest è lo strumento di diagnostica approfondita nella cassetta degli attrezzi per le prestazioni web. web.dev, il sito per sviluppatori di Google, lo inquadra bene: “WebPageTest contains an advanced suite of metrics and trace viewers. It enables deep diving into the performance of your site on real mobile hardware with network conditions.” (traduzione) «WebPageTest contiene una suite avanzata di metriche e visualizzatori di trace. Consente di approfondire le prestazioni del tuo sito su hardware mobile reale con condizioni di rete.» (web.dev, “How To Think About Speed Tools”)

La sua pagina “audit” aggiunge l’angolazione legata alla SEO: “WebPagetest will also check static-content caching, time to first byte, and if your site makes effective use of CDNs.” (traduzione) «WebPagetest controllerà anche la memorizzazione nella cache dei contenuti statici, il tempo al primo byte e se il tuo sito fa un uso efficace delle CDN.» (web.dev, “Audit performance”)

Dove gli strumenti gemelli di questo gruppo — Google Lighthouse, PageSpeed Insights e Chrome UX Report (CrUX) — ti danno un punteggio o un esito positivo/negativo, WebPageTest ti dà l’evidenza richiesta per richiesta, fotogramma per fotogramma, alla base del punteggio.

Una breve storia — e una nota a piè di pagina davvero strana

Patrick Meenan ha creato e reso open-source WebPageTest nel 2008; è nato come strumento di test interno presso AOL. Catchpoint lo ha acquisito nel 2020. La pagina About racconta direttamente la storia delle origini: “Catchpoint’s 2020 acquisition of WebPageTest, created and open-sourced by Patrick Meenan in 2008, marked a significant milestone.” (traduzione) «L’acquisizione di WebPageTest da parte di Catchpoint nel 2020, creato e reso open-source da Patrick Meenan nel 2008, ha segnato una tappa significativa.» La missione dichiarata è schietta: “slow is the new down, and our mission is to empower you to deliver the best experiences to your users.” (traduzione) «lento è il nuovo giù, e la nostra missione è darti gli strumenti per offrire le migliori esperienze ai tuoi utenti.» (webpagetest.org/about)

Ecco la strana nota a piè di pagina che vale la pena menzionare: Meenan ora lavora presso Google su Chrome e sulle prestazioni web. Eppure la pagina ufficiale degli strumenti Core Web Vitals di Google — web.dev/articles/vitals-tools, l’esatta pagina che il documento Core Web Vitals di Search Central collega come “the different tools that can help you measure and report Core Web Vitals” — non menziona WebPageTest. Elenca CrUX, PageSpeed Insights, Search Console, Lighthouse, il pannello Performance di DevTools, la libreria JS web-vitals e Lighthouse-CI. Lo strumento costruito dalla persona che ora lavora lì è assente.

Leggilo attentamente, però: non è un segnale che WebPageTest sia deprecato o non approvato. Google cura la propria lista di strumenti di prodotto; uno strumento open-source di terze parti semplicemente non c’è. Altre pagine di web.dev (speed-tools, performance-audit-tools) citano WebPageTest in modo positivo. È una lacuna di curatela, non un verdetto sullo strumento.

Lab vs. campo — la distinzione che conta di più

Questa è la spina dorsale dell’accuratezza dell’intero argomento, ed è la sorella del punto lab-vs-campo che attraversa l’intero gruppo di strumenti per le prestazioni web.

WebPageTest esegue dati di laboratorio (sintetici): un test controllato e ripetibile su una macchina che configuri, in un momento che scegli. È una cosa diversa dai dati di campo — le misurazioni reali degli utenti del Chrome UX Report (CrUX) che Google Search usa effettivamente per il segnale di ranking Core Web Vitals, e che compaiono in PageSpeed Insights e Search Console.

Quindi, chiaramente:

• Un’esecuzione di WebPageTest non alimenta il segnale di ranking di Google. Misura le stesse metriche a cui Google tiene (LCP, INP, CLS), ma il numero su cui Google si basa per il ranking proviene dai dati di campo CrUX, non da alcuna esecuzione di laboratorio — né quella di WebPageTest, né la sezione lab di PSI, né quella di Lighthouse.
• WebPageTest serve per la diagnosi: riprodurre un problema, isolarlo e confermare una correzione in un ciclo rapido e controllato. I dati di campo (CrUX) sono la conferma lenta e autorevole che gli utenti reali hanno percepito il miglioramento — vedi Core Web Vitals per come funziona quel segnale di ranking.

In parole povere, un risultato di WebPageTest non è — e non può sostituire — i dati di campo CrUX, i numeri di traffico reale degli utenti, o un posizionamento su Google Search o un esito di page experience. Questi sono set di dati separati che richiedono le proprie prove; un’esecuzione sintetica veloce non è la prova che nessuno di essi sia cambiato.

Se devi ricordare solo una cosa da questa pagina: WebPageTest ti dice cosa correggere; CrUX ti dice se il segnale di ranking di Google è cambiato.

Come eseguire un test di base

Il flusso principale è volutamente semplice:

1. URL. La pagina pubblica che vuoi testare (deve essere raggiungibile pubblicamente).
2. Posizione del test. WebPageTest viene eseguito su macchine reali distribuite fisicamente in tutto il mondo — scegline una vicina al tuo pubblico, perché la distanza e le condizioni di rete cambiano il risultato.
3. Browser / dispositivo. Chrome ti offre la maggior parte dei dati. Puoi anche emulare dispositivi mobili.
4. Profilo di connessione. Una rete limitata (ad es. una connessione mobile lenta) così testi condizioni realistiche, non la fibra del tuo ufficio.
5. Esecuzioni ripetute. Questo è ciò che i principianti saltano. Le prestazioni variano da un’esecuzione all’altra (jitter di rete, carico del server, contesa della CPU), quindi WebPageTest esegue più test e riporta una mediana. Non fidarti mai di una singola esecuzione — leggi la mediana. Tieni presente che la mediana è comunque un campione sintetico della configurazione scelta, non una misura a livello di popolazione di ciò che i visitatori reali sperimentano — è a questo che servono i dati di campo (CrUX).

Ognuna di queste impostazioni fa parte dell’esperimento, non è un dettaglio secondario. Se stai confrontando due test — prima/dopo una correzione, o il tuo sito contro quello di un concorrente — il confronto ha senso solo quando registri le impostazioni e le mantieni costanti: stessa posizione, stesso browser, stesso profilo di connessione, stesso stato della cache (prima vista vs. vista ripetuta), e approssimativamente lo stesso numero di esecuzioni e finestra temporale. Se cambi una di queste tra le esecuzioni, puoi facilmente scambiare una deriva della configurazione del test per una differenza di prestazioni reale.

Leggere i risultati

Il grafico a cascata

La cascata è una timeline richiesta per richiesta: una riga per risorsa, in ordine di caricamento, ogni barra mostra le fasi DNS/connect/TLS/wait/download. Evidenzia le risorse che bloccano il rendering, mostra le catene di reindirizzamento come hop extra, e rende ovvio quando una manciata di risorse in cima sta bloccando tutto ciò che sta dietro. È qui che “ridurre le risorse che bloccano il rendering” smette di essere un’astrazione e diventa “quel file CSS, a quel secondo.”

La vista connessione

Raggruppata per connessione piuttosto che per richiesta, questa vista espone la ricerca DNS, la connessione TCP, la negoziazione TLS e il tempo al primo byte (TTFB) per host. È il modo più rapido per vedere se la tua lentezza è lato server/rete (un TTFB lento, troppe connessioni separate) rispetto al lato contenuti.

La striscia di film / vista video — e la mia ricetta per la caccia al CLS

La striscia di film è una striscia di screenshot della pagina che si dipinge nel tempo; la vista video la riproduce. È così che vedi — non deduci — quando appare il tuo contenuto principale e quando qualcosa nella pagina salta.

Questa è la funzionalità di WebPageTest su cui faccio più affidamento, e l’ho illustrata ripetutamente nei talk e nella mia guida Ahrefs Core Web Vitals. Per dare la caccia al Cumulative Layout Shift, la ricetta esatta che uso: “In Filmstrip View, use the following options: Highlight Layout Shifts, Thumbnail Size: Huge, Thumbnail Interval: 0.1 secs.” (traduzione) «Nella vista Filmstrip, usa le seguenti opzioni: Evidenzia spostamenti di layout, Dimensione miniatura: Enorme, Intervallo miniatura: 0,1 s.» Questo trasforma la striscia di film in una timeline ad alta risoluzione in cui uno spostamento è impossibile da non notare. Nell’esempio reale di quella guida, il colpevole era un cambio di font — “Notice how our font restyles between 5.1 secs and 5.2 secs, shifting the layout as our custom font is applied.” (traduzione) «Nota come il nostro font si ristilizza tra 5,1 s e 5,2 s, spostando il layout mentre il nostro font personalizzato viene applicato.» I font web, le immagini a caricamento tardivo e gli annunci iniettati sono i soliti sospetti del CLS, e la striscia di film li cattura visivamente sul fatto.

Un avvertimento: una risorsa che termina il caricamento nella waterfall nello stesso momento in cui il filmstrip mostra un salto è una forte prova circostanziale, non una prova definitiva — è un’ipotesi. Confermala isolando il sospetto (blocca quel dominio/richiesta, o rimandala) e rieseguendo la stessa configurazione; se lo spostamento scompare, hai confermato la causa invece di limitarti a correlare due timeline.

Core Web Vitals, fotogramma per fotogramma

WebPageTest riporta LCP, CLS e (con interazione reale) INP insieme a TTFB, FCP e Speed Index — e ti permette di vedere dove nel caricamento ciascuno di essi è avvenuto, invece di un semplice valore finale. Dove i dati sul campo CrUX sono disponibili, possono essere mostrati insieme ai risultati di laboratorio, ma le diagnosi approfondite provengono dall’esecuzione di laboratorio.

Funzionalità avanzate

• Scripting / flussi multi-step. Testa pagine dietro un login, o un flusso di carrello/checkout — scrivi gli step così WebPageTest misura un percorso reale, non solo una homepage a freddo. Controlla e annota da cosa dipende lo script: l’account/le credenziali di test usate, lo stato dell’account, eventuali contenuti dinamici sulla pagina e la tua quota API — uno script non documentato è difficile da confrontare tra esecuzioni quanto un test manuale non documentato.
• Blocco di domini / richieste. Blocca un dominio di terze parti specifico e riesegui per misurare esattamente quanto ti costa quel widget di chat o script pubblicitario. Questo è qualcosa che PSI semplicemente non può fare.
• Lighthouse dentro WebPageTest. “WebPageTest vs. Lighthouse” è una falsa dicotomia — puoi eseguire un audit Lighthouse dall’interno di WebPageTest. Vale la pena essere precisi su cosa significa: l’audit Lighthouse è un report distinto e versionato a sé — con il suo punteggio 0–100 e il suo elenco di audit — generato all’interno della più ampia sessione di test WebPageTest, non fuso nelle metriche native waterfall/filmstrip di WebPageTest. Come ho detto nella guida Ahrefs, la maggior parte degli strumenti di velocità usa Lighthouse sotto il cofano: “The exception is WebPageTest, although you can also run Lighthouse tests with it as well.” (traduzione) «L’eccezione è WebPageTest, anche se puoi eseguire anche test Lighthouse con esso.» (Ahrefs — Core Web Vitals)
• Opportunities & Experiments. Una funzionalità di confronto prima/dopo delle modifiche HTML senza codice che ti permette di confrontare due stati di una pagina senza toccare la produzione — introdotta intorno al 2022, secondo la copertura contemporanea di Detlef Johnson su Search Engine Land (quell’articolo specifico è stato da allora rimosso dal sito, e non ho potuto riconfermare in modo indipendente il nome o la disponibilità attuale della funzionalità contro una sessione WebPageTest live durante questo aggiornamento — vale un nuovo controllo prima di costruire un flusso di lavoro attorno a quel nome).
• API / automazione e istanze private. C’è un’API per test programmatici, e poiché il codice è open source, puoi creare la tua istanza privata.

Usare WebPageTest per la SEO tecnica

Questo è l’angolo che la maggior parte delle guide su WebPageTest salta, ed è il motivo per cui lo strumento appartiene al kit di un SEO tecnico:

• Test come Googlebot. Puoi impostare uno user agent di Googlebot e osservare come si comporta la JS che blocca il rendering: un’approssimazione utile (non una replica perfetta) di come il renderer di Google potrebbe percepire la pagina. La guida tecnica SEO di MobileMoxie su WebPageTest inquadra bene il valore SEO: “The tool provides detailed information about the health of your pages and helps analyze things like round trip requests, asset errors, redirects, caching concerns, security information, and more.” (traduzione) «Lo strumento fornisce informazioni dettagliate sulla salute delle tue pagine e aiuta ad analizzare aspetti come le richieste di andata e ritorno, gli errori delle risorse, i redirect, i problemi di caching, le informazioni di sicurezza e altro ancora.»
• Controlla le catene di redirect. La waterfall mostra ogni salto di redirect, quindi una catena di redirect gonfiata (ogni salto è un round trip) è visibile invece che nascosta.
• Verifica l’efficacia di caching e CDN. Come da web.dev sopra, WebPageTest controlla il caching dei contenuti statici, il TTFB e l’uso della CDN: la struttura che determina la velocità con cui bot e utenti ricevono i tuoi byte.
• Diagnostica i problemi di rendering JS. Se il contenuto appare solo dopo l’esecuzione di JavaScript, la filmstrip e la waterfall mostrano quando (e se) è stato renderizzato.
• Prove prima/dopo per gli stakeholder. Una filmstrip affiancata della pagina attuale rispetto a una correzione proposta è un artefatto molto più persuasivo per un cliente o un team di ingegneria rispetto a un punteggio Lighthouse sceso di sei punti.

Prezzi e accesso

Il servizio pubblico gratuito su webpagetest.org ha storicamente offerto circa centinaia di esecuzioni di test al mese, oltre a una chiave API gratuita con limiti giornalieri. Un livello a pagamento WebPageTest Pro sblocca più volume API, test privati e priorità nella coda di test. E poiché l’intero progetto è open source con la licenza Polyform Shield — la prospettiva di Catchpoint è che “the WebPageTest code remains freely accessible under the Polyform Shield license, permitting its use for internal or non-competing commercial projects” (webpagetest.org/about) (traduzione) «il codice di WebPageTest rimane liberamente accessibile con la licenza Polyform Shield, consentendone l’uso per progetti commerciali interni o non concorrenti» — puoi anche ospitare da solo un’istanza privata.

Limiti onesti

• Curva di apprendimento. L’interfaccia è densa; una waterfall è intimidatoria prima di essere utile.
• Account necessario per risultati salvati/privati. I test singoli casuali sono aperti, ma salvare e testare in privato richiede un account.
• Diagnostica, non risolve. WebPageTest mostra il problema in dettaglio squisito; non ti prende per mano attraverso la correzione come fanno alcuni strumenti di punteggio.
• Variabilità di una singola esecuzione. Una singola esecuzione può trarre in inganno. Usa più esecuzioni e leggi la mediana: lo strumento usa questa impostazione di default per un motivo.

Una nota su Bing

Non esiste documentazione Bing o Microsoft che posizioni WebPageTest come input di ranking o raccomandazione di prima parte. Bing Webmaster Tools ha il proprio Site Scan e raccomandazioni relative alla velocità, ma nulla di specifico per WebPageTest — e Core Web Vitals stesso rimane principalmente un costrutto di Google. (Non confondere WebPageTest con il bing.com/tools/speedtest di Bing, che è un test di velocità di rete, non uno strumento di prestazioni delle pagine.)

Dove si colloca

Questo è il membro di diagnostica approfondita del cluster strumenti per le prestazioni web. I suoi fratelli hanno ciascuno un compito diverso: Google Lighthouse è l’audit di laboratorio che produce il punteggio 0–100 (e che molti altri strumenti eseguono internamente); PageSpeed Insights mostra i dati sul campo CrUX e un’esecuzione di laboratorio Lighthouse in un’unica interfaccia; il Chrome UX Report (CrUX) è il dataset sul campo degli utenti reali su cui Google si basa per il ranking. Per le metriche che tutti questi misurano e le soglie che Google usa, inizia dall’hub Core Web Vitals. Per l’intera pipeline in cui questi strumenti si inseriscono, vedi il cluster sulle prestazioni web.

Riepilogo AI

Una sintesi della versione Advanced:

• WebPageTest = lo strumento di diagnostica approfondita basato su laboratorio per le prestazioni. Gratuito e open source; creato da Patrick Meenan nel 2008 (uno strumento interno di AOL), acquisito da Catchpoint nel 2020, codice sotto licenza Polyform Shield.
• Ogni risultato è una singola esecuzione configurata — un URL, una località, un browser, un profilo di connessione, un momento nel tempo — non una misurazione universale. I confronti hanno senso solo quando registri queste impostazioni e le mantieni costanti.
• Laboratorio, non campo. Produce dati sintetici di laboratorio e non alimenta il segnale di ranking Core Web Vitals di Google — quello è CrUX di utenti reali (visibile in PageSpeed Insights e Search Console). Un’esecuzione di WebPageTest non stabilisce traffico di utenti reali né un esito di ranking/esperienza di pagina — serve per la diagnosi, non per il numero su cui Google si basa per il ranking.
• Il flusso: URL → posizione di test distribuita reale → browser/dispositivo → rete limitata → più esecuzioni ripetute, leggi la mediana (mai una singola esecuzione — anche se la mediana è comunque un campione sintetico, non dati di campo).
• Viste caratteristiche: waterfall (richiesta per richiesta, flag di blocco del rendering, catene di reindirizzamento), filmstrip/video (fotogramma per fotogramma; un’opzione Highlight Layout Shifts per il CLS), vista connessione (DNS/TCP/TLS/TTFB), e Core Web Vitals fotogramma per fotogramma. Allineare un evento del waterfall con un fotogramma del filmstrip è un’ipotesi forte, non una prova — confermalo isolando la risorsa e rieseguendo il test.
• Ricetta CLS: Filmstrip View → Highlight Layout Shifts attivo, Thumbnail Size Huge, Thumbnail Interval 0,1 s — il modo per cogliere uno spostamento da font-swap o immagine tardiva in flagrante.
• Non è un concorrente di Lighthouse — puoi eseguire un audit Lighthouse dall’interno di WebPageTest, ma è un report distinto e versionato (proprio punteggio, propri audit), non integrato nelle metriche native di WebPageTest. Altre funzionalità avanzate: scripting/flussi multi-step (documenta credenziali/stato/quote), blocco di domini di terze parti, una funzionalità di confronto prima/dopo senza codice introdotta intorno al 2022 (il suo nome/disponibilità attuale non è stato riconfermato in modo indipendente in questa passata), un’API e self-hosting.
• Usi SEO: testa come Googlebot, audita le catene di reindirizzamento, controlla caching/CDN/TTFB, diagnostica il rendering JS e produci prove prima/dopo per gli stakeholder.
• Nota curiosa: Meenan ora lavora a Google, eppure la pagina ufficiale degli strumenti CWV di Google (web.dev/articles/vitals-tools) non elenca WebPageTest. Questa è una lacuna di curatela per uno strumento di terze parti, non un segnale che sia deprecato.
• Limitazioni: UI densa/curva di apprendimento, account necessario per test salvati/privati, diagnostica piuttosto che risolve, e singole esecuzioni possono trarre in inganno.

Documentazione ufficiale

Documentazione di fonti primarie (le menzioni di WebPageTest da parte di Google, la documentazione di WebPageTest stessa e una nota su Bing).

WebPageTest / Catchpoint

• WebPageTest — About — la storia delle origini Meenan/Catchpoint, la dichiarazione di intenti e la licenza Polyform Shield.
• WebPageTest — il servizio di test pubblico gratuito, inclusi il modulo di test, l’interfaccia dei risultati/filmstrip e l’API per test programmatici.

Google (dove menziona WebPageTest — e dove notoriamente non lo fa)

• web.dev — How To Think About Speed Tools — colloca WebPageTest come opzione avanzata di diagnostica di laboratorio e nota che puoi eseguire Lighthouse al suo interno.
• web.dev — Audit performance — WebPageTest per controlli di caching/TTFB/CDN.
• web.dev — Core Web Vitals tools — la raccolta degli strumenti CWV di Google, che non menziona WebPageTest (la nota sulla lacuna di curatela).
• Google Search Central — Core Web Vitals — rimanda a web.dev per le raccomandazioni sugli strumenti piuttosto che nominare uno strumento di laboratorio di terze parti.

Bing / Microsoft

• Nessuna documentazione Bing/Microsoft fa riferimento a WebPageTest come input di ranking o raccomandazione di prima parte. Il Site Scan di Bing Webmaster Tools è l’analogo di prima parte più vicino. Vedi linee guida per i webmaster di Bing per indicazioni generali.

Citazioni dalla fonte

Dichiarazioni pubbliche su WebPageTest. Dove un link include un’ancora #:~:text=, salta al passaggio citato nella pagina di origine.

Google / web.dev — dove si colloca WebPageTest

• “WebPageTest contains an advanced suite of metrics and trace viewers. It enables deep diving into the performance of your site on real mobile hardware with network conditions.” (traduzione) «WebPageTest contiene una suite avanzata di metriche e visualizzatori di trace. Consente di approfondire le prestazioni del tuo sito su hardware mobile reale con condizioni di rete.» — web.dev, “How To Think About Speed Tools.” Vai alla citazione
• “WebPagetest will also check static-content caching, time to first byte, and if your site makes effective use of CDNs.” (traduzione) «WebPagetest controllerà anche la cache dei contenuti statici, il tempo al primo byte e se il tuo sito fa un uso efficace delle CDN.» — web.dev, “Audit performance.” Vai alla citazione

WebPageTest / Catchpoint — storia, missione, licenza

• “Catchpoint’s 2020 acquisition of WebPageTest, created and open-sourced by Patrick Meenan in 2008, marked a significant milestone.” (traduzione) «L’acquisizione di WebPageTest da parte di Catchpoint nel 2020, creato e reso open-source da Patrick Meenan nel 2008, ha segnato una tappa significativa.» — webpagetest.org/about. Fonte
• “slow is the new down, and our mission is to empower you to deliver the best experiences to your users.” (traduzione) «lento è il nuovo giù, e la nostra missione è darti gli strumenti per offrire le migliori esperienze ai tuoi utenti.» — webpagetest.org/about. Fonte
• “The WebPageTest code remains freely accessible under the Polyform Shield license, permitting its use for internal or non-competing commercial projects.” (traduzione) «Il codice di WebPageTest rimane liberamente accessibile sotto la licenza Polyform Shield, che ne consente l’uso per progetti commerciali interni o non concorrenti.» — Catchpoint, webpagetest.org/about. Fonte

Patrick Stox (io) / Ahrefs — la tecnica del filmstrip per il CLS

• “In Filmstrip View, use the following options: Highlight Layout Shifts, Thumbnail Size: Huge, Thumbnail Interval: 0.1 secs.” (traduzione) «Nella vista Filmstrip, usa le seguenti opzioni: Evidenzia spostamenti di layout, Dimensione miniatura: Enorme, Intervallo miniatura: 0,1 s.» — dal mio articolo su Ahrefs Core Web Vitals. Fonte
• “The exception is WebPageTest, although you can also run Lighthouse tests with it as well.” (traduzione) «L’eccezione è WebPageTest, anche se puoi eseguire anche test Lighthouse con esso.» — io, su come WebPageTest differisce dagli strumenti basati su Lighthouse. Fonte

MobileMoxie — l’angolo della SEO tecnica

• “The tool provides detailed information about the health of your pages and helps analyze things like round trip requests, asset errors, redirects, caching concerns, security information, and more.” (traduzione) «Lo strumento fornisce informazioni dettagliate sulla salute delle tue pagine e aiuta ad analizzare cose come richieste di andata e ritorno, errori delle risorse, reindirizzamenti, problemi di cache, informazioni di sicurezza e altro.» — MobileMoxie, su WebPageTest per la SEO tecnica. Fonte

Cheat sheet di WebPageTest

Dove si colloca rispetto agli altri strumenti

Le viste

Ricetta per la caccia al CLS (la mia)

• Filmstrip View → Highlight Layout Shifts attivo → Thumbnail Size: Huge → Thumbnail Interval: 0,1 secs. Osserva il frame in cui il layout salta (spesso un cambio di web-font o un’immagine/pubblicità tardiva).

Fatti rapidi

• Lab, non field — non alimenta il segnale di ranking CWV di Google (quello è CrUX).
• Leggi la mediana, mai un singolo run — le prestazioni variano da run a run.
• Puoi eseguire Lighthouse dentro WebPageTest — non è un aut-aut.
• Open source con licenza Polyform Shield; l’auto-hosting è possibile.
• Meenan (creatore) ora lavora a Google, eppure web.dev/articles/vitals-tools non elenca WebPageTest — una lacuna di curation, non una deprecazione.

Un run di WebPageTest — checklist

Ottieni un risultato affidabile e utile invece che fuorviante:

• Posizione del test impostata vicino al tuo pubblico reale (la distanza cambia i numeri).
• Profilo dispositivo + connessione corrispondente ai tuoi utenti (es. mobile emulato su una rete limitata), non alla tua fibra in ufficio.
• Più run ripetuti abilitati — e stai leggendo la mediana, non un singolo run.
• Controllato il waterfall per risorse render-blocking e hop di redirect superflui.
• Controllata la connection view per un TTFB lento o troppe connessioni separate.
• Eseguita la filmstrip per vedere quando viene renderizzato il contenuto principale — e, per il CLS, abilitata Highlight Layout Shifts a intervalli di 0,1s, anteprime Huge.
• Confermato che tratti il risultato come dati lab — incrociato il vero segnale di ranking con CrUX (PageSpeed Insights / Search Console).
• Per una terza parte sospetta, usato domain/request blocking per misurarne il costo reale.
• Per i flussi di login/checkout, usato scripting invece di testare una homepage fredda.
• Salvata una filmstrip prima/dopo se proponi una correzione agli stakeholder.

Strumenti che si abbinano a WebPageTest

• WebPageTest stesso (webpagetest.org) — lo strumento lab pubblico gratuito, più l’API e un livello Pro a pagamento per test in volume/privati.
• PageSpeed Insights — il modo rapido per controllare i dati field (CrUX) che WebPageTest non può generare, così sai se il segnale di ranking si è effettivamente mosso.
• Google Search Console — report Core Web Vitals — trova gruppi di pagine che falliscono su larga scala nel sito, poi porta un URL rappresentativo in WebPageTest per diagnosticare.
• Pannello Performance di Chrome DevTools — il compagno locale, compatibile con i login, per la profilazione lab quando non servono posizioni distribuite.
• Google Lighthouse — eseguibile da dentro WebPageTest, o standalone in DevTools/CLI per l’audit 0–100.
• CrUX Vis (cruxvis.withgoogle.com) — visualizza la tendenza field degli utenti reali nel tempo per confermare che una correzione diagnosticata con WebPageTest sia arrivata agli utenti reali. (Vedi Chrome UX Report (CrUX).)

Errori di WebPageTest che creano falsa fiducia

Trattare un test di laboratorio come il verdetto sul campo di Google

WebPageTest è un dato sintetico proveniente dal dispositivo, dalla posizione, dal browser e dal profilo di rete che hai selezionato. Usalo per diagnosticare le cause; usa CrUX o RUM di prima parte per descrivere gli utenti reali e la valutazione CWV di Google.

Confrontare test con impostazioni diverse

Una posizione, una connessione, un browser, uno stato della cache o un numero di test modificati possono superare la modifica del codice che stai testando. Salva la configurazione e confronta elementi simili con elementi simili.

Ottimizzare il punteggio principale invece del waterfall

Il valore di WebPageTest è la sequenza delle richieste, la configurazione della connessione, i filmstrip e i tempi delle metriche. Traccia la metrica lenta fino a una richiesta concreta o a un evento del thread principale, piuttosto che ottimizzare un voto isolatamente.

Giudicare una modifica da un singolo test

I test di laboratorio variano. Esegui più test con lo stesso profilo e confronta i risultati rappresentativi; indaga sui valori anomali invece di selezionare il test più veloce.

Testare solo la homepage

Template diversi hanno elementi LCP, script, terze parti e comportamento della cache diversi. Includi le pagine in cui gli utenti e i dati sul campo mostrano il problema reale.

Dimostrare una modifica delle prestazioni in WebPageTest

Test controllato prima/dopo

Test da eseguire: salva una configurazione di posizione/browser/rete/cache ed esegui più test per le versioni invariata e modificata. Risultato atteso: la metrica target e la sua causa nel waterfall migliorano nei test rappresentativi. Interpretazione del fallimento: la modifica è inefficace o la varianza del test supera l’effetto. Finestra di monitoraggio: risultato di laboratorio immediato. Trigger di rollback: una regressione coerente nella metrica target o in una Core Web Vital adiacente.

Test di sequenza delle richieste

Test da eseguire: confronta i waterfall dopo aver modificato preload, priorità, CSS/JS bloccanti o caching. Risultato atteso: la richiesta prevista inizia prima, trasferisce meno byte o evita la rete nello stato di cache previsto. Interpretazione del fallimento: l’hint/la configurazione non è stata applicata o un’altra dipendenza controlla la sequenza. Finestra di monitoraggio: immediata. Trigger di rollback: la modifica ritarda una richiesta più critica o crea errori.

Test di correttezza visiva

Test da eseguire: ispeziona filmstrip/video e l’evidenziazione degli spostamenti di layout per lo stesso profilo prima/dopo. Risultato atteso: un rendering più veloce non introduce contenuti mancanti, flash o nuovi spostamenti. Interpretazione del fallimento: il miglioramento numerico ha sacrificato la correttezza visiva. Finestra di monitoraggio: ogni viewport rappresentativo prima del rilascio. Trigger di rollback: contenuti rotti o una nuova instabilità visibile.

Risorse che meritano il tuo tempo

I miei scritti correlati

• Core Web Vitals: A Complete Guide (Ahrefs) — include la mia ricetta WebPageTest Filmstrip per diagnosticare il Cumulative Layout Shift, l’inquadramento WebPageTest-vs-Lighthouse e le metriche che WebPageTest misura insieme a come funziona il lato ranking. (Questa pagina ha assorbito il mio precedente post “Advanced Guide to PageSpeed Insights”, che ora reindirizza qui.)
• The Beginner’s Guide to Technical SEO (Ahrefs) — dove si colloca la performance web nel quadro più ampio.

I miei interventi

• Page Experience Update — TMC, June 2021 (SlideShare) — copre la stessa tecnica WebPageTest Filmstrip/CLS in forma di talk.
• A Crash Course in Technical SEO — Beer & SEO Meetup, May 2019 (SlideShare) — WebPageTest come parte del toolkit SEO tecnico, nel 2019.

Dal settore

• WebPageTest — About — la fonte primaria per la storia, la missione e la licenza Polyform Shield.
• How To Think About Speed Tools (web.dev) — il posizionamento di WebPageTest da parte di Google tra gli strumenti di test di laboratorio.
• Audit performance (web.dev) — WebPageTest per controlli su caching, TTFB e CDN.
• How to Set Up WebPageTest to Evaluate Technical SEO (MobileMoxie) — la guida esistente più vicina all’angolazione SEO (user agent di Googlebot, redirect, caching, errori delle risorse).
• A Complete Guide to Using WebPageTest (Kinsta) — la spiegazione generale più completa (storia, configurazione, interpretazione dei risultati, prezzi).
• WebPageTest: A Guide To Web Performance Testing (DebugBear) — scritto dal fornitore, ma una buona analisi della media su più esecuzioni, delle viste waterfall/filmstrip/connection e dello scripting.

Mettiti alla prova: WebPageTest

Cinque domande rapide su cos’è WebPageTest, come leggerlo e dove si colloca. Scegli una risposta per ciascuna, poi controlla.

Cronologia modifiche