Come velocizzare un web server: guida completa all’ottimizzazione

La velocità del web server è uno dei fattori tecnici con il maggiore impatto sulle performance di un sito, sull’esperienza utente e sul posizionamento nei risultati di ricerca. Google utilizza i Core Web Vitals — LCP, INP e CLS — come segnali di ranking dal 2021, e il TTFB (Time To First Byte) è il punto di partenza di tutta la catena di caricamento.

Questa guida copre ogni livello dell’ottimizzazione: dall’infrastruttura hardware alla configurazione del web server, dai protocolli di rete al caching applicativo, fino all’ottimizzazione degli asset frontend. Ogni sezione include configurazioni testate e riferimenti alla documentazione ufficiale.

---

Perché la velocità del server è un fattore di ranking

A marzo 2024, Google ha sostituito il First Input Delay (FID) con Interaction to Next Paint (INP) come metrica ufficiale dei Core Web Vitals. Le tre metriche attuali sono:

Metrica	Cosa misura	Soglia “buona”
LCP (Largest Contentful Paint)	Tempo di caricamento dell’elemento visibile più grande	< 2,5 secondi
INP (Interaction to Next Paint)	Latenza peggiore tra tutte le interazioni utente	< 200 millisecondi
CLS (Cumulative Layout Shift)	Stabilità visiva (spostamenti inattesi degli elementi)	< 0,1

INP è una metrica significativamente più severa di FID: mentre FID misurava solo il ritardo del primo input, INP valuta tutte le interazioni durante l’intera sessione. I siti con JavaScript pesante che passavano FID senza problemi possono risultare lenti secondo INP.

Il TTFB è il fondamento su cui poggiano tutte le metriche di velocità: se il server impiega 800 ms a rispondere, è matematicamente impossibile ottenere un LCP sotto i 2,5 secondi con contenuti complessi. L’ottimizzazione parte sempre dal server. Per un approfondimento sulle metriche di SEO tecnica legate alla velocità, c’è una guida dedicata sul blog.

---

Scegliere l’infrastruttura giusta

La scelta dell’infrastruttura è la decisione con il maggiore impatto sulle performance. Un sito su hosting condiviso da 3 €/mese non potrà mai competere con un VPS ben configurato, indipendentemente dalle ottimizzazioni software.

Shared hosting vs VPS vs Cloud vs Dedicato

Tipo	TTFB tipico	Controllo	Adatto a
Shared hosting	300-800 ms	Minimo (pannello)	Siti piccoli, blog personali
VPS (DigitalOcean, Hetzner, Vultr)	50-200 ms	Root completo	Siti professionali, e-commerce piccoli
Cloud (AWS, GCP, Azure)	30-150 ms	Completo + scalabilità	Progetti ad alto traffico, SaaS
Dedicato	20-100 ms	Hardware dedicato	Enterprise, siti con requisiti specifici

Il passaggio da shared hosting a un VPS con stack LEMP (Linux, Nginx, MariaDB, PHP-FPM) è l’upgrade singolo con il miglior rapporto costo/beneficio. Con un VPS da 10-20 €/mese si ottiene accesso root, risorse dedicate e la possibilità di configurare ogni componente dello stack. Per una guida alla scelta dell’hosting in base al progetto, il blog ha un approfondimento dedicato.

Separare il database dal web server

Su siti con traffico elevato, il database e il web server competono per le stesse risorse (CPU, RAM, I/O disco). Spostare MariaDB/MySQL su un server separato — o usare un servizio gestito come Amazon RDS o Google Cloud SQL — libera il web server e riduce i tempi di risposta. La latenza della connessione interna (rete privata) è trascurabile rispetto al beneficio ottenuto.

---

Ottimizzare il web server: Nginx e Apache

La configurazione del web server è dove si ottengono i guadagni più immediati. Nginx e Apache hanno filosofie diverse — event-driven il primo, process-based il secondo — e ciascuno richiede un tuning specifico. Per un confronto approfondito tra i due, la guida Apache vs Nginx analizza architettura, performance e casi d’uso.

Tuning Nginx

Le direttive fondamentali per le performance in /etc/nginx/nginx.conf:

