English version draft — full translation in F3. Italian content preserved for technical fidelity.
Il sito di un nostro cliente del settore editoriale aveva un problema preciso: il traffico mobile, che rappresentava il 71% delle sessioni, abbandonava al 62% prima di leggere un singolo articolo. Lighthouse mobile riportava TTI 8.4 secondi, LCP 6.2 secondi, score performance 18/100. Le campagne SEO non si convertivano perche' Google penalizzava il sito nelle ricerche mobile-first.
Abbiamo intrapreso una performance review strutturata. Sei settimane dopo, il sito caricava completamente in meno di 0.4 secondi dal first byte. Score Lighthouse mobile: 96/100. Bounce rate mobile: 18% (-71% relativo).
Raccontiamo cosa abbiamo fatto, in che ordine, e quanto ciascun intervento ha contribuito.
Audit di partenza (settimana 1)
L'audit ha rivelato i problemi tipici di un sito cresciuto incrementalmente per dieci anni: 8.2 MB di JavaScript caricato sincrono, 11 file CSS separati, 4 librerie diverse di analytics, 6 tag advertising di terze parti, immagini in JPG ottimizzate male, server PHP 7.2 con cache disabilitato in produzione per debug.
Strumenti usati per l'audit: Lighthouse CI per le metriche, WebPageTest per dettaglio waterfall, Chrome DevTools coverage tab per JS non utilizzato, GTmetrix per cross-check.
Settimana 2 — Critical rendering path
Il primo intervento, il piu' impattante, e' stato sul critical rendering path. Concetto chiave: il browser non puo' renderizzare nulla finche' non ha scaricato e parsato tutto il CSS render-blocking. Ogni script <script src=...> nel <head> blocca anche il parsing HTML.
Abbiamo applicato:
- Critical CSS inline nel
<head>(8 KB di CSS minified, sufficiente per renderizzare l'above-the-fold). - Resto del CSS in async con
media="print"+onload="this.media='all'"(technique di Filament Group). - Defer di tutti gli script tranne il critico runtime.
- Preconnect a domini terzi necessari (font CDN, immagini CDN).
Risultato: LCP da 6.2 a 1.8 secondi. TTI da 8.4 a 4.2 secondi. Score Lighthouse mobile da 18 a 56.
Settimana 3 — JavaScript code splitting
Il bundle JS singolo da 8.2 MB conteneva: framework UI (React + 12 librerie UI), analytics, advertising, codice di pagina specifica, codice morto delle vecchie funzionalita'.
Interventi:
- Tree-shaking aggressivo via Webpack + Terser, rimosse dipendenze morte.
- Route-based code splitting: ogni route ha il proprio chunk, caricato on-demand.
- Vendor splitting: librerie cambiabili raramente in chunk separati per cache long-lived.
- Dynamic import per feature heavy (commenti, gallery, video player).
- Sostituito moment.js con date-fns (-65 KB).
- Sostituito lodash globale con import puntuali.
Risultato: bundle homepage da 2.8 MB a 380 KB. TTI da 4.2 a 1.4 secondi.
Settimana 4 — Immagini
Le immagini rappresentavano il 60% del peso totale. Tre interventi:
Conversione WebP + AVIF con fallback automatico via <picture>. AVIF dove supportato (-50% peso vs JPG), WebP fallback (-30%), JPG fallback per browser antichi.
Responsive srcset con 4 breakpoint (320, 640, 1024, 1920 px). Il browser scarica solo la dimensione che serve.
Lazy load nativo con loading="lazy" per tutte le immagini sotto la fold. Su browser moderni, intersection observer integrato.
Pipeline build aggiunta: ImageMagick + cwebp + avifenc, output multi-format pre-generato a build time. Niente conversione runtime.
Risultato: peso medio pagina da 4.8 MB a 1.1 MB. LCP da 1.8 a 0.9 secondi.
Settimana 5 — CDN edge + cache
Il sito girava su un singolo server VPS in Italia. Latency da nord Europa: 60ms, da USA: 200ms.
Interventi:
- Cloudflare CDN con cache policy aggressiva su asset statici (1 anno) e moderata su HTML (5 min con stale-while-revalidate).
- Brotli compression abilitata (incluso su HTML/CSS/JS).
- HTTP/3 + QUIC abilitato per browser supportati.
- Pre-fetch DNS e preconnect ai domini terzi residui.
Per HTML dinamico abbiamo introdotto cache layer Varnish davanti a PHP-FPM: cache 30 secondi su richieste anonime, bypass su utenti loggati.
Risultato: TTFB medio da 380ms a 45ms. TTI da 1.4 a 0.6 secondi.
Settimana 6 — Pulizia terze parti
L'ultimo passo, spesso il piu' politicamente difficile: tagliare le terze parti non essenziali.
Trovati:
- 4 librerie analytics diverse (Google Analytics, Adobe Analytics, Crazy Egg, Hotjar) — mantenuto solo GA4 con configurazione asincrona.
- 6 tag advertising — 4 erano per campagne concluse anni fa. Eliminati. 2 rimasti caricati on-scroll dopo first interaction.
- Widget social (Facebook, Twitter, LinkedIn) — sostituiti con bottoni statici linkanti.
- Live chat con caricamento sincrono — sostituita con bottone che carica chat on-click.
Risultato: terze parti scendono da 18 a 3 attive at-load. TTI da 0.6 a 0.42 secondi.
Metriche finali
| Metrica (mobile) | Prima | Dopo | Delta |
|---|---|---|---|
| Time To Interactive | 8.4 s | 0.42 s | -95% |
| Largest Contentful Paint | 6.2 s | 0.9 s | -85% |
| Cumulative Layout Shift | 0.42 | 0.02 | -95% |
| Peso pagina | 4.8 MB | 1.1 MB | -77% |
| Score Lighthouse mobile | 18 | 96 | +78 |
| Bounce rate mobile | 62% | 18% | -71% |
| Sessioni mobile organic | baseline | +147% | 3 mesi post-go-live |
Lezioni apprese
Tre osservazioni che applichiamo ad altri clienti.
Lezione 1: la maggior parte del beneficio viene da pochi interventi mirati. Critical CSS + code splitting + immagini hanno generato circa l'80% del miglioramento.
Lezione 2: le ottimizzazioni di fondo hanno effetto compounding nel tempo. Bundle leggero significa anche CDN piu' efficace e cache piu' efficace.
Lezione 3: le terze parti accumulate negli anni sono il debt tecnico piu' invisibile. Una review semestrale paga.
FAQ
Quanto costa fare bene performance optimization?
Sito medio-complesso (CMS-based, 100+ pagine): 3-6 settimane di lavoro per arrivare a Lighthouse 90+. 15-25k euro tipicamente.
Si puo' farlo senza riscrivere il sito?
Si', praticamente sempre. L'80% degli interventi riguarda configurazione, build pipeline, ottimizzazione asset. Non richiede refactor del codice di business.
Il beneficio SEO dura nel tempo?
Si', purche' si mantenga la performance. Google Core Web Vitals e' parte stabile dell'algoritmo. La penalita' per LCP > 2.5s rimane.
Quanto incide la performance sulle conversioni e-commerce?
Studi recenti riportano che ogni 100ms di miglioramento LCP genera 1-2% di conversion uplift. Su volumi alti, ROI di intervento solido.
Conclusione
La performance non e' magia. E' applicazione disciplinata di tecniche note e misurazione continua. Per un audit del vostro sito, apriamo un confronto tecnico.