Performance web: le ottimizzazioni che contano davvero

Parliamoci chiaro: la performance web è diventata un'ossessione. Tutti vogliono il sito veloce, tutti inseguono i 100/100 su PageSpeed Insights, tutti si preoccupano dei Core Web Vitals. E va benissimo, per carità. Ma nella mia esperienza ventennale ho visto sprecare più tempo a ottimizzare dettagli irrilevanti che a sistemare i veri colli di bottiglia.

La settimana scorsa un cliente mi chiama preoccupatissimo perché aveva letto che doveva "minimizzare il CSS" e "eliminare il render-blocking JavaScript". Il suo sito caricava in 8 secondi. Otto. E si preoccupava del CSS minificato. È come pulire i vetri mentre la casa va a fuoco.

Le ottimizzazioni che fanno davvero male (a non farle)

Partiamo dai fondamentali, quelli che sul serio spostano l'ago della bilancia. E qui parlo di esperienze concrete, non di teoria letta su qualche blog americano.

Le immagini non ottimizzate sono il nemico numero uno. Punto. Non il JavaScript, non il CSS, non il server. Le immagini. Un mio cliente qui a Trento aveva un sito web professionale che caricava in 12 secondi. Dodici! Sapete perché? Aveva caricato le foto dei prodotti direttamente dalla fotocamera: 6MB a immagine. Ho convertito tutto in WebP, ridimensionato ai pixel effettivi, implementato il lazy loading. Da 12 secondi a 2.3 secondi. Senza toccare una riga di codice.

Oggi lavoro sempre con formati moderni: WebP per compatibilità, AVIF dove possibile. E uso il tag <picture> con fallback. Non è complicato, è solo questione di prenderci la mano.

Il secondo killer è il database. Specialmente se lavorate con WordPress o qualsiasi CMS che dialoga con MySQL. Ho visto siti che facevano 150 query per caricare una singola pagina. Centocinquanta. Sapete perché? Plugin mal scritti che facevano query in loop. Ho installato Query Monitor, individuato i colpevoli, sistemato con un paio di query ottimizzate. Da 4 secondi a 1.2 secondi.

Quando realizzo un software gestionale su misura con Laravel, uso sempre eager loading per evitare il problema N+1. Una cosa del tipo:

// MALE - query N+1
$orders = Order::all();
foreach ($orders as $order) {
    echo $order->customer->name; // query per ogni ordine!
}

// BENE - eager loading
$orders = Order::with('customer')->get();
foreach ($orders as $order) {
    echo $order->customer->name; // una query sola
}

Sembra una cavolata, ma su un gestionale con migliaia di record fa una differenza abissale.

La cache: quella dimenticata e quella sopravvalutata

Tutti parlano di Redis, Memcached, Varnish. E sono ottime tecnologie, sia chiaro. Ma quante volte ho visto implementare Redis per cachare dati che cambiano ogni 10 secondi? O peggio, per siti che hanno 20 visite al giorno? È come comprare un trattore per tagliare il prato di casa.

La cache che fa davvero la differenza è quella del browser. HTTP caching fatto bene. Un Cache-Control configurato come si deve vale più di mille Redis installati a caso. Per i file statici (CSS, JS, immagini) imposto cache lunghe con versioning:

# .htaccess

    Header set Cache-Control "max-age=31536000, public"

E poi uso un sistema di versioning nei nomi file: style.v1234.css. Quando cambio qualcosa, cambio versione. Cache infinita + controllo totale.

Per i contenuti dinamici, uso la cache di oggetti. Su WordPress, con un plugin come WP Super Cache o W3 Total Cache configurato bene, si ottengono risultati eccellenti. L'importante è capire cosa cachare e cosa no. I carrelli degli e-commerce non si cachano. I cataloghi prodotti sì.

CDN: quando serve davvero

"Devo usare una CDN?" Me lo chiedono in continuazione. La risposta è: dipende. Se i vostri utenti sono tutti in Trentino e il server è a Milano, la CDN vi porta un beneficio marginale. Se vendete in tutta Italia o all'estero, allora sì, ha senso.

Cloudflare nella versione free va benissimo per iniziare. Costa zero, è facile da configurare, e porta anche benefici di sicurezza. Ma non aspettatevi miracoli se i problemi sono altri.

