Velocità sito web: come analizzare, testare e ottimizzare la velocità del tuo sito

Cosa si intende quando parliamo di velocità di un sito web

Velocità del sito: la definizione tradizionale

Quando parliamo di velocità di un sito web, il primo pensiero va al tempo necessario per caricare una pagina. Questa definizione tradizionale misura quanto impiega il browser a scaricare e visualizzare tutti gli elementi: HTML, CSS, JavaScript, immagini, font.
In questo approccio, la prima distinzione principale è tra contenuto above the fold (sopra la piega) e contenuto below the fold (sotto la piega). Il primo è ciò che l’utente vede immediatamente senza scorrere, il secondo quello che appare solo dopo lo scroll. In questo contesto, l’idea è che tutto ciò che è visibile (above the fold) migliori la percezione di velocità.
La velocità percepita dall’utente diventa quindi centrale: non conta solo quando il caricamento è tecnicamente completo, ma quando l’utente percepisce che può iniziare a usare la pagina.

Una nuova definizione di velocità

Il problema della definizione tradizionale di velocità è che il caricamento completo non coincide più con l’esperienza effettiva dell’utente. Un sito può aver scaricato tutti i file e risultare “caricato” secondo i parametri tradizionali, ma restare inutilizzabile perché gli elementi si spostano continuamente, i pulsanti non rispondono o le immagini compaiono con ritardo causando salti nel layout.
La velocità espressa come numero singolo (secondi di caricamento, percentuale, punteggio) non descrive la qualità reale dell’esperienza. Due siti possono caricare in 2 secondi, ma uno può essere immediatamente utilizzabile mentre l’altro frustrante e confuso.
Dobbiamo quindi considerare che la velocità di caricamento è solo una componente delle ottimizzazioni delle performance di un sito web, e se vogliamo una misurazione più completa dobbiamo sempre fare riferimento ai Core Web Vitals.
Oggi la velocità del sito web deve essere intesa come stabilità, reattività e fluidità dell’interazione, non solo come rapidità di download.

Perché la velocità del sito web è considerata importante

Le ragioni per cui la velocità viene considerata importante sono ben note. Un sito veloce offre comunque una migliore esperienza utente, riducendo la frustrazione e l’attesa e lo stesso Google ha dichiarato di considerare la velocità come un fattore di ranking, quindi teoricamente migliori performance, significano maggiore visibilità organica.
È certo che la velocità influisce sulla riduzione del bounce rate: se una pagina impiega troppo tempo a caricare, l’utente abbandona prima ancora di vedere il contenuto. Di conseguenza, un sito più veloce dovrebbe generare un aumento delle conversioni, perché utenti più soddisfatti completano più facilmente le azioni desiderate.

Perché la velocità, da sola, non garantisce risultati

Ma la velocità da sola non garantisce automaticamente questi risultati. L’esperienza utente e le conversioni dipendono da numerosi fattori: chiarezza del messaggio, qualità dei contenuti, architettura informativa, design, accessibilità, fiducia nel brand.
Un sito veloce ma confuso, con navigazione poco intuitiva o contenuti irrilevanti, resta inefficace. La velocità è un prerequisito necessario, non un obiettivo sufficiente. Serve per rimuovere una frizione, ma non sostituisce la strategia, la progettazione e la qualità.
Ottimizzare esclusivamente la velocità senza considerare il contesto complessivo rischia di produrre miglioramenti tecnici senza impatto reale sul business.

Come testare la velocità di un sito web

Approccio tradizionale al test della velocità

L’approccio più comune per testare la velocità di un sito web prevede l’utilizzo di tool automatici come PageSpeed Insights, GTmetrix o WebPageTest. Questi strumenti analizzano una singola pagina, simulano il caricamento in condizioni controllate e restituiscono un punteggio accompagnato da suggerimenti di ottimizzazione.
Il test è semplice: inserisci l’URL, avvii l’analisi, ottieni un numero (da 0 a 100 in PageSpeed Insights) e una lista di problemi da risolvere. La valutazione si basa su metriche tecniche standardizzate.

