Ogni volta che qualcuno apre una pagina del tuo sito inizia un piccolo negoziato: da una parte c’è l’attenzione dell’utente, dall’altra il tempo che il sito impiega a mostrarsi, a rispondere e a restare stabile. Le Web Performance sono il modo in cui misuriamo e governiamo questo negoziato. Non sono un dettaglio tecnico da lasciare agli sviluppatori, ma una caratteristica del prodotto che incide su vendite, contatti, costi pubblicitari e reputazione del marchio.
In questo articolo proviamo a rispondere in modo ordinato a tre domande: che cosa si intende davvero per Web Performance, come si misurano in modo affidabile e perché dovrebbero interessare chi prende decisioni di business, non solo chi scrive codice.
Una definizione operativa
Con Web Performance si indica la velocità e la reattività con cui un sito o un’applicazione web si rendono utilizzabili per le persone che li visitano. La definizione è volutamente centrata sull’utente: non ci interessa quanto è potente il server o quanto è leggero il codice in astratto, ma quanto tempo passa prima che l’utente veda il contenuto che cercava, quanto rapidamente la pagina reagisce quando tocca un pulsante e se il layout resta fermo mentre legge.
È una distinzione importante, perché per anni la velocità è stata raccontata con numeri che dicevano poco dell’esperienza reale: il tempo di caricamento completo, il peso della pagina, il numero di richieste. Sono utili per la diagnosi, ma l’utente percepisce soprattutto quando vede ciò che cerca e quando può usarlo.
Per questo oggi si parla di performance percepita e la si scompone in tre momenti: quando il contenuto principale diventa visibile, quanto velocemente la pagina risponde alle interazioni e quanto è stabile visivamente. Sono esattamente i tre aspetti che Google ha codificato nei Core Web Vitals.
Le metriche che contano: i Core Web Vitals
I Core Web Vitals sono tre metriche standardizzate, misurate nei browser degli utenti reali e valutate al 75° percentile: significa che una pagina è considerata “buona” solo se almeno tre visite su quattro rientrano nella soglia, non se lo è la media.
| Metrica | Cosa misura | Soglia “buona” | Soglia “scarsa” |
|---|---|---|---|
| LCP (Largest Contentful Paint) | Quando compare il contenuto principale | entro 2,5 s | oltre 4 s |
| INP (Interaction to Next Paint) | Quanto rapidamente la pagina risponde a clic, tocchi e tasti | entro 200 ms | oltre 500 ms |
| CLS (Cumulative Layout Shift) | Quanto si spostano gli elementi durante la visita | entro 0,1 | oltre 0,25 |
Accanto a queste tre metriche ne esistono altre di supporto, preziose per capire da dove nasce un problema. Il TTFB (Time to First Byte) misura quanto tempo impiega il server a iniziare a rispondere; il FCP (First Contentful Paint) indica quando compare il primo elemento sullo schermo. Non fanno parte dei Core Web Vitals, ma un TTFB alto rende quasi impossibile ottenere un buon LCP: se il server impiega un secondo e mezzo a rispondere, il margine per tutto il resto si riduce drasticamente.
Dati sul campo e dati di laboratorio
Uno degli equivoci più diffusi riguarda il modo in cui le performance vengono misurate. Esistono due famiglie di dati, e confonderle porta a decisioni sbagliate.
I dati sul campo (field data) sono raccolti dai browser di utenti reali, con i loro dispositivi, le loro connessioni e i loro comportamenti. La fonte pubblica più nota è il Chrome UX Report (CrUX), che Google usa anche per valutare l’esperienza delle pagine nella ricerca. Sono i dati che raccontano la verità, ma arrivano aggregati su una finestra di 28 giorni: un miglioramento rilasciato oggi si vede per intero solo dopo quattro settimane.
I dati di laboratorio (lab data) sono prodotti da strumenti come Lighthouse o PageSpeed Insights, che caricano la pagina in condizioni simulate e ripetibili. Sono indispensabili per la diagnosi, perché mostrano cosa succede durante il caricamento e permettono di verificare subito l’effetto di una modifica. Ma restano una simulazione: un punteggio di 95 in laboratorio non garantisce che gli utenti reali, magari su uno smartphone di fascia media e in mobilità, vivano un’esperienza veloce.
Il punteggio di laboratorio serve a capire il perché. Solo i dati degli utenti reali dicono se il problema è risolto.
Un approccio serio usa entrambe le prospettive: i dati sul campo per stabilire dove intervenire e per verificare i risultati, il laboratorio per individuare le cause e testare le soluzioni. Quando possibile, a CrUX si affianca un monitoraggio degli utenti reali (RUM) sul proprio sito, che permette di scendere al dettaglio della singola pagina, del singolo elemento e della singola interazione.
Perché le performance sono una questione di business
La ragione per cui un’azienda dovrebbe occuparsi di Web Performance non è ottenere un punteggio verde, ma il fatto che la velocità modifica il comportamento delle persone. Ogni secondo di attesa è un momento in cui l’utente può cambiare idea, tornare ai risultati di ricerca o aprire il sito di un concorrente.
Le ricerche pubbliche su questo tema sono numerose e coerenti. Uno studio di Google del 2017 sul traffico mobile ha stimato che, quando il tempo di caricamento passa da uno a tre secondi, la probabilità che l’utente abbandoni la pagina aumenta del 32%. Un’analisi condotta da Deloitte nel 2020 su 37 marchi europei e statunitensi ha osservato che un miglioramento di appena un decimo di secondo nella velocità da mobile si associava a un aumento medio delle conversioni dell’8,4% nel retail e del 10,1% nel turismo. Sono medie, e ogni sito ha la sua storia, ma la direzione è sempre la stessa: meno attesa significa più persone che arrivano in fondo al percorso.
Le conseguenze concrete di un sito lento si manifestano in più punti del conto economico:
- Conversioni perse. Carrelli abbandonati, moduli di contatto non inviati, iscrizioni interrotte. Il traffico c’è, ma una parte si disperde prima di diventare valore.
- Budget pubblicitario meno efficiente. Una campagna paga ogni clic, anche quello di chi abbandona prima che la landing page si carichi. Inoltre, nelle piattaforme pubblicitarie l’esperienza sulla pagina di destinazione concorre alla qualità dell’annuncio e quindi al costo per clic.
- Visibilità organica. L’esperienza delle pagine, di cui i Core Web Vitals fanno parte, è uno dei segnali considerati da Google. Non basta da sola a scalare le classifiche, ma a parità di pertinenza dei contenuti può fare la differenza, e un sito lento viene anche scansionato meno in profondità.
- Percezione del marchio. Un’interfaccia che si blocca o salta mentre la si usa comunica trascuratezza, anche quando prodotti e servizi sono eccellenti. La fiducia si costruisce anche con la sensazione che “tutto funzioni”.
- Costi di infrastruttura. Un’applicazione inefficiente richiede più risorse per servire lo stesso traffico. Spesso si risponde con server più grandi, che nascondono il problema senza risolverlo e aumentano i costi fissi.
C’è poi un aspetto spesso sottovalutato: la lentezza non colpisce tutti allo stesso modo. Chi naviga dall’ufficio con la fibra può non accorgersi di nulla, mentre chi arriva da una campagna social con uno smartphone di qualche anno fa vive un sito completamente diverso. E spesso è proprio questa la quota più ampia del traffico.
Da dove nasce la lentezza
Un sito lento raramente ha una sola causa. Nella nostra esperienza i problemi si distribuiscono su due livelli, che vanno sempre analizzati insieme.
Il primo è il livello server: tutto ciò che accade prima che il browser riceva la pagina. Qui pesano la configurazione del web server, la versione di PHP o del linguaggio usato, la presenza e la correttezza della cache di pagina, l’object cache, lo stato del database, la latenza di rete e l’uso di protocolli moderni come HTTP/3. Una cache configurata male, ad esempio, può essere scavalcata da un semplice cookie e costringere il server a generare ogni pagina da zero.
Il secondo è il livello applicazione: ciò che il browser deve scaricare, interpretare ed eseguire. Immagini non ottimizzate o caricate senza priorità, font che bloccano il testo, fogli di stile e script che crescono a ogni nuovo plugin, widget e tag di terze parti eseguiti tutti all’avvio, elementi inseriti dopo il primo rendering che spostano il contenuto. Nei CMS più diffusi, come WordPress, WooCommerce, Magento o PrestaShop, questo accumulo è quasi fisiologico: ogni funzione aggiunta per il marketing o per la gestione porta con sé il proprio codice.
Separare i due livelli è fondamentale anche per non sprecare budget: ottimizzare il front-end di un sito che ha un TTFB di due secondi produce risultati modesti, così come potenziare il server non risolve un INP compromesso da JavaScript di terze parti.
Il limite delle scorciatoie
Il mercato offre molte soluzioni “a un clic”: plugin di ottimizzazione, servizi che promettono punteggi perfetti, configurazioni preimpostate. Alcune sono utili, ma nessuna conosce il tuo sito. Rinviare tutto il JavaScript al primo clic può migliorare il punteggio di laboratorio e peggiorare l’INP reale, perché il lavoro non scompare: si sposta nel momento in cui l’utente interagisce. Rimuovere automaticamente il CSS “inutilizzato” può rompere menu, filtri e stati dinamici che il test non ha visto.
Esistono persino tecniche che servono una versione diversa del sito agli strumenti di test, ottenendo punteggi eccellenti mentre gli utenti reali continuano ad aspettare. È il motivo per cui un punteggio verde, da solo, non dimostra nulla: conta ciò che misurano i dati sul campo.
Un metodo sostenibile
Migliorare le performance in modo duraturo richiede un percorso strutturato più che un intervento isolato. Il metodo che applichiamo si articola in quattro fasi:
- Misurare. Partire dai dati sul campo per capire quali pagine e quali metriche sono critiche, per quali dispositivi e con quale impatto sul traffico reale.
- Diagnosticare. Usare il laboratorio e il monitoraggio degli utenti reali per risalire alle cause, distinguendo ciò che dipende dal server da ciò che dipende dall’applicazione.
- Intervenire per priorità. Ordinare le modifiche in base al rapporto tra impatto atteso e costo, partendo dalle pagine che generano più valore: schede prodotto, categorie, landing page delle campagne, articoli più letti.
- Verificare e mantenere. Confrontare i dati prima e dopo, sulla stessa finestra temporale, e mettere in piedi controlli che impediscano di tornare indietro a ogni nuovo plugin, banner o script di marketing.
L’ultima fase è quella che distingue un progetto riuscito da un miglioramento temporaneo. Un sito è un organismo che cambia ogni settimana, e le performance vanno trattate come un requisito permanente, con soglie condivise tra sviluppo, marketing e fornitori.
In sintesi
Le Web Performance misurano quanto velocemente un sito diventa utile per chi lo visita: quando mostra il contenuto, quanto rapidamente risponde e quanto resta stabile. Si valutano con i Core Web Vitals, osservati sugli utenti reali e interpretati con l’aiuto del laboratorio. E incidono direttamente sui risultati: conversioni, costo delle campagne, visibilità, reputazione e costi di infrastruttura.
Trattarle come un tema tecnico marginale significa accettare, spesso senza saperlo, di perdere una parte del valore che il sito potrebbe generare. Trattarle come una leva di business significa misurare, scegliere le priorità e intervenire là dove il tempo degli utenti si trasforma in risultati.
