Misurare e valutare correttamente il tempo di caricamento del sito web

Quanto è veloce il mio sito web? La domanda sembra semplice, ma non può essere risposta completamente con un solo numero.

Un sito web non ha un solo momento in cui è „caricato“. Il browser inizia a connettersi al server, riceve l'HTML, carica ulteriori risorse e costruisce gradualmente da queste la pagina visibile e interattiva.

Ecco perché diversi strumenti di performance possono mostrare metriche diverse per lo stesso sito web, senza che nessuno di essi sia necessariamente errato.

In questa guida ti spieghiamo come misurare in modo utile il tempo di caricamento di un sito web, quali parametri sono importanti e come valutare correttamente i risultati della misurazione.

Breve spiegazione: Non giudicare la velocità di un sito web in base a un singolo tempo di caricamento o a un singolo test. Più significativa è la combinazione di più misurazioni, diverse metriche di prestazione e, se disponibili, dati di visitatori reali.

Perché non esiste un unico tempo di caricamento? #

Durante la visita a un sito web si verificano numerosi processi in successione e in parte contemporaneamente.

In sintesi:

Aprire l'URL
    ↓
Stabilire la connessione
    ↓
Il server elabora la richiesta
    ↓
L'HTML viene trasmesso
    ↓
Il browser elabora l'HTML
    ↓
Caricamento di CSS, JavaScript, immagini e font
    ↓
I primi contenuti diventano visibili
    ↓
Il contenuto principale importante appare
    ↓
Ulteriori risorse vengono caricate
    ↓
La pagina risponde alle interazioni dell'utente

A seconda della parte di questo processo presa in considerazione da uno strumento, si ottiene un valore di misura diverso.

Cosa influenza il tempo di ricarica misurato? #

Una misurazione non dipende solo dal sito web stesso.

Anche le condizioni del test influenzano il risultato. Tra queste rientrano, ad esempio:

• Ubicazione del sistema di test,
• Velocità di rete e latenza,
• dispositivo utilizzato o hardware simulato,
• Browser,
• Stato della cache,
• Carico del server,
• servizi e risorse esterni.

Ecco perché lo stesso sito web può fornire risultati diversi in due misurazioni.

Cosa significa TTFB? #

TTFB sta per Tempo al primo byte.

L'indicatore descrive in modo semplificato il tempo tra l'inizio di una richiesta e l'arrivo del primo byte della risposta HTTP.

Inizio della richiesta
      ↓
Connessione / Richiesta / Elaborazione
      ↓
primo byte della risposta
      ↑
     TTFB

Il TTFB può fornire indicazioni sulla prima parte della richiesta, ma non è una misurazione completa del tempo di caricamento del sito web.

Ad esempio, un buon TTFB non significa automaticamente che in seguito immagini grandi, JavaScript esteso o risorse esterne vengano elaborate rapidamente.

Il TTFB non è solo la „velocità del server“ #

Il TTFB viene spesso definito in modo semplicistico come il solo tempo di risposta del web server. Questo non è preciso.

Il valore misurato può comprendere diverse componenti, tra cui i tempi di rete e di connessione, nonché l'elaborazione della richiesta sul lato server.

Anche la posizione del sistema di misurazione rispetto al server può quindi avere un'influenza.

Importante: Usa il TTFB come valore diagnostico, ma non come unica valutazione della velocità di un sito web o di un server di hosting.

Cosa significa FCP? #

FCP sta per First Contentful Paint.

Il valore descrive il momento in cui il browser esegue per la prima volta il rendering del contenuto del documento, ad esempio testo, un'immagine o altri elementi visibili.

FCP considera quindi un aspetto diverso rispetto al TTFB.

Il server risponde
      ↓
Il browser elabora la pagina
      ↓
viene visualizzato il primo contenuto rilevante
      ↑
     FCP

Cosa significa LCP? #

LCP sta per Largest Contentful Paint.

L'indicatore considera quando il principale elemento di contenuto rilevante è stato visualizzato nell'area visibile.

A seconda della pagina, questo può essere ad esempio un'immagine grande, un titolo o un altro blocco di contenuto.

Un grande hero image può quindi avere un impatto notevole sul LCP.

Spieghiamo l'esatto significato di LCP, INP e CLS su Core Web Vitals spiegati: LCP, INP e CLS.