Perché i test automatici non raccontano tutta la storia

Il limite dei test automatici è che operano in condizioni ideali e controllate: connessione stabile, browser pulito, nessuna estensione attiva, hardware performante. Gli utenti reali navigano in contesti molto diversi: connessioni mobili instabili, dispositivi meno potenti, browser con estensioni attive.
I tool misurano performance tecniche, non l’esperienza d’uso concreta. Un sito può ottenere 95 in PageSpeed Insights (un valore molto alto) ma risultare lento nella percezione dell’utente reale perché elementi critici caricano con ritardo o l’interfaccia è instabile.
Una citazione la merita Chrome DevTools che permette di simulare throttling di rete e CPU per avvicinarsi maggiormente alle condizioni reali ed ottenere, seppur in condizioni controllate, dei dati più vicini a quelli degli utenti reali.
Per testare efficacemente la velocità del sito web è necessario integrare i test automatici con verifiche su dispositivi reali, in condizioni reali, ed è imprescindibile, per un’analisi qualitativa, l’utilizzo di Google Search Console per il monitoraggio di tutte le metriche relative ai Core Web Vitals, in grado di misurare l’intera esperienza degli utenti effettivi del sito.

Analisi della velocità sito web

Analisi tecnica secondo i parametri classici

Entrando maggiormente nel dettaglio, l’analisi della velocità di un sito web non è solo l’espressione di un risultato finale, ma si concentra su vari aspetti infrastrutturali e tecnici. I numeri che generano il punteggio finale sono infatti il risultato di misurazioni parziali che tengono conto di aspetti quali:

• L‘hosting e la configurazione del server che influenzano il tempo di risposta iniziale
• Il peso complessivo delle pagine (misurato in MB) che determina quanto deve scaricare il browser
• Il numero di richieste HTTP che indica quanti file diversi devono essere recuperati.
• Script e risorse esterne (librerie JavaScript, font, video embed, tracking) che aggiungono ulteriori richieste e dipendenze da server terzi, rallentando il caricamento e introducendo variabilità.

Questi parametri tecnici sono oggettivamente misurabili e confrontabili, e permettono di pianificare gli interventi necessari al miglioramento della velocità di caricamento, ma raccontano solo una parte della storia.

Analisi della velocità come analisi dell’esperienza

Al di là di quanto abbiamo già detto a proposito dell’esperienza utente e dei Core Web Vitals, e cercando di rimanere nel perimetri della velocità di caricamento, un’analisi più completa della velocità deve considerare necessariamente aspetti come:
La stabilità visiva durante il caricamento: la fine del caricamento di una pagina non si può limitare a quando gli elementi sono visibili, ma anche a quando sono stabili e non cambiano la propria posizione.
Il tempo di interazione è breve: una pagina non può considerarsi caricata solo quando tutti gli elementi sono visibili, ma quando per l’utente sono utilizzabili e i tempi di reazione all’azione dell’utente sono altrettanto veloci.
L’analisi della velocità diventa quindi analisi qualitativa dell’esperienza complessiva.

Le metriche della velocità di un sito web

Le metriche moderne della velocità si concentrano sull’esperienza percepita. Le quattro metriche Core Web Vitals più rilevanti nel 2026 sono:

• LCP (Largest Contentful Paint): misura quanto tempo impiega il contenuto principale della pagina a diventare visibile. Idealmente sotto 2.5 secondi.
• INP (Interaction to Next Paint): sostituisce la precedente FID e misura la reattività complessiva del sito alle interazioni dell’utente. Idealmente sotto 200 millisecondi.
• CLS (Cumulative Layout Shift): quantifica la stabilità visiva, misurando quanto gli elementi si spostano durante il caricamento. Idealmente sotto 0.1.
• TTFB (Time to First Byte): misura la velocità del server nel rispondere alla richiesta iniziale. Pur non essendo un Core Web Vital, influenza tutte le altre metriche.

Nel nostro processo di misurazione della velocità di caricamento, a queste, aggiungiamo altri parametri altrettanto importanti:

