Quando si tratta di prestazioni web, la cache di WordPress è una di quelle cose che ogni proprietario di un sito web ad un certo punto deve affrontare. Adoriamo WordPress, ma in definitiva non è la piattaforma più veloce, specialmente se la si confronta con un sito completamente statico. Un dei motivi è che è sviluppato in PHP, che semplicemente non può far le cose più veloce di così. Abbiamo assistito ad un massiccio miglioramento delle prestazioni con PHP 8.0 e PHP 8.1, ma se non si provvede a memorizzare correttamente le pagine del sito nella cache, si arriverà comunque ad un rallentamento.
Non sarebbe bello se non doveste preoccuparvi di capire quale possa essere il miglior plugin di caching? Bene, qui da Kinsta siamo noi ad occuparci del caching per voi, in modo che voi possiate concentrarvi sullo sviluppo del vostro business.
Che Cos’è la Cache di WordPress?
Il caching è il processo di archiviazione delle risorse a partire da una richiesta e di riutilizzo di quelle risorse per le richieste successive. Fondamentalmente, riduce la quantità di lavoro richiesta per generare una “page view”.
Perché dovreste utilizzare la cache? É semplice: il caching rende più veloci i siti WordPress e riduce il carico sul server. Questo è il motivo per cui ogni sito dovrebbe sforzarsi di utilizzare quanta più cache possibile. In aggiunta, nel caso del caching CDN, ciò riduce la quantità di ampiezza di banda del server necessaria a generare una page view memorizzando le risorse statiche esterne a quelle del proprio host WordPress.
Nessun Plugin di Cache per WordPress è Necessario da Kinsta
Giusto! Se il vostro host WordPress è Kinsta, non dovete preoccuparvi di perdere tempo con un complicato e sconcertante plugin di caching. Questo perché abbiamo diversi tipi di caching già in funzione. Potete finalmente smettere di cercare su Google il “miglior plugin di caching del 2024” e concentrarvi maggiormente su attività più produttive.
Da Kinsta, utilizziamo i seguenti quattro tipi di cache, che vengono tutti automaticamente eseguiti a livello di software o server:
Molti dei nostri clienti riportano enormi diminuzioni dei tempi di caricamento semplicemente migrando a Kinsta. Di seguito, ecco un esempio di un sito che ha visto un aumento delle prestazioni del 212,5%. E questo senza alcun plugin di caching installato.
Ci sono anche altre variabili coinvolte nella riduzione dei tempi di caricamento, ma il caching riveste un ruolo importantissimo. Non stiamo diciamo che nessun plugin di caching è buono. Infatti, molte volte l’inefficacia è dovuta al fatto che l’utente non configura il plugin di caching correttamente, cosa che si traduce nel rallentamento del proprio sito WordPress. Avete mai provato a configurare W3 Total Cache? Può diventare rapidamente molto intricato.
Non Dovete Crederci sulla Parola
E per quanto riguarda le prestazioni, non limitatevi a crederci sulla parola, ma leggete alcune testimonianze di persone che sono passate da Kinsta. Nessuno di questi utilizza più i plugin di caching.
An instant 37% reduction in the loading time after moving @WPColt to @kinsta! (NO CACHING PLUGINS) 🚀🚀🚀
— WPColt (@WPColt) January 3, 2018
Quite impressed what @googlecloud and @kinsta can pull of for #WordPress hosting! #DevOps #Cloud #WPDev #webdevelopment pic.twitter.com/Cr7UMaHdpH
— Neuralab (@Neuralab) July 22, 2017
@TheSportReview's new @Googlecloud based @kinsta environment handled the post-match @ManUtd v @ChelseaFC traffic spike in style 👌⚽ pic.twitter.com/kJewykSqaV
— Martin Caparrotta (@MartinCap) April 16, 2017
60%+ drop in @pingdom load times for @voompla after move to @kinsta + @CloudFlare CDN + site optimization! support by @tomzur @MarkGavalda
— Palash Bakshi (@ppbakshi) September 11, 2016
Tipi di Cache per WordPress
Analizziamo ora ogni tipo di cache di WordPress in cui vi imbatterete regolarmente qui da Kinsta. Capire cosa fa ogni livello di caching vi aiuterà a risolvere anomalie relative alla cache e garantirà che il vostro sito funzioni senza problemi.
Bytecode Cache
La Bytecode Cache memorizza codice PHP compilato in modo tale che al successivo utilizzo la fase della compilazione possa essere saltata. Da Kinsta abbiamo attivato la OPcache in PHP 7.3 e 7.4 (e lo attiveremo sulle versioni più recenti di PHP non appena saranno disponibili sulla nostra piattaforma).
Aggiornamento: PHP 8.1 (versione ufficiale) è ora disponibile per tutti i clienti Kinsta. PHP 7.4 non è più supportato da Kinsta. Si noti che supportiamo le versioni di PHP 7.4, 8.0, 8.1, 8.2, 8.3 e 8.4.
Quando un file o uno script PHP viene elaborato, deve essere prima compilato in un codice operativo comprensibile alla macchina. Quello che fa la OPcache è convertire l’opcode in modo che PHP sia in condizione di evitare il passaggio della compilazione la prossima volta che sia richiesto lo stesso file o script. L’utilizzo di OPcache migliora in modo significativo le prestazioni di PHP. Tuttavia, implica anche che le modifiche ai file PHP non opereranno immediatamente. Per questo motivo, la OPcache è disativata sui siti in staging WordPress di Kinsta.
Leggete di più sul modo in cui OPcache velocizza le applicazioni PHP.
Object Cache
La Object cache memorizza i risultati delle query del database in modo tale che, la prossima volta che è richiesto un particolare bit di dati, questo possa essere consegnato dalla cache senza interrogare il database di WordPress.
WordPress dispone di un oggetto cache nativo: WP_Object_Cache. Tuttavia, questo oggetto cache memorizza solo oggetti per un singolo caricamento di pagina. Lo scopo della cache è assicurare che il database non venga ripetutamente interrogato nello stesso modo durante un singolo caricamento di pagina. Ma gli oggetti memorizzati non vengono più utilizzati dopo quel singolo caricamento di pagina. Sebbene questa sia una funzionalità utile in WordPress, il caching degli oggetti è molto più potente se gli oggetti cache possono essere utilizzati tra caricamenti di pagina multipli.
É possibile modificare questa modalità e riutilizzare gli oggetti in memoria per caricamenti di pagina multipli passando dall’oggetto cache nativo di WordPress ad una soluzione esterna. Ciò avviene inserendo uno script di caching nella directory /wp-content/. Esistono opzioni basate su plugin come W3 Total Cache.
I clienti di Kinsta possono anche acquistare la nostra add-on Redis ed averla a disposizione dalla versione 8.0 alla versione 8.1 di PHP. Redis è un archivio di strutture dati in-memory open-source, utilizzato come database, cache e broker di messaggi. Date un’occhiata al nostro articolo su come utilizzare Redis come cache di oggetti permanente per saperne di più.
Cache di Pagina
Il caching delle pagine consiste nella memorizzazione dell’intero codice HTML di una pagina in modo che le successive visualizzazioni possano essere generate senza che WordPress debba generare nuovamente la stessa pagina.
Quando viene caricato un sito, WordPress deve elaborare un gran numero di file PHP e interrogare il database svariate volte. Per le pagine che non sono aggiornate di frequente, questo si traduce in uno sforzo inutile. É molto più efficiente generare ogni pagina una sola volta, quindi archiviare quella pagina e consegnarla ai successivi visitatori. Questo è quello che fa il caching delle pagine.
I benefici del page caching consistono in:
- Caricamenti delle pagine molto più veloci.
- Drastica riduzione del carico del server e, di conseguenza, possibilità di gestire una mole di traffico enormemente superiore.
Per il caching delle pagine, i nostri server usano il nginx fastcgi cache module: è impostato in modo che scada ogni ora per default. Tuttavia, i nostri clienti possono cambiare la scadenza della cache delle pagine in qualsiasi momento dalla dashboard di MyKinsta. Per modificare la scadenza della cache delle pagine, andate alla pagina “Tools” del sito, fate clic sul menu a tendina “Modify” sotto “Site Cache” e poi fate clic su Change Cache Expiration.
Nel modal “Change Cache Expiration”, selezionate il tempo di scadenza desiderato e fate clic su Change Expiration. Forniamo opzioni da 1 ora a 7 giorni. Per i siti che non cambiano spesso, può essere vantaggioso in termini di prestazioni avere una scadenza della cache più lunga.
La cache di pagina è configurata per funzionare di default nei normali siti WordPress, BuddyPress, WooCommerce, ed Easy Digital Download. Questo significa che pagine come la bacheca di WordPress, i carrelli di WooCommerce, i forum di BuddyPress per gli utenti che hanno effettuato il login e altro ancora vengono automaticamente esclusi dalla cache delle pagine. Se state usando una configurazione WordPress altamente personalizzata, potrebbero essere necessarie ulteriori personalizzazioni alle impostazioni della cache di pagina, e il nostro team di supporto può assistervi in questo.
Per impostazione predefinita, la cache di pagina è disabilitata sui siti di staging di Kinsta. In alcuni casi, l’abilitazione del caching di pagina in staging è utile per scopi di test. Il page caching per i siti di staging può essere abilitato nel cruscotto MyKinsta.
Cache CDN
La cache CDN memorizza i file dei siti (come JavaScript, CSS e file media) su un content delivery network per una consegna più rapida ad utenti che sono geograficamente distanti dalla località del server host. Quando qualcuno cerca di raggiungere un sito, questi file sono consegnati dal CDN invece di essere consegnati dal server che ospita effettivamente il sito web. Per approfondire, leggete perché dovreste utilizzare un CDN.
Un content delivery network (CDN) offre due principali vantaggi:
- Riduce le risorse del server necessarie per caricare un sito. Dato che questo compito lo svolge la CDN, non sarà il server a doversene occupare.
- Fa in modo che le risorse vengano consegnate da località sparse per il mondo, migliorando le prestazioni del sito per gli utenti che sono geograficamente distanti dal server che ospita il sito.
Ci sono due tipi di CDN di base: quelli che sono semplicemente dei CDN e quelli che offrono un CDN assieme a funzionalità di sicurezza. Alcuni esempi comuni di entrambi i tipi comprendono:
- CDN Standard: Stackpath, Cloudfront.
- CDN più security: Kinsta CDN (Cloudflare), Sucuri, Akamai (opzionale).
Il primo tipo di CDN è impostato creando URL che vengono utilizzate per accedere alle risorse dei siti. Il modo preciso in cui questo è abilitato cambia da un CDN all’altro. L’idea di base è che le URL per le risorse statiche saranno cambiate nelle URL del CDN in modo che le risorse vengano recuperate dal CDN. Di solito, un CDN standard memorizza solo file statici come JS, CSS e file media.
Il secondo tipo di CDN funziona come server proxy completo. Ciò significa che ogni richiesta deve passare attraverso i server del provider prima di arrivare ai server di Kinsta. Questo è attivato utilizzando i nameserver del provider CDN, in modo che il provider CDN abbia il pieno controllo del DNS del sito. Questo permette al provider di fare molte cose che un semplice CDN non può fare, come filtrare il traffico da IP maligni, offrire protezione DoS/DDoS, o anche memorizzare una cache a pagina intera sul CDN. Il nostro CDN Kinsta è alimentato da Cloudflare, un servizio proxy per le prestazioni e la sicurezza.
Caching CDN Avanzato
Se state utilizzando un server proxy CDN come Cloudflare o Sucuri, avrete la possibilità di creare una cache a pagina intera sul CDN. L’utilizzo di un CDN come Cloudflare o Sucuri per memorizzare nella cache il codice HTML dell’intera pagina eliminando completamente il lavoro dei nostri server, ed è una soluzione eccellente per un sito che attende una grande ondata di traffico.
- Sucuri imposta una cache a pagina intera se il livello di cache è impostato su “Enabled”.
- Cloudflare richiede l’impostazione di regole di pagina per il funzionamento del caching di pagina completo. Le regole devono usare il livello di cache “Cache Everything”.
L’Header di Risposta Kinsta Cache
È possibile verificare se la pagina viene servita dalla cache di Kinsta controllando le intestazioni di risposta HTTP. Kinsta aggiunge l’header X-Kinsta-Cache. Alla prima richiesta di una pagina non in cache, verrà visualizzato MISS, come mostrato di seguito.
Alla seconda richiesta della stessa pagina, il valore dell’header X-Kinsta-Cache sarà HIT, che vuol dire che viene servito dalla cache.
E se avete letto il nostro articolo su come ottenere 100/100 in Google PageSpeed Insights, saprete che Kinsta dispone di ottimizzazioni aggiuntive a livello di server per risolvere automaticamente i seguenti messaggi di notifica, che dovrebbero esservi familiari:
- Abilitare la compressione (Kinsta ha già attivato GZIP su tutti i server, quindi non c’è bisogno di attivarlo)
- Ridurre i tempi di risposta del server (Kinsta è già molto veloce, decisamente all’interno dell’intervallo dei parametri ritenuto accettabile da Google senza alcuna ottimizzazione)
- Scadenza degli Header (non c’è bisogno di attivazione perché Kinsta ha gli header della cache abilitati a livello di server)
Ad esempio, il nostro sito di prova ottiene 100/100 su PageSpeed Insights senza l’attivazione di alcun plugin di caching. La cache di WordPress è completamente gestita da Kinsta a livello di server.
Le Impostazioni della Cache di Kinsta
Potreste chiedervi ora come controllare la cache su Kinsta. Ci possono essere delle occasioni, naturalmente, in cui avrete bisogno di calcellarla, specialmente quando risolvete dei problemi. Avete un paio di semplici opzioni. Potete cancellare la cache sia dal cruscotto MyKinsta, sia utilizzando il plugin Kinsta MU.
Svuotare la Cache di WordPress
Potete svuotare manualmente la cache delle pagine dal cruscotto MyKinsta. Basterà cliccare sul menu Siti, poi su Strumenti e quindi sul pulsante “Elimina Cache”.
Per impostazione predefinita, il caching è disabilitato negli ambienti di staging WordPress di Kinsta. Se desiderate testare la funzionalità di caching delle pagine su un sito di staging, potete abilitare il caching utilizzando lo strumento “Site Cache” nel cruscotto di MyKinsta. Dopo che il caching è abilitato per l’ambiente di staging, potete usare il pulsante “Clear Cache” per cancellare la cache proprio come nell’ambiente live.
Il Plugin Kinsta MU
La seconda opzione è utilizzare il plugin Kinsta MU. Come? Sì, tecnicamente è un plugin di caching, ma non è il vostro comune plugin di caching, perché lavora a livello di server.
Di default Kinsta MU è un plugin installato su ogni sito ospitato da noi ed è accessibile dal lato sinistro del pannello di amministrazione di WordPress. É utilizzato per svuotare in modo intelligente la cache sulle pagine appropriate del vostro sito. Il plugin è necessario per essere sicuri che il vostro sito venga eseguito correttamente all’interno del vostro ambiente. Inoltre, ricordate che la cache delle pagine scade di default ogni ora.
Il plugin permette anche di svuotare la cache direttamente dalla barra di amministrazione di WordPress. Questa è probabilmente il motivo principale per utilizzarlo, dato che non dovrete mai entrare nel cruscotto MyKinsta. Potrete farlo direttamente dal vostro sito.
Il plugin vi permette anche di impostare regole di caching personalizzate. A seconda della configurazione del vostro sito, potrebbero essere richieste regole di caching aggiuntive. Potete aggiungere percorsi personali per liberare la cache ogni volta che il vostro sito viene aggiornato.
Potete anche contattare il nostro team di supporto se avete bisogno di escludere una certa pagina o URL dalla cache.
Ambiente di Staging Kinsta
Per impostazione predefinita, gli ambienti di staging su Kinsta hanno la cache delle pagine disabilitata. Questo facilita lo sviluppo e il debug del sito WordPress senza dover cancellare manualmente la cache dopo ogni modifica. In alcuni casi, potreste voler abilitare il page caching su un ambiente di staging per eseguire un accurato test di velocità per una pagina in cache senza mettere il sito live.
Per abilitare la cache delle pagine in un ambiente di staging, andate su Sites > Tools su MyKinsta e fate clic sul pulsante “Enable Cache”. Quando il caching è abilitato in fase di staging, potete utilizzare il pulsante “Clear Cache” per eliminare la cache.
Statistiche Cache di Kinsta
Potete fare un’analisi approfondita di come il vostro sito WordPress sta utilizzando la cache in MyKinsta Analytics. Lo stack dei componenti della cache vi consente di visualizzare lo stato di ciascuna richiesta, sia che si tratti di HIT, BYPASS, MISS o EXPIRED. È possibile filtrare i dati per le ultime 24 ore, per 7 giorni o 30 giorni.
Il grafico dei componenti della cache vi offre una visualizzazione rapida del vostro indicatore di cache. Maggiore è il numero di richieste che vengono servite dalla cache, meglio è.
La sezione dei principali bypass della cache vi consente di vedere quali richieste non vengono servite dalla cache. In genere queste possono includere CRON job, richieste admin-ajax, pagine di checkout di ecommerce, query string e parametri UTM, ecc.
Mettere in Cache le Pagine 404
Le pagine 404 possono richiedere molte risorse. Molti siti WordPress, soprattutto i siti di grandi dimensioni, generano più errori 404 di quanto si possa pensare. Forse avete cambiato la posizione di una pagina e vi siete dimenticati di aggiungere un reindirizzamento, o avete un link sbagliato su un contenuto che avete condiviso sui social media. In altre parole, ci sono molte cose che fanno sì che un visitatore finisca sulla vostra pagina 404. Queste pagine hanno anche la tendenza ad avere delle query per ottenere risultati di ricerca alternativi che poi hanno riscontro sul database.
Per garantire migliori prestazioni sul vostro sito WordPress, Kinsta mette in cache le pagine 404 per 15 minuti. Il valore dell’header X-Kinsta-Cache mostrerà un HIT, il che significa che viene servito dalla cache. Se create una pagina che prima era una 404, la cache viene cancellata immediatamente.
Il nostro strumento MyKinsta analytics può aiutarvi a determinare l’esatto ammontare di errori 404 che si verificano sul vostro sito.
È importante chiarire però che non mettiamo in cache tutte le richieste 404. Ce ne sono di due tipi diversi: quelle provenienti da pagine PHP che atterrano sulla vostra pagina 404 e quelle provenienti da file o immagini mancanti che non esistono più o che sono state spostate. Noi mettiamo in cache le pagine 404, mentre le richieste 404 di file e immagini mancanti vengono gestite in modo diverso.
Pertanto, è possibile utilizzare i “Gli errori 404 più frequenti” per determinare meglio dove si manifestano e cosa li causa.
Potete controllare gli errori 404 in Google Search Console o installare un plugin di terze parti come Redirection che registra gli errori 404. Tuttavia, ricordate che plugin come questi hanno anche un impatto sulle prestazioni. È molto meglio affidarsi a uno strumento a livello di server.
Create un semplice template 404 che eviti di interrogare ulteriormente il database, se possibile.
Le Richiesta POST Bypassano la Cache
Vogliamo che le nostre statistiche relative al caching siano il più accurate possibile. È importante perché quando si risolvono i problemi di performance, di solito si guarda il rapporto di HIT della cache totale affinché sia il più alto possibile. Pertanto, le richieste POST sono incluse nel nostro reporting.
Le richieste POST non possono essere memorizzate nella cache, a parte alcune configurazioni altamente specializzate. Il valore dell’header X-Kinsta-Cache mostrerà un BYPASS per queste richieste. Questo tipo di richieste non devono essere confuse con i post del blog o con qualsiasi tipo di post WordPress (che sono memorizzabili nella cache). Una richiesta POST viene utilizzata per inviare i dati al server. Così, ad esempio, i dati inviati quando inviate un modulo web vengono memorizzati nel corpo della richiesta HTTP.
Riepilogo
Ci auguriamo che ora ci sia più chiarezza sulla cache di WordPress e sui quattro diversi tipi di cache che incontrerete regolarmente su Kinsta: Bytecode cache, Object cache, Page cache e CDN cache.
Se vi siete stancati di perdere tempo con i tradizionali plugin per il caching di WordPress, e se volete un sito che sia semplicemente veloce, allora vi consigliamo di provare Kinsta! C’è una ragione per cui ci è stato riconosciuto da ReviewSignal per 5 anni di seguito lo status di “primo livello” nelle prestazioni di WordPress. Questo perché i nostri server sono perfettamente configurati al top di Google Cloud Platform per avere tempi di caricamento immediati. Non rimarrete delusi dalle nostre prestazioni.
Brian ha una grande passione per WordPress, lo usa da più di dieci anni e sviluppa anche un paio di plugin premium. Brian ama i blog, i film e le escursioni. Entra in contatto con Brian su Twitter.
Lascia un commento