Per velocizzare un sito web lento le tecniche più impattanti sono: comprimere e convertire le immagini in WebP/AVIF, eliminare JavaScript non necessario, attivare il caching del browser e della CDN, scegliere un hosting con TTFB basso, e rimuovere i plugin inutilizzati. Implementando queste ottimizzazioni insieme si può dimezzare il tempo di caricamento in pochi giorni. Secondo i dati di Google, un sito che passa da 5 secondi a 1 secondo riduce il tasso di abbandono del 40%.
Diagnosi prima di tutto: scopri cosa rallenta il sito
Prima di toccare qualsiasi cosa, misura. Usa PageSpeed Insights inserendo l'URL del tuo sito: il report mostra le opportunità di miglioramento ordinate per impatto stimato. GTmetrix offre una visione ancora più dettagliata con la waterfall delle richieste, che mostra esattamente quali risorse bloccano il caricamento e per quanto tempo.
La diagnosi corretta richiede di misurare dalla prospettiva dell'utente reale, non dello sviluppatore. Usa WebPageTest.org scegliendo come location "Frankfurt, Germany" (server EU più vicino agli utenti italiani) e come dispositivo "Moto G4" su "3G Fast": questa combinazione simula lo scenario più comune tra gli utenti mobili italiani. Il report mostra una filmstrip video del caricamento frame per frame: spesso è illuminante vedere esattamente cosa vede l'utente nei primi 5 secondi.
I dati che raccogliamo mostrano che il 68% delle PMI italiane che chiedono supporto per la performance ha almeno un problema critico identificabile immediatamente nel primo report PageSpeed Insights: immagini non ottimizzate, script render-blocking, o TTFB superiore a 600ms. Raramente è necessario un'analisi profonda prima di trovare il problema principale: quasi sempre è visibile al primo sguardo della waterfall.
Le immagini: il fattore più impattante in assoluto
Le immagini pesanti sono la causa numero uno dei siti lenti. Il percorso ottimale: converti in WebP o AVIF (risparmio del 40-80% rispetto a JPEG), dimensiona le immagini alle dimensioni reali di visualizzazione, attiva il lazy loading con `loading="lazy"` per le immagini fuori dalla viewport, e usa srcset per servire dimensioni diverse in base alla risoluzione dello schermo. Un'immagine hero da 3 MB diventa facilmente 180 KB con questi accorgimenti.
Nella pratica, il passaggio più trascurato è il dimensionamento corretto. Un'immagine caricata a 2400px di larghezza ma visualizzata in un container di 800px trasferisce 9 volte più dati del necessario. Usa sempre l'attributo `srcset` per fornire varianti multiple: `srcset="img-400.avif 400w, img-800.avif 800w, img-1600.avif 1600w"` permette al browser di scegliere la variante corretta per la risoluzione dello schermo dell'utente. Su Next.js il componente `<Image>` genera automaticamente queste varianti.
Un errore frequente che vediamo nei siti WordPress è caricare le immagini originali della fotocamera (spesso 5-10 MB in JPEG 4K) e affidarsi al resize del browser o del tema. Questo spreca banda, rallenta il LCP, e non è recuperabile con nessun altro tipo di ottimizzazione. La regola empirica che usiamo: nessuna immagine sul web dovrebbe superare 200 KB per immagini full-width su desktop e 80 KB per immagini mobili.
JavaScript: meno codice, pagina più reattiva
Ogni kilobyte di JavaScript deve essere scaricato, analizzato ed eseguito dal browser prima che la pagina diventi interattiva. Rimuovi le librerie non utilizzate (usa il tab "Coverage" in Chrome DevTools per identificarle), implementa il code splitting per caricare solo il JS necessario alla pagina corrente, e sposta gli script non critici con `defer` o `async`. Nella nostra pratica di realizzazione siti web tagliare il JavaScript è quasi sempre la mossa con il ROI più alto.
Il problema del JavaScript non è solo il peso del file da scaricare: è il tempo di parsing ed esecuzione. Su un laptop moderno, 500 KB di JavaScript vengono processati in circa 400ms. Su uno smartphone mid-range Android (il dispositivo più comune tra gli utenti italiani) lo stesso JavaScript impiega 1,5-2 secondi. Questo è il motivo per cui i punteggi Lighthouse "da mobile" sono così diversi da quelli desktop.
CSS: elimina il render-blocking
Il browser non può renderizzare nulla finché non ha scaricato e processato tutto il CSS nel `<head>`. Inline il CSS critico (above-the-fold) direttamente nell'HTML, carica il resto in modo asincrono con `media="print" onload="this.media='all'"`. Rimuovi il CSS inutilizzato con strumenti come PurgeCSS. Un file CSS da 800 KB con il 90% di regole inutilizzate è un classico problema dei siti WordPress con temi multipurpose.
Il CSS critico inline è una delle tecniche più impattanti ma anche più delicate da implementare. L'obiettivo è estrarre solo le regole necessarie per il rendering above-the-fold — tipicamente header, font-face declarations, variabili CSS, e stili dell'elemento hero — e inserirle direttamente nell'`<head>` come `<style>` tag. Il resto del CSS viene caricato in modo asincrono. Strumenti come Critical CSS di Filament Group automatizzano l'estrazione, ma richiedono sempre una revisione manuale per i siti complessi.
Font web: zero layout shift, caricamento fluido
I font esterni (Google Fonts, Adobe Fonts) aggiungono un'ulteriore richiesta di rete e spesso causano FOIT (Flash of Invisible Text) o FOUT (Flash of Unstyled Text). La soluzione: self-host i font nel tuo dominio, usa `font-display: swap` o `optional`, e precarica i file WOFF2 con `<link rel="preload">`. Next.js con `next/font` automatizza tutto questo azzerando il CLS da font.
Self-hostare i font significa scaricare i file WOFF2 (il formato più compresso) e servirli dal proprio server o CDN. Questo elimina la connessione a Google Fonts (un DNS lookup + TCP + TLS handshake aggiuntivo), evita i problemi di privacy GDPR legati all'invio dell'IP dell'utente a Google, e permette di controllare le cache headers. Strumenti come `google-webfonts-helper.herokuapp.com` generano automaticamente il CSS @font-face e i file da scaricare.
Caching: non ri-scaricare ciò che non è cambiato
Il caching del browser conserva risorse statiche (immagini, CSS, JS) in locale per le visite successive. Configura header `Cache-Control` con `max-age` lunga (es. 1 anno) per asset con hash nel nome file, e `no-cache` o `must-revalidate` per l'HTML. Sul server, attiva il caching a livello di CDN e considera il reverse proxy caching per le pagine generate dinamicamente. Questi accorgimenti portano il tempo di caricamento delle visite successive vicino allo zero.
La strategia di caching corretta dipende dalla natura del contenuto. Per gli asset statici (JavaScript, CSS, immagini) con fingerprint nel nome file (come `main.a7f3b2.js`) usa `Cache-Control: public, max-age=31536000, immutable`: il browser non ri-scarica mai finché il nome file non cambia. Per le pagine HTML usa `Cache-Control: no-cache` che istruisce il browser a rivalidare sempre, ma grazie all'ETag la pagina viene ri-scaricata solo se è effettivamente cambiata (304 Not Modified altrimenti).
Server e hosting: il TTFB deve essere sotto 200ms
Il Time to First Byte (TTFB) misura quanto impiega il server a rispondere. Un hosting economico con server condivisi e sovraffollati può avere TTFB di 1-2 secondi. Soluzioni: scegli un hosting con server in Europa (latenza ridotta per gli utenti italiani), usa Vercel o Cloudflare Workers per edge rendering, ottimizza le query al database, e implementa una CDN.
Dalla nostra esperienza, i hosting italiani economici (Aruba, Serverplan, Register) hanno TTFB medio di 800ms-1,5s su piani shared. Un VPS su Hetzner in Germania a 20-30€/mese ha TTFB di 50-80ms per utenti italiani. Vercel con Edge Network ha TTFB di 20-40ms dalle principali città italiane. La differenza tra 1.500ms e 30ms di TTFB è la differenza tra un LCP di 5 secondi e uno di 1,5 secondi, a parità di tutto il resto. L'hosting è la prima leva da migliorare nei siti lenti.
Plugin e script di terze parti
Ogni plugin WordPress o script di terze parti (chatbot, widget social, pixel di tracking) aggiunge peso. Fai un audit: installa solo i plugin essenziali, unifica i pixel di tracking attraverso Google Tag Manager, e carica gli script non critici dopo il caricamento principale della pagina con `defer`. Spesso scopriamo siti con 40+ plugin di cui la metà non vengono usati attivamente.
Lo script più comune e pesante che troviamo nei siti italiani è il widget di Tidio o Intercom per la live chat, caricato in modo sincrono nel `<head>`. Questi script possono pesare 150-300 KB e aggiungere 500ms-1s al LCP. La soluzione non è rimuoverli, ma caricarli con strategia `lazyOnload` (Next.js) o `defer` (HTML classico): il widget compare pochi secondi dopo il caricamento della pagina, senza impattare le metriche Core Web Vitals.
HTTP/2 e HTTP/3: più richieste in parallelo
HTTP/2 permette di inviare più richieste contemporaneamente su una singola connessione (multiplexing), eliminando il collo di bottiglia di HTTP/1.1. HTTP/3, basato su QUIC, riduce ulteriormente la latenza grazie alla connessione più rapida e alla gestione migliore della perdita di pacchetti. Verifica che il tuo hosting supporti HTTP/2 o HTTP/3 — i principali CDN e cloud provider (Cloudflare, Vercel, AWS CloudFront) li supportano già.
Un modo semplice per verificare il protocollo usato dal tuo sito: apri Chrome DevTools → tab Network → fai click destro sull'intestazione della tabella e aggiungi la colonna "Protocol". Dovresti vedere "h2" (HTTP/2) o "h3" (HTTP/3) per le risorse del tuo dominio. Se vedi "http/1.1" il server non supporta HTTP/2: contatta l'hosting per abilitarlo o valuta una migrazione a un provider moderno.
Checklist rapida: 10 azioni immediate
- Converti tutte le immagini in AVIF con fallback WebP, e dimensionale per la viewport reale di visualizzazione
- Aggiungi lazy loading (`loading="lazy"`) a tutte le immagini tranne la prima above-the-fold
- Abilita la compressione Brotli sul server (superiore a Gzip del 15-25% per testo/JSON/HTML)
- Minifica CSS, JavaScript e HTML: rimuovi spazi, commenti e codice non raggiungibile
- Rimuovi plugin e script inutilizzati: ogni plugin WordPress ha un costo anche se non attivo
- Precarica il font principale con `<link rel="preload" as="font" crossorigin>` nel `<head>`
- Attiva Cloudflare (gratuito): CDN globale, SSL automatico, e protezione DDoS in 5 minuti
- Configura `Cache-Control: max-age=31536000, immutable` per tutti gli asset statici con fingerprint
- Sposta tutti gli script di terze parti con `defer` o `async`, mai sincroni nel `<head>`
- Monitora i Core Web Vitals in Google Search Console ogni settimana e configura gli alert email
Quanto costa non ottimizzare: il prezzo della lentezza
I dati di Google mostrano che ogni secondo aggiuntivo di caricamento su mobile aumenta il tasso di abbandono del 20%. Per un e-commerce che riceve 10.000 visite al mese con un tasso di conversione del 2% e uno scontrino medio di 80€, ogni secondo in più di caricamento costa circa 1.600€/mese in conversioni perse. Un sito che passa da 4 a 2 secondi può guadagnare 3.200€/mese in conversioni aggiuntive — un ROI in pochi mesi su qualsiasi investimento di ottimizzazione. Vuoi sapere quanto stai perdendo con il tuo sito attuale? Contattaci per un'analisi gratuita.