• FCP (First Contentful Paint): misura quando il primo elemento di contenuto (testo, immagine, canvas) diventa visibile sullo schermo. È il primo segnale all’utente che il sito sta effettivamente caricando qualcosa. Idealmente sotto 1.8 secondi.
• Speed Index: quantifica la rapidità con cui il contenuto visibile della pagina viene popolato. A differenza di metriche puntuali come LCP o FCP, lo Speed Index considera l’intera progressione visiva del caricamento. Idealmente sotto 3.4 secondi.
• Page Weight: indica il peso totale della pagina, sommando dimensioni di HTML, CSS, JavaScript, immagini, font e altre risorse. Non esiste un valore universale ideale, ma pagine sotto i 2 MB sono generalmente più gestibili, specialmente su connessioni mobili.
• Total Request: conta il numero totale di richieste HTTP necessarie per caricare completamente la pagina. Ogni richiesta aggiunge overhead e potenziali punti di fallimento. Idealmente sotto le 50-60 richieste per pagine standard, anche se questo valore dipende fortemente dalla complessità del sito.

L’analisi della waterfall per comprendere il caricamento delle risorse

Le metriche numeriche forniscono indicatori sintetici, ma per comprendere realmente cosa rallenta un sito è necessario analizzare la waterfall disponibile in strumenti come WebPageTest e Chrome DevTools. La waterfall mostra graficamente l’ordine e la tempistica di ogni singola richiesta: quale risorsa viene scaricata, quando inizia, quanto tempo impiega, quali dipendenze esistono tra le risorse.
Questa visualizzazione rivela problemi invisibili ai punteggi aggregati: script bloccanti che impediscono il rendering del contenuto, risorse caricate in sequenza quando potrebbero essere parallele, file di terze parti che rallentano l’intero caricamento, risorse critiche richieste troppo tardi nel processo. Un sito può avere 50 richieste totali ma se sono ben orchestrate risulta più veloce di uno con 30 richieste mal organizzate.
L’analisi della waterfall permette di identificare priorità concrete: quali risorse spostare in alto nella sequenza di caricamento, quali rendere asincrone, quali eliminare o sostituire. È il livello di dettaglio necessario per passare da ottimizzazioni generiche a interventi mirati che producono miglioramenti reali nelle metriche che contano.

Come ottimizzare la velocità del sito web

Ottimizzazione della cache

La cache è un meccanismo che memorizza copie temporanee di risorse per evitare di rigenerarle o scaricarle ogni volta. Esistono diversi livelli di cache, ciascuno con uno scopo specifico.

• Browser cache: il browser dell’utente memorizza localmente CSS, JavaScript, immagini e font. Una volta scaricati, questi file non vengono più richiesti al server nelle visite successive, riducendo drasticamente i tempi di caricamento per utenti ricorrenti.
• Server cache: il server memorizza la versione HTML completa della pagina, evitando di rigenerarla a ogni richiesta. Particolarmente utile per contenuti che cambiano raramente.
• CDN cache: una Content Delivery Network distribuisce copie delle risorse su server geograficamente vicini all’utente, riducendo la latenza fisica.
• Object cache: memorizza query al database e risultati di elaborazioni complesse, accelerando la generazione dinamica delle pagine.

Il principio fondamentale è impostare intestazioni di cache corrette che indichino al browser quanto tempo conservare ogni risorsa. Risorse statiche (immagini, font, CSS, JS versionati) possono avere cache di mesi o anni. Contenuti dinamici richiedono strategie più conservative.

Impatto sulle metriche: la cache riduce TTFB (meno lavoro per il server), migliora FCP e LCP (risorse disponibili immediatamente), riduce Page Weight percepito nelle visite successive.

Utilizzo della compressione