Cosa significa „completamente carico“? #

Anche il termine „completamente carico“ non è così chiaro come sembra a prima vista.

Un sito web può già sembrare completamente utilizzabile per il visitatore, mentre in background vengono ancora elaborate ulteriori risorse o richieste.

Viceversa, un evento di carica tecnica potrebbe essere già avvenuto, sebbene un'importante funzione esterna non sia ancora pronta.

Perciò una singola indicazione come „Load Time: 2,1 Sekunden“ non dovrebbe essere considerata isolatamente.

Cosa sono i dati di laboratorio? #

I dati di laboratorio vengono generati in condizioni di test controllate o simulate.

Uno strumento di performance carica il sito web in condizioni definite e misura diverse metriche.

Questo ha un grande vantaggio: i test possono essere ripetuti in condizioni simili e confrontati tra loro.

I dati di laboratorio sono quindi particolarmente adatti alla diagnosi tecnica e al confronto prima e dopo una modifica.

Cosa sono i dati di campo? #

I dati di campo si basano su misurazioni effettuate in condizioni di utilizzo reali.

Mostrano come un sito Web sia stato effettivamente vissuto da visitatori reali, ovvero su dispositivi e condizioni di rete reali, a condizione che siano disponibili dati sufficienti relativi al sito Web o all'URL in questione.

Ciò consente ai dati sul campo di offrire una prospettiva diversa rispetto a un singolo test di laboratorio.

Breve spiegazione: I dati di laboratorio mostrano come un sito web funziona in determinate condizioni di test. I dati di campo mostrano come è stato effettivamente vissuto in condizioni di utilizzo reale.

Perché i dati di laboratorio e quelli sul campo possono essere diversi? #

Un test di laboratorio utilizza condizioni definite. I visitatori reali, invece, utilizzano dispositivi, browser, connessioni di rete e posizioni geografiche differenti.

Ad esempio, un computer desktop potente con una connessione veloce può visualizzare un sito Web in modo diverso rispetto a uno smartphone più datato su una rete mobile.

Risultati differenti non costituiscono pertanto automaticamente una contraddizione.

Cosa sono i Core Web Vitals? #

I Core Web Vitals sono parametri utilizzati per misurare determinati aspetti dell'esperienza utente di un sito web.

Attualmente ne fanno parte:

LCP → Largest Contentful Paint
      esperienza di caricamento

INP → Interaction to Next Paint
      reattività

CLS → Cumulative Layout Shift
      stabilità visiva

Questi tre valori considerano diversi aspetti di un sito web e non dovrebbero quindi essere combinati in un unico tempo di caricamento generale.

Quali valori di misurazione sono importanti per me? #

Questo dipende da cosa vuoi esaminare.

Se vuoi sapere se il server risponde tempestivamente a una richiesta, il TTFB può essere interessante.

Se vuoi sapere quando compaiono importanti contenuti visibili, le metriche di rendering come FCP e LCP sono più utili.

Se gli utenti segnalano risposte ritardate alle interazioni, a sua volta l'interattività è rilevante.

Una buona analisi delle prestazioni inizia quindi con la domanda:

Quale problema desidero effettivamente misurare?

Misurare un sito web con Google PageSpeed Insights #

Google PageSpeed Insights è un noto strumento per l'analisi delle performance dei siti web.

Può mostrare dati di laboratorio da Lighthouse e – qualora siano disponibili dati sufficienti per la pagina o l'origine in questione – dati di utilizzo reali dal Chrome User Experience Report.

Ciò rende PageSpeed Insights adatto sia per una prima analisi tecnica sia per la valutazione dei Core Web Vitals.

I singoli settori e le raccomandazioni verranno spiegati nel prossimo articolo alla pagina Usare correttamente Google PageSpeed Insights.

Considerare separatamente dispositivi mobili e desktop #

I risultati delle prestazioni per i dispositivi mobili e i sistemi desktop possono variare notevolmente.

Non è una sorpresa: uno smartphone possiede caratteristiche prestazionali diverse e può accedere a un sito web tramite una connessione di rete differente rispetto a un PC desktop.

Non giudicare quindi esclusivamente il test desktop, solo perché lì viene raggiunto un valore di performance più elevato.

Se una parte considerevole dei tuoi visitatori utilizza dispositivi mobili, l'utilizzo da mobile è almeno altrettanto rilevante.

