Molte regole di ottimizzazione che circolano ancora oggi sono nate ai tempi di HTTP/1.1: unire tutti i file in uno, creare sprite di immagini, distribuire le risorse su più sottodomini. Con HTTP/2 e HTTP/3 alcune di queste pratiche sono diventate inutili, altre addirittura dannose. Vale la pena capire che cosa è cambiato a livello di protocollo per decidere con cognizione.
Il problema di HTTP/1.1
Con HTTP/1.1 ogni connessione TCP può gestire una sola richiesta alla volta: si invia, si aspetta la risposta completa, poi si invia la successiva. Per non mettere tutto in fila, i browser aprono fino a sei connessioni parallele per dominio. Una pagina con ottanta risorse sullo stesso dominio le scarica quindi a gruppi di sei, e ogni connessione aggiuntiva costa il suo handshake.
Da qui le classiche ottimizzazioni:
- concatenazione di CSS e JavaScript in pochi file grandi;
- sprite di immagini, cioè molte icone in un'unica immagine;
- domain sharding, cioè distribuire le risorse su sottodomini diversi per avere più connessioni in parallelo;
- inlining aggressivo di risorse piccole direttamente nell'HTML.
Cosa porta HTTP/2
HTTP/2 introduce il multiplexing: su una sola connessione viaggiano in parallelo molti flussi indipendenti, suddivisi in frame che si alternano. Il browser può chiedere cento risorse insieme senza aprire cento connessioni. Inoltre le intestazioni vengono compresse con HPACK, che evita di ripetere a ogni richiesta lo stesso blocco di cookie e intestazioni.
Le conseguenze pratiche:
- il domain sharding diventa controproducente: ogni dominio in più richiede una connessione e una negoziazione TLS separate, e impedisce al browser di gestire tutte le priorità su un'unica connessione;
- la concatenazione estrema perde senso: un unico bundle enorme invalida tutta la cache a ogni piccola modifica. Meglio file di dimensione ragionevole, separati per funzione o per pagina, che si possono memorizzare in cache indipendentemente;
- gli sprite non sono più necessari per ridurre le richieste; per le icone è spesso più pratico usare SVG singoli o un set di simboli.
Attenzione però a non esagerare nell'altra direzione. Centinaia di moduli JavaScript minuscoli caricati separatamente hanno un costo, sia per l'overhead di ogni richiesta sia per la scarsa efficacia della compressione su file molto piccoli. La via di mezzo, con qualche decina di file ben divisi, funziona meglio.
Il limite di HTTP/2 su TCP
HTTP/2 risolve il blocco a livello di applicazione, ma resta un problema a livello di trasporto: TCP garantisce che i byte arrivino in ordine. Se un pacchetto si perde, tutti i flussi sulla connessione si fermano finché non viene ritrasmesso, anche quelli che non c'entrano. Questo fenomeno si chiama head-of-line blocking di TCP ed è particolarmente sensibile su reti mobili con perdita di pacchetti.
Cosa porta HTTP/3
HTTP/3 sostituisce TCP con QUIC, un protocollo di trasporto costruito sopra UDP. Le differenze principali:
| Aspetto | HTTP/2 su TCP | HTTP/3 su QUIC |
|---|---|---|
| Perdita di un pacchetto | blocca tutti i flussi | blocca solo il flusso coinvolto |
| Avvio connessione | handshake TCP, poi TLS | trasporto e cifratura insieme |
| Riconnessione | nuovo handshake | ripresa più rapida, anche con dati iniziali |
| Cambio di rete | la connessione cade | la connessione può proseguire |
L'ultima voce è utile per chi naviga in mobilità: passando dal Wi-Fi alla rete cellulare, QUIC usa identificativi di connessione che non dipendono dall'indirizzo IP, quindi la sessione può proseguire.
Il browser scopre che un server supporta HTTP/3 tramite l'intestazione Alt-Svc o un record DNS di tipo HTTPS; la prima visita può quindi avvenire ancora con HTTP/2 e le successive con HTTP/3. Se UDP è bloccato da un firewall aziendale, il browser ripiega automaticamente su HTTP/2.
Che cosa conta ancora
Il protocollo migliora il trasporto, non il contenuto. Restano validi:
- ridurre il peso complessivo di JavaScript, immagini e font;
- evitare catene di dipendenze, perché ogni gradino è comunque un viaggio di andata e ritorno;
- limitare il numero di domini terzi, ciascuno con la propria connessione;
- assegnare priorità corrette alle risorse critiche, per esempio con
fetchpriority.
Come verificare il protocollo
In DevTools, nel pannello Rete, la colonna «Protocollo» mostra h2 per HTTP/2 e h3 per HTTP/3. Se compaiono ancora molte richieste http/1.1, conviene controllare quale server o quale dominio terzo le sta servendo. Spesso il sito principale è aggiornato, mentre una vecchia CDN di immagini o un servizio esterno usa ancora il protocollo precedente.
In sintesi
- HTTP/2 permette molte richieste parallele su una sola connessione grazie al multiplexing.
- Domain sharding e sprite sono superati; la concatenazione estrema danneggia la cache.
- HTTP/3 su QUIC evita il blocco di tutti i flussi quando si perde un pacchetto e sopravvive ai cambi di rete.
- Il protocollo non sostituisce la riduzione del peso e delle catene di dipendenze.
- Controlla la colonna Protocollo in DevTools per scoprire chi usa ancora HTTP/1.1.
