Ottimizzare la velocità di un sito: un ordine di lavoro pratico
Il lavoro sulla velocità ha una forma di Pareto marcata: una manciata di correzioni spiega la maggior parte del miglioramento sulla maggior parte dei siti, e sono quasi sempre immagini, risposta del server e script di terze parti.
Questa guida copre in che ordine lavorare, come misurare se un cambiamento ha aiutato, e le ottimizzazioni che di solito non valgono lo sforzo.
Misura prima di cambiare qualsiasi cosa#
Ottimizzare senza misurare significa correggere ciò che è più facile anziché ciò che è lento. Due misurazioni, poi al lavoro.
- Procurati dati sul campo di visitatori veri: il rapporto Core Web Vitals in Search Console, o il tuo monitoraggio.
- Esegui un test di laboratorio sui tre template più importanti, limitato a un telefono di fascia media in 4G.
- Annota i numeri prima di iniziare. Senza un riferimento non puoi dire se un cambiamento ha aiutato.
- Individua la risorsa singola più grande e la richiesta bloccante più grande di ogni template.
- Annota a parte il Time to First Byte: se supera gli 800 ms, nessun lavoro sul front-end ti salverà.
L'ordine che rende#
Grosso modo per miglioramento ottenuto per ora di sforzo, per un tipico sito editoriale o vetrina.
| Lavoro | Guadagno tipico | Sforzo |
|---|---|---|
| Ottimizzare e dimensionare correttamente le immagini | Grande | Basso |
| Rimuovere gli script di terze parti inutilizzati | Grande | Basso: è soprattutto un compito politico |
| Attivare cache e un CDN | Grande | Basso |
| Correggere CSS e JS che bloccano il rendering | Medio-grande | Medio |
| Ridurre il bundle JavaScript | Medio-grande | Medio-alto |
| Correggere query di database lente | Grande dove si applica | Medio |
| Ottimizzare il caricamento dei font | Medio | Basso |
| Minificare e comprimere le risorse testuali | Piccolo | Basso: di solito già attivo |
| Micro-ottimizzare i selettori CSS | Trascurabile | Non ne vale la pena |
Immagini: di solito il guadagno più grande#
Sulla maggior parte dei siti le immagini sono la parte prevalente del peso di pagina, e la maggior parte viene servita diverse volte più grande di come viene mostrata. È il miglioramento grande meno costoso disponibile.
- Servi WebP o AVIF; entrambi sono ampiamente supportati e tipicamente più leggeri del 25–50 % rispetto al JPEG a parità di qualità.
- Genera più dimensioni e usa srcset con sizes perché i telefoni scarichino file di dimensione telefono.
- Non servire mai un'immagine da 2000 px in uno spazio da 400 px: questo singolo errore è estremamente comune.
- Carica in differita tutto ciò che sta sotto la piega, e nulla sopra.
- Automatizzalo nella build o nel CMS. Le immagini ottimizzate a mano smettono di esserlo la prima volta che qualcun altro ne carica una.
- Rimuovi i metadati; l'EXIF della fotocamera può pesare decine di kilobyte per file.
L'automazione è il punto. Una passata di ottimizzazione una tantum si degrada nel giro di mesi mentre si aggiungono contenuti, e nessuno se ne accorge finché il peso di pagina non è raddoppiato.
Script di terze parti e server#
Sono le due aree in cui il problema è di solito organizzativo anziché tecnico: nessuno è responsabile del gestore di tag, e nessuno è responsabile della scelta di hosting.
| Problema | Cosa fare |
|---|---|
| Gestore di tag con tag sconosciuti | Verificare ogni tag; cancellare tutto ciò che nessuno sa giustificare |
| Widget di chat caricato su ogni pagina | Caricarlo all'interazione, o solo dove serve assistenza |
| Più strumenti di statistiche | Tenerne uno; ciascuno è uno script completo e una connessione |
| Script di test A/B che blocca il rendering | Spostarlo lato server, o accettare uno sfarfallio e caricarlo async |
| TTFB lento su hosting condiviso | Aggiungere cache di pagina intera; passare a un piano superiore se persiste |
| Query di database senza cache | Mettere in cache quelle costose; aggiungere indici per quelle frequenti |
| Nessun CDN | Aggiungerne uno: è la correzione di latenza globale meno costosa che esista |
Gli script di terze parti sono la fonte più affidabile di rallentamenti inspiegabili, perché cambiano senza avvisarti e stanno fuori dal tuo processo di rilascio.
Domande frequenti
Qual è un buon tempo di caricamento?
Gli obiettivi utili sono le soglie dei Core Web Vitals anziché un singolo numero di caricamento: LCP sotto 2,5 secondi e Time to First Byte sotto 800 ms. Il tempo di caricamento totale è una misura scadente perché una pagina può essere usabile molto prima che ogni risorsa finisca, e inutilizzabile molto prima di quello su un dispositivo lento.
Un sito più veloce aumenta le conversioni?
In genere sì, e l'effetto è maggiore dove le pagine sono attualmente lente e i visitatori stanno su reti mobili. Il guadagno da tre secondi a due è molto maggiore di quello da uno e mezzo a uno. Se il tuo sito è già veloce, investi lo sforzo in contenuti e chiarezza: il ritorno è migliore.
I plugin di cache risolvono tutto?
Risolvono bene una cosa vera — il lavoro ripetuto del server per la stessa pagina — e possono creare problemi nuovi, in particolare con utenti autenticati, carrelli e moduli. Inoltre non fanno nulla contro immagini sovradimensionate e script di terze parti, che di solito sono i problemi maggiori. Utili, non sufficienti.
Il rendering lato server conviene per la velocità?
Se oggi le tue pagine vengono rese solo nel browser, sì: il rendering lato server o la generazione statica elimina un giro completo prima che compaia il contenuto, e nel frattempo aiuta l'indicizzazione. Se le tue pagine sono già HTML servito, la domanda non si pone: il beneficio ce l'hai già.
ottimizzazione velocità sitovelocità di paginaprestazioni sito webottimizzazione immaginicachecdn