# Worker: uno per core CPU
worker_processes auto;
worker_rlimit_nofile 65535;

events {
    worker_connections 4096;
    multi_accept on;
}

http {
    # I/O: zero-copy file transfer
    sendfile on;
    tcp_nopush on;      # accumula dati fino a un pacchetto TCP completo
    tcp_nodelay on;     # disabilita Nagle per keepalive

    # Keepalive
    keepalive_timeout 65;
    keepalive_requests 1000;

    # Cache dei file descriptor
    open_file_cache max=1000 inactive=20s;
    open_file_cache_valid 30s;
    open_file_cache_min_uses 2;

    # Buffer
    client_body_buffer_size 16k;
    client_header_buffer_size 1k;
    large_client_header_buffers 4 8k;
}

Nota: sendfile on abilita il trasferimento zero-copy dal kernel al socket — Netflix ha documentato incrementi di throughput da 6 Gbps a 30 Gbps con questa singola direttiva. tcp_nopush e tcp_nodelay lavorano insieme: il primo ottimizza i pacchetti pieni, il secondo riduce la latenza sulle connessioni keepalive.

FastCGI Cache su Nginx

Il FastCGI Cache di Nginx è la forma di full page cache più efficiente per siti PHP: serve le pagine direttamente dalla RAM o dal disco di Nginx, senza mai raggiungere PHP-FPM. Il risultato è un TTFB di 1-5 ms per le pagine in cache, contro i 200-800 ms di una risposta PHP.

# Definire la zona di cache nel blocco http
fastcgi_cache_path /var/cache/nginx levels=1:2 keys_zone=WORDPRESS:100m inactive=60m max_size=1g;
fastcgi_cache_key "$scheme$request_method$host$request_uri";

# Nel blocco server/location
location ~ \.php$ {
    fastcgi_pass unix:/run/php/php8.3-fpm.sock;
    fastcgi_cache WORDPRESS;
    fastcgi_cache_valid 200 60m;
    fastcgi_cache_valid 404 1m;
    fastcgi_cache_bypass $skip_cache;
    fastcgi_no_cache $skip_cache;
    add_header X-Cache-Status $upstream_cache_status;
}

Tuning Apache

Se usi Apache, le ottimizzazioni più impattanti sono:

• Usa l’MPM Event (non Prefork) — gestisce le connessioni con thread non bloccanti, simile all’architettura event-driven di Nginx.
• Disabilita i moduli inutili — il setup di default carica decine di moduli. Ogni modulo disabilitato libera memoria e CPU.
• Evita .htaccess dove possibile — con AllowOverride None, Apache non deve cercare e parsare file .htaccess in ogni directory per ogni richiesta. Sposta le regole nella configurazione del VirtualHost.
• Abilita mod_cache e mod_expires — per il caching delle risposte e l’impostazione degli header Cache-Control.

---

Protocolli moderni: HTTP/2, HTTP/3 e QUIC

Il protocollo di trasporto ha un impatto diretto sulla velocità percepita. L’evoluzione da HTTP/1.1 a HTTP/3 ha eliminato colli di bottiglia fondamentali. Per un approfondimento completo sulle differenze architetturali, la guida ai protocolli HTTP/1.1, HTTP/2 e HTTP/3 copre ogni aspetto tecnico.

Caratteristica	HTTP/1.1	HTTP/2	HTTP/3 (QUIC)
Trasporto	TCP	TCP	QUIC (UDP)
Multiplexing	No (1 richiesta per connessione)	Sì (stream multiplexati)	Sì (stream indipendenti)
Head-of-line blocking	Sì (TCP + HTTP)	Parziale (solo TCP)	No (eliminato)
Handshake	TCP + TLS (3-4 RTT)	TCP + TLS (2-3 RTT)	QUIC + TLS 1.3 (1 RTT, 0-RTT per ritorni)
Compressione header	No	HPACK	QPACK

Abilitare HTTP/3 su Nginx

Nginx supporta nativamente HTTP/3 dalla versione 1.25.0 (maggio 2023). La configurazione richiede TLS 1.3 e l’apertura della porta UDP 443 nel firewall:

server {
    listen 443 ssl;
    listen 443 quic reuseport;

    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

    # Abilita 0-RTT per connessioni di ritorno
    ssl_early_data on;

    # Header Alt-Svc: informa il browser che HTTP/3 è disponibile
    add_header Alt-Svc 'h3=":443"; ma=86400' always;
}

Il beneficio reale di HTTP/3 si manifesta soprattutto su connessioni mobili e ad alta latenza: test indipendenti mostrano pagine caricate il 20-30% più velocemente su reti 4G rispetto a HTTP/2. Il supporto browser supera il 95% (Chrome, Firefox, Edge, Safari).

---

TLS 1.3 e OCSP Stapling

Un tempo si consigliava di evitare HTTPS per non appesantire il server. Nel 2025 è vero il contrario: TLS 1.3 è più veloce e leggero di qualsiasi versione precedente, e HTTPS è requisito obbligatorio per HTTP/2 e HTTP/3. Per installare un certificato SSL gratuito, la guida su Certbot e certificato SSL su Nginx copre l’intero processo.

Vantaggi prestazionali di TLS 1.3

• Handshake 1-RTT — risparmia ~100 ms rispetto al 2-RTT di TLS 1.2 sulla prima connessione.
• 0-RTT resumption — i visitatori di ritorno saltano completamente l’handshake TLS, con latenza zero aggiuntiva.
• Cipher suite ridotta — solo algoritmi moderni (ChaCha20-Poly1305, AES-GCM), meno overhead di negoziazione.
• Rimossi RSA key exchange, RC4, SHA-1, CBC — meno complessità computazionale.

Configurazione Nginx ottimizzata

ssl_protocols TLSv1.2 TLSv1.3;
ssl_prefer_server_ciphers off;     # TLS 1.3: lascia scegliere al client

ssl_session_timeout 1d;
ssl_session_cache shared:SSL:10m;
ssl_session_tickets off;           # sicurezza migliore

# OCSP Stapling: elimina la richiesta del browser alla CA
ssl_stapling on;
ssl_stapling_verify on;
ssl_trusted_certificate /etc/letsencrypt/live/example.com/chain.pem;
resolver 1.1.1.1 8.8.8.8 valid=300s;

# HSTS: forza HTTPS ed elimina il redirect HTTP->HTTPS
add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload" always;

OCSP Stapling elimina una richiesta DNS + HTTP che il browser dovrebbe fare alla Certificate Authority per verificare la validità del certificato. Senza stapling, ogni nuova connessione TLS subisce un ritardo di 30-100 ms in più. Con HSTS attivo, il browser sa già che deve usare HTTPS e salta il redirect 301 da HTTP — un altro round-trip risparmiato.

---

Compressione: Brotli, gzip e Zstandard

La compressione del traffico HTTP riduce la dimensione dei file trasferiti del 60-70%, con un impatto diretto sui tempi di caricamento. Nel 2025 la situazione è cambiata rispetto al passato: gzip non è più l’unica opzione. Per la configurazione di gzip su WordPress, la guida dedicata ad abilitare gzip su Apache e Nginx resta il punto di partenza.

Algoritmo	Riduzione file	Velocità compressione	Supporto browser	Quando usarlo
gzip	~65%	Molto veloce	~100%	Fallback universale
Brotli	~70%	Lento ad alti livelli	~96%	Default per CSS/JS/HTML
Zstandard (zstd)	~68%	42% più veloce di Brotli	Tutti tranne Safari	Contenuti dinamici ad alto traffico

Strategia di compressione raccomandata

1. Pre-comprimi gli asset statici con Brotli livello 11 durante il build/deploy — massima compressione, costo computazionale pagato una sola volta.
2. Usa Brotli livello 4-6 per il contenuto dinamico — buon compromesso tra rapporto di compressione e consumo CPU.
3. Mantieni gzip come fallback per il ~4% dei browser che non supporta Brotli.
4. Valuta Zstandard se il server gestisce grandi volumi di risposte dinamiche — la velocità di compressione è il 42% superiore a Brotli a parità di rapporto.

