un sito web veloce: velocità di consegna e di caricamento non sono la stessa cosa

web · 2026-11-01 · 4 min

"mi serve un sito veloce" significa due cose diverse, e la maggior parte delle conversazioni fallisce perché nessuno le separa. veloce da costruire è una promessa di calendario. veloce da caricare è una misura tecnica. un sito può essere consegnato in una settimana e impiegare quattro secondi ad aprirsi, o richiedere un mese e aprirsi in 600 millisecondi.

il primo è un argomento di vendita. il secondo è quello che i visitatori sentono e che google misura.

veloce da costruire

una settimana, un mese, sei mesi: dipende da decisioni, contenuti e integrazioni. è un numero di project management. non dice nulla su cosa fa il browser quando qualcuno arriva.

un ai builder è veloce da costruire. non è automaticamente veloce da caricare: le pagine generate portano spesso un framework, set di font, analytics, widget di chat e immagini non compresse che nessuno ha scelto.

veloce da caricare

questo si misura con tre numeri.

lcp (largest contentful paint): quando appare il contenuto principale. buono sotto 2,5 s, scarso oltre 4 s.
inp (interaction to next paint): quanto in fretta la pagina reagisce a un tocco. buono sotto 200 ms.
cls (cumulative layout shift): quanto salta la pagina durante il caricamento. buono sotto 0,1.

google li misura sui visitatori reali, non sul tuo portatile. è per questo che un sito può segnare 95 in laboratorio e sembrare lento su un telefono in un negozio con una tacca di segnale.

misura il tuo in tre minuti

apri pagespeed insights e incolla il tuo url. leggi la scheda mobile, non desktop.
guarda prima i dati sul campo (utenti reali, ultimi 28 giorni). se mancano, hai poco traffico e i dati di laboratorio sono l'unico segnale.
nella lista delle opportunità ignora il punteggio. leggi i tre trasferimenti più pesanti e i tre task più lunghi.

se la pagina trasferisce più di 1 mb, il problema è il peso. se l'immagine principale appare tardi, il problema è la hero. se toccare un menù richiede mezzo secondo, il problema è il javascript.

i colpevoli abituali, in ordine di frequenza

immagini. una foto da 4 mb scattata col telefono, servita in jpg, a piena risoluzione, dentro un riquadro da 600 px. la correzione è ridimensionare, webp o avif, e dimensioni corrette.

font. due o tre famiglie, ognuna con quattro pesi, precaricate. un font display può pesare 300-700 kb. la correzione è subsetting, meno pesi e font-display swap.

javascript. plugin dopo plugin, tag dopo tag. ogni widget di terze parti è una richiesta, un parsing e un rischio. la correzione è cancellare, non ottimizzare.

hosting e caching. un server condiviso economico in un altro continente, html senza header di cache, nessuna compressione. la correzione è noiosa ed efficace.

plugin. su wordpress, un page builder più dieci estensioni possono produrre una pagina da 2 mb prima di qualsiasi contenuto. la correzione è meno plugin o una build statica.

come si scrive un budget di prestazioni

prima di costruire, concorda i numeri: html sotto 100 kb, css sotto 60 kb, js sotto 150 kb, immagine hero sotto 200 kb, lcp sotto 2,5 s su un telefono di fascia media. poi misurali nella build, non nell'ultima settimana.

su questo sito il budget è in parte imposto: le pagine sono pre-renderizzate, metadati e link sono controllati dalla build, e il gate di contrasto blocca la release. non è perfetto. il font display è ancora più pesante di quanto dovrebbe, ed è il prossimo punto della lista. dirlo costa meno che fingere.

un sito veloce è sempre un sito migliore?

no. la velocità è un vincolo, non un obiettivo. una pagina veloce che non risponde alla domanda resta inutile. ma una pagina lenta perde le persone prima che possano giudicare il contenuto.

la velocità influisce sul posizionamento su google?

i core web vitals sono un fattore di ranking confermato, ma piccolo rispetto a rilevanza e contenuto. trattala come lavoro sulle conversioni prima che come lavoro seo.

quanto costa sistemare un sito lento?

meno di un sito nuovo, di solito. un audit e una settimana mirata su immagini, font, script e caching recuperano gran parte del divario. rifare il sito si giustifica quando è la piattaforma stessa a essere il peso.

se vuoi i numeri del tuo sito, prenota una call di 30 minuti oppure leggi come velocizzare un sito e le note sui core web vitals per parma.