La velocità uccide: quanto le sta costando un sito lento

Il tempo di caricamento è un numero di fatturato. Non una metrica tecnica — un numero di fatturato. Amazon ha riferito che ogni 100ms di latenza aggiuntiva costa l’1% delle vendite. I dati di Google mostrano che la bounce rate aumenta del 32% quando il caricamento della pagina passa da 1s a 3s.

Il suo sito è probabilmente lento in modi che non ha misurato.

I numeri reali

Largest Contentful Paint (LCP) è la metrica che correla più fortemente con la conversione. La soglia di Google:

• Buono: sotto 2,5s
• Da migliorare: 2,5s-4s
• Scarso: oltre 4s

La maggior parte dei siti aziendali che analizziamo si colloca nell’intervallo 3-6s. La differenza tra 6s e 2s non è una vittoria di design — è una vittoria di tasso di conversione che si vede nel fatturato.

Dove se ne va il tempo

Immagini — le immagini non ottimizzate sono il colpevole più comune. Un’immagine hero da 4MB servita agli utenti mobile è una tassa da 4MB su ogni prima impressione.

Script di terze parti — analytics, widget di chat, pixel pubblicitari. Ognuno blocca il rendering. Un sito di marketing tipico carica 8-12 script di terze parti.

Risorse che bloccano il rendering — CSS e JS caricati nell’head del documento che impediscono al browser di disegnare qualsiasi cosa.

Tempo di risposta del server (TTFB) — se il suo server impiega 800ms a rispondere, nessuna quantità di ottimizzazione frontend colmerà quel divario.

Rendering lato client — le SPA che spediscono una pagina HTML vuota e poi idratano sono intrinsecamente lente al primo caricamento.

Lo stack delle correzioni

Per la maggior parte dei siti, le correzioni a maggior leva, in ordine:

1. Migrare a un runtime edge CDN — Vercel, Cloudflare Pages o simili. TTFB sotto i 100ms a livello globale.
2. Servire immagini ottimizzate — usi next/image o Cloudflare Image Resizing. WebP, dimensioni corrette, caricamento pigro.
3. Differire gli script non critici — carichi analytics e widget di chat dopo che la pagina è interattiva.
4. Eliminare il CSS che blocca il rendering — inline del CSS critico, differire il resto.
5. Passare al rendering lato server — pre-renderizzi l’HTML in modo che gli utenti vedano subito il contenuto.

Misurare correttamente

Non testi le prestazioni dal suo ufficio su una macchina veloce. Usi:

• WebPageTest con una connessione mobile 4G throttled
• Lighthouse CI nella sua pipeline di build per rilevare regressioni
• Core Web Vitals in Google Search Console per dati real-user

L’obiettivo è essere visibilmente veloce su un telefono Android di fascia media su una rete mobile congestionata. Tutto il resto è ottimizzare per un pubblico che comunque non se ne accorgerebbe.