Perché è importante il luogo del test? #

I dati devono essere trasferiti tra il sistema di test e i server coinvolti.

Maggiore o più sfavorevole è la distanza di rete e il percorso, maggiore può essere la latenza.

Un sito Web con un pubblico di riferimento principale in Svizzera o nell'Europa centrale non dovrebbe pertanto essere valutato esclusivamente sulla base di un singolo test proveniente da una posizione molto lontana.

Per misurazioni comparabili, dovresti utilizzare postazioni di test il più possibile simili.

Cosa significa latenza? #

In parole semplici, la latenza descrive il ritardo nella trasmissione dei dati tra due punti.

Non è la stessa cosa della larghezza di banda.

Una connessione può avere una velocità di dati massima elevata e tuttavia presentare una latenza relativamente elevata.

Nelle pagine web possono verificarsi numerose operazioni di rete, motivo per cui la latenza può essere rilevante per la velocità percepita.

La cache influenza i risultati delle misurazioni #

Durante il primo accesso a un sito web, potrebbero dover essere caricate risorse che, in una visita successiva, saranno già presenti nella cache del browser.

Anche i sistemi di cache lato server possono fare in modo che una risposta già preparata o memorizzata nella cache venga fornita più rapidamente rispetto a una richiesta che deve essere generata completamente da zero.

Per questo motivo dovresti sapere se misuri in cosiddette condizioni fredde o già riscaldate.

Cosa significano Cold Cache e Warm Cache? #

In sintesi:

Cold Cache
→ i dati necessari non sono ancora presenti nella cache pertinente

Warm Cache
→ i dati necessari sono già disponibili in una cache

Quali cache siano coinvolte dipende dal sito web e dall'infrastruttura.

Nei confronti delle prestazioni, dovresti misurare in condizioni il più possibile simili.

Un singolo test non basta #

Le reti e i server non lavorano in condizioni completamente costanti.

Una misurazione può essere influenzata, ad esempio, da un ritardo di rete a breve termine o da un servizio esterno.

Esegui quindi diverse misurazioni e fai attenzione a modelli ricorrenti.

Esempio:

Test 1 → 1,8 s
Test 2 → 2,0 s
Test 3 → 1,9 s

altro test:

Test 1 → 1,7 s
Test 2 → 8,4 s
Test 3 → 1,8 s

Nel secondo esempio, si dovrebbe prima esaminare il motivo per cui una misurazione si discosta nettamente dalla norma, prima di trarre da ciò una conclusione generale sul sito web.

Confrontare sempre la stessa URL #

La pagina iniziale non è automaticamente rappresentativa dell'intero sito web.

Una semplice pagina di contatto, ad esempio, può richiedere molte meno risorse rispetto a una pagina di prodotto complessa o a un negozio online.

Quando confronti le ottimizzazioni, utilizza pertanto la stessa URL prima e dopo la modifica.

Prima:
/produkt/beispiel/

Dopo:
/produkt/beispiel/

Solo così puoi confrontare lo stesso tipo di pagina.

Testare diversi tipi di pagine importanti #

Per una valutazione più completa, non dovresti misurare esclusivamente la homepage.

A seconda del sito web, ad esempio, possono essere utili i seguenti tipi di pagine:

Home page
importante pagina dei servizi
articolo del blog
landing page
pagina prodotto
pagina di categoria dello shopping
checkout

Una singola pagina veloce non dimostra che tutte le altre aree abbiano le stesse prestazioni.

Documentare i test prima e dopo le modifiche #

Se vuoi valutare una misura di performance, dovresti documentare lo stato iniziale e finale.

Esempio:

URL:
https://example.com/beispiel/

Test:
da cellulare

Teststandort:
stesso

Datum:
stessa finestra di test

VOR Änderung:
Annotare le metriche

Änderung:
Immagine Hero ottimizzata

NACH Änderung:
Rilevare nuovamente le metriche

Ciò ti consente di valutare meglio se la modifica specifica ha effettivamente portato a un miglioramento misurabile.

Non cambiare dieci cose contemporaneamente #

Se comprimi contemporaneamente le immagini, modifichi la cache, disattivi i plugin, rimuovi JavaScript e cambi la versione di PHP, il sito web potrebbe risultare più veloce, ma difficilmente saprai quale misura ha prodotto quale effetto.

