Velocizzare un sito web significa ridurre il tempo che passa tra il clic di un utente e il momento in cui la pagina mostra il contenuto principale e risponde ai comandi. Si fa intervenendo nel punto preciso in cui il caricamento si inceppa: il server, la scoperta delle risorse, il loro peso o il disegno a schermo.
È l'ultima parte della definizione a fare la differenza. Le guide italiane su questo tema propongono quasi tutte la stessa lista (comprimi le immagini, attiva la cache, cambia hosting), e la lista non è sbagliata: per la maggior parte dei siti lenti è nell'ordine sbagliato. I dati raccolti da Chrome sui siti reali dicono che chi ha un caricamento scadente spende meno del 10% del tempo a scaricare l'immagine principale. Il resto se ne va prima.
Cosa consigliano le dieci guide italiane in prima pagina
Il 4 ottobre 2026 abbiamo letto i dieci articoli che Google.it mostra in prima pagina per «come velocizzare un sito web» e «velocizzare sito web», esclusi forum e video, e abbiamo segnato quali concetti nominano nel testo.
| Guida | Pubblicata | Core Web Vitals | LCP | INP | TTFB | Priorità all'immagine principale | Script di terze parti |
|---|---|---|---|---|---|---|---|
| teamsviluppo.it | n.d. | no | no | no | no | no | no |
| waveinformatica.com | 2022 | sì | no | no | no | no | no |
| cloudflare.com (it) | n.d. | sì | sì | no | sì | no | sì |
| aranzulla.it | n.d. | sì | no | no | no | no | no |
| wp-assistenza.it | 2021 | no | no | no | no | no | no |
| it.siteground.com | 2019 | no | no | no | sì | no | no |
| zmotlab.it | 2025 | no | no | no | no | no | no |
| aioseo.com (it) | 2022 | no | no | no | sì | no | no |
| serverplan.com | 2020 | no | no | no | no | no | no |
| seo-verona.it | n.d. | no | no | no | no | no | sì |
| Totale | 3 su 10 | 1 su 10 | 0 su 10 | 3 su 10 | 0 su 10 | 2 su 10 |
Tutte e dieci parlano di immagini, cache e hosting. Nessuna nomina l'INP, la metrica di reattività che Google usa al posto del FID dal 12 marzo 2024. Una sola nomina l'LCP, che è la misura del caricamento su cui Google valuta le pagine. Nessuna spiega come far partire prima il download dell'immagine principale, che secondo i dati di Chrome è il collo di bottiglia più frequente. Cinque sono state pubblicate tra il 2019 e il 2022, anche se alcune sono state ritoccate dopo, e una consiglia ancora le pagine AMP. L'AI Overview che Google mette sopra i risultati ripete la stessa lista: hosting, immagini, cache, plugin.
Molte di quelle regole hanno una genealogia precisa. Nella SERP americana sulla stessa domanda compare ancora in prima pagina il documento Best Practices for Speeding Up Your Web Site pubblicato da Yahoo nel dicembre 2006: ridurre le richieste HTTP, usare una CDN, aggiungere le intestazioni di scadenza. Erano le regole giuste per il web di vent'anni fa. Rispondono alla domanda «cosa si può fare per velocizzare un sito», mentre quella utile oggi è «perché il mio è lento».
Come capire se il sito è lento davvero
Prima di toccare qualcosa serve un numero raccolto dagli utenti reali, non da un test. Google valuta le pagine con i dati di campo del Chrome UX Report: le visite fatte con Chrome negli ultimi 28 giorni, lette al 75° percentile, cioè il valore entro cui stanno tre visite su quattro. Il punteggio da 0 a 100 di PageSpeed Insights è un'altra cosa, una simulazione singola: la differenza tra i due la spieghiamo nella guida al page speed.
| Metrica | Cosa misura | Buono | Scarso |
|---|---|---|---|
| LCP | Comparsa del contenuto principale | fino a 2,5 s | oltre 4 s |
| INP | Risposta a clic e tocchi | fino a 200 ms | oltre 500 ms |
| CLS | Spostamenti del layout | fino a 0,1 | oltre 0,25 |
| TTFB | Primo byte dal server (non è un Core Web Vital) | fino a 0,8 s | oltre 1,8 s |
Il posto dove guardare per primo è il report Segnali web essenziali di Google Search Console, che raggruppa gli URL simili e dice quale metrica è fuori soglia, separando mobile e desktop. Conta soprattutto il primo, perché Google valuta il sito nella sua versione mobile. Se il sito non ha abbastanza traffico per avere dati di campo, PageSpeed Insights resta utile per capire cosa succede, a patto di leggerlo come diagnosi e non come voto. Come vengono calcolate le soglie lo trovi nell'articolo sui Core Web Vitals.
La metrica fuori soglia decide da dove partire. Nella maggior parte dei casi è l'LCP, e qui serve il passaggio che le guide saltano.
Le quattro fasi in cui si divide il caricamento
L'LCP non è un tempo unico. Chrome lo scompone in quattro fasi in sequenza e, da febbraio 2025, il Chrome UX Report le pubblica separatamente per ogni sito la cui pagina ha un'immagine come elemento LCP. Il team di Chrome ha confrontato i siti con LCP buono e quelli con LCP scarso.
| Fase | Cosa succede | Siti con LCP buono | Siti con LCP scarso |
|---|---|---|---|
| TTFB | Il server invia il primo byte dell'HTML | 600 ms | 2.270 ms |
| Ritardo di caricamento | Attesa tra il primo byte e l'inizio del download dell'immagine | 350 ms | 1.290 ms |
| Durata del caricamento | Download dell'immagine | 160 ms | 350 ms |
| Ritardo di rendering | Dall'arrivo dell'immagine alla comparsa a schermo | 230 ms | 360 ms |
Due numeri cambiano le priorità. Il sito mediano con LCP scarso aspetta quasi quattro volte più tempo prima di iniziare a scaricare l'immagine di quanto ne impieghi a scaricarla. E per almeno metà dei siti con LCP scarso il solo TTFB, 2,27 secondi, rende impossibile stare sotto i 2,5 secondi qualunque cosa si faccia all'immagine. Comprimere un JPEG da 400 a 200 KB lavora sulla fase che pesa meno.
Google indica come distribuzione sana circa il 40% del tempo al TTFB, circa il 40% al download della risorsa e meno del 10% a ciascuna delle due fasi di attesa. Ogni millisecondo in cui il browser non sta scaricando né l'HTML né l'immagine principale è tempo recuperabile.
Per vedere come si divide il tuo LCP basta PageSpeed Insights: nella diagnosi, la voce dedicata all'elemento LCP mostra la ripartizione nelle quattro fasi. La stessa scomposizione compare nel pannello Performance di Chrome DevTools. Da lì in poi il lavoro si sceglie in base alla fase più lunga.
Fase 1: il server risponde tardi
Se il TTFB supera gli 0,8 secondi, il lavoro parte da qui. Secondo il Web Almanac 2025 di HTTP Archive solo il 44% dei siti ha un TTFB buono da mobile e il 55% da desktop: tra le metriche di caricamento è quella messa peggio.
Le cause che troviamo più spesso sui siti aziendali:
- Nessuna cache di pagina. Su WordPress ogni visita senza cache ricostruisce la pagina eseguendo PHP e interrogando il database. Una cache lato server la consegna già pronta. Come funzionano i diversi livelli lo spieghiamo nell'articolo sulla cache di un sito.
- Redirect in catena. Ogni passaggio da http a https, dalla versione senza www a quella con www, da un vecchio indirizzo al nuovo aggiunge un giro completo prima del primo byte. I link interni dovrebbero puntare all'URL finale e i redirect 301 restare un salto solo.
- Server lontano o sottodimensionato. Una CDN avvicina i file agli utenti. Un hosting migliore serve quando il TTFB resta alto anche con la cache attiva.
- Plugin che lavorano a ogni richiesta: filtri di ricerca, traduzioni, statistiche lato server, builder che generano il markup al volo.
Il cambio di hosting è l'intervento che ci viene chiesto più spesso ed è quello da fare per ultimo. Se il problema è una pagina generata da zero a ogni visita, un server più potente la genera solo un po' più in fretta.
Fase 2: il browser scopre tardi l'immagine principale
È la fase che pesa di più sui siti lenti, ed è quella che nessuna delle dieci guide italiane affronta. Il browser legge l'HTML dall'alto e avvia i download man mano che trova le risorse. Se l'immagine principale non è scritta nell'HTML, o è marcata come da caricare più tardi, il download parte in ritardo anche con un server velocissimo.
Le cause ricorrenti sono tre.
- Immagine LCP in lazy loading. L'attributo loading="lazy" dice al browser di aspettare. Va bene per le immagini sotto la piega, è un errore sulla prima. Secondo il Web Almanac 2025 lo fa il 16-17% delle pagine sull'immagine LCP. La documentazione di Google non lascia margini: l'immagine LCP non va mai caricata in lazy loading.
- Immagine caricata da CSS o JavaScript. Uno sfondo impostato via CSS o uno slider che inserisce le foto con uno script diventano visibili al browser solo dopo che quei file sono stati scaricati ed eseguiti. Un tag img nell'HTML viene trovato subito.
- Nessuna priorità dichiarata. L'attributo fetchpriority="high" sull'immagine principale chiede al browser di scaricarla prima delle altre. Lo usa il 17% delle pagine mobile con immagine LCP. Il preload, che serve quando l'immagine non è nell'HTML, si ferma al 2,1%.
Su WordPress una parte del lavoro la fa il core: dalla versione 6.3, uscita nell'estate 2023, aggiunge da solo fetchpriority="high" all'immagine che ritiene sarà l'LCP ed evita il lazy loading sulle immagini visibili al primo caricamento. Temi, page builder e plugin di ottimizzazione però spesso sovrascrivono quella scelta, ed è una delle ragioni per cui la scelta del CMS e del tema pesa più dei plugin installati dopo. Vale la pena aprire il codice sorgente della pagina e controllare quali attributi ha davvero l'immagine principale.
La decisione più efficace, in questa fase, non è tecnica: chiedersi se quell'elemento deve esistere. Uno slider da cinque foto in home è un LCP lento per costruzione.
Fase 3: l'immagine pesa troppo
Questa è la fase su cui si concentrano tutte le liste, e conta: secondo il Web Almanac 2025 l'immagine è l'elemento LCP nel 76% delle pagine mobile e nell'85,3% di quelle desktop. Nel capitolo Page Weight la pagina mobile mediana pesa 2.559 KB, di cui 911 KB di immagini e 632 KB di JavaScript.
Gli interventi sono noti: formati moderni come WebP e AVIF, dimensioni pari a quelle di visualizzazione, versioni diverse per schermi diversi con srcset, attributi width e height per prenotare lo spazio. La procedura completa sta nella guida all'ottimizzazione delle immagini. Il punto è l'ordine. Se la tua scomposizione mostra 1,3 secondi di attesa e 300 millisecondi di download, dimezzare il peso del file fa guadagnare 150 millisecondi; spostare il download all'inizio ne fa guadagnare più di uno.
Fase 4: l'immagine è arrivata ma non compare
Il ritardo di rendering è il tempo in cui l'immagine è già scaricata ma il browser non la disegna, di solito perché sta ancora aspettando CSS o JavaScript che bloccano il rendering. Secondo il Web Almanac 2025 supera il controllo di Lighthouse sulle risorse bloccanti solo il 15% delle pagine mobile e il 13% di quelle desktop.
Le cause tipiche sono fogli di stile caricati per intero anche dove servono poche regole, script nell'head senza defer e font esterni che tengono il testo invisibile finché non arrivano (sui font c'è un articolo dedicato a quanto contano per la SEO). E c'è il caso più banale, che abbiamo raccontato nella guida al page speed: un banner dei cookie così grande da diventare lui l'elemento LCP della pagina, risolto ridimensionandolo dalla console della piattaforma di consenso.
Se il problema è la risposta ai clic
Quando l'LCP è buono ma l'INP no, il caricamento non c'entra. L'INP misura quanto il sito impiega a reagire a un tocco e dipende da quanto è occupato il processore del telefono in quel momento. È il motivo per cui il 97% dei siti ha un INP buono da desktop e solo il 77% da mobile.
Il responsabile di solito è il JavaScript, spesso non scritto da chi gestisce il sito. Secondo il capitolo Third Parties del Web Almanac 2025, tra il 90% e il 92% delle pagine carica risorse di terze parti, e i domini più presenti sono quelli di Google Fonts, Google Tag Manager e Google Analytics. Ogni pixel pubblicitario, chat o mappa di calore aggiunge lavoro al thread principale. Un'operazione che lo occupa per più di 50 millisecondi è un long task, e mentre dura il sito non risponde.
L'ordine di lavoro è questo: censire i tag in Google Tag Manager e togliere quelli di campagne chiuse, caricare chat e video incorporati solo quando l'utente li apre, e solo dopo chiedere allo sviluppo di spezzare i task lunghi, per esempio con scheduler.yield(). I primi due passaggi non richiedono una riga di codice.
Un intervento gratuito che quasi nessuno controlla
Secondo i dati d'uso di Chrome, una navigazione su cinque da mobile e una su dieci da desktop è un clic su avanti o indietro. Se la pagina è idonea alla back/forward cache, il browser la ripristina dalla memoria all'istante, senza ricaricarla. Le due cause che più spesso la escludono sono un listener sull'evento unload, inserito di frequente da vecchi script di statistiche, e l'intestazione Cache-Control: no-store su pagine che non contengono dati sensibili. Lighthouse ha un controllo dedicato che dice se la pagina è idonea e, se non lo è, perché.
L'ordine di lavoro, in sette passi
- Apri il report Segnali web essenziali in Search Console e annota quale metrica è fuori soglia, su quali gruppi di URL e su quale dispositivo.
- Scegli un URL rappresentativo del gruppo, non la home, che è quasi sempre la pagina più pesante e meno tipica, e aprilo in PageSpeed Insights.
- Se il problema è l'LCP, leggi la scomposizione nelle quattro fasi e lavora sulla più lunga.
- Se il problema è l'INP, parti dall'elenco degli script di terze parti e da quello che si può togliere senza sviluppo.
- Se il problema è il CLS, dai dimensioni fisse a immagini, banner e spazi pubblicitari.
- Ripeti il test di laboratorio per verificare che la modifica abbia effetto tecnico.
- Aspetta 28 giorni prima di giudicare i dati di campo: è la finestra su cui vengono calcolati.
È lo stesso approccio che usiamo negli audit SEO: la velocità è una voce della SEO tecnica e va pesata contro le altre. Su un sito con poche centinaia di visite al mese, mezzo secondo di LCP sposta meno di una pagina scritta bene su una query che nessuno presidia. Su un e-commerce o su un sito che vive di richieste di preventivo, lo stesso mezzo secondo si vede nel tasso di conversione.
Quando la lentezza nasce dal tema o dal page builder e non si risolve con le impostazioni, il problema diventa di progetto, ed è il caso in cui ha senso parlare di sviluppo del sito invece che di un altro plugin. Se invece vuoi capire quanto pesa la velocità rispetto al resto della visibilità organica, la strada è una consulenza SEO.
Dove si decide davvero la velocità di un sito
Gran parte della velocità di un sito si decide prima che qualcuno scriva una riga di codice, quando si sceglie il tema. Un tema con slider a tutto schermo in home, video di sfondo e tre famiglie di font ha già fissato il proprio LCP; un page builder che costruisce la pagina via JavaScript ha già fissato una parte del proprio INP. Le ottimizzazioni successive lavorano sui margini di quella scelta. Per questo la domanda più utile da fare a chi propone un sito nuovo non è che punteggio avrà su PageSpeed, ma quale sarà l'elemento più grande della home vista da un telefono, e in che modo arriverà al browser.
Domande frequenti su come velocizzare un sito
Dipende da dove il sito perde tempo. Se il TTFB supera 0,8 secondi si parte dal server e dalla cache di pagina. Se il TTFB è buono ma l'LCP è lento, quasi sempre conviene far partire prima il download dell'immagine principale, togliendo il lazy loading e aggiungendo fetchpriority="high". La scomposizione dell'LCP in PageSpeed Insights dice quale dei due casi è il tuo.
No, nella maggior parte dei siti lenti. I dati di campo di Chrome mostrano che i siti con LCP scarso spendono meno del 10% del tempo di LCP a scaricare l'immagine principale. Ridurre il peso aiuta, ma il guadagno grosso di solito sta nel far partire prima il download e nel ridurre il tempo di risposta del server.
Solo se il collo di bottiglia è il server. Se il TTFB resta sopra 0,8 secondi anche con una cache di pagina attiva, un hosting migliore serve. Se il tempo si perde nell'attesa dell'immagine o negli script di terze parti, un server più potente non cambia quasi niente.
Per Google l'elemento principale della pagina deve comparire entro 2,5 secondi nel 75% delle visite reali, il sito deve rispondere alle interazioni entro 200 millisecondi e lo spostamento del layout non deve superare 0,1. La soglia dei 3 secondi che circola in molte guide non corrisponde a nessuna delle metriche che Google usa per valutare le pagine.
Dopo circa 28 giorni. I dati di campo sono calcolati su una finestra mobile di quattro settimane, quindi nei primi giorni mescolano visite precedenti e successive alla modifica. Il test di laboratorio di PageSpeed Insights invece cambia subito ed è quello da usare per verificare che l'intervento abbia effetto.
Dipende da cosa fanno. Un plugin di cache di pagina quasi sempre migliora il TTFB. I plugin che minificano, combinano e rimandano tutto il JavaScript possono alzare il punteggio e rompere funzioni del sito, e alcuni applicano il lazy loading anche all'immagine principale, annullando quello che WordPress fa da solo dalla versione 6.3.
