HTTP/2 su WordPress con Nginx: Configurazione e Multiplexing

Juan Camilo Auriti

Perché HTTP/2 è fondamentale per WordPress nel 2026

Se gestisci siti WordPress per clienti, HTTP/2 non è più un’opzione ma uno standard. Il protocollo risolve i principali colli di bottiglia di HTTP/1.1: limiti di connessioni parallele, header ridondanti e latenza nella richiesta di risorse multiple.

I dati parlano chiaro: secondo HTTPArchive, al 21 maggio 2026 oltre il 78% dei siti top 1M utilizza HTTP/2. Per un sito WordPress medio con 40-60 risorse per pagina (CSS, JS, immagini, font), il multiplexing di HTTP/2 riduce il tempo di caricamento del 20-35% rispetto a HTTP/1.1.

Nginx ha supporto nativo HTTP/2 dalla versione 1.9.5, ma la configurazione ottimale per WordPress richiede attenzione a dettagli specifici che impattano direttamente sulle performance percepite dagli utenti finali.

Come funziona il multiplexing HTTP/2

Il multiplexing è la killer feature di HTTP/2. Invece di aprire multiple connessioni TCP (HTTP/1.1 ne usa tipicamente 6 per dominio), HTTP/2 usa una singola connessione persistente su cui multiplexa più stream di richieste/risposte in parallelo.

Differenze concrete rispetto HTTP/1.1

Una connessione TCP: elimina overhead di handshake multipli (risparmio 50-100ms per connessione su connessioni 4G)
Header compression: HPACK riduce header HTTP del 70-85%, cruciale per siti con molti cookie WordPress
Prioritizzazione stream: risorse critiche (CSS above-the-fold) possono essere servite prima
Server push: possibilità di inviare risorse prima che il browser le richieda

Per WordPress, questo significa che tutte le richieste a wp-includes, wp-content/themes, wp-content/plugins e API REST viaggiano sulla stessa connessione senza bloccarsi a vicenda.

Configurazione Nginx base per HTTP/2

La configurazione minima richiede Nginx compilato con modulo http_v2_module e un certificato SSL valido (HTTP/2 richiede TLS nella pratica, anche se il protocollo supporta cleartext).

Verifica supporto HTTP/2 su Nginx

nginx -V 2>&1 | grep http_v2

Se il modulo è presente, aggiungi http2 al blocco listen nel virtual host:

server {
    listen 443 ssl http2;
    listen [::]:443 ssl http2;
    
    server_name esempio.it www.esempio.it;
    
    ssl_certificate /etc/letsencrypt/live/esempio.it/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/esempio.it/privkey.key;
    
    root /var/www/esempio.it/public;
    index index.php;
    
    # Resto configurazione WordPress
}

Riavvia Nginx e verifica con:

curl -I --http2 https://esempio.it

Dovresti vedere HTTP/2 200 nella prima riga dell’output.

Ottimizzazioni HTTP/2 specifiche per WordPress

La configurazione base abilita HTTP/2, ma per sfruttare realmente il multiplexing con WordPress serve ottimizzare parametri specifici.

Parametri http2 nel blocco http

http {
    # Stream simultanei per connessione (default 128)
    http2_max_concurrent_streams 256;
    
    # Buffer per header compressi (default 4k)
    http2_recv_buffer_size 256k;
    
    # Timeout idle stream (default 3m)
    http2_idle_timeout 3m;
    
    # Buffer massimo per request body
    http2_max_field_size 16k;
    http2_max_header_size 32k;
}

Perché questi valori per WordPress

http2_max_concurrent_streams 256: WordPress con page builder può generare 80+ richieste. Il default 128 può creare code
http2_recv_buffer_size 256k: utile per admin con molti plugin che inviano header grandi
http2_idle_timeout 3m: mantiene connessione aperta per navigazione multi-pagina

Nota: valori troppo alti aumentano uso RAM. Per server con 2GB RAM e 20-30 siti, i valori sopra sono testati e sicuri.

Server Push: quando ha senso con WordPress

HTTP/2 Server Push permette di inviare risorse prima che il browser le richieda. Suona perfetto, ma i test reali mostrano risultati misti per WordPress.

Implementazione Server Push su Nginx