Configurazione Brotli su Nginx (richiede il modulo ngx_brotli):

# Brotli dinamico
brotli on;
brotli_comp_level 6;
brotli_types text/plain text/css application/javascript application/json image/svg+xml;

# Brotli statico (serve file .br pre-compressi se esistono)
brotli_static on;

# Gzip come fallback
gzip on;
gzip_comp_level 5;
gzip_types text/plain text/css application/javascript application/json image/svg+xml;

---

Caching a tre livelli: OPcode, Object cache, Full page

Una strategia di caching efficace opera su tre livelli distinti, ciascuno con un impatto diverso. Lo stack ottimale per un sito WordPress su Nginx è:

Richiesta → Cloudflare (edge cache + Early Hints)
         → Nginx (FastCGI page cache)
         → PHP-FPM (OPcache + JIT)
         → Redis (object cache)
         → MariaDB/MySQL

Livello 1 — OPcode cache (OPcache)

OPcache memorizza in RAM lo script PHP già compilato in bytecode, eliminando la necessità di ricompilare lo stesso codice a ogni richiesta. L’impatto è un miglioramento di 2-3x sui tempi di esecuzione PHP. È incluso in PHP dalla versione 5.5 e attivato di default, ma la configurazione va ottimizzata per la produzione.

# /etc/php/8.3/fpm/conf.d/10-opcache.ini
opcache.enable=1
opcache.memory_consumption=256
opcache.interned_strings_buffer=32
opcache.max_accelerated_files=20000
opcache.validate_timestamps=0       # disabilita in produzione
opcache.revalidate_freq=0
opcache.jit_buffer_size=100M
opcache.jit=1255                    # tracing JIT

Nota: con validate_timestamps=0, OPcache non controlla se i file PHP sono cambiati. In produzione questo è il comportamento corretto — ogni deploy deve essere seguito da un restart di PHP-FPM o dal comando opcache_reset() per invalidare la cache.

Livello 2 — Object cache (Redis)

L’object cache memorizza in RAM i risultati delle query al database, le risposte API e i valori calcolati. Redis è la scelta predefinita nel 2025: con la versione 8.0 ha introdotto l’I/O multi-thread (fino al 112% di throughput in più su CPU multi-core) e ha integrato nel core funzionalità che prima richiedevano moduli separati (JSON, ricerca full-text, time series).

Memcached resta un’alternativa valida per scenari con caching puramente string-based e volumi estremi, ma Redis lo supera in quasi tutti i casi d’uso grazie a strutture dati più ricche, persistenza e replicazione nativa.

Livello 3 — Full page cache

Il full page cache serve l’intera risposta HTML senza eseguire PHP né interrogare il database. L’impatto è il più drammatico: da 200-800 ms (generazione dinamica) a 1-5 ms (cache hit). Le opzioni principali:

• Nginx FastCGI Cache — la soluzione più efficiente: Nginx serve le pagine direttamente dalla cache in RAM/disco, PHP non viene nemmeno invocato.
• Varnish — reverse proxy cache dedicato, potente ma aggiunge un layer di complessità.
• CDN edge cache — la pagina viene servita dal nodo CDN più vicino all’utente. L’approccio più veloce in assoluto per visitatori distribuiti geograficamente.
• Plugin WordPress (WP Rocket, WP Super Cache) — generano file HTML statici su disco. Efficaci se non si ha accesso alla configurazione del server.

---

PHP 8.x: JIT, OPcache e performance

PHP 8.4 (novembre 2024) e PHP 8.5 (novembre 2025) hanno consolidato i miglioramenti introdotti dalla famiglia 8.x. Il salto prestazionale rispetto a PHP 7.x — che una guida del 2016 avrebbe citato come versione corrente — è significativo: PHP 8.5 è circa il 14% più veloce di PHP 8.1 e fino a 2x più veloce di PHP 7.4 su alcuni workload.

Il compilatore JIT

Il JIT (Just-In-Time) compiler traduce il bytecode PHP in codice macchina nativo durante l’esecuzione. I benefici variano in base al tipo di carico:

