Con oltre 1 milione di installazioni attive, W3 Total Cache (W3TC) è uno dei plugin di cache e ottimizzazione più popolari nel repository di WordPress. A differenza di altri plugin di ottimizzazione di WordPress che offrono un’interfaccia relativamente più semplice e snella, W3 Total Cache dà il controllo completo sulla configurazione del caching del vostro sito WordPress.
La granularità delle impostazioni di W3TC lo rende un plugin ideale per utenti e sviluppatori avanzati che vogliono il massimo controllo sui loro siti WordPress. In questo articolo, daremo un’occhiata approfondita alle impostazioni di W3 Total Cache, e vi daremo la nostra configurazione consigliata per aumentare le prestazioni del vostro sito WordPress.
Se siete utenti Kinsta, non avrete bisogno di configurare alcune impostazioni in W3 Total Cache perché il nostro stack di hosting ha già molte ottimizzazioni integrate.
Ad esempio, come parte della nostra integrazione con Cloudflare, Edge Caching salva la cache del vostro sito/pagina Kinsta in uno qualsiasi dei centri dati della rete globale di 260+ di Cloudflare.
Edge Caching è incluso gratuitamente in tutti i piani Kinsta, non richiede un plugin separato e riduce il tempo necessario per servire l’HTML di WordPress nella cache di una media di oltre il 50%!
Come installare W3 Total Cache
Se non avete W3 Total Cache installato sul vostro sito, potete installarlo direttamente nel backend di WordPress. Basta cercare “W3 Total Cache” nella pagina “Aggiungi plugin” e installarla.
C’è anche una versione Pro di W3 Total Cache, che può essere acquistata sul sito web di BoldGrid. La versione Pro è dotata di alcune funzionalità aggiuntive come REST API caching, Google Maps caching, ed estensioni aggiuntive. In questo articolo, useremo la versione gratuita che si trova nel repository dei plugin di WordPress.
Dove Sono Memorizzate le Impostazioni di W3 Total Cache?
Dopo aver installato W3 Total Cache, vedrete una scheda “Performance” nella barra laterale della vostra bacheca di amministrazione di WordPress. Facendo clic sulla scheda “Performance”, si aprirà una serie di sottomenu come “General Settings”, “Page Cache”, “Minify” e altro ancora.
È inoltre possibile accedere alle impostazioni di W3 Total Cache tramite la scheda “Performance” nella barra degli strumenti di amministrazione di WordPress.
Come Eliminare la Cache con W3 Total Cache
Prima di entrare nel dettaglio della configurazione di W3 Total Cache, esaminiamo rapidamente come eliminare o cancellare la cache. Se passate il mouse sulla scheda “Performance” nella barra degli strumenti di amministrazione, vedrete due opzioni di pulizia.
- Purge All Caches: elimina tutte le cache in una sola volta.
- Purge Modules: eliminare una singola cache (ad es. risorse minificate, cache di pagina, object caching, ecc.)
Impostazioni Generali di W3 Total Cache
Immergiamoci nel menu “General Settings” di W3 Total Cache per configurare alcune delle sue impostazioni di base.
Cache di Pagina
Per impostazione predefinita, ogni singola richiesta al vostro sito WordPress è resa in tempo reale. Per alcuni tipi di siti come i negozi di ecommerce o i forum di discussione, il rendering dinamico è l’ideale. Tuttavia, per blog, siti di notizie e altri siti che non richiedono contenuti dinamici, l’aggiunta di un livello di caching di pagina può migliorare le prestazioni e ridurre il carico del server.
Se il vostro sito è ospitato su Kinsta, non dovete preoccuparvi del caching di pagina. Abbiamo una configurazione ad alte prestazioni a livello di server che salva mette automaticamente in cache le pagine del vostro sito in file HTML statici. Se il vostro host non offre il caching di pagina, potete abilitalo nel plugin W3 Total Cache.
Minify
Minificando le vostre risorse HTML, CSS e JavaScript potete ridurre le dimensioni complessive delle pagine del vostro sito rimuovendo gli spazi bianchi non necessari. Per la maggior parte dei siti WordPress, abilitare la funzione “Minify” di W3 Total Cache e selezionare l’opzione “Auto” per “Minify Mode” andrà benissimo.
In alcuni casi, la minificazione degli asset può causare la rottura del codice CSS o JavaScript, che spesso si traduce in errori visibili sul frontend. Se notate problemi insoliti sul vostro sito dopo aver minificato gli asset, vi consigliamo di lavorare con uno sviluppatore per identificare gli asset che causano problemi. Dopodiché, potete usare la funzione “Minify” in modalità manuale, che consente di bypassare la minificazione per specifici file CSS e JavaScript.
Cache Opcode
WordPress è un CMS dinamico, il che significa che i PHP worker stanno costantemente eseguendo il codice in background. La cache Opcode aiuta a velocizzare il sito memorizzando il codice PHP compilato, il che rende più veloci le richieste successive che richiedono lo stesso codice.
Se il vostro sito è ospitato su Kinsta, non dovete preoccuparti di abilitare un livello di caching opcode in W3 Total Cache. Abilitiamo OPcache, una cache opcode, su tutti gli ambienti live. OPcache è disabilitata sugli ambienti di staging per garantire che il codice PHP compilato non venga messo in cache e non interferisca con lo sviluppo del sito e il debug.
Se il vostro host non offre una cache opcode, vi consigliamo di abilitarla in W3 Total Cache. Tenete presente che la funzione di cache opcode è disponibile solo nella versione Pro di W3TC.
Cache del Database
Il database di W3TC memorizza i risultati delle query del database MySQL. Anche se questa funzione sembra utile, vi consigliamo di tenerla disabilitata e di usare invece una object caching.
Abbiamo scoperto che in alcuni casi la funzione di cache del database può comportare un elevato utilizzo della CPU. Ciò significa che la quantità di CPU salvata memorizzando i risultati delle query del database potrebbe finire per essere compensata dall’aumento di CPU richiesto per questa funzione.
Object Cache
Nel contesto di WordPress, una object cache memorizza i risultati delle interrogazioni del database completate. WordPress ha in realtà una object cache incorporata, ma conserva i dati solo per il caricamento di una singola pagina. Ciò consente un rendering delle pagine più efficiente, perché garantisce che il caricamento delle pagine non sprechi le risorse della CPU per eseguire interrogazioni di database identiche.
Mentre la object cache predefinita di WordPress è indubbiamente vantaggiosa per le prestazioni, una object cache che conserva i dati nel corso di diversi caricamenti di pagina è ancora meglio! La funzione “Object Cache” di W3TC aggiunge uno script di caching personalizzato nella vostra directory /wp-content, e cambia il comportamento della object cache di WordPress per mantenere i dati in modo persistente (attraverso multipli caricamenti di pagina).
Vi consigliamo di abilitare la funzione di object cache di W3TC sul vostro sito WordPress per velocizzare le richieste che utilizzano le query del database solo se il vostro sito non è ospitato su Kinsta.
Se il vostro sito è ospitato su Kinsta, offriamo un livello di object caching ad alte prestazioni alimentato dal nostro add-on Redis. Redis è un archivio open-source di struttura dati in-memory che viene spesso usato per applicazioni di database e di message broker.
Poiché Redis mette in cache i dati in RAM, permette a WordPress di accedere ai dati in cache da una object cache persistente che è molto più veloce rispetto alle tradizionali configurazioni di object cache.
Cache del Browser
Il caching del browser può velocizzare notevolmente il vostro sito WordPress memorizzando localmente risorse statiche come CSS, JavaScript, immagini e font. Il caching del browser utilizza un periodo di scadenza per determinare per quanto tempo mettere in cache le risorse. Sul web moderno, la maggior parte degli sviluppatori specifica un periodo di scadenza di 1 anno per le risorse statiche.
Per i siti ospitati su Kinsta, applichiamo un periodo di cache di 1 anno per i file statici. Questo può essere verificato controllando l’header cache-control per un file statico ospitato su Kinsta. Se il vostro web host non applica un “tempo di scadenza lontano” per la cache del browser, potete attivare la funzione “Browser Cache” in W3 Total Cache e configurare il periodo di scadenza.
CDN (Content Delivery Network)
Se usate una CDN, o una rete di distribuzione di contenuti per scaricare file statici nei data center di tutto il mondo, potete configurare W3 Total Cache affinché riscriva gli URL per “i file del tema, gli allegati della libreria multimediale, CSS, JS” e altro ancora con il proprio hostname CDN.
Se il vostro sito è ospitato su Kinsta, vi consigliamo di usare Kinsta CDN, la nostra rete di distribuzione di contenuti ad alte prestazioni alimentata da Cloudflare. Quando Kinsta CDN è abilitato, gli URL dei file statici saranno automaticamente riscritti per essere serviti da Kinsta CDN.
Ottenete anche l’accesso ad altre caratteristiche integrate, tra cui la funzione di minificazione del codice che permette ai clienti di Kinsta di abilitare la minificazione automatica di CSS e JavaScript direttamente nel cruscotto MyKinsta con il clic di un pulsante.
Se preferite usare un altro fornitore di CDN o se il vostro sito non è ospitato su Kinsta, potete attivare la funzione “CDN” in W3 Total Cache e aggiungere il vostro URL del CDN.
Reverse Proxy
Un reverse proxy si trova tra il vostro server web e WordPress e può essere utilizzato per eseguire varie manipolazioni logiche sulle richieste in arrivo. W3TC supporta Varnish, che è un popolare “acceleratore HTTP” per il caching e il servizio di dati con l’obiettivo di ridurre il carico di backend.
Per poter usare Varnish, il pacchetto Varnish deve essere prima installato dal vostro host. Se siete clienti Kinsta, non attivate l’opzione reverse proxy, in quanto la nostra infrastruttura non è progettata per funzionare con Varnish.
Esperienza Utente
L’ottimizzazione dell’esperienza utente di W3TC consente di abilitare il lazy-loading, disabilitare gli emojis e lo script wp-embed.js. Vi consigliamo di abilitare il lazy-loading sul vostro sito WordPress per velocizzare il caricamento delle pagine. Se non state ancora usando il lazy-loading tramite il browser o altro plugin, vi consigliamo di farlo tramite W3 Total Cache.
Nel mondo di oggi, la maggior parte dei sistemi operativi ha il supporto integrato per gli emojis. Pertanto, vi consigliamo di disabilitare lo script emoji incluso in WordPress se non usate spesso gli emoji. W3TC vi permette di rimuovere wp-emoji-release.min.js e vi aiuterà a eliminare una richiesta HTTP e a rimuovere ~10KB dal caricamento di pagina.
Allo stesso modo, se non siete soliti incorporate i post di WordPress, potete disattivare lo script wp-embed.js con W3 Total Cache. La disabilitazione di questo script non influirà sulle funzionalità di oEmbed per l’incorporazione di video YouTube, stream SoundCloud, ecc.
Varie
W3 Total Cache include poi alcune impostazioni varie da configurare. Se desiderate visualizzare nel backend WordPress un widget della bacheca di Google Page Speed, potete inserire la chiave API Page Speed. C’è anche un’opzione per visualizzare la valutazione della velocità della pagina nella barra dei menu per ogni pagina del vostro sito WordPress.
Per le altre impostazioni come “NGINX server configuration file path”, “enable file locking”, “optimize disk enhanced page and minify disk caching for NFS”, vi consigliamo di lasciarle nelle impostazioni di default a meno che non abbiate un motivo specifico per modificarle.
Debug
Se state risolvendo un problema sul vostro sito, W3 Total Cache ha un pratico menu “Debug” che permette di disabilitare specifici livelli di caching e impostazioni di ottimizzazione. Ad esempio, se notate un problema visivo sul vostro sito, potete attivare la modalità di debug per l’opzione “Minify”, che inserirà commenti HTML nel codice sorgente della vostra pagina per aiutarvi nella risoluzione dei problemi.
Dal momento che la funzione di debug aggiunge un carico aggiuntivo sulle risorse del server, vi consigliamo di usarla solo in un ambiente di staging o durante le ore di basso traffico. Inoltre, assicuratevi di disattivare la modalità di debug una volta terminata la risoluzione dei problemi!
Impostazioni di Importazione/Esportazione
Dopo aver terminato la configurazione delle impostazioni, è possibile usare la funzione “Import/Export” di W3TC per creare un backup della configurazione. W3 Total Cache ha un sacco di impostazioni, quindi essere in grado di esportare un backup completo vi farà stare tranquilli. Inoltre, consente di replicare facilmente la configurazione personalizzata di W3TC su più siti senza dover configurare manualmente nulla.
Impostazioni W3 Total Cache – Cache di pagina
Immergiamoci nelle impostazioni della sezione “Page Cache” di W3 Total Cache. Ricordate che se il vostro sito è ospitato su Kinsta, non dovete preoccuparvi del page caching – quindi sentitevi liberi di saltare questa sezione.
- Cache Front Page – Per la maggior parte dei siti, la prima pagina è tipicamente la pagina che riceve il maggior traffico. Pertanto, vi consigliamo di abilitare questa impostazione per mettere in cache la front page del vostro sito.
- Cache Feeds – WordPress genera vari feed RSS, che permettono ad applicazioni e servizi esterni come Feedburner di visualizzare i contenuti del vostro sito. Anche se oggi gli RSS non sono più così popolari come una volta, consigliamo comunque di abilitare questa impostazione.
- Cache SSL (HTTPS Requests) – Se il vostro server web non forza l’HTTPS per tutte le richieste in arrivo, l’attivazione di questa impostazione può avere un impatto positivo sulle prestazioni. Se state già forzando HTTPS a livello di server web, non è necessario abilitare questa impostazione.
- Cache URIs with Query String Variables – Questa opzione permette di mettere in cache gli URI che contengono query string. La query string è un parametro che viene aggiunto alla fine dell’URL (ad esempio /?version=123) ed è spesso usata per richiedere e visualizzare dati specifici dal vostro database WordPress. In generale, lo scopo di una query string è quello di richiedere una versione univoca di una pagina, quindi si consiglia di tener disabilitata l’opzione, a meno che non disponiate di specifiche query string che desiderate mettere in cache.
- Cache 404 (Not Found) Pages – Per impostazione predefinita, W3TC mantiene disabilitata l’opzione per mettere in cache le pagine 404. La ragione di ciò è probabilmente dovuta al comportamento della cache se state usando il metodo di cache delle pagine “Disk Enhanced”. Con questa opzione selezionata, le pagine 404 restituiscono un codice di risposta 200. Idealmente, le pagine 404 dovrebbero restituire dei codici di risposta 404, quindi vi consigliamo di testare questa impostazione con la configurazione del caching per vedere se è compatibile.
- Don’t Cache Pages for Logged In Users – Vi consigliamo di abilitare questa opzione per evitare di mettere in cache le pagine per gli utenti registrati al sito. Di solito gli utenti registrati lavorano nell’aggiornamento delle pagine. Con la cache abilitata, gli utenti dovrebbero cancellare la cache costantemente per vedere gli aggiornamenti delle pagine.
- Don’t Cache Pages for Certain User Roles – Questa opzione permette di bypassare la cache per alcuni ruoli di WordPress. Se l’opzione “Don’t Cache Pages for Logged In Users” è già abilitata, questa opzione non avrà alcun effetto sul comportamento della cache.
Alias
La funzione “Alias” di W3 Total Cache permette di mettere in cache contenuti identici di WordPress disponibili su diversi domini. Vi sconsigliamo di abilitare questa funzione. Se il vostro sito WordPress è accessibile su diversi domini (ad esempio domain.com e www.domain.com), è meglio impostare una regola di reindirizzamento 301 per inoltrare le richieste al vostro dominio primario ed evitare la duplicazione delle richieste di Google e di altri motori di ricerca.
Precaricamento della Cache
La funzione “Cache Preload” scansiona la vostra sitemap e fa richieste alle pagine del vostro sito per precaricare la cache delle pagine. Per la maggior parte dei siti, consigliamo di disabilitare il precaricamento della cache perché può causare picchi di risorse del server che compensano i potenziali benefici in termini di prestazioni.
Se desiderate abilitare il precaricamento della cache, W3TC consente di specificare un URL della sitemap, un intervallo di aggiornamento e le pagine per intervallo. Assicuratevi di non impostare “update interval” e “pages per internal” con valori troppo alti per ridurre la possibilità di picchi di CPU.
Purge Policy
La “Purge Policy” di W3TC consente di specificare le pagine e i feed che desiderate eliminare automaticamente dopo la pubblicazione o la modifica dei post. Per la maggior parte dei siti, le impostazioni predefinite (prima pagina, pagina dei post e feed del blog) dovrebbero essere sufficienti. Se desiderate aggiungere altre pagine alla politica di eliminazione della cache, è possibile configurare diverse opzioni.
REST API
La REST API inclusa in WordPress permette di cercare dati in formato JSON. REST API è utilizzata da una varietà di plugin, ed è fondamentale per le impostazioni headless di WordPress. A seconda del vostro caso d’uso esatto per la REST API, la cache dei risultati della query può essere una buona idea. Il caching REST API rientra nella categoria “se ne hai bisogno, lo verrai a sapere”, quindi se non siete sicuri se abilitare o meno il caching REST API, vi consigliamo di lasciarlo su “Don’t Cache”.
Avanzato
Nelle opzioni di cache delle pagine “Advanced” di W3TC, potete personalizzare una varietà di impostazioni, tra cui “accepted query strings”, “rejected user agents”, impostazioni di bypass della cache granulare e altro ancora. Per esempio, se avete bisogno di configurare il vostro W3 Total Cache per non mettere mai in cache i post sotto una certa categoria o tag, potrete farlo nelle opzioni “Advanced”.
Poiché queste impostazioni possono essere molto specifiche del sito, non ci sono “impostazioni consigliate” che possiamo fornire. Detto questo, se state cercando di personalizzare un aspetto molto specifico del comportamento di caching delle pagine del vostro sito, date senz’altro un’occhiata alle opzioni avanzate.
Impostazioni W3 Total Cache – Minify
Passiamo ora alle impostazioni “Minify” di W3 Total Cache.
- Rewrite URL Structure – Questa impostazione influisce sulla struttura URL dei beni minificati. Vi consigliamo di mantenerla abilitata in modo che i vostri URL risultino leggibili e ben formattati.
- Disable Minify for Logged In Users – Se vi state occupando della risoluzione di un problema o di un debug, disattivare la minificazione per gli utenti registrati può essere utile. Altrimenti, vi consiglia di mantenere questa opzione disabilitata.
HTML & XML
Nella sezione “HTML & XML” potete configurare le impostazioni di minificazione HTML.
- Inline CSS minification – Vi consigliamo di abilitare questa opzione per rimuovere gli spazi bianchi nei CSS in linea.
- Inline JS minification – Vi consigliamo di abilitare questa opzione per rimuovere gli spazi bianchi nei JavaScript in linea. In alcuni casi, la minificazione JS può causare un errore di codice. Se l’abilitazione di questa opzione interrompe la funzionalità del sito, disattivatela.
- Don’t minify feeds – Vi consigliamo di mantenere questa opzione disabilitata. I feed sono usati solo da lettori RSS e altri servizi simili, quindi non è necessario minificarli.
- Line break removal – Questa opzione è disabilitata per impostazione predefinita: per garantire il corretto rendering del sito vi consigliamo di lasciarla disabilitata.
JS
Nella sezione “JS” è possibile configurare le impostazioni di minificazione JavaScript.
- Operations in Areas – Questa opzione consente di selezionare il “tipo embed” per il JavaScript minificato. Per i file JS prima
</head>e dopo<body>, si può scegliere tra “blocking”, “non-blocking”, “non-blocking using async”, e “non-blocking using defer”. Anche se i metodi di caricamento non-blocking di solito portano a prestazioni migliori, non sono sempre compatibili al 100% con tutto il codice JavaScript. Inoltre, “async” e “defer” hanno casi d’uso molto diversi. Pertanto, vi consigliamo di usare il metodo di “blocco” predefinito, a meno che non siate consapevoli delle stranezze del codice JavaScript non bloccante. - Minify o Combine Only – È possibile scegliere tra due modalità di ottimizzazione per JavaScript. Selezionando “Minify”, i vostri file JS saranno combinati e minificati. Se selezionate “Combine Only”, il file JS combinato risultante non verrà minificato. Se si verificano problemi di minificazione e non si desidera eseguire il debug per scoprire quale script sta causando il problema, selezionando l’opzione “Combine Only” potete correggere l’errore.
- HTTP/2 Push – Se il vostro server supporta HTTP/2 Server Push, l’attivazione di questa opzione può aiutare a ridurre il tempo di caricamento delle pagine. HTTP/2 Server Push spinge i file ai visitatori prima che vengano richiesti. Si consiglia di fare dei test adeguati prima di abilitare questa opzione in un ambiente di produzione perché Server Push è spesso utilizzato in modo improprio. Server Push non è l’ideale per i file JavaScript di grandi dimensioni, e vi conviene essere sicuri che i vantaggi siano superiori al caricamento dei file JS direttamente dalla cache del browser di un visitatore.
CSS
Nella sezione “CSS” è possibile configurare le impostazioni di minificazione CSS.
- Combine Only – A differenza dei file JavaScript, i CSS in genere non soffrono di problemi legati alla minificazione. Pertanto, non consigliamo di abilitare “Combine Only”.
- Preserved Comment Removal – Questa impostazione rimuove i commenti dai file CSS. Si consiglia di abilitare questa opzione per ridurre il più possibile le dimensioni dei file.
- Line Break Removal – Questa impostazione rimuove le interruzioni di linea dai file CSS. Si consiglia di abilitare anche questa opzione. Se notate problemi di visualizzazione dopo aver abilitato la “Line Break Removal”, disabilitatela.
Advanced
La sezione “Advanced” contiene alcune impostazioni aggiuntive per personalizzare il comportamento di minificazione.
- Update External Files Every – W3TC consente di specificare l’intervallo di tempo tra gli aggiornamenti dei file CSS e JS. Con l’impostazione predefinita di 86400 secondi, le vostre risorse saranno scaricate e minificate ogni 24 ore. Se il vostro sito non cambia frequentemente, sentitevi liberi di impostare un periodo di tempo più lungo.
- Garbage Collection Interval – Questa impostazione specifica la frequenza di cancellazione dei dati della cache scaduti. L’impostazione predefinita è di 24 ore. Se il vostro sito ha poco spazio in memoria, vi consigliamo di abbassare il “Garbage Collection Interval”.
Il resto della sezione “Advanced” include campi di input che permettono di specificare i file di asset che non devono mai essere minificati. C’è anche un campo “Rejected User Agent” che permette di servire file non minificati a certi user agent. Infine, potete aggiungere file di asset esterni da includere nel processo di minificazione di W3 Total Cache.
Impostazioni W3 Total Cache – Object Cache
La prossima lista è costituita dalle impostazioni della “Object Cache” di W3TC. Per la maggior parte dei siti, le impostazioni predefinite funzioneranno bene, ma esaminiamole comunque.
- Default Lifetime of Cache Objects – Indica il tempo di scadenza per gli elementi di cache invariati. Un periodo di tempo più lungo determina una object cache più grande. Se siete preoccupati per la capacità di memorizzazione del vostro server, vi consigliamo di mantenere il valore di default o di abbassarlo.
- Garbage Collection Interval – Questa impostazione specifica la frequenza con cui i dati della cache scaduti vengono cestinati. Il valore predefinito di 3.600 secondi (1 ora) dovrebbe andare bene per la maggior parte dei siti.
- Global Groups – Questa impostazione consente di configurare gruppi di caching condivisi tra siti in un’unica rete multisito. Vi consigliamo di lasciare questa impostazione nel suo stato predefinito, a meno che non abbiate un motivo specifico per modificarla.
- Non-Persistent Groups – Questa impostazione consente di selezionare quali gruppi di oggetti non devono mai essere messi in cache. Anche in questo caso, vi consigliamo di attenervi alla configurazione predefinita.
- Enable Caching for wp-admin Requests – Questa opzione è disabilitata di default, e non consigliamo di abilitarla perché può causare effetti collaterali. Inoltre, i visitatori della maggior parte dei siti WordPress non interagiscono mai con la dashboard di wp-admin.
Impostazioni W3 Total Cache – Cache del Browser
La maggior parte degli host di WordPress, incluso Kinsta, implementa già gli header di cache del browser a livello di server web. Se il vostro host non lo fa, o se volete personalizzare ulteriormente il comportamento del browser caching, potete farlo con W3 Total Cache.
Nelle impostazioni “Browser Cache”, le opzioni predefinite per le sezioni “General”, “CSS & JS”, e “HTML & XML” e “Media & Other Files” sono sufficienti per la maggior parte dei siti WordPress. Dato che ci sono così tante impostazioni su questa pagina, vi consigliamo di consultare uno sviluppatore prima di apportare qualsiasi modifica al comportamento della cache del browser. Detto questo, qui di seguito sono riportate alcune impostazioni chiave per prestare attenzione al caching del browser.
- Expires Headers Lifetime – La configurazione di una lunga scadenza per gli header è importante per un’efficiente cache del browser. In Kinsta, applichiamo una durata di 1 anno per gli asset statici come CSS, JS, immagini e font. Se usate W3TC per configurare la cache del browser, assicuratevi di impostare questo valore a
31536000(1 anno). - Cache Control Policy – Per assicurarvi che le vostre risorse statiche siano memorizzabili nella cache dai browser, assicuratevi che la “Cache Control Policy” sia impostata su “public, max_age=EXPIRES SECONDS”.
- Enable HTTP (GZIP) Compression – La compressione GZIP riduce drasticamente la dimensione dei file delle pagine HTML e degli asset prima che vengano inviati ai visitatori, quindi assicuratevi di abilitare questa opzione se la configurazione del server del vostro host supporta GZIP. Se il vostro sito è ospitato su Kinsta, non è necessario abilitare la compressione GZIP in W3TC perché è già abilitata come parte della nostra configurazione predefinita.
- Remove query strings from static resources – Una stringa di query è una stringa aggiuntiva che viene aggiunta alla fine di un percorso URL per specificare i parametri della richiesta o forzare un server web a fornire una nuova risorsa. Le stringhe di query iniziano con un
?, e la maggior parte dei server web sono configurati per bypassare la cache per le richieste con stringhe di query. Rimuovere le stringhe di query dalle richieste di pagine è utile per ridurre il carico del server, perché queste richieste usano PHP per rendere le pagine. Non raccomandiamo di rimuovere le query string dalle risorse statiche in W3 Total Cache perché aiutano a garantire che l’ultima versione dei file CSS e JS sia consegnata ai vostri visitatori.
La pagina delle impostazioni “Browser Cache” contiene anche una serie di impostazioni relative alle intestazioni di sicurezza come Content Security Policy (CSP) e X-XSS Protection. Consigliamo sempre di lavorare con uno sviluppatore qualificato per passare attraverso queste impostazioni perché configurazioni non corrette possono avere un impatto diretto sull’esperienza utente del vostro sito. Ad esempio, abilitare l’intestazione HSTS senza un certificato SSL adeguato e la configurazione HTTPS può rendere il vostro sito inaccessibile.
Impostazioni W3 Total Cache – User Agent Groups
La funzione “User Agent Groups” di W3 Total Cache è molto potente se avete bisogno di reindirizzare il traffico in base al tipo di dispositivo di un utente. Ad esempio, è possibile configurare il sito in modo da renderizzarlo su un tema diverso se un utente visita il sito dal telefono cellulare. Allo stesso modo, potete reindirizzare gli utenti a un sito completamente diverso se il vostro sito mobile vive su un sottodominio unico.
Nell’era del responsive web design, non vediamo troppi casi d’uso per questa particolare caratteristica. Al giorno d’oggi, la migliore pratica è quella di rendere il vostro sito responsive fin dall’inizio, invece di affidarsi a più temi o a un sottodominio solo mobile.
Impostazioni W3 Total Cache – Referrer Groups
Un referrer HTTP è un’intestazione HTTP opzionale che fornisce informazioni sulla provenienza della richiesta. Ad esempio, se un visitatore fa clic sul vostro sito da un elenco di Google Search, il referrer HTTP è google.com.
In W3 Total Cache, è possibile definire un comportamento di caching personalizzato basato sul referrer HTTP di una richiesta con “Referrer Groups”. Per esempio, potreste creare un gruppo di referrer che consiste di motori di ricerca, e personalizzare il comportamento di caching solo per le richieste provenienti da quei domini.
Analogamente agli “User Agent Groups” di cui sopra, è anche possibile reindirizzare le richieste a un dominio diverso con la funzione “Referrer Groups”. La maggior parte dei siti WordPress non avrà bisogno di impostare gruppi referrer, quindi non consigliamo di configurarne nessuno.
Impostazioni W3 Total Cache – Cookie Groups
L’ultimo gruppo di caching che W3 Total Cache supporta è “Cookie Groups”. Questa funzione consente di creare piccoli gruppi di caching e comportamenti unici basati sui cookie di una richiesta. In modo simile agli “User Agent Groups” e ai “Referrer Groups”, la maggior parte dei siti non avrà bisogno di impostare una configurazione di caching personalizzata basata sui cookie. Se il vostro sito richiede un caching basato sui cookie, vi consigliamo di lavorare con uno sviluppatore per configurarlo correttamente.
Impostazioni W3 Total Cache – CDN
Passiamo ora alle impostazioni della CDN di W3 Total Cache.
- Host Attachments – Attivate questo servizio per servire le risorse della vostra libreria media WordPress dalla vostra CDN.
- Host wp-includes/ Files – Abilitate questa opzione per servire i file nella cartella
wp-includesdalla vostra CDN. - Host Theme Files – Abilitate questa opzione per servire i vostri file del tema dalla vostra CDN.
- Host File CSS e JS minificati – Permettete a questa opzione di servire i file CSS e JS minificati di W3TC dal vostro CDN.
- Host Custom Files – Se avete file che non sono nella vostra libreria media o nella cartella dei temi, potete aggiungere i percorsi dei file in W3TC per servirli dalla vostra CDN.
- Add Canonical Header – Un tag
rel="canonical"aiuta i motori di ricerca a identificare la fonte o l’URL originale. Poiché le CDN usano tipicamente un dominio diverso, l’aggiunta di un tag canonical notifica ai motori di ricerca la posizione dell’asset originale. Detto questo, va bene mantenere questa impostazione disabilitata perché i motori di ricerca moderni sono abbastanza intelligenti da identificare le CDN senza influenzare il posizionamento SEO del sito.
Advanced
- Only Purge CDN Manually – Vi consigliamo di mantenere questa opzione disabilitata per permettere a W3TC di gestire automaticamente l’eliminazione della cache.
- Disable CDN on SSL Pages – Mantenete questa impostazione disabilitata. Se usate una CDN, è meglio averla attivo sia sulle pagine HTTP che HTTPS.
- Use CDN Links for Media Library on Admin Pages – Non consigliamo di abilitare questa opzione perché riscriverebbe gli URL nella vostra libreria media.
- Add CORS Header – Mantenete questa impostazione attivata per consentire la visualizzazione delle vostre risorse CDN su altri domini.
- Disable CDN for the Following Roles – Questa opzione consente di disabilitare la CDN per determinati ruoli utente di WordPress. Nella maggior parte dei casi, è meglio mantenere questa opzione disabilitata.
- wp-includes File Types to Upload – Questo campo specifica i formati di file nella cartella
wp-includesche saranno serviti dalla vostra CDN. L’elenco predefinito dei formati di file dovrebbe andare bene per la maggior parte dei siti. Se avete file personalizzati nella vostra cartellawp-includes, sentitevi liberi di aggiungere altri formati necessari. - Theme File Types to Upload – Questo campo specifica i formati di file nella cartella del tema di WordPress che saranno serviti dalla vostra CDN. L’elenco predefinito contiene tutti i formati di asset, immagini e font più diffusi. Sentitevi liberi di aggiungere altri formati se necessario.
- Custom File List – Se avete abilitato “Host Custom Files”, in questo campo potete aggiungere una lista di file da servire dalla vostra CDN.
- Rejected User Agents – Questo campo permette di specificare gli user agent che non saranno serviti dalla vostra CDN. Vi consigliamo di mantenere questo campo vuoto per garantire che la vostra CDN venga usata correttamente.
- Rejected Files – Questo campo permette di specificare i file che non devono essere serviti dalla vostra CDN. Se un servizio che state usando richiede che le risorse siano servite dal vostro dominio principale, potete aggiungere il percorso del file nel campo “Rejected Files”.
Impostazioni W3 Total Cache – User Experience
Ora personalizziamo le impostazioni di “User Experience”, o lazy loading, in W3 Total Cache.
- Process HTML Image Tags – Abilitate questa opzione per garantire che alle immagini sia applicato il lazy loading.
- Process Background Images – Se usate `background` per visualizzare un’immagine in CSS, abilitando questa opzione potete caricare le immagini con il lazy loading.
- Exclude Words – In questo campo potete specificare il testo per bypassare il lazy loading. Per esempio, se aggiungete
no-lazy-loada questo campo, a un’immagine visualizzata con non verrà applicato il lazy loading. - Script Embed Method – Questa impostazione consente di personalizzare il metodo di caricamento per lo script di lazy loading. Il metodo di default
asyncè l’opzione migliore per la maggior parte dei siti. Se il vostro sito consiste di una sola pagina di destinazione, il metodoinlinepuò essere usato per ridurre il numero di richieste HTTP per caricare la pagina.
Estensioni Disponibili per W3 Total Cache
W3 Total Cache offre varie estensioni da integrare con servizi di terze parti che al momento includono:
- AMP
- Cloudflare
- Google Feedburner
- Fragment Cache
- Genesis Framework
- New Relic
- Swarmify
- Yoast SEO
- WPML
Se usate uno di questi servizi sul vostro sito, vi consigliamo di impostare la relativa estensione per garantire la corretta compatibilità con W3 Total Cache. In questa sezione, daremo un’occhiata all’estensione Cloudflare per W3 Total Cache.
Come Configurare W3 Total Cache con l’Estensione Cloudflare
Per integrare Cloudflare in W3 Total Cache, avrete bisogno di due informazioni dalla vostra bacheca Cloudflare: email dell’account e chiave API. L’email dell’account è l’indirizzo email che usate per accedere a Cloudflare. Diamo un’occhiata a come impostare una chiave API in Cloudflare.
Nella bacheca di Cloudflare, fate clic sulla scheda “Overview”. Successivamente, scorrete verso il basso e fate clic su Get Your API Token nella barra laterale destra.
Scorrete verso il basso e fate clic su View accanto a “Global API Key” per ottenere la chiave API di Cloudflare. Fate attenzione a non condividere questa chiave API key al di fuori di W3 Total Cache perché può essere utilizzata per controllare il vostro account Cloudflare.
Successivamente, attivate l’estensione Cloudflare nella pagina “Extensions” di W3 Total Cache e fate clic su “Settings”. Nella sezione “Credentials”, fate clic sul pulsante Authorize.
Nel popup successivo, inserite l’email del vostro account Cloudflare e la chiave API. Se ricevete un messaggio di errore, verificate che l’indirizzo email e la chiave API siano corretti. Dopo che le credenziali sono state autorizzate, dovreste vedere le impostazioni aggiuntive di Cloudflare sulla pagina.
Ripassiamo le impostazioni di Cloudflare in W3 Total Cache.
- Widget Statistics Interval – Questa opzione specifica il periodo di tempo coperto dal widget Cloudflare di W3TC. L’impostazione predefinita è 30 minuti. Se desiderate vedere un periodo di tempo più lungo, sentitevi liberi di aumentarlo.
- Cache Time – Specifica la quantità di tempo in cui i dati dei widget di Cloudflare vengono memorizzati nella cache. Se non prevedete di usare molto il widget, vi consigliamo di aumentare questo numero per ridurre il numero di richieste a Cloudflare dal vostro sito.
- Page Caching – Se avete configurato Cloudflare per mettere in cache le pagine HTML del vostro sito WordPress, abilitate questa opzione per cancellare automaticamente la cache di Cloudflare dopo aver postato modifiche e aggiornamenti..
Cloudflare Caching
Questa sezione consente di personalizzare le impostazioni di cache di Cloudflare.
- Development Mode – Mantenete questa opzione disabilitata a meno che non sia necessario mettere Cloudflare in modalità di sviluppo. Quando Cloudflare è in modalità di sviluppo, l’edge caching, la minificazione e l’ottimizzazione delle immagini sono disabilitati per tre ore. Questo permette di vedere immediatamente gli aggiornamenti dei file CSS e JS ed è utile per la risoluzione dei problemi.
- Cache Level – Per la maggior parte dei siti, consigliamo di usare il livello di cache “Standard”, che serve una risorsa diversa ogni volta che la query string cambia. Se siete sicuri al 100% che il vostro sito WordPress non fa uso di query string per servire contenuti dinamici, potete anche usare l’impostazione “Ignore Query String”.
- Browser Cache TTL – Vi consigliamo di impostare la cache del browser di Cloudflare TTL a 31536000 secondi, pari a 1 anno.
- Challenge TTL – Cloudflare offre una varietà di servizi legati alla sicurezza, e mettere alla prova i visitatori è una di queste. Se Cloudflare rileva un utente malintenzionato o un comportamento strano, servirà un messaggio di prova sotto forma di Captcha. L’impostazione “Challenge TTL” specifica per quanto tempo un utente avrà accesso al vostro sito dopo aver completato la prova. Con l’impostazione predefinita di 3600 secondi, un visitatore che è stato oggetto di una prova potrà usare il vostro sito per 1 ora prima di un’altra prova.
- Edge Cache TTL – Questa impostazione controlla per quanto tempo gli asset saranno memorizzati nella cache degli edge server di Cloudflare. Vi consigliamo di impostarlo sul valore massimo di 31536000 secondi, o 1 anno.
Elaborazione dei Contenuti di Cloudflare
Immergiamoci ora nelle impostazioni di elaborazione dei contenuti di Cloudflare in W3 Total Cache.
- Rocket Loader – Il Rocket Loader di Cloudflare velocizza il caricamento di JavaScript per il vostro sito WordPress. Vi consigliamo di abilitare Rocket Loader se il vostro sito ha un sacco di JS.
- Minify JS/CSS/HTML – Se avete già abilitato la minificazione per HTML, CSS e JavaScript in W3 Total Cache, sentitevi liberi di mantenere disabilitate queste opzioni nelle impostazioni dell’estensione Cloudflare, in quanto non c’è bisogno di minificare gli asset che sono già stati minificati.
- Server Side Exclude (SSE) – Questa opzione consente di nascondere le informazioni sensibili ai visitatori sospetti (secondo la definizione di Cloudflare). Le esclusioni lato server sono utili per nascondere informazioni come indirizzo email, numeri di telefono e altre informazioni personali sul vostro sito. Per utilizzare SSE, abilitatelo e avvolgete le informazioni sensibili nei tag
<!--sse--><!--/sse-->nel vostro codice HTML o nel vostro template PHP. - Email Obfuscation – Quando questa opzione è attiva, Cloudflare offusca automaticamente gli indirizzi email sul vostro sito WordPress grazie al JavaScript. Anche se l’offuscamento non eliminerà completamente lo spam via email, vi consigliamo di attivare questa opzione perché scoraggia i bot di base dallo scraping degli indirizzi email dal vostro sito.
Elaborazione delle Immagini in Cloudflare
Esaminiamo le impostazioni di elaborazione delle immagini in Cloudflare.
- Hotlink Protection – Abilitate la protezione hotlink per impedire ad altri siti di incorporare le vostre immagini. Se vi trovate in presenza di limiti di larghezza di banda a causa di incorporamenti esterni non autorizzati, l’abilitazione della “Hotlink Protection” può aiutarvi a ridurre l’utilizzo della larghezza di banda.
- Mirage (Pro) – Mirage ottimizza la trasmissione delle immagini ai dispositivi e alle reti a bassa larghezza di banda. Questa funzione è disponibile solo sul piano Cloudflare Pro e superiori.
- Polish (Pro) – L’opzione Polish ottimizza le immagini del vostro sito e può essere configurata per servire le immagini WEBP ai browser supportati. Questa funzione è disponibile solo sul piano Cloudflare Pro e superiori.
Protezione Cloudflare
La caratteristica principale di Cloudflare è un sofisticato firewall che può aiutare a proteggervi dagli attacchi DDoS e dagli attori malintenzionati. Esaminiamo le impostazioni di sicurezza di Cloudflare.
- Security Level – Questa impostazione controlla la sensibilità del firewall e delle regole di sicurezza di Cloudflare. Vi consiglia di impostare il “Security Level ” su “Medium” per la maggior parte dei siti.
- Browser Integrity Check – Questa funzione cerca comportamenti scorretti e user agent sospetti. Se rileva un utente potenzialmente malintenzionato o uno spammer, Cloudflare si attiva automaticamente. Vi consigliamo di abilitare questa funzione.
- Always Online – Questa opzione servirà le pagine HTML statiche del vostro sito in caso di down. Vi consigliamo di abilitarla se avete configurato Cloudflare per mettere in cache l’HTML.
- Web Application Firewall – Il WAF di Cloudflare, o firewall delle applicazioni web, scansionerà il traffico in entrata e filtrerà il “traffico illegittimo” dal raggiungere il vostro sito. Vi consigliamo di abilitare questa funzione.
- Advanced DDoS Protection – Questa funzione è abilitata di default e non può essere disabilitata finché il proxy di Cloudflare è attivo. La protezione DDoS aiuta a proteggere il vostro sito da attacchi di “distributed denial of service”.
- Max Upload – Imposta la dimensione massima consentita dei file da caricare sul vostro sito. Volete essere sicuri che questa impostazione sia uguale o superiore alla dimensione massima consentita per il caricamento dei file in WordPress.
Cloudflare SSL
Infine, assicuratevi che le impostazioni SSL di Cloudflare siano configurate correttamente. Ripercorriamo la giusta configurazione in questa sezione.
- SSL – Se il vostro sito è ospitato su Kinsta, vi consigliamo di usare l’opzione SSL “Full” o “Full (Strict)”. L’opzione “Flexible” non è compatibile con la nostra infrastruttura. L’opzione “Full Strict” richiede un SSL da un’autorità di certificazione valida, mentre l’opzione “Full” supporta anche gli SSL autofirmati. L’opzione “Flexible” non richiede un certificato SSL sul server di origine, ma non consigliamo questa opzione perché è la più insicura.
- TLS 1.2 Only – TLS, o Transport Layer Security, è un protocollo sicuro per il trasferimento di dati su una rete. Alcuni standard di conformità PCI richiedono l’eliminazione del supporto per TLS 1.1 e successivi. Se questo è un requisito per il vostro sito, potete abilitare l’impostazione “TLS 1.2 Only” in Cloudflare per impostare la versione minima TLS su 1.2.
Lettura consigliata: Come Impostare Cloudflare APO per WordPress.
Impostazioni WooCommerce in W3 Total Cache
WooCommerce è la piattaforma di ecommerce più popolare per i siti WordPress. Se state usando W3 Total Cache nel vostro negozio alimentato da WooCommerce, vorrete assicurarvi che la vostra configurazione sia corretta per evitare di mettere in cache i dati dei clienti.
Bypassare i Cookie WooCommerce
Per bypassare il page caching per le pagine che includono cookie specifici di WooCommerce, andate alle impostazioni “Page Cache” di W3TC, scorrete verso il basso fino a “Rejected Cookies”, e aggiungete queste quattro voci.
- woocommerce_items_in_cart
- woocommerce_cart_hash
- wp_woocommerce_session_
- wordpress_logged_in
Per essere sicuri, raccomandiamo anche di bypassare gli URL specifici di WooCommerce come la pagina del carrello, la pagina del checkout e la pagina dell’account. Per bypassare queste pagine dalla cache, andate alle impostazioni “Page Cache” di W3TC e aggiungete gli URL nella sezione “Never Cache the Following Pages”.
Come Ripristinare Tutte le Impostazioni in W3 Total Cache
In alcuni casi, potrebbe essere necessario ricominciare da capo con la configurazione del W3TC. Ecco come riportare W3 Total Cache alle sue impostazioni predefinite. Andate al menu “General Settings” di W3TC, scorrete fino alla sezione “Import/Export Settings” e fate clic su Restore Default Settings (Ripristina impostazioni predefinite).
Riepilogo
Come potete vedere, il plugin W3 Total Cache è ricco di funzioni e impostazioni. Dal page caching, alla minificazione delle risorse, all’integrazione con Cloudflare, W3TC ha tutto ciò che serve per aumentare le prestazioni del vostro sito WordPress!
In questo articolo, abbiamo esaminato la configurazione consigliato per il plugin W3 Total Cache. Avete un plugin di ottimizzazione WordPress preferito? Fatecelo sapere nei commenti qui sotto!
Brian has been a WordPress user for over 10 years, and enjoys sharing his knowledge with the community. In his free time, Brian enjoys playing the piano and exploring Tokyo with his camera. Connect with Brian on his website at brianli.com.
Lascia un commento