Reti di distribuzione, compressione e minify: la guida moderna

Quando questo tema comparve per la prima volta su queste pagine, si parlava di MaxCDN, di plugin di minificazione e di header da manovrare a mano. Era il tempo in cui una rete di distribuzione era un accessorio da esperti. Oggi la CDN non è più un optional: è l'infrastruttura che consegna la maggior parte del web, e le decisioni che un tempo richiedevano un sistemista ora si prendono in un pannello. Rileggere quei temi con gli occhi del presente significa capire cosa vale ancora, cosa è cambiato e dove si guadagna davvero velocità.

Che cosa fa davvero una rete di distribuzione

Una CDN porta una copia dei contenuti vicina al lettore: nodi in decine di paesi chiudono la connessione TLS al posto del server d'origine, servono file statici dalla cache locale e inoltrano all'origine solo ciò che non conosce. Il beneficio principale non è «più banda», ma meno distanza: round trip più corti, TLS più rapida, origine protetta dai picchi di traffico. Per un sito statico l'origine può letteralmente dormire: i nodi edge servono tutto.

Compressione: Brotli, Gzip e l'ordine giusto

La compressione agisce sui formati di testo: HTML, CSS, JavaScript, JSON, SVG. Le immagini sono già compresse e non vanno ricompresse al volo: per JPEG, PNG, WebP e AVIF l'intestazione corretta è una sola, Cache-Control generosa, non un livello di gzip in più. Per il testo, Brotli ha sostituito Gzip come standard de facto: la qualità 11 precompressa in fase di build è imbattibile, mentre la compressione dinamica a livello 4-5 è il compromesso ragionevole quando il contenuto cambia a ogni richiesta. La regola: comprimere una volta, alla build, e lasciare all'edge il compito di consegnare.

Minify e bundle: meglio in build che all'edge

La minificazione rimuove spazi, commenti e nomi superflui; il bundling riduce il numero di file. Sono operazioni da fare prima della pubblicazione, con gli strumenti di build, non a ogni richiesta sul server né attraverso plugin che minificano a runtime consumando CPU preziosa. Il file già ridotto, con un hash nel nome, permette la regola più potente che esista:

Cache-Control: public, max-age=31536000, immutable

Sui file con impronta nel nome la cache non scade mai: al cambio versione cambia il nome, e il lettore scarica solo il nuovo file.

Le intestazioni che valgono oro

Il controllo di cache è il punto in cui si vince o si perde. Uno schema solido per un sito a contenuti:

• HTML: max-age=0, must-revalidate — sempre verificato, così le correzioni si vedono subito;
• CSS/JS con hash: immutable con anno di durata;
• immagini: durata lunga e nome versionato, oppure percorso versionato per intero;
• font: durata lunga, con crossorigin per la condivisione di cache;
• quando serve freschezza e velocità insieme: stale-while-revalidate, che consegna la copia in cache e aggiorna in secondo piano.

HTTP/3, 0-RTT e il trasporto

Con HTTP/3 il trasporto passa a QUIC, su UDP: connessioni più rapide da aprire, migliori sulle reti mobili che perdono pacchetti, riconnessione senza ripartire da zero quando il telefono salta da Wi-Fi a rete cellulare. Il 0-RTT elimina un round trip per chi torna, con una avvertenza: va usato solo per richieste idempotenti, perché un pacchetto ripetuto può arrivare due volte. Sono ottimizzazioni trasparenti: si attivano a livello di rete, non toccano il sito.

La checklist finale

• testo precompresso in Brotli alla build, immagini nei formati moderni;
• hash nei nomi dei file statici e immutable in cache;
• HTML sempre verificabile, purge selettivo quando cambia qualcosa;
• HTTP/3 attivo e redirect in un solo salto;
• misurazione sui dati reali, non solo nei tool: la differenza la spiegano i punteggi e i Core Web Vitals.

Il tema si collega naturalmente alla scelta della forma canonica del dominio, trattata nella guida su www e redirect, e alla scelta dell'hosting, di cui parliamo nell'analisi di un servizio partito male.