I plugin di caching WordPress<\/a> fanno un ottimo lavoro, ma il caching a livello server<\/strong> \u00e8 su un altro piano. Funziona prima ancora che PHP venga eseguito, servendo le pagine direttamente dalla memoria del web server. Il risultato sono tempi di risposta di pochi millisecondi anzich\u00e9 centinaia. In questa guida ti spiego come configurare il caching del server per WordPress<\/strong> con Nginx FastCGI Cache, Redis Object Cache e Varnish.<\/p>\n Un plugin di caching<\/strong> come WP Rocket o WP Super Cache genera file HTML statici delle pagine e li salva su disco. Quando un visitatore richiede una pagina, PHP verifica se esiste una versione cache e la serve. Il processo \u00e8 veloce ma coinvolge comunque l’esecuzione di PHP.<\/p>\n Il caching a livello server<\/strong> intercetta la richiesta prima che arrivi a PHP. Il web server (Nginx, Apache con Varnish) ha la pagina gi\u00e0 pronta in memoria RAM e la serve direttamente. PHP non viene mai chiamato, il database non viene interrogato. \u00c8 il livello di caching pi\u00f9 veloce possibile.<\/p>\n I due livelli non sono in competizione: lavorano insieme. Il caching server gestisce le richieste ripetute, mentre il plugin di caching genera le pagine statiche e gestisce la purge intelligente della cache.<\/p>\n Se il tuo server usa Nginx<\/strong> come web server (o come reverse proxy davanti ad Apache), FastCGI Cache \u00e8 la soluzione pi\u00f9 efficiente. Memorizza l’output di PHP-FPM direttamente nella memoria del server e serve le pagine senza coinvolgere PHP.<\/p>\n La configurazione base richiede di aggiungere queste direttive al file di configurazione Nginx:<\/p>\n Questa configurazione crea una cache di massimo 1 GB che memorizza le pagine per 60 minuti. Le pagine admin e le richieste degli utenti loggati bypassano la cache, garantendo che vedano sempre il contenuto aggiornato.<\/p>\n Redis<\/strong> \u00e8 un database in-memory che pu\u00f2 essere usato come cache degli oggetti WordPress. A differenza del page caching che salva l’intera pagina HTML, l’object cache<\/strong> memorizza i risultati delle query al database. Questo accelera le pagine dinamiche che non possono essere servite da cache statica: il pannello admin, le pagine WooCommerce con carrello, le aree riservate.<\/p>\n Per configurare Redis su WordPress:<\/p>\n Aggiungi in wp-config.php<\/span>:<\/p>\n Redis \u00e8 particolarmente efficace per siti con molte query al database: ecommerce<\/a>, siti con membership, forum e siti multilingua. La dashboard WordPress stessa diventa notevolmente pi\u00f9 reattiva con Redis attivo.<\/p>\n Varnish<\/strong> \u00e8 un HTTP accelerator che si posiziona davanti al web server (Apache o Nginx) e serve le pagine dalla memoria RAM. \u00c8 usato da siti ad alto traffico come Wikipedia e molti provider di hosting managed WordPress lo includono nella configurazione di default.<\/p>\n Varnish \u00e8 estremamente potente ma la configurazione (tramite il linguaggio VCL) \u00e8 complessa. Per WordPress, puoi usare configurazioni VCL pre-fatte che gestiscono correttamente il bypass per utenti loggati, pagine admin e risorse dinamiche. Il plugin Varnish HTTP Purge<\/strong> gestisce la purge automatica della cache quando pubblichi o modifichi un contenuto.<\/p>\n Non \u00e8 propriamente caching delle pagine, ma OPcache<\/strong> \u00e8 essenziale per le performance di WordPress. OPcache memorizza il bytecode compilato dei file PHP in memoria, evitando la ricompilazione a ogni richiesta. Su un sito WordPress con decine di plugin, questo riduce significativamente il tempo di esecuzione PHP.<\/p>\n Verifica che OPcache sia attivo nel tuo php.ini con queste impostazioni raccomandate:<\/p>\n Queste impostazioni allocano 256 MB di memoria per il bytecode cache e rivalidano i file ogni 60 secondi. Per siti in produzione dove i file PHP cambiano raramente, puoi aumentare revalidate_freq<\/span> a 300 o pi\u00f9.<\/p>\n La configurazione ideale per un sito WordPress ad alte prestazioni combina pi\u00f9 livelli di cache:<\/p>\n Con tutti questi livelli attivi, un sito WordPress pu\u00f2 servire migliaia di richieste al secondo con tempi di risposta inferiori a 50 millisecondi. La differenza rispetto a un sito senza caching server \u00e8 enorme: da 2-3 secondi di TTFB a meno di 50ms. Questo si traduce in una migliore esperienza utente, un bounce rate pi\u00f9 basso e un posizionamento migliore sui motori di ricerca.<\/p>\n Il problema principale del caching server \u00e8 l’invalidazione<\/strong>: quando pubblichi un nuovo articolo o modifichi una pagina, la cache deve essere svuotata per mostrare il contenuto aggiornato. Ogni sistema ha il suo meccanismo: Nginx FastCGI Cache usa la direttiva purge, Redis ha il comando FLUSHDB, Varnish usa le regole di ban nel VCL. I plugin di caching come WP Rocket e LiteSpeed Cache integrano automaticamente la purge per i rispettivi server. La configurazione corretta della purge \u00e8 fondamentale per evitare che i visitatori vedano contenuti obsoleti.<\/p>\nDifferenza tra caching plugin e caching server<\/h2>\n
Nginx FastCGI Cache<\/h2>\n
# Definisci la zona di cache (nel blocco http)\nfastcgi_cache_path \/var\/cache\/nginx levels=1:2\n keys_zone=wordpress:100m inactive=60m max_size=1g;\n\n# Nel blocco server\nset $skip_cache 0;\n\n# Non cachare per utenti loggati\nif ($http_cookie ~* \"wordpress_logged_in\") {\n set $skip_cache 1;\n}\n\n# Non cachare le pagine admin\nif ($request_uri ~* \"\/wp-admin\/|\/wp-login.php\") {\n set $skip_cache 1;\n}\n\n# Attiva la cache nel blocco location ~ .php$\nfastcgi_cache wordpress;\nfastcgi_cache_valid 200 60m;\nfastcgi_cache_bypass $skip_cache;\nfastcgi_no_cache $skip_cache;<\/pre>\nRedis Object Cache<\/h2>\n
\n
define('WP_REDIS_HOST', '127.0.0.1');\ndefine('WP_REDIS_PORT', 6379);<\/pre>\nVarnish Cache<\/h2>\n
OPcache per PHP<\/h2>\n
opcache.enable=1\nopcache.memory_consumption=256\nopcache.max_accelerated_files=20000\nopcache.revalidate_freq=60<\/pre>\n
Combinare i livelli di cache<\/h2>\n
\n
Invalidare la cache correttamente<\/h2>\n
Serve aiuto con la configurazione?<\/h2>\n