• Operazioni CPU-bound (calcoli, elaborazione immagini, trasformazione dati) — fino a 3x più veloci nei benchmark sintetici.
• Web request standard (WordPress, Laravel, Symfony) — miglioramento reale tra 0% e 15%. Il collo di bottiglia è l’I/O (database, filesystem), non la CPU.

Il JIT è abilitato tramite la configurazione OPcache mostrata nella sezione precedente (opcache.jit=1255 per il tracing JIT, opcache.jit_buffer_size=100M).

Configurazione PHP-FPM

La configurazione del pool PHP-FPM è critica per la stabilità sotto carico:

# /etc/php/8.3/fpm/pool.d/www.conf
pm = dynamic
pm.max_children = 50           # RAM disponibile / ~40 MB per worker
pm.start_servers = 10
pm.min_spare_servers = 5
pm.max_spare_servers = 20
pm.max_requests = 500          # ricicla i worker per prevenire memory leak

request_terminate_timeout = 30s
request_slowlog_timeout = 5s
slowlog = /var/log/php-fpm/slow.log

Il parametro pm.max_children va calcolato in base alla RAM disponibile: se ogni processo PHP-FPM consuma ~40 MB e il server ha 2 GB di RAM libera, il valore massimo è circa 50. Superare questo limite porta a swap e degrado immediato delle performance.

---

Ottimizzazione del database

Il database è spesso il collo di bottiglia più sottovalutato. Un’installazione WordPress standard con plugin attivi può eseguire 50-200 query SQL per ogni caricamento pagina. Per le operazioni di manutenzione, la guida alla gestione del database WordPress con phpMyAdmin copre le procedure fondamentali.

Tuning MariaDB/MySQL

Nota: la MySQL Query Cache è stata rimossa in MySQL 8.0. Le vecchie guide che suggeriscono di configurare query_cache_size si riferiscono a MySQL 5.7 o precedenti. Nel 2025 il caching delle query si gestisce con Redis o Memcached.

# /etc/mysql/mariadb.conf.d/50-server.cnf

# InnoDB Buffer Pool: 70-80% della RAM su server dedicato al DB
innodb_buffer_pool_size = 4G
innodb_buffer_pool_instances = 4    # 1 per GB di buffer pool

# Skip DNS lookup per le connessioni
skip-name-resolve = 1

# InnoDB log: file più grandi = meno I/O su disco
innodb_log_file_size = 512M
innodb_flush_log_at_trx_commit = 2  # performance (1 = max sicurezza)
innodb_flush_method = O_DIRECT      # evita double buffering con OS

# Tabelle temporanee in memoria
tmp_table_size = 64M
max_heap_table_size = 64M

# Connessioni
max_connections = 200
wait_timeout = 300

Manutenzione del database WordPress

• Limita le revisioni — WordPress salva ogni revisione di ogni post. Con define('WP_POST_REVISIONS', 5); nel wp-config.php limiti a 5 per post.
• Pulisci i transient scaduti — i transient sono cache temporanee nel database. Quelli scaduti occupano spazio e rallentano le query sulla tabella wp_options.
• Ottimizza le tabelle — esegui periodicamente OPTIMIZE TABLE sulle tabelle InnoDB per recuperare spazio frammentato.
• Controlla le autoloaded options — la tabella wp_options con autoload=yes viene caricata a ogni richiesta. Plugin disinstallati male lasciano dati autoloaded che rallentano ogni singola pagina.

---

CDN e edge computing

Una CDN (Content Delivery Network) distribuisce i contenuti su centinaia di server nel mondo, servendo ogni richiesta dal nodo geograficamente più vicino all’utente. Nel 2025 le CDN non sono più semplici cache di file statici: piattaforme come Cloudflare offrono edge computing (Workers), WAF, bot management, ottimizzazione immagini e caching HTML — tutto al livello edge, senza mai raggiungere il server origin.

Strategie di caching CDN

