Come rendere più veloce il tuo sito: 5 interventi

Un visitatore apre il tuo sito dal telefono.

Lo schermo resta bianco. Poi compare il testo. Poi un'immagine spinge giù il testo. Poi il pulsante non risponde al primo tocco.

Sono passati pochi secondi, ma bastano per farlo tornare indietro.

La velocità di un sito non dipende quasi mai da un solo problema. Di solito è la somma di tante scelte piccole: un'immagine troppo grande, uno script caricato senza motivo, una risorsa scaricata di nuovo a ogni visita.

In questa guida trovi 5 interventi che contano davvero e, per ognuno, cosa fare in pratica.

01. Ottimizzare le immagini

Le immagini sono spesso la risorsa più pesante di una pagina. Una foto scattata con il telefono e caricata così com'è può pesare più di tutto il resto del sito messo insieme.

Tre passaggi

Ottimizzare un'immagine vuol dire lavorare su tre fronti:

• Dimensioni: se l'immagine viene mostrata larga 800 pixel, non ha senso scaricarne una da 4000.
• Compressione: per le foto va bene una compressione con perdita, controllando a occhio che la qualità resti accettabile.
• Formato: WebP comprime meglio di JPEG e PNG ed è supportato da tutti i browser moderni. AVIF in alcuni test arriva a risparmiare oltre il 50% rispetto a JPEG.

Immagine originale
  ↓
Ridimensiona
  ↓
Comprimi
  ↓
WebP o AVIF
  ↓
Una versione per desktop, tablet e mobile

Servire la versione giusta a ogni schermo

Con srcset e sizes il browser sceglie da solo la versione più adatta allo schermo. Con <picture> puoi offrire AVIF e WebP e tenere JPEG come riserva per i browser che non li supportano:

<picture>
  <source type="image/avif" srcset="foto-800.avif 800w, foto-1600.avif 1600w" sizes="(max-width: 800px) 100vw, 800px">
  <source type="image/webp" srcset="foto-800.webp 800w, foto-1600.webp 1600w" sizes="(max-width: 800px) 100vw, 800px">
  <img src="foto-800.jpg" alt="Descrizione della foto" width="800" height="533">
</picture>

Gli attributi width e height non servono a ridimensionare l'immagine: permettono al browser di riservarle lo spazio prima che arrivi, così il testo non salta giù quando l'immagine compare.

La regola da ricordare: non far scaricare al visitatore un'immagine più grande di quella che vedrà.

02. Caricare dopo quello che sta sotto la piega

Quando una pagina si apre, il visitatore vede solo la parte iniziale, quella "sopra la piega". Tutto il resto lo vedrà scorrendo, forse.

Non ha senso che il browser scarichi subito le immagini in fondo alla pagina, sottraendo banda a quelle che servono adesso.

Lazy loading nativo

Oggi basta un attributo, supportato da tutti i browser principali, per le immagini e anche per gli iframe:

<img src="galleria-1.webp" alt="Sala del ristorante" width="800" height="533" loading="lazy">

Il browser scarica l'immagine solo quando il visitatore si avvicina a quel punto della pagina.

L'errore opposto

Il lazy loading va usato solo per ciò che sta fuori dallo schermo iniziale. Applicato all'immagine principale in cima alla pagina, la rallenta: il browser aspetta di sapere se è visibile prima di scaricarla.

Uno studio pubblicato su web.dev riguardava pagine WordPress che applicavano il lazy loading anche alle immagini visibili subito. Disattivandolo, l'elemento principale compariva circa il 13-15% prima.

Per l'immagine principale vale il contrario: va segnalata come prioritaria.

<img src="hero.webp" alt="Vista del locale" width="1200" height="800" fetchpriority="high">

Sopra la piega → subito, con priorità alta
  ↓
Sotto la piega → quando il visitatore si avvicina

03. Tagliare il JavaScript che non serve

Un'immagine pesante rallenta il download. Il JavaScript fa di più: va scaricato, analizzato, compilato ed eseguito, e tutto questo occupa il thread principale del browser.

Mentre il thread principale è occupato, la pagina può sembrare pronta ma non rispondere ai tocchi. È esattamente il ritardo che il visitatore percepisce come "il sito è bloccato".

Dove si nasconde il peso

• Dipendenze non usate: librerie installate per una funzione che poi è stata tolta.
• Bundle unici troppo grandi: tutto il codice dell'applicazione caricato anche se la pagina ne usa una piccola parte.
• Script di terze parti: chat, pixel pubblicitari, widget social, strumenti di analisi. Ognuno aggiunge codice che non controlli.

Cosa fare

Rimuovi le dipendenze che non usi più. Dividi il codice in parti e carica quelle non essenziali solo quando servono, con un import() dinamico:

button.addEventListener("click", async () => {
  const { apriMappa } = await import("./mappa.js");
  apriMappa();
});

Il codice della mappa viene scaricato solo se qualcuno la apre davvero. Per gli script che non servono al primo caricamento, l'attributo defer evita che blocchino la lettura della pagina.

Per trovare il codice inutilizzato, lo strumento Coverage di Chrome DevTools mostra quanta parte di ogni file viene davvero eseguita durante il caricamento.

