HTTPS cifra la comunicazione tra browser e server proteggendo dati sensibili. HTTP/3, costruito su QUIC (UDP), elimina il TCP handshake e il TLS handshake separato riducendo la latenza di connessione da 3 round-trip a 1. Insieme migliorano sia la sicurezza che la velocità: Google marca i siti HTTP come "non sicuri" e usa HTTPS come segnale di ranking positivo. HTTP/3 riduce il TTFB del 30-40% su connessioni con alta latenza rispetto a HTTP/2, e del 60-70% rispetto a HTTP/1.1.
Perché HTTPS è obbligatorio nel 2026
Chrome e gli altri browser moderni mostrano "Non sicuro" nella barra degli indirizzi per tutti i siti HTTP. Google usa HTTPS come segnale di ranking dal 2014 e lo ha rafforzato progressivamente. I form senza HTTPS sono vulnerabili al man-in-the-middle attack: i dati viaggiano in chiaro sulla rete. L'HTTPS è gratuito con Let's Encrypt (certificati SSL/TLS automatici, rinnovati ogni 90 giorni) e viene attivato automaticamente da Cloudflare, Vercel, Netlify e qualsiasi hosting moderno.
Eppure, secondo i dati di Netcraft, circa il 15% dei siti web italiani non usa ancora HTTPS correttamente — alcuni servono ancora risorse miste (mixed content) anche se il sito ha HTTPS attivo. Questo include e-commerce con immagini di prodotto servite via HTTP, siti aziendali con widget di terze parti con URL HTTP hardcoded, e WordPress con URL nel database che contengono http://. Il risultato sono warning del browser che spaventano gli utenti e compromettono la fiducia nel sito.
TLS 1.3: handshake più veloce, sicurezza più forte
TLS 1.3 (2018) ha ridotto l'handshake TLS da 2 round-trip a 1, eliminando cipher suite obsolete e aggiungendo 0-RTT resumption (connessioni riprese senza handshake per utenti di ritorno). TLS 1.0 e 1.1 sono deprecati e non supportati dai browser moderni. TLS 1.2 è ancora supportato ma più lento e con cipher suite più deboli. Verifica la versione TLS del tuo sito su SSL Labs (ssllabs.com/ssltest): dovresti avere TLS 1.3 con rating A+.
La 0-RTT resumption di TLS 1.3 è particolarmente vantaggiosa per gli utenti di ritorno: la seconda visita al sito (o le visite successive nella stessa sessione) non richiede il TLS handshake, eliminando 50-100ms di latenza iniziale. Cloudflare e Vercel implementano 0-RTT automaticamente. Se gestisci il tuo server, controlla che nginx o Apache siano configurati con TLS 1.3 e 0-RTT abilitati. La configurazione richiede 15 minuti ma migliora percettibilmente la velocità per gli utenti abituali.
HTTP/2: multiplexing e header compression
HTTP/1.1 apre connessioni TCP separate per ogni risorsa (o le mette in coda su connessioni parallele limitate). HTTP/2 introduce il multiplexing: richieste e risposte multiple viaggiano in parallelo su una singola connessione TCP. Aggiunge anche header compression (HPACK) e server push. Il risultato: siti con molte risorse (CSS, JS, immagini) caricano significativamente più veloce. HTTP/2 richiede HTTPS: è un incentivo de facto ad adottare TLS.
Con HTTP/2, la pratica di concatenare tutti i CSS in un unico file e tutti i JS in un unico file (comune con HTTP/1.1 per ridurre le richieste) diventa meno necessaria e a volte controproducente. Con multiplexing, molti file piccoli caricano in parallelo senza overhead significativo per file. Anzi, molti file piccoli permettono un caching più granulare: modificare un componente rigenera solo il suo chunk, non l'intero bundle concatenato. Questo è uno dei motivi per cui il code splitting funziona così bene con HTTP/2.
HTTP/3 e QUIC: la rivoluzione del protocollo
HTTP/3 sostituisce TCP con QUIC, un protocollo trasporto costruito su UDP. Il vantaggio principale: la connessione e il TLS handshake avvengono in un singolo round-trip (contro i 3 di TCP+TLS 1.2 o i 2 di TCP+TLS 1.3). Su mobile con connessioni instabili QUIC è ancora più vantaggioso: gestisce meglio la perdita di pacchetti senza il head-of-line blocking di TCP. Cloudflare e Vercel supportano HTTP/3 automaticamente — se il browser è compatibile (Chrome, Firefox, Safari moderni) la connessione usa automaticamente QUIC.
Il head-of-line blocking di TCP è un problema che HTTP/3 risolve elegantemente. In HTTP/2 su TCP, se un pacchetto si perde tutti gli stream sulla connessione si bloccano finché non viene ritrasmesso (anche se i pacchetti degli altri stream sono già arrivati). Con QUIC su UDP, ogni stream è indipendente: la perdita di un pacchetto blocca solo lo stream corrispondente, non gli altri. Su reti con perdita di pacchetti (3G, Wi-Fi affollato) questo è un vantaggio enorme che si traduce in caricamenti più stabili.
HSTS: forza HTTPS con un header
L'header `Strict-Transport-Security` (HSTS) dice al browser di usare sempre HTTPS per il tuo dominio per un periodo specificato (es. `max-age=31536000; includeSubDomains`). Anche se l'utente digita `http://` il browser converte automaticamente a `https://` senza fare la richiesta HTTP. Questo elimina il redirect 301 da HTTP a HTTPS (che aggiunge latenza) e protegge da downgrade attack. Dopo aver verificato che HTTPS funziona correttamente su tutto il sito, HSTS va sempre attivato.
La HSTS Preload List è il passo successivo: inviare il dominio a hstspreload.org per farlo includere nella lista hardcoded nei browser. Una volta nella lista, i browser non inviano mai richieste HTTP al tuo dominio — nemmeno la prima volta. Questo è il livello massimo di protezione contro i downgrade attack e gli errori di configurazione. Prerequisiti: `max-age` di almeno 1 anno, `includeSubDomains` e `preload` nell'header HSTS. Prima di attivarlo, verifica che tutti i sottodomini abbiano HTTPS funzionante.
Contenuto misto: il rischio nascosto
Un sito HTTPS che carica risorse via HTTP (immagini, script, CSS) ha "contenuto misto" (mixed content). I browser bloccano il contenuto misto attivo (script, CSS) e mostrano warning per quello passivo (immagini). Il risultato: errori in console, funzionalità rotte, e avvisi di sicurezza che spaventano gli utenti. Usa sempre URL assoluti con `https://` o URL relativi al protocollo (`//cdn.example.com/...`). Per la gestione siti web controlliamo sempre il contenuto misto dopo una migrazione HTTP→HTTPS.
Su WordPress la causa più comune di mixed content dopo la migrazione a HTTPS è il database: gli URL delle immagini e dei link interni sono salvati con `http://` nella tabella `wp_posts` e nelle opzioni. La soluzione più rapida: il plugin "Better Search Replace" o la funzione WP-CLI `wp search-replace http://esempio.it https://esempio.it --all-tables` sostituisce tutti gli URL in una volta. Esegui sempre questa operazione su un backup e verifica il risultato prima di andare in produzione.
Preconnect e ALPN: ottimizzare la connessione iniziale
`<link rel="preconnect">` istruisce il browser a stabilire la connessione TCP+TLS con un dominio prima che sia necessario: utile per CDN, Google Fonts, e API di terze parti. ALPN (Application-Layer Protocol Negotiation) è l'estensione TLS con cui browser e server negoziano il protocollo (HTTP/1.1, HTTP/2, HTTP/3) durante l'handshake: riduce un round-trip aggiuntivo. Verifica che il tuo server advertisi H3 via `Alt-Svc: h3=":443"` header per permettere al browser di scoprire HTTP/3 automaticamente.
Usare `preconnect` con giudizio: ogni connessione pre-stabilita consuma risorse (CPU, memoria, banda) per il handshake TCP+TLS. Limita `preconnect` ai 2-3 domini più critici (CDN primario, dominio API principale). Per tutti gli altri usa `dns-prefetch` che risolve solo il DNS senza stabilire la connessione. Uno schema tipico nei nostri progetti Next.js: `preconnect` per il CDN di immagini e per l'endpoint analytics, `dns-prefetch` per Google Fonts (se non self-hosted), Meta Pixel, e altri domini terzi. Vuoi implementare questi miglioramenti nel tuo sito? Il nostro team di sviluppo web può occuparsene.