La compressione riduce la dimensione dei file trasferiti dal server al browser attraverso algoritmi che eliminano ridondanze nei dati. I formati più utilizzati sono Gzip (standard consolidato) e Brotli (più efficiente, supporto ormai universale).
Quando il browser richiede una risorsa, segnala di accettare contenuti compressi. Il server invia il file compresso, il browser lo decomprime e lo utilizza. Questo processo è trasparente per l’utente ma riduce significativamente il tempo di trasferimento, specialmente per file testuali come HTML, CSS e JavaScript che contengono molte ripetizioni.
La compressione va applicata a tutti i file testuali. Le immagini e i video già compressi (JPEG, PNG, WebP, MP4) non beneficiano di ulteriore compressione e anzi potrebbero aumentare di dimensione. Il principio è comprimere tutto ciò che è testo, lasciare invariato ciò che è già ottimizzato.

Impatto sulle metriche: riduce Page Weight effettivo, migliora TTFB per file grandi, accelera FCP e LCP riducendo i tempi di download delle risorse critiche.

Ottimizzazione delle immagini

Le immagini costituiscono spesso la maggior parte del peso di una pagina e richiedono un’ottimizzazione articolata su più fronti.

• Formati moderni: WebP offre compressione superiore a JPEG e PNG mantenendo qualità visiva. AVIF è ancora più efficiente ma con supporto browser meno universale. Il principio è servire formati moderni ai browser che li supportano, con fallback per browser datati:

HTML
     srcset="immagine-400.webp 400w,
             immagine-800.webp 800w,
             immagine-1200.webp 1200w"
     sizes="(max-width: 600px) 400px,
            (max-width: 1200px) 800px,
            1200px"
     alt="Descrizione immagine"
     loading="lazy">

• Lazy loading: l’attributo loading=”lazy” carica le immagini solo quando stanno per entrare nel viewport. Riduce il numero di richieste iniziali e il peso della pagina al primo caricamento. Va applicato a tutte le immagini below the fold, mai a quelle immediatamente visibili che peggiorerebbero LCP.
• Impatto sulle metriche: riduce drasticamente Page Weight e Total Request, migliora LCP (se l’immagine principale è ottimizzata), migliora Speed Index riducendo il tempo di caricamento visivo complessivo.

Gestione dei font

I font personalizzati aggiungono peso e possono causare FOIT (Flash of Invisible Text) o FOUT (Flash of Unstyled Text), rendendo il testo temporaneamente illeggibile.

• CDN o self-hosted: i font da CDN come Google Fonts sono veloci e distribuiti globalmente, ma aggiungono una richiesta DNS esterna. L’hosting diretto sul proprio server elimina questa dipendenza ma richiede configurazione di cache e compressione. Il principio è valutare caso per caso: per progetti complessi con molti font, il self-hosting ottimizzato è preferibile.
• Strategie di caricamento: utilizzare font-display: swap nell’@font-face permette al browser di mostrare immediatamente un font di sistema, sostituendolo con quello personalizzato quando disponibile. Questo elimina FOIT ma può causare un breve flash visivo:

CSS    
@font-face {
 font-family: 'CustomFont';
 src: url('/fonts/custom-font.woff2') format('woff2');
 font-display: swap;
} 

Precaricare i font critici accelera la disponibilità:

HTML  
<link rel="preload" href="/fonts/custom-font.woff2" as="font" type="font/woff2" crossorigin>

Impatto sulle metriche: migliora FCP rendendo il testo immediatamente visibile, può influenzare CLS se il font di fallback ha dimensioni molto diverse da quello finale, riduce TTFB eliminando richieste DNS esterne.

Ottimizzazione di CSS e JavaScript

La gestione di CSS e JavaScript è cruciale perché questi file possono bloccare il rendering della pagina e ritardare l’interattività.

• Risorse critiche e non critiche: il CSS necessario per visualizzare il contenuto above the fold è critico e deve essere caricato immediatamente, possibilmente inline nell’HTML. Il CSS per contenuti below the fold o per interazioni successive è non critico e può essere caricato in modo differito.
  JavaScript per funzionalità non immediate (slider, modali, animazioni complesse) è non critico. Il principio è caricare il minimo indispensabile all’inizio, tutto il resto solo quando serve.
  
• Caricamento condizionale: invece di includere tutti gli script sempre, caricare solo quelli necessari per la pagina specifica o per funzionalità effettivamente attivate