La regola: ogni kilobyte di JavaScript costa due volte, prima per scaricarlo e poi per eseguirlo.

04. Mettere in cache le risorse statiche

Alla prima visita il browser deve scaricare tutto: immagini, font, CSS, JavaScript. Alla seconda visita, gran parte di quelle risorse è identica.

Senza una cache configurata bene, il browser le scarica di nuovo.

Prima visita
  ↓
Scarica → conserva
  ↓
Visita successiva
  ↓
Riusa dalla cache, scarica solo ciò che è cambiato

Due regole diverse per due tipi di file

Il trucco sta nel distinguere i file che cambiano nome quando cambiano contenuto da quelli che non lo fanno.

I file con un'impronta nel nome, come style.x234dff.css, prodotti in automatico dalla maggior parte dei framework moderni, possono restare in cache a lungo. Quando il contenuto cambia, cambia anche il nome, e il browser scarica il file nuovo.

Cache-Control: max-age=31536000, immutable

L'HTML invece ha sempre lo stesso indirizzo. Va conservato, ma ricontrollato con il server prima di ogni uso:

Cache-Control: no-cache

no-cache non vuol dire "non salvare". Vuol dire "salva, ma chiedi prima di usarlo": se la pagina non è cambiata, il server risponde con un 304 Not Modified e il browser non riscarica nulla. Per vietare del tutto la copia esiste no-store, da usare solo per contenuti che non devono restare sul dispositivo.

05. Controllare i Core Web Vitals

Tutto quello che hai fatto finora va misurato. I Core Web Vitals sono le tre metriche con cui Google valuta l'esperienza di caricamento di una pagina:

• LCP (Largest Contentful Paint): quanto tempo serve per mostrare l'elemento principale della pagina. Buono entro 2,5 secondi.
• INP (Interaction to Next Paint): quanto velocemente la pagina risponde a tocchi, clic e tasti. Buono entro 200 millisecondi. Da marzo 2024 ha sostituito il vecchio FID.
• CLS (Cumulative Layout Shift): quanto gli elementi si spostano mentre la pagina carica. Buono entro 0,1.

Una pagina supera la soglia quando almeno il 75% delle visite rientra nel valore buono.

Dati di laboratorio e dati reali

Gli strumenti principali sono due, e misurano cose diverse:

• Lighthouse simula il caricamento su un telefono di fascia media con una rete mobile. È utile mentre lavori, perché dà un risultato immediato e ripetibile.
• PageSpeed Insights mostra anche i dati reali degli utenti di Chrome negli ultimi 28 giorni, quando la pagina ha abbastanza traffico. Per un sito nuovo o con poche visite questi dati possono mancare.

Misura
  ↓
Trova il problema principale
  ↓
Correggi
  ↓
Misura di nuovo

Il ciclo conta più del punteggio singolo. Un 100 su Lighthouse ottenuto una volta non garantisce nulla se poi una nuova immagine da 5 MB finisce in homepage.

La velocità è una funzione del prodotto

Nessuno di questi interventi da solo rende veloce un sito. Puoi avere immagini perfette e un bundle JavaScript enorme. Puoi avere una cache configurata benissimo e l'immagine principale caricata in lazy loading.

Immagini ottimizzate
  ↓
Lazy loading sotto la piega
  ↓
Meno JavaScript
  ↓
Cache delle risorse statiche
  ↓
Core Web Vitals misurati
  ↓
Sito veloce

La velocità nasce dalla somma di questi livelli, e si perde allo stesso modo: una scelta piccola alla volta.

Checklist per un sito più veloce

Prima di pubblicare una pagina, verifica almeno questi cinque punti:

• Le immagini sono compresse, in WebP o AVIF, e servite nella dimensione in cui vengono mostrate.
• Le immagini sotto la piega hanno loading="lazy", quella principale no.
• Nessuna libreria o script di terze parti viene caricato senza un motivo preciso.
• I file statici con l'impronta nel nome hanno una cache lunga, l'HTML viene ricontrollato.
• LCP, INP e CLS sono misurati da mobile, e di nuovo dopo ogni modifica importante.

Questa lista non risolve ogni problema di prestazioni, ma copre le cause più frequenti di un sito lento.

La velocità si progetta

La velocità non è qualcosa da sistemare alla fine, quando il sito è già online e qualcuno si lamenta. Ogni immagine aggiunta, ogni libreria installata, ogni script di terze parti è una decisione che pesa sul caricamento.

Un sito veloce non si nota. Si nota solo quando è lento: per questo conviene pensarci prima che qualcuno se ne accorga.

Fonti

• web.dev, How the Core Web Vitals metrics thresholds were defined
• web.dev, Interaction to Next Paint becomes a Core Web Vital on March 12
• web.dev, Image performance
• web.dev, Browser-level image lazy loading for the web
• web.dev, The performance effects of too much lazy loading
• web.dev, Optimize resource loading with the Fetch Priority API
• web.dev, Code-split JavaScript
• web.dev, Prevent unnecessary network requests with the HTTP Cache
• Google for Developers, About PageSpeed Insights