AVVISO IMPORTANTE: Dato l'elevato numero di richieste, Eternal Curiosity non può accettare nuovi clienti, sia che si tratti di consulenze scritte che di ottimizzazione SEO diretta. Valutiamo solo casi eccezionali e ad alto budget. Per informazioni, vi invitiamo a scriverci a info@eternalcuriosity.it

Questo articolo apparteneva al vecchio blog (blog.danilopetrozzi.it), per cui le informazioni potrebbero non essere più aggiornate ed attendibili.

Optimus Prime Cache: cos’è e a cosa serve il cache priming

Chi non ha mai sentito parlare di W3 Total Cache? È il plugin per il caching più usato, ed è famoso quasi quanto WordPress SEO by Yoast.

Che cosa fanno W3 e gli altri plugin per la cache?

Oltre a tante chicche “extra”, il core della sua attività è uno: creare una versione statica delle pagine (cache, appunto) da servire agli utenti, in modo da evitare le lungaggini dovute alla risoluzione del codice PHP, le query MySQL, ecc.

Grazie alla cache, l’utente può visualizzare le pagine in tempi molto più rapidi.

È tutto oro quello che luccica? Mmh, no!

No visit, no party

La maggior parte di questi plugin serve la versione statica della pagina solo dopo che essa è stata generata. Se una pagina non è mai stata visitata, non c’è una versione statica della stessa, per questo la cache non può essere servita.

Prima che una pagina possa essere servita sotto forma di cache statica, quindi, deve essere stata visitata almeno una volta.

Questo significa che quando la cache viene pulita (es. “Empty All Caches” su W3 Total Cache), tutte le pagine saranno prive di cache e quindi se Googlebot fosse il primo visitatore ad aprire le pagine, le vedrebbe tutte “in modo dinamico”, e quindi lento.

Priming cache: precaricare la cache a intervalli regolari

Il cache preloading, meglio chiamato “priming” dal verbo “to prime”, è una funzione attivabile in diversi plugin per WordPress, anche W3 Total Cache.

La cosa che in pochi sanno è che il cache preloading di W3.. spesso non funziona.

cache preloader di W3 Total Cache

Il cache preloader di W3 Total Cache

Esatto, non funziona! Cercando “W3 Total Cache cache preload not working” troverete centinaia di discussioni aperte un pò ovunque. Il problema deriva dalla gestione interna (senza cron) con cui W3 tenta di fare il priming automatico.

Tutto si basa sulle visite degli utenti: se ci sono tantissime visite, su quasi tutte le pagine del sito, il caching e la “garbage collection” funzionano abbastanza bene.

Nella maggior parte dei casi, con la configurazione standard di un server, il priming e la garbage collection non funzionano a dovere, per cui si rimane con molte pagine non cachate oppure con altre la cui cache è vecchia di millenni (e per l’editoria = morte)

Soluzione: componente esterno per il priming

Un modo pratico per effettuare il priming della cache su tutte le pagine del sito (esatto, tutte) è quello di affidarsi a un componente esterno studiato per questo scopo.

Oggi vi parlo di Optimus Cache Prime, uno dei tanti primer che ho testato a fondo (su questo blog :D)

Cos’è OCP?

OCP è un file che si scarica e si carica sullo spazio web del sito su cui va utilizzato. Può essere anche installato in un unico host per poi essere usato ovunque.

OCP prende in input una o più sitemap XML dalla quale estrapola tutti gli URL. In base alle regole stabilite, OCP visita tutte le pagine della sitemap in modo da generare la cache, per esempio tramite W3 Total Cache, o qualsiasi altro plugin. (OCP richiede solo una sitemap XML, quindi va bene con qualsiasi CMS, a patto che sia installato un cacher “a chiamata”)

Configurabile per ogni esigenza

È possibile fornire a OCP anche una sitemap index: lui scansionerà automaticamente tutte le sitemap interne.

La quantità di richieste GET simultanee che OCP effettua può essere variata a piacimento. Nel caso di siti leggeri, è possibile incrementare drasticamente il numero di pagine aperte simultaneamente da OCP, in modo da avere un priming fulmineo.

L’user-agent con cui OCP effettua le richieste può essere variato.

Come si utilizza

Dopo averlo caricato nell’host (presumiamo nello stesso host del sito da “primare”), è sufficiente attivare un cron job a intervalli regolari per fare in modo che ogni URL venga cachato automaticamente.