JavaScript: il nemico (a volte) necessario

Diciamocelo: JavaScript è sia la soluzione che il problema. Serve per creare esperienze interattive, ma può distruggere completamente la performance se usato male.

La mia regola è semplice: carico il minimo indispensabile, e lo carico bene. Uso defer per gli script non critici, async quando l'ordine non conta. E soprattutto, elimino quello che non serve.

Un esempio pratico: un cliente voleva un effetto parallax sulla homepage. Bellissimo, d'accordo. Aveva incluso una libreria di 87KB per fare una cosa che si può fare con 15 righe di JavaScript vanilla e un po' di CSS. Risultato: parsing time ridotto del 60%.

Non sto dicendo di non usare mai librerie o framework. Ma di sceglierli con criterio. Se state facendo una web app complessa con React o Vue, ha senso. Se state facendo un sito vetrina, probabilmente no.

Le ottimizzazioni che non contano (quanto pensate)

Ora la parte che farà arrabbiare i puristi. Ci sono ottimizzazioni che tecnicamente sono corrette, ma che nella pratica reale spostano pochissimo.

Minificare HTML. Sì, riduce i byte. Ma di quanto? Nel migliore dei casi del 10-15%. E i browser moderni sono bravissimi a gestire HTML non minificato. Non dico di non farlo, ma se dovete scegliere dove investire tempo, non è certo la priorità numero uno.

Combinare tutti i CSS in un file unico. Anni fa aveva senso per ridurre le richieste HTTP. Con HTTP/2 e HTTP/3, che gestiscono il multiplexing, non è più così critico. Anzi, a volte è meglio avere CSS modulari che vengono cachati separatamente.

Eliminare ogni millisecondo dal TTFB. Time To First Byte è importante, ma ossessionarsi per passare da 120ms a 80ms quando il resto della pagina impiega 3 secondi a caricare... ha poco senso. È come litigare per la marca della benzina quando l'auto ha le gomme sgonfie.

Il mio approccio pratico

Quando mi chiamano per ottimizzare un sito, parto sempre dai dati. Chrome DevTools aperto, tab Network, hard reload. Guardo la waterfall chart. Cosa pesa di più? Cosa blocca il rendering? Cosa arriva per ultimo ma è critico?

Poi uso web.dev e PageSpeed Insights per avere i Core Web Vitals. Ma non inseguo il 100/100 a tutti i costi. Inseguo metriche che hanno senso per quel sito specifico.

Un e-commerce ha bisogno di LCP basso (caricamento veloce delle immagini prodotto) e FID ottimo (interattività del carrello). Un blog ha bisogno di CLS perfetto (niente layout shift mentre leggi). Sono contesti diversi, ottimizzazioni diverse.

E poi testo. Testo su connessioni lente (throttling a Fast 3G), su dispositivi vecchi, su browser diversi. Perché i numeri sono una cosa, l'esperienza reale è un'altra. Ho visto siti con 95 su PageSpeed che sembravano lentissimi, e siti con 78 che andavano benissimo nella pratica.

Monitorare, sempre

L'errore più grande è ottimizzare una volta e dimenticarsi del sito. La performance decade nel tempo. Si aggiungono plugin, si caricano nuove immagini, si implementano funzionalità. Bisogna monitorare costantemente.

Io uso un mix di strumenti: Google Search Console per i dati reali degli utenti, Pingdom o GTmetrix per test sintetici periodici, e per i progetti più grossi anche New Relic o Sentry per il monitoring applicativo.

Per i miei clienti trentini imposto sempre degli alert: se il tempo di caricamento supera una certa soglia, ricevo una notifica. Mi è capitato di scoprire problemi sul server prima ancora che il cliente se ne accorgesse.

La performance web non è una checklist da spuntare. È un processo continuo, fatto di scelte consapevoli e di compromessi ragionati. Non esiste la soluzione perfetta che va bene per tutti. Esiste la soluzione giusta per quel progetto, per quegli utenti, per quel budget.

Se avete un sito lento e non sapete da dove partire, scrivetemi. Spesso basta un'analisi di un'ora per individuare i veri problemi. E vi assicuro che quasi mai sono quelli che pensate.