Per una diagnosi accurata, le modifiche controllate sono preferibili.

Consiglio pratico: Misurare → apportare una modifica tracciabile → misurare di nuovo. In questo modo capirai molto meglio quale ottimizzazione funziona davvero.

Il punteggio delle prestazioni e il tempo di caricamento non sono la stessa cosa #

Molti strumenti di analisi calcolano un punteggio a partire da diversi valori di misura.

Un tale punteggio è utile per classificare rapidamente i risultati, ma non coincide con un tempo di caricamento misurato direttamente.

Un valore come:

Prestazione: 92

significa non:

Il sito web è veloce al 92 %.

Il punteggio viene calcolato in base a una specifica metodologia a partire da diversi valori misurati.

Non ottimizzare esclusivamente per 100 punti #

Un punteggio perfetto può essere un obiettivo motivante, ma non dovrebbe diventare un fine a se stesso.

Un intervento può teoricamente migliorare un valore misurato e allo stesso tempo peggiorare il sito web effettivo – ad esempio se un'immagine importante viene visivamente compressa in modo eccessivo o se viene rimossa una funzione necessaria.

L'ottimizzazione delle prestazioni dovrebbe quindi tenere sempre conto sia delle metriche tecniche che dell'effettiva esperienza degli utenti.

Perché due strumenti di performance possono fornire risultati diversi? #

Strumenti diversi possono utilizzare posizioni di test, profili di dispositivi, condizioni di rete, browser o metodi di calcolo differenti.

Ecco perché non dovresti confrontare acriticamente i numeri assoluti di diversi servizi.

Per i confronti prima e dopo è opportuno utilizzare, per quanto possibile, lo stesso strumento con impostazioni comparabili.

Che significa analisi a cascata? #

Una visualizzazione a cascata, o waterfall, mostra quali risorse carica una pagina e quando iniziano o finiscono le rispettive richieste.

In sintesi:

HTML       ███████
CSS           ████
Caratteri           █████
Immagine 1          █████████
Immagine 2             ███████
JavaScript       ███████████
API                      █████

Con questo puoi, ad esempio, riconoscere se un file immagine di grandi dimensioni, un servizio esterno o un'altra risorsa richiede molto tempo.

Il solo numero di richieste non è una misura di qualità #

Una pagina con più richieste HTTP non è automaticamente più lenta di una pagina con meno richieste.

Anche le dimensioni, la priorità, la memorizzazione nella cache, il protocollo, le dipendenze e l'elaborazione delle risorse giocano un ruolo importante.

Una semplice direttiva sugli obiettivi come „meno di 50 richieste“ non è quindi una regola di performance universale.

Valutare correttamente la dimensione totale di una pagina #

La quantità di dati trasferiti è un'indicazione utile, in particolare per i siti web ricchi di immagini.

Tuttavia, dovrebbe essere considerata anche nel suo contesto.

Una galleria fotografica richiede naturalmente più dati di immagine rispetto a una semplice pagina di testo.

L'obiettivo non è costringere ogni sito Web alla stessa dimensione complessiva, ma evitare trasferimenti di dati non necessari.

Spieghiamo come preparare le immagini in modo efficiente su Ottimizzare le immagini per il web: dimensione del file, formato e SEO.

Le risorse esterne possono influenzare le performance #

I siti web caricano spesso contenuti da altri servizi.

Questi possono includere, ad esempio:

Webfont
Servizi di analisi
Video
Mappe
Contenuti di social media
Servizi pubblicitari o di tracciamento
Librerie JavaScript esterne

Non controlli completamente da solo il tempo di risposta di queste risorse.

Se un servizio esterno risponde lentamente, questo può quindi ripercuotersi su determinati aspetti del tuo sito web.

Un sito web lento non significa automaticamente un hosting lento #

Quando un sito web sembra lento, spesso viene immediatamente ritenuto responsabile il server di hosting.

Questa può essere una possibile causa, ma non è affatto l'unica.

Un sito web può essere rallentato, ad esempio, da immagini di grandi dimensioni, complesse query di database, plugin, temi, JavaScript o servizi esterni.

Viceversa, un'applicazione inefficiente può rimanere lenta anche su un'infrastruttura potente.

Come isolare sistematicamente tali cause lo trattiamo sotto Sito web lento: trovare sistematicamente le cause.