Di seguito, alcuni esempi forniti dal sito ufficiale:

esempi di utilizzo di optimus prime cache

Un esempio concreto: DaniloPetrozzi.it

Nel caso del mio blog, il cron è così composto:

Al posto di “PATH-DI-OCP” c’è l’URL completo della path in cui risiede il componente.

-c 5”  significa che OCP aprirà 5 URL simultaneamente per cacharli

http://www.danilopetrozzi.it/sitemap_index.xml” è la mia sitemap index, dalla quale OCP estrapola tutti gli URL del mio sito

Ho deciso di impostare il cron job ogni 20 minuti, così il mio sito può sempre restituire le versioni statiche delle pagine. Anche se io decidessi di pulire tutta la cache da W3 Total Cache, al massimo potrebbero trascorre 20 minuti di blackout.

L’implementazione di un primer va pianificata

Prima di fiondarvi a installare OCP e a settare un “-c 1000” sul vostro sito composto da 100.000 pagine, aspettate un attimo. Evitiamo i disastri!

Per prima cosa: occhio ai log e a Google Analytics. OCP effettua numerose richieste GET per generare la cache delle pagine, per cui dovete essere sicuri che queste visite “finte” non incidano su Google Analytics o altri strumenti che monitorano il traffico.

Dovete assicurarvi di aver filtrato correttamente l’user-agent, che è fisso. L’IP di provenienza delle richieste è ovviamente il server stesso (se hostate il componente nello stesso luogo in cui sta il sito). Un esempio dei miei log, quando OCP “attacca”:

Occhio al carico

OCP è un componente ottimo per siti medio-piccoli. Se avete decine di migliaia di pagine, dovete impostare il cron a intervalli molto lunghi, e dovete cercare di tenere basse le connessioni simultanee.

Se la quantità di pagine che OCP deve aprire è troppo elevata potrebbe saturarsi la banda oppure, ancora peggio, potrebbe aumentare il carico del server a livelli tali da impedire l’apertura del sito. Alcuni plugin per la cache (non è il caso di W3) potrebbero addirittura cachare la versione “non aperta” delle pagine (errori 500 e similari).

Nei casi più gravi, senza una adeguata pianificazione, un cron job di OCP potrebbe partire prima che il precedente lavoro sia concluso, dando origine a loop potenzialmente disastrosi.

Per siti molto grandi, la soluzione più bilanciata può essere quella di usare OCP su una sitemap XML ridotta, che magari contiene solo gli URL più importanti (homepage, categorie, landing importanti, ecc). Oppure è possibile creare tanti cron job per attivare OCP su sitemap differenti, potendo così manipolare i tempi di attesa e le richieste simultanee.

L’aumento prestazionale

Come potete vedere dallo screen in basso, l’aumento prestazionale è stato notevole, almeno per il mio blog:

velocità di caricamento di danilopetrozzi.it

A fine luglio, il mio sito era ancora in WordPress ma non era il blog che vedete adesso. C’erano pagine statiche, W3 Total Cache, ma ovviamente senza priming.

Dal 9 agosto ho rifatto completamente il layout e ho implementato Optimus Prime Cache. Come vedete, siamo passati da picchi di 2.000 millisecondi, a una media (costante!) di circa 300.

Come ben sapete, in molti articoli ho pubblicato tantissimo materiale multimediale (iframe, grosse immagini, ecc), ho aggiunto social (che portano dietro vari JS e tempi di attesa), ecc, ma la velocità di caricamento è in continuo miglioramento.

In conclusione

Ridotto ai minimi termini, Optimus Cache Primer è solo un bot che visita il tuo sito a intervalli regolari. È utile solo se utilizzato in combinazione con un cacher (W3 Total Cache & co).

Il fatto di essere ultra ottimizzato per la gestione di sitemap XML, lo rende uno strumento potente, dato che può essere modulato con i cron job. (che sono indipendenti da qualsiasi CMS)

Sta a voi settarlo nel modo migliore per bilanciare carico e prestazioni!

 

Danilo petrozzi

Ciao! Io sono Danilo Petrozzi, il fondatore di Eternal Curiosity. Oltre a essere un senior SEO Specialist e un Web Developer, è dall'età di 9 anni che mi appassiono a qualsiasi cosa ruoti intorno al web e all'informatica in generale.

Lascia un commento