• Asset statici — imposta Cache-Control: public, max-age=31536000, immutable per CSS, JS e immagini con hash nel filename. TTL di un anno, zero rivalidazione.
• HTML dinamico — usa Cache-Control: public, s-maxage=3600, stale-while-revalidate=86400 per cachare le pagine HTML al livello edge con rivalidazione in background.
• Tiered caching — abilita il tiered cache di Cloudflare: quando un nodo edge non ha la pagina in cache, la richiede a un nodo regionale (che probabilmente ce l’ha) prima di raggiungere l’origin.

Early Hints (HTTP 103)

Le Early Hints (103) sono una risposta HTTP preliminare che il server invia mentre sta ancora elaborando la richiesta principale. Contengono header Link con le risorse critiche da precaricare (CSS, font, JS):

# Nginx 1.21+
location / {
    add_header Link "; rel=preload; as=style" early;
    add_header Link "; rel=preload; as=font; crossorigin" early;
    proxy_pass http://backend;
}

Cloudflare offre Early Hints come funzionalità integrata: memorizza gli header Link dalle risposte HTML e li invia automaticamente come 103 alle richieste successive. Shopify e Cloudflare hanno documentato miglioramenti LCP di diverse centinaia di millisecondi.

---

Ottimizzazione delle immagini

Le immagini rappresentano tipicamente il 50-70% del peso totale di una pagina web. I formati moderni e il caricamento intelligente possono ridurre drasticamente questo peso. Per un approfondimento sul formato WebP e sulla tecnica del lazy loading senza JavaScript, il blog ha guide specifiche.

AVIF vs WebP vs JPEG

Formato	Riduzione vs JPEG	Supporto browser	Velocità encoding
AVIF	~50%	93,8%	Lenta
WebP	~30%	95,3%	Veloce
JPEG	baseline	100%	Molto veloce

La strategia ottimale nel 2025 è servire AVIF come formato primario, WebP come fallback e JPEG come fallback universale, usando l’elemento <picture>:

<picture>
  <source srcset="immagine.avif" type="image/avif">
  <source srcset="immagine.webp" type="image/webp">
  <img src="immagine.jpg" alt="Descrizione" loading="lazy"
       fetchpriority="high" width="800" height="600">
</picture>

WordPress 6.7+ supporta nativamente la generazione di immagini AVIF. L’attributo fetchpriority="high" (supportato da WordPress 6.9) indica al browser di dare priorità al download dell’immagine LCP, mentre loading="lazy" va usato su tutte le immagini below the fold.

Regole pratiche per le immagini

• Ridimensiona prima di caricare — servire un’immagine 3000 px per visualizzarla a 800 px è spreco puro. Genera le dimensioni necessarie lato server.
• Specifica sempre width e height — previene il layout shift (CLS) riservando lo spazio nel DOM prima del caricamento.
• Usa una CDN per le immagini — servire immagini da un dominio separato o dalla CDN riduce il carico sul server origin e sfrutta la distribuzione geografica.
• Comprimi con qualità 80-85% — la differenza visiva tra qualità 85 e 100 è impercettibile, ma la differenza in peso può essere del 40-60%.

---

Ottimizzazione CSS e JavaScript

CSS e JavaScript bloccanti sono i principali responsabili di LCP elevati e punteggi INP scarsi. L’obiettivo è ridurre al minimo le risorse che bloccano il rendering e differire tutto ciò che non è necessario per la prima visualizzazione.

Critical CSS

Il critical CSS è il sottoinsieme di regole necessario per renderizzare il contenuto above the fold. Va inserito inline nell’<head> della pagina, mentre il resto del foglio di stile viene caricato in modo asincrono. Tool come Critical (npm) o Penthouse automatizzano l’estrazione. Per una guida completa, vedi l’articolo su come ottimizzare il CSS.

Defer e async per JavaScript

Ogni file JavaScript senza attributi speciali blocca il parsing HTML fino al completamento del download e dell’esecuzione. Le due soluzioni sono async e defer:

• defer — scarica in parallelo, esegue dopo il parsing HTML, mantiene l’ordine di esecuzione. Ideale per la maggior parte degli script.
• async — scarica in parallelo, esegue appena disponibile (senza ordine garantito). Adatto a script indipendenti come analytics.

Ridurre il peso del CSS

• Rimuovi il CSS inutilizzato — i framework CSS e i page builder caricano migliaia di regole non necessarie. La guida su come rimuovere il CSS inutilizzato mostra le tecniche e gli strumenti.
• Minifica — rimuovi spazi, commenti e caratteri superflui. Plugin come Autoptimize o WP Rocket automatizzano il processo su WordPress.
• Dividi per pagina — non caricare un unico foglio di stile monolitico su tutte le pagine. Carica solo le regole necessarie per ciascuna sezione del sito.

---

Resource hints: preload, preconnect, prefetch

I resource hints sono istruzioni che il browser riceve per anticipare il caricamento di risorse che saranno necessarie a breve. Utilizzati correttamente, eliminano la latenza di scoperta e connessione. Per approfondimenti specifici: HTTP Preload, Preconnect e dns-prefetch, Prefetch e Prerender.

Hint	Cosa fa	Quando usarlo
preload	Scarica la risorsa con alta priorità nella pagina corrente	Font, CSS critico, immagine LCP
preconnect	Stabilisce la connessione (DNS + TCP + TLS) verso un dominio esterno	CDN, font Google, API di terze parti
dns-prefetch	Risolve solo il DNS di un dominio esterno	Domini secondari usati nella pagina
prefetch	Scarica una risorsa a bassa priorità per un uso futuro	Pagine successive probabili

Speculative Loading (WordPress 6.8+)

WordPress 6.8 (marzo 2025) ha introdotto lo Speculative Loading tramite la Speculation Rules API. Questa funzionalità pre-renderizza le pagine verso cui l’utente potrebbe navigare, producendo transizioni quasi istantanee. È abilitata di default per tutti i visitatori non autenticati e ha portato la percentuale di navigazioni con Speculation Rules dal 8,47% al 10,81% del web globale entro due mesi dal lancio.

---

Tuning del kernel Linux

Il kernel Linux gestisce lo stack di rete, i file descriptor, i buffer e l’algoritmo di congestione TCP. I default del kernel sono pensati per un uso generico: su un web server ad alto traffico, il tuning dei parametri di rete produce miglioramenti misurabili.

Parametri sysctl per web server

# /etc/sysctl.d/99-webserver.conf

# Connection backlog
net.core.somaxconn = 65535
net.core.netdev_max_backlog = 65536
net.ipv4.tcp_max_syn_backlog = 8192

# Buffer TCP
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216

# Riutilizzo connessioni TIME_WAIT
net.ipv4.tcp_tw_reuse = 1

# BBR: algoritmo di congestione basato su banda e RTT
net.core.default_qdisc = fq
net.ipv4.tcp_congestion_control = bbr

# TCP Fast Open (client + server)
net.ipv4.tcp_fastopen = 3

# File descriptor
fs.file-max = 2097152

# TCP keepalive
net.ipv4.tcp_keepalive_time = 600
net.ipv4.tcp_keepalive_intvl = 60
net.ipv4.tcp_keepalive_probes = 3

BBR congestion control

BBR (Bottleneck Bandwidth and Round-trip propagation time) è un algoritmo di congestione sviluppato da Google, disponibile dal kernel Linux 4.9. A differenza degli algoritmi tradizionali basati sulla perdita di pacchetti (CUBIC), BBR stima la banda disponibile e il round-trip time per regolare la velocità di invio. Il risultato è throughput più elevato e latenza inferiore, specialmente su connessioni a lunga distanza o con packet loss.

Nota: il parametro tcp_tw_recycle è stato rimosso nel kernel Linux 4.12 per problemi con NAT. Le vecchie guide che lo raccomandano sono obsolete — usare solo tcp_tw_reuse.

---

Ridurre redirect e correggere errori

Ogni redirect HTTP aggiunge un round-trip completo (DNS + TCP + TLS + risposta 301/302 + nuova richiesta). Una catena di 3 redirect può aggiungere 300-500 ms al caricamento. Le azioni prioritarie:

• Elimina le catene di redirect — se A → B → C → D, correggi in A → D direttamente.
• Correggi i link alla fonte — anziché fare affidamento sui redirect 301, aggiorna i link interni per puntare all’URL definitivo.
• Usa HSTS per eliminare il redirect HTTP → HTTPS — con HSTS il browser sa già che deve usare HTTPS e non tenta nemmeno la connessione HTTP.
• Trova e correggi gli errori 404 — ogni 404 servito a Googlebot spreca crawl budget. Monitora gli errori in Search Console e correggi i link rotti.

---

Come misurare le performance

Non si può ottimizzare ciò che non si misura. Ogni intervento richiede una baseline prima e una misurazione dopo. Gli strumenti si dividono in due categorie: lab data (test sintetici, riproducibili) e field data (dati reali da utenti in produzione).

Strumenti di lab testing

• Chrome DevTools — il pannello Network e Performance offrono visibilità in tempo reale su ogni richiesta, waterfall di caricamento, tempi di rendering e thread principale.
• Lighthouse — integrato in Chrome DevTools e disponibile come CLI. Produce un audit completo di performance, accessibilità, SEO e best practice con punteggi e raccomandazioni operative.
• WebPageTest — il tool più avanzato per test sintetici. Permette di scegliere la location, il device, la connessione, e produce waterfall dettagliati, filmstrip del caricamento e confronti A/B.
• GTmetrix — combina Lighthouse e Web Vitals con un’interfaccia intuitiva e storico delle misurazioni nel tempo.

Strumenti di field testing (dati reali)

• PageSpeed Insights — mostra i dati CrUX (Chrome User Experience Report) reali per il dominio, affiancati ai risultati del lab test Lighthouse.
• Google Search Console — il report Core Web Vitals raggruppa le pagine per stato (buono, migliorabile, scarso) e identifica i problemi specifici da risolvere.
• CrUX Dashboard — report BigQuery con l’andamento storico dei Core Web Vitals per dominio, analizzabile per dispositivo, connessione e paese.

Stress testing

Per verificare come il server si comporta sotto carico reale, gli stress test simulano centinaia o migliaia di connessioni simultanee. Tool come wrk, ab (Apache Bench) e k6 permettono di identificare il punto di rottura prima che lo facciano gli utenti reali.

---

Checklist riepilogativa

Le ottimizzazioni ordinate per impatto decrescente — le prime producono i benefici più significativi:

Priorità	Intervento	Impatto TTFB
1	Full page cache (Nginx FastCGI / CDN edge)	10-100x più veloce
2	CDN con edge caching + Early Hints 103	-200-500 ms
3	PHP 8.4+ con OPcache + JIT ottimizzati	2-3x PHP più veloce
4	Redis object cache	-50-200 ms (query DB)
5	HTTP/3 QUIC + TLS 1.3 + OCSP Stapling	-100-300 ms (handshake)
6	Brotli compression	-5-20% tempo trasferimento
7	Tuning Nginx (worker, buffer, keepalive)	-20-50 ms
8	Tuning MariaDB/MySQL (buffer pool, skip-name-resolve)	-10-100 ms (query)
9	Immagini AVIF/WebP + lazy loading + fetchpriority	Impatto su LCP, non TTFB
10	Critical CSS + JS defer/async	Impatto su LCP e INP
11	Resource hints (preload, preconnect)	Impatto su LCP
12	Kernel tuning (BBR, somaxconn, TCP Fast Open)	-5-30 ms
13	Eliminare catene di redirect	-100-300 ms per redirect

---

Fonti e riferimenti

• Nginx Official Documentation — documentazione completa di tutti i moduli e direttive
• Apache HTTP Server 2.4 Documentation
• Interaction to Next Paint (INP) — web.dev, definizione e guida all’ottimizzazione
• Core Web Vitals — Google Search Central
• PHP OPcache Documentation — php.net
• Redis 8 is now GA — redis.io, benchmark e nuove funzionalità
• Nginx QUIC (HTTP/3) Documentation
• Cloudflare Cache Documentation
• RFC 9114 — HTTP/3 — specifica ufficiale IETF
• RFC 8446 — TLS 1.3 — specifica ufficiale IETF
• MariaDB Performance Tuning — documentazione ufficiale
• Speculative Loading in WordPress 6.8 — Make WordPress Core