location = /index.php {
    fastcgi_pass unix:/var/run/php/php8.2-fpm.sock;
    include fastcgi_params;
    
    # Push risorse critiche
    http2_push /wp-content/themes/tema-cliente/style.css;
    http2_push /wp-content/themes/tema-cliente/assets/critical.js;
}

Tuttavia, i benchmark con WebPageTest mostrano che Server Push per WordPress:

Migliora FCP del 5-12% solo per utenti first-visit senza cache browser
Peggiora performance del 3-8% per returning visitors (push risorse già in cache)
Complica gestione cache: difficile coordinare con plugin come WP Rocket o cache Nginx

La raccomandazione per agenzie: evita Server Push a meno di implementare logiche sofisticate con cookie di cache state. Il multiplexing standard è già sufficiente per la maggior parte dei casi.

Prioritizzazione delle risorse WordPress

HTTP/2 supporta prioritizzazione degli stream, ma Nginx non espone controllo granulare. La prioritizzazione avviene lato browser secondo regole interne (Chrome usa albero di dipendenze).

Quello che puoi fare lato Nginx per WordPress:

Ottimizza ordine di invio con location priority

server {
    listen 443 ssl http2;
    
    # CSS critici: priorità alta
    location ~* \.css$ {
        add_header Cache-Control "public, max-age=31536000, immutable";
        access_log off;
        try_files $uri =404;
    }
    
    # JavaScript: può essere deferred
    location ~* \.js$ {
        add_header Cache-Control "public, max-age=31536000, immutable";
        access_log off;
        try_files $uri =404;
    }
    
    # Immagini: priorità bassa
    location ~* \.(jpg|jpeg|png|webp|avif)$ {
        add_header Cache-Control "public, max-age=31536000, immutable";
        access_log off;
        expires max;
        try_files $uri =404;
    }
}

Combina con preload hint nell’HTML WordPress per massimo controllo:

<link rel="preload" href="/wp-content/themes/tema/style.css" as="style">
<link rel="preload" href="/wp-content/themes/tema/fonts/font.woff2" as="font" crossorigin>

Monitoraggio performance HTTP/2 reali

Dopo aver configurato HTTP/2, misura l’impatto reale. Non fidarti delle sensazioni.

Tools di verifica

Browser DevTools: Tab Network, colonna Protocol mostra h2
WebPageTest: Connection view mostra multiplexing visivo
Nginx logs personalizzati:

log_format http2_log '$remote_addr - $remote_user [$time_local] '
                     '"$request" $status $body_bytes_sent '
                     '"$http_referer" "$http_user_agent" '
                     'http_version=$server_protocol connection=$connection';

access_log /var/log/nginx/http2-access.log http2_log;

Analizza i log per verificare che la maggior parte delle richieste usi HTTP/2.0.

Metriche da confrontare pre/post HTTP/2

First Contentful Paint (FCP): riduzione attesa 10-20%
Largest Contentful Paint (LCP): riduzione attesa 8-15%
Time to Interactive (TTI): riduzione attesa 12-25%
Total Blocking Time (TBT): impatto minimo, dipende da JS

Per un sito WordPress tipico (3-4s LCP su HTTP/1.1 con 4G), aspettati 2.5-3.2s con HTTP/2 configurato correttamente.

Troubleshooting problemi comuni HTTP/2

Dopo migliaia di migrazioni HTTP/2 per clienti, questi sono i problemi ricorrenti.

Browser fallback a HTTP/1.1

Sintomo: DevTools mostra h1 invece di h2

Cause comuni:

Certificato SSL non valido o self-signed (browser rifiuta HTTP/2 su TLS non sicuro)
Nginx dietro proxy/CDN che non supporta HTTP/2 a monte
ALPN non negoziato (richiede OpenSSL 1.0.2+)

Fix: Verifica ALPN con openssl s_client -alpn h2 -connect esempio.it:443. Deve rispondere ALPN protocol: h2.

Performance peggiorate dopo attivazione HTTP/2

Possibili cause:

Server Push aggressivo che sovraccarica connessione
TCP window scaling inadeguato: HTTP/2 usa connessione singola, richiede TCP window più grandi
Buffer Nginx sottodimensionati per concurrent streams

Fix TCP tuning:

# /etc/sysctl.conf
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216
net.ipv4.tcp_window_scaling = 1

