Demistificare l’uso delle cache nei nostri siti

Aggiornato il: 30-06-2022 11:38
Cache, che passione: impostandola il nostro sito andrà più veloce. O forse no… È noto che esistono vari livelli di cache, non equivalenti tra loro: la cache del database, ad esempio, tende a ridurre il numero di hit ed il carico di lavoro per eseguire alcuni tipi di query, anche grazie agli indici ed al monitoraggio via EXPLAIN. La cache del server (esempi classici: memcached e OPcache) è molto efficente sia su Apache che su NGINX, e può essere sfruttata a livello server per migliorare le prestazioni oppure, alla meglio, il TTFB. Senza scomodare in questa sede la cache dei servizi esterni come Google e web archive, che salvano copie delle pagine web periodicamente e che hanno una funzione diversa, esiste infine la cache del browser dell’utente, con cui salviamo i file più usati nel browser dell’utente  per evitare di sfruttare eccessivamente la banda a disposizione.

Il problema degli “automatismi ciechi”

È quello che fanno – quasi in automatico – sia plugin gratuiti come W3 Total Cache che a pagamento come WP Rocket, spesso ricorrendo ad “automatismi ciechi“: semplici (?) procedure che “ottimizzano” il sito, senza che pero’ l’utente capisca realmente ciò che succede. Pensare di poter ottimizzare il proprio sito con una procedura guidata può andare bene fin quando si rimane nel terreno noto, all’interno della cornice classica hosting condiviso + Apache + PHP in versione recente, ma nel momento in cui dobbiamo farlo su scenari differenti o anche solo su server NGINX (tutt’altro che di nicchia, questi ultimi) i dolori sono in arrivo.Si veda questo semplice esempio dalla schermata di configurazione automatica di W3 Total Cache, in cui la procedura guidata – per quanto interessante da altri punti di vista, come spiegato nella recente guida alla riduzione del TTFB – rischia di portare ad un vicolo cieco e, soprattutto, da’ per buono che l’header Cache-Control non debba essere presente (Not present in entrambi i casi), quando invece andrebbe impostato manualmente a parte quantomeno nel caso di uso di una CDN o di cache comunque esterne al sito (es. Jetpack). Problema che qui nemmeno si pone, da cui una configurazione cieca che non tiene conto di questo aspetto, e non si pone nemmeno il dilemma lasciando, di fatto, le cose in maniera incompleta o potenzialmente problematica.

durata cache w3 total cache

Questo ha portato alla diffusione massificata di un bias cognitivo non da poco, che prevede che basti installare quattro plugin in croce per “ottimizzare” un sito, senza che si capisca seriamente in cosa consista farlo e perchè si facciano certe scelte. Poi rimane vero che il web è una macchina strana, che continua a funzionare al netto di bug distribuiti alla meno peggio anche quando uno mai se lo aspetterebbe: ci sono siti anche molto visitati che funzionano ancora oggi su architetture vecchie, non aggiornate e zeppe di situazioni omesse o malconfigurate come quella, eppure continuano a funzionare e siamo tutti contenti lo stesso.

Quando la rete è più veloce della cache (!)

L’uso e la configurazione corretta della cache di un sito non è esente da questo genere di ragionamenti, spesso potenzialmente fuorvianti (ed arriviamo al punto di cui trattiamo oggi): del resto delegare il compito quasi interamente al dispositivo del client sembra anche tremendamente “giusto”, perchè in questo modo scaricherà tutto in locale ed il sito funzionerà più velocemente, almeno sulla carta.

In realtà l’analisi dovrebbe essere meno superficiale di così: come notato dallo sviluppatore e ottimizzatore web Simon Hearne nel suo blog, l’uso esasperato e “cieco” della cache tende a mostrare vari limiti in cui le prestazioni degradano, invece di migliorare, in dipendenza del dispositivo utilizzato, e anche in dipendenza dell’uso di browser come Google Chrome. È una cosa che mi è capitato di notare varie volte, su molti siti, che attivando la cache sembrano rallentare e togliendola le cose vanno meglio: probabilmente il motivo è su questa falsariga.

L’effetto negativo è dovuto ai tempi di accesso agli asset della cache (CSS, JS, immagini, ecc.), che sui dispositivi più economici hanno processori meno performanti per cui, di fatto, sono più lenti e saranno sempre più lenti anche nel tempo, dato che dovranno comunque elaborare quei file e portando alla situazione paradossale che, ad esempio, se non dovessero nemmeno supportare HTTP/2 si tornerebbe ad una situazione risalente a 10 anni fa o più, in cui contava sempre e comunque (nonostante le apparenze contrarie, e nonostante molti tool – anche qui – siano molto fuorvianti nell’ammetterlo) usare script minificati e compressione file.

SMSHosting Usa il codice PROMO per uno sconto sul primo acquisto: PRT96919

Dal grafico di Hearne esce fuori che sia Google Chrome a soffrire maggiormente del problema, specie se si supera (sull’asse delle ascisse) il numero di un centinaio di asset memorizzati in cache (in media la maggioranza dei siti rientra in questa casistica). Tanto vale, a questo punto, snellire gli script e la grafica, lavorando sulle dimensioni del DOM e, come sostengo da sempre, su grafiche essenziali e prive di orpelli automatizzanti come i vari site builder, abusati ed usati anche dai professionisti, in mancanza di risorse di sviluppo adeguate.

Schermata 2022 06 30 alle 09.47.22

Fare affidamento sulle tecnologie recenti va benissimo, in ogni casi, ma delegare tutto il compito ad un singolo aspetto tecnologico per “fare prima” rischia di portarci, in alcuni casi, in direzioni inattese e sgradevoli.

Foto di Mudassar Iqbal da Pixabay



Questo blog pubblica contenuti ed offre servizi free da 11 anni. – Leggi un altro articolo a caso – Per informazioni contattaci
Demistificare l’uso delle cache nei nostri siti
web design 3411373 1920
Torna su