Differenza tra ora del server e ora del frontend #

Per la diagnosi è utile distinguere a grandi linee tra la generazione o la fornitura di una risposta e la successiva elaborazione nel browser.

Server / Backend
→ Elaborare la richiesta
→ Fornire HTML

Browser / Frontend
→ Analizzare l'HTML
→ Elaborare il CSS
→ Eseguire JavaScript
→ Caricare le immagini
→ Visualizzare la pagina

Se il server risponde velocemente, ma il browser deve successivamente elaborare risorse molto grandi, la pagina può comunque sembrare lenta.

Viceversa, un frontend snello può essere rallentato da un'elaborazione lato server molto lenta.

Perché una connessione internet veloce può ingannare uno sviluppatore #

Chi testa un sito web tramite una connessione in fibra ottica veloce e un computer potente potrebbe quasi non notare alcun ritardo.

Tuttavia, i visitatori possono avere condizioni diverse.

Ecco perché le condizioni di test mobili simulate e i dati di utilizzo reali sono utili. Mostrano aspetti che difficilmente si noterebbero accedendo da una postazione di lavoro veloce.

Testare le prestazioni su uno smartphone #

Oltre agli strumenti automatizzati, vale la pena fare un vero test pratico.

Apri le pagine importanti su uno smartphone e osserva come si comporta effettivamente il sito web.

Osserva, per esempio:

Quando compaiono i contenuti principali?

Il layout si sposta durante il caricamento?

Posso interagire rapidamente con la pagina?

Le immagini compaiono in tempo?

Un banner dei cookie blocca l'utilizzo?

La navigazione risponde immediatamente?

Tali osservazioni non sostituiscono una misurazione tecnica, ma la integrano utilmente.

Testare il sito web non solo da utenti autenticati #

I sistemi di gestione dei contenuti possono comportarsi in modo diverso per gli amministratori registrati rispetto ai normali visitatori.

Le cache possono essere aggirate, ad esempio, per gli utenti registrati.

Perciò, testa ulteriormente il sito web pubblico in una finestra di navigazione in incognito, in cui non sei connesso al CMS.

Evitare misurazioni durante i lavori di manutenzione #

Se sono in corso backup, importazioni, aggiornamenti o altri lavori intensivi, le misurazioni potrebbero non essere rappresentative.

Lo stesso vale per una struttura di cache appena svuotata, se in realtà vuoi valutare il normale stato del visitatore.

Documenta quindi le condizioni di test in caso di confronti importanti.

Qual è un buon tempo di caricamento? #

La domanda su un unico „buon tempo di caricamento“ è troppo generale.

Google definisce soglie concrete per i Core Web Vitals. Per l'LCP, ad esempio, una valutazione fino a 2,5 secondi al 75° percentile è considerata „buona“.

Ciò non significa tuttavia che qualsiasi altra metrica di tempo di caricamento concepibile debba anch'essa essere complessivamente inferiore a 2,5 secondi.

Diverse metriche misurano cose diverse.

Importante: Non trasferire semplicemente il limite di una determinata metrica di prestazione a tutti gli altri valori dei tempi di caricamento.

Che cosa significa 75º percentile? #

Con i dati di utilizzo reali non si prendono semplicemente in considerazione singoli valori ottimali o medi.

Il 75° percentile significa semplicemente che il 75 percento delle esperienze considerate raggiunge un valore pari o superiore a questa soglia.

In questo modo non si considerano solo le singole chiamate particolarmente rapide.

Prestazioni e SEO #

Le prestazioni del sito web possono essere rilevanti anche in relazione alla ricerca Google. I Core Web Vitals fanno parte dei segnali di esperienza utente presi in considerazione da Google.

Tuttavia, ciò non significa che un punteggio di performance migliore porti automaticamente a un determinato miglioramento del posizionamento.

Le performance tecniche dovrebbero essere ottimizzate soprattutto perché un sito web veloce e stabile è più fruibile per i visitatori.

La misurazione delle prestazioni è una diagnosi, non una competizione #

Ha poco senso confrontare esclusivamente un punteggio con un sito web completamente diverso.

Un semplice blog, un negozio online complesso e un'applicazione web hanno requisiti differenti.

Più significativa è la domanda:

Dove si trovano i colli di bottiglia concreti del mio sito web e quali di questi posso migliorare utilmente?