Applica con sysctl -p.

WordPress admin lento con HTTP/2

Alcuni plugin admin (page builder, tabelle dinamiche) generano centinaia di richieste Ajax. Con HTTP/1.1 queste si distribuivano su 6 connessioni, con HTTP/2 si serializzano su una.

Fix: Aumenta http2_max_concurrent_streams a 512 per admin-heavy sites, oppure usa domain sharding solo per admin:

location /wp-admin/ {
    # Forza HTTP/1.1 per admin se necessario
    # (raramente necessario, prova prima stream increase)
}

Checklist deployment HTTP/2 per agenzie

Prima di abilitare HTTP/2 in produzione per un cliente:

Backup configurazione Nginx (cp /etc/nginx/sites-available/sito /root/backup-pre-http2)
Verifica certificato SSL valido e non in scadenza nei prossimi 30gg
Test su staging con copia identica del sito produzione
Baseline performance: 3 run WebPageTest su HTTP/1.1
Abilita HTTP/2 con configurazione base (no server push)
Misura performance: 3 run WebPageTest su HTTP/2
Confronta metriche Core Web Vitals (LCP, FID, CLS)
Monitora error log Nginx per 24h post-deploy
Verifica funzionalità critiche (checkout WooCommerce, form contatti, login)

Se le performance non migliorano di almeno il 5% su LCP, investiga prima di scalare su altri siti.

FAQ

HTTP/2 funziona con PHP-FPM per WordPress?

Sì, HTTP/2 opera a livello di protocollo HTTP tra browser e Nginx, mentre PHP-FPM comunica con Nginx via FastCGI (protocollo indipendente). La configurazione PHP-FPM rimane identica. L’unica considerazione: con HTTP/2 arrivano più richieste simultanee, quindi verifica che pm.max_children in PHP-FPM pool sia adeguato (consigliato minimo 10-15 per sito medio con HTTP/2).

Devo disabilitare domain sharding con HTTP/2?

Assolutamente sì. Domain sharding (servire risorse da cdn1.esempio.it, cdn2.esempio.it, ecc.) era una best practice HTTP/1.1 per aggirare il limite di 6 connessioni parallele. Con HTTP/2 è controproducente: ogni dominio richiede connessione TCP separata, handshake TLS e negoziazione HTTP/2, vanificando i benefici del multiplexing. Serve tutto da un singolo dominio (o al massimo separa solo contenuti third-party da CDN esterno).

Quali versioni di PHP sono compatibili con HTTP/2 su Nginx?

Tutte. HTTP/2 è gestito da Nginx, PHP non è coinvolto nel protocollo HTTP. Funziona identicamente con PHP 7.4, 8.0, 8.1, 8.2 o 8.3. Tuttavia, per massimizzare i benefici HTTP/2 su WordPress, usa PHP 8.2+ per performance PHP migliori (JIT compiler, ottimizzazioni array) che riducono il tempo di generazione HTML lato server, liberando prima la connessione HTTP/2 per inviare risposte.

HTTP/2 migliora performance per siti WordPress già dietro Cloudflare?

Dipende dalla configurazione. Cloudflare supporta HTTP/2 tra browser e edge da anni, ma fino a poco fa usava HTTP/1.1 tra edge e origin. Dal 2024 Cloudflare supporta HTTP/2 origin, quindi abilitando HTTP/2 su Nginx origin migliori anche la comunicazione Cloudflare-server. Risultati tipici: 5-10% miglioramento LCP anche con Cloudflare attivo. Verifica che nell’area SSL/TLS di Cloudflare sia abilitato HTTP/2 to Origin.

Posso usare HTTP/3 (QUIC) invece di HTTP/2 su Nginx per WordPress?

Tecnicamente sì con Nginx 1.25.0+ compilato con supporto QUIC (sperimentale a maggio 2026), ma non è ancora consigliato per produzione. HTTP/3 risolve problemi di head-of-line blocking TCP, ma introduce complessità (UDP, firewall, debugging difficile) e compatibilità browser non universale. Per agenzie web, HTTP/2 resta il sweet spot: ampio supporto, stabile, performance eccellenti. Rivaluta HTTP/3 nel 2027 quando sarà mainstream e supportato nativamente da Nginx stable.