JAVASCRIPT  
// Carica script solo se l'elemento esiste
if (document.querySelector('.carousel')) {
  import('./carousel.js').then(module => {
    module.initCarousel();
  });
}

• Minificazione e concatenazione: la minificazione rimuove spazi, commenti e caratteri superflui riducendo la dimensione dei file. La concatenazione unisce più file in uno solo, riducendo il numero di richieste. Attenzione però: con HTTP/2, concatenare tutto può essere controproducente perché impedisce il caricamento parallelo efficiente. Il principio è raggruppare file logicamente correlati, non tutto in un unico bundle gigante.

• Posizionamento: il CSS va nel <head> per evitare FOUC (Flash of Unstyled Content). JavaScript non critico va prima della chiusura del </body> per non bloccare il rendering, oppure nel <head> con attributi appropriati.

• Attributi defer e async: async scarica lo script in parallelo ed esegue appena disponibile, potenzialmente interrompendo il parsing HTML. defer scarica in parallelo ma esegue solo dopo il parsing completo del DOM, mantenendo l’ordine di esecuzione. Il principio è usare defer per script che dipendono dal DOM completo, async per script indipendenti (analytics, pixel tracking):

HTML
<script src="analytics.js" async></script>
<script src="main.js" defer></script>

Impatto sulle metriche: riduce drasticamente FCP e LCP eliminando blocchi al rendering, migliora INP riducendo il tempo di parsing ed esecuzione di JavaScript, riduce Page Weight e Total Request caricando solo il necessario, migliora Speed Index velocizzando il popolamento visivo della pagina.

L’importanza del refactoring

L’ottimizzazione tecnica delle risorse è necessaria ma non sufficiente se il codice stesso è inefficiente. Il refactoring del codice JavaScript e PHP (o del linguaggio back-end utilizzato) serve sia per ottimizzare le performance delle singole funzioni, sia per migliorare l’architettura complessiva del codice.

Funzioni ottimizzate riducono il tempo di esecuzione, alleggerendo il carico sulla CPU e migliorando la reattività percepita. Ma altrettanto importante è dividere il codice in moduli logici, separando funzionalità in file distinti che possono essere caricati selettivamente.
Un singolo file JavaScript di 500KB contenente tutto il codice dell’applicazione penalizza ogni pagina, anche quelle che usano solo una frazione di quel codice. Suddividere le funzionalità in moduli permette di implementare code splitting e lazy loading efficaci, caricando solo ciò che serve quando serve.

Questo approccio migliora tutte le metriche rilevanti: riduce Page Weight iniziale, diminuisce Total Request non necessarie, accelera il parsing ed esecuzione (migliore INP), rende il sito più manutenibile nel tempo. Il refactoring è un investimento che paga dividendi continui in performance e qualità del codice.

Plugin e moduli per l’ottimizzazione

Per implementare queste ottimizzazioni senza interventi manuali complessi, esistono strumenti consolidati sia per WordPress che per Prestashop.

WordPress: plugin come WP Rocket offrono cache completa (pagina, browser, preload), minificazione, lazy loading, ottimizzazione database e integrazione CDN in un’unica soluzione. W3 Total Cache è l’alternativa open source più completa, con controllo granulare su ogni aspetto della cache. Per ottimizzazioni più specifiche, Autoptimize gestisce minificazione e concatenazione, ShortPixel ottimizza automaticamente le immagini, Asset CleanUp permette di disabilitare selettivamente CSS e JavaScript per pagina.

Prestashop: il modulo PageSpeed Optimizer combina cache, compressione e lazy loading. Advanced Cache gestisce cache multi-livello con supporto Varnish. Per le immagini, Image Optimizer comprime automaticamente i caricamenti. JsMinify e CSS Optimizer gestiscono minificazione e concatenazione. Many Requests offre controllo granulare sul caricamento delle risorse.

Questi strumenti automatizzano molte best practice, ma richiedono configurazione attenta per evitare conflitti e assicurare che le ottimizzazioni migliorino effettivamente l’esperienza senza introdurre problemi di compatibilità o funzionalità.