Rivalutare regolarmente le performance #

Un sito web sta cambiando.

Nuovi plugin, immagini, script di tracciamento, font, video o funzionalità possono influenzare le performance.

Ecco perché una misurazione non è valida per sempre.

Soprattutto dopo modifiche importanti vale la pena effettuare un nuovo controllo.

Quando dovrei misurare di nuovo? #

Una nuova misurazione delle prestazioni è particolarmente utile dopo:

Rilancio del sito web
Cambio di tema
modifiche importanti ai plugin
nuovi script di tracciamento o marketing
inserimento di immagini o video di grandi dimensioni
modifiche alla cache
modifiche al server o a PHP
estensioni importanti del negozio

L'accessibilità di un sito web è diversa dalle prestazioni #

Un sito web può essere raggiungibile e ciononostante rispondere lentamente.

Al contrario, un test delle prestazioni non misura automaticamente in modo affidabile se un sito web è disponibile 24 ore su 24.

Per il monitoraggio continuo della raggiungibilità vengono impiegati sistemi di monitoraggio.

Trattiamo questo argomento sotto Monitoraggio di siti web: monitorare la disponibilità e le interruzioni.

Procedura pratica per una misurazione delle prestazioni #

selezionare un URL rappresentativo
↓
stabilire le condizioni di test
↓
testare su dispositivi mobili e desktop
↓
effettuare più misurazioni
↓
documentare i valori misurati
↓
identificare le risorse anomale
↓
indagare su una causa specifica
↓
apportare una modifica mirata
↓
misurare nuovamente in condizioni comparabili
↓
valutare il risultato

Quali valori dovrei documentare? #

Quali dati siano utili dipende dallo strumento utilizzato. Per un confronto riproducibile, ad esempio, possono essere utili le seguenti informazioni:

URL testata
data e ora
strumento di test
dispositivo mobile o desktop
luogo del test, se selezionabile
TTFB
FCP
LCP
altri Core Web Vitals
quantità di dati trasferiti
risorse problematiche
modifica effettuata

Ciò ti consente di classificare molto meglio le misurazioni successive.

Errori comuni nella misurazione della velocità del sito web #

eseguire un solo test
testare solo la homepage
considerare solo il desktop
confrontare direttamente strumenti diversi
ignorare diverse località di test
non considerare lo stato della cache
confondere il punteggio delle prestazioni con i secondi
ottimizzare solo per 100 punti
apportare più modifiche contemporaneamente
attribuire immediatamente qualsiasi sito web lento all'hosting
valutare le metriche senza l'effettiva esperienza utente

Lista di controllo per una misurazione significativa #

Quale URL desidero analizzare?
        ↓
Quale problema desidero misurare?
        ↓
Le condizioni del test sono comparabili?
        ↓
Considerati sia dispositivi mobili che desktop?
        ↓
Eseguiti più test?
        ↓
Distinto tra dati di laboratorio (Lab) e dati reali (Field)?
        ↓
Considerati separatamente TTFB e rendering?
        ↓
Verificate le risorse problematiche?
        ↓
Eseguita una sola modifica mirata?
        ↓
Misurato nuovamente nelle stesse condizioni?
        ↓
Testato personalmente anche il sito web reale?

Riepilogo #

La velocità di un sito web non può essere descritta in modo sensato con un unico numero. Durante il caricamento di una pagina, la risposta del server, la rete, il browser, le immagini, i CSS, JavaScript, i servizi esterni e molti altri fattori agiscono insieme.

Metriche come TTFB, FCP e LCP esaminano diverse sezioni di questo processo. I dati di laboratorio vengono generati in condizioni di test controllate, mentre i dati reali (field data) riflettono le esperienze di utilizzo nel mondo reale.

Per confronti significativi, dovresti testare più volte lo stesso URL in condizioni il più possibile comparabili, prendendo in considerazione sia gli scenari mobili che quelli desktop.

Un punteggio di performance rappresenta un orientamento utile, ma non è un fine a sé stesso. L'aspetto fondamentale è identificare colli di bottiglia specifici e verificare successivamente se un'ottimizzazione mirata porti effettivamente a un miglioramento.

Una buona analisi delle prestazioni non significa raccogliere più numeri possibile. Significa misurare in condizioni comparabili, comprendere le metriche giuste e dedurre la giusta misura tecnica.