Come abbiamo ridotto il tempo di caricamento di un site a meno di un secondo
La velocità non è una metrica di vanità — influisce sui posizionamenti e sui ricavi. Ecco l’esatto lavoro di performance che eseguiamo su ogni build, nell’ordine che conta di più.
La maggior parte dei website lenti non lo è per motivi misteriosi. Sono lenti a causa di una serie di problemi prevedibili accumulati l’uno sull’altro — e si risolvono in un ordine prevedibile. Quando un cliente si rivolge a noi con un tempo di caricamento di tre secondi, raramente abbiamo bisogno di trucchi esotici. Abbiamo bisogno di disciplina.
Questa è la stessa checklist che eseguiamo su ogni progetto di performance, all’incirca in ordine di priorità. Ogni passaggio è economico rispetto al suo impatto, e la maggior parte dei site sembra incredibilmente più veloce già dopo i primi tre.
Misura prima di toccare qualsiasi cosa
Non puoi migliorare ciò che non misuri, e non puoi assolutamente dimostrare un miglioramento senza una baseline. Iniziamo ogni progetto con i dati sul campo, non solo con i punteggi di laboratorio.
- Laboratorio — Lighthouse e WebPageTest per uno snapshot controllato e ripetibile.
- Campo — metriche degli utenti reali (CrUX / RUM) per ciò che le persone sperimentano effettivamente.
- Budget — un limite massimo rigido per route, in modo che le regressioni vengano rilevate nella CI, non in production.
Un punteggio di laboratorio pari a 100 non significa nulla se i tuoi utenti reali utilizzano telefoni di fascia media e reti instabili. Ottimizza per il campo.
Elimina le risorse render-blocking
Il singolo vantaggio più grande sulla maggior parte dei site è rimuovere CSS e JavaScript dal critical path. Il browser non può eseguire il paint finché non ha completato il parsing delle risorse render-blocking — quindi meno ce ne sono, prima apparirà qualcosa sullo schermo.
// esegui il defer di tutto ciò che non è critico
const load = () => import('./analytics.js');
if ('requestIdleCallback' in window)
requestIdleCallback(load);
else setTimeout(load, 2000);Inserisci inline la piccola quantità di CSS necessaria per il primo viewport, quindi carica il resto in modo asincrono. Esegui il defer degli script non critici. L’obiettivo è un first paint che non attenda nulla di cui non abbia assolutamente bisogno.
Gestisci le immagini come un budget
Le immagini sono solitamente l’elemento più pesante di una pagina e il più facile da sbagliare. Tre regole coprono il novanta percento dei casi:
- Fornisci formati moderni — AVIF o WebP — con un fallback.
- Ridimensiona le immagini in base alle loro dimensioni di rendering; non inserire mai una hero da 3000px in uno slot da 600px.
- Applica il lazy-load a tutto ciò che si trova below the fold e riserva lo spazio per evitare il layout shift.
Cache all’edge
Una volta che la pagina è leggera, la domanda successiva è quanto velocemente i byte raggiungano l’utente. Una CDN con cache headers sensati trasforma un origin trip di 600ms in un edge hit di 30ms. Per i contenuti dinamici, stale-while-revalidate offre risposte istantanee eseguendo il refresh in background.
La performance è una feature. Definiamo un budget per essa allo stesso modo in cui lo facciamo per qualsiasi altra parte della build.
Il risultato
Nel progetto che ha ispirato questo articolo, la homepage è passata da un largest contentful paint di 3,1s a 0,9s, e le conversioni organiche sono aumentate in modo misurabile entro il mese. Nulla di tutto questo è stato magico — solo la checklist sopra indicata, applicata con ordine.
Se il tuo site ti sembra lento e non sai da dove iniziare, mettiti in contatto con noi — un breve audit di solito fa emergere le due o tre modifiche che contano di più.