Monitoraggio della velocità di caricamento del sito web nel tempo

Per l’attività di monitoraggio è estremamente rilevante il contesto in cui operiamo per definire la strategia da utilizzare. Se il progetto su cui interveniamo è sviluppato con un CMS, sarà periodicamente oggetto di modifiche dei contenuti, evoluzione delle funzionalità, aggiornamenti di core, temi e plugin ed è pertanto necessario pianificare un monitoraggio costante e periodico, in quanto i continui interventi, modificano gli asset considerati nelle misurazioni.

La verifica delle performance, che siano Core Web Vitals, o che si decida di limitarla alla velocità di caricamento, prevede controlli periodici utilizzando gli stessi tool di test e considerandone le loro caratteristiche.

Approfondisci sulla nostra guida per i Core Web Vitals.

Perché è importante pianificare una verifica continua e qualitativa

Strumenti quali WebPageTest sono particolarmente adatti a una misurazione controllata con risultati riferiti all’esatto momento del test e quindi rilevano immediatamente l’impatto delle modifiche e degli interventi.
Tuttavia, gli utenti, i dispositivi e i contesti d’uso cambiano continuamente. Un sito può mantenere punteggi tecnici stabili ma peggiorare come esperienza reale: nuovi contenuti, modifiche editoriali, aggiornamenti di librerie terze possono introdurre problemi non visibili nei test sintetici.

La verifica continua utilizza i dati di Google Search Console nella sezione Core Web Vitals, che mostrano l’esperienza aggregata degli utenti reali (field data) negli ultimi 28 giorni. Questi dati rivelano problemi concreti che i test di laboratorio potrebbero non intercettare.

In questo modo è possibile ottenere sia una misurazione in real-time della situazione e degli interventi effettuati senza attese di giorni, e una conferma con dati solidi sulla reale efficacia degli interventi misurando il comportamento degli utenti reali.

L’importanza delle competenze umane

L’analisi umana resta fondamentale: testare il sito manualmente su dispositivi diversi, in condizioni di rete variabili, verificando che l’esperienza sia effettivamente fluida e utilizzabile. Nessun punteggio automatico sostituisce l’osservazione diretta dell’usabilità.

Quando la velocità non è il vero problema del sito web

Non sempre un sito lento è un problema di velocità tecnica. Esistono situazioni in cui ottimizzare la velocità non risolve i problemi fondamentali.

Un sito può essere veloce ma inutilizzabile a causa di problemi di accessibilità: contrasto insufficiente tra testo e sfondo, mancanza di testi alternativi per le immagini, navigazione impossibile da tastiera. In questi casi la velocità è irrilevante.

Problemi di architettura informativa rendono il sito confuso indipendentemente dalla velocità: menu incomprensibili, contenuti mal organizzati, percorsi utente frammentati. Velocizzare un sito mal progettato non lo rende più utilizzabile.

La velocità può diventare un falso positivo: il sito ottiene 100 in PageSpeed Insights ma le conversioni restano basse perché il valore offerto non è chiaro, la call to action è debole o il processo di acquisto è complesso.

In questi scenari, investire esclusivamente nell’ottimizzazione della velocità distrae da problemi più rilevanti che impattano realmente sul business.

Conclusione

La velocità del sito web è un concetto di partenza necessario, non un punto di arrivo. È un prerequisito per offrire un’esperienza di qualità, ma non garantisce automaticamente risultati se altri elementi fondamentali (usabilità, accessibilità, contenuti, strategia) sono carenti.

Testare, analizzare e ottimizzare la velocità efficacemente richiede un approccio integrato che consideri metriche tecniche e esperienza reale, dati di laboratorio e field data, interventi tecnici e miglioramenti qualitativi. Il vero obiettivo non è il punteggio, ma l’esperienza delle persone che usano il sito.

Un approccio maturo alla velocità riconosce che performance, usabilità e accessibilità sono dimensioni interconnesse di un’unica qualità complessiva. Ottimizzare la velocità significa migliorare concretamente l’esperienza, riducendo frizioni e facilitando il raggiungimento degli obiettivi degli utenti.