Perché il tuo sito WordPress non supera 90 di PageSpeed (e come cambiarlo)
Velocizzare un sito WordPress oltre la soglia dei 90 punti su PageSpeed Insights non è magia: è architettura. La maggior parte degli sviluppatori si ferma ai plugin di caching di base, senza capire che il collo di bottiglia spesso non è dove sembra. In questo articolo analizziamo le tecniche avanzate che fanno davvero la differenza.
Il caching non è uno solo: conosci i livelli
Uno degli errori più comuni è trattare il caching come un interruttore on/off. In realtà esistono almeno quattro livelli distinti che devi gestire consapevolmente:
- Full Page Cache (FPC): salva l'HTML completo generato da PHP. Strumenti come WP Rocket, W3 Total Cache o soluzioni server-side con Nginx FastCGI Cache riducono il TTFB a meno di 50ms su pagine statiche.
- Object Cache: memorizza query al database e risultati di funzioni costose. Redis o Memcached sono lo standard. Senza object cache, ogni richiesta autentica colpisce MySQL anche per dati identici.
- Opcode Cache (OPcache): PHP compila i file .php in bytecode. OPcache mantiene quel bytecode in memoria. Abilitarlo correttamente (con opcache.validate_timestamps=0 in produzione) può ridurre il tempo di esecuzione PHP del 30-50%.
- Browser Cache e CDN: header Cache-Control e Expires corretti, combinati con un CDN edge come Cloudflare o BunnyCDN, eliminano round-trip inutili per asset statici.
Configurazione avanzata di Nginx FastCGI Cache
Se gestisci il server (VPS, cloud), FastCGI Cache è probabilmente la scelta più performante per WordPress. Ecco un blocco di configurazione minimale ma efficace:
- Definisci la zona cache in nginx.conf: fastcgi_cache_path /var/cache/nginx levels=1:2 keys_zone=WORDPRESS:100m inactive=60m;
- Nel blocco server, usa fastcgi_cache_bypass per escludere utenti loggati, carrelli WooCommerce e pagine con cookie di sessione.
- Imposta fastcgi_cache_valid 200 60m; e aggiungi l'header X-Cache-Status per il debug in produzione.
- Invalida la cache selettivamente con uno script bash o un hook WordPress che chiama nginx -s reload solo sulle pagine modificate.
Questo approccio bypassa completamente PHP per le pagine cachate: il TTFB scende sotto i 20ms anche su hardware modesto.
Critical CSS e deferimento delle risorse
Il caching risolve il backend, ma Core Web Vitals come LCP e CLS dipendono dal frontend. Le tecniche chiave:
- Estrai il Critical CSS con strumenti come critical (npm) o PurgeCSS. Inline il CSS above-the-fold nel <head> e carica il resto in modo asincrono.
- Defer JavaScript non essenziale: aggiungi defer o async agli script che non bloccano il rendering. In WordPress usa il filtro script_loader_tag.
- Preconnect e DNS-prefetch per domini di terze parti (Google Fonts, analytics, CDN): riducono la latenza di connessione percepita.
- Lazy loading nativo con loading="lazy" su immagini e iframe below-the-fold. WordPress lo aggiunge automaticamente dalla 5.5, ma verifica che il tuo tema non lo sovrascriva.
Database optimization: il collo di bottiglia nascosto
Un sito con 3 anni di storia accumula tabelle wp_options con migliaia di righe di autoload, revisioni post illimitate e transient scaduti mai puliti. Questo degrada le query anche con object cache attivo.
- Limita le revisioni in wp-config.php: define('WP_POST_REVISIONS', 5);
- Pulisci i transient scaduti con WP-CLI: wp transient delete --expired
- Analizza le opzioni in autoload con: SELECT option_name, length(option_value) FROM wp_options WHERE autoload='yes' ORDER BY length(option_value) DESC LIMIT 20;
- Aggiungi indici mancanti su wp_postmeta e wp_options se usi query custom frequenti.
Se stai cercando un toolkit che semplifichi parte di questa gestione senza moltiplicare i plugin attivi, LANGA Tools integra funzionalità di ottimizzazione e sicurezza in un'unica installazione, riducendo il overhead complessivo sul sito.
Monitoraggio continuo: non ottimizzare al buio
Raggiungere 90+ non basta se il punteggio crolla dopo il prossimo aggiornamento del tema. Implementa un sistema di monitoraggio:
- Lighthouse CI integrato nella pipeline CI/CD (GitHub Actions, GitLab CI) per testare ogni deploy.
- Google Search Console per i Core Web Vitals reali degli utenti (field data), non solo i dati lab.
- Alerting su TTFB con UptimeRobot o Better Uptime: un TTFB che sale oltre 500ms è spesso il primo segnale di un problema di caching o database.
FAQ: Performance WordPress avanzata
Redis o Memcached per WordPress?
Redis è generalmente preferibile: supporta strutture dati più ricche, la persistenza opzionale e il cluster nativo. Con il plugin Redis Object Cache di Till Krüss la configurazione richiede meno di 10 minuti su un VPS standard.
Il caching rompe WooCommerce?
Solo se mal configurato. Devi escludere dalla cache le pagine carrello, checkout, account e qualsiasi URL con cookie woocommerce_items_in_cart. Tutti i plugin di caching seri hanno regole predefinite per WooCommerce.
Quanti plugin di caching posso usare contemporaneamente?
Uno solo per il full page cache. Usarne due crea conflitti e può corrompere gli header HTTP. Puoi combinare un FPC plugin con un CDN esterno, ma la logica di invalidazione deve essere coordinata.
PageSpeed 100 è necessario per il ranking?
No. Google usa i Core Web Vitals come segnale di ranking, non il punteggio PageSpeed numerico. Punta a LCP sotto 2.5s, FID/INP sotto 200ms e CLS sotto 0.1 nel field data reale. Il punteggio lab è uno strumento diagnostico, non un obiettivo assoluto.
Per continuare a leggere,
accedi al tuo account.
Il tuo account LANGA ti connette a tutta la Galaxy.
Articoli completi su tutti i blog Galaxy.
Un solo login, accesso ovunque.
Guadagna Leghe e sblocca contenuti premium.