Ogni giorno il proprio sito web risponde a centinaia di migliaia di richieste dal web, elaborando e recuperando informazioni dalle banche dati, impiegando del tempo e facendo attendere l'utente prima che venga visualizzata la pagina web. E' possibile, però, migliorare questo processo di elaborazione grazie ai sistemi di caching. Analizziamo come fare e in che modo adattarli al meglio alle nostre esigenze.

Il web è in continua crescita ed espansione ed ogni giorno offre agli utenti nuovi servizi e tecnologie che aiutano a semplificare e migliorare la vita. Crescendo il numero di servizi offerti dalla rete cresce anche la richiesta di informazioni che ogni utente fa verso un determinato servizio (ad esempio un portale social o un portale che offre servizi gratuiti come la condivisione di file e di musica etc...), creando un traffico dati sempre maggiore, che mette a dura prova le infrastrutture tecnologiche e l'hardware necessario, al fine di rendere veloce e sempre più "real time" la web experience che l'utente percepisce navigando il sito. Lo standard HTTP di base prevede il caching delle risorse statiche, come i file javascript, i file di stile CSS, delle immagini, e anche dell'intera pagina web con una data di "Expire", che però possono risultare insufficienti qualora i dati contenuti nelle pagine sono il frutto di particolari elaborazioni complesse, sia da parte di un DBMS che da parte del linguaggio di programmazione usato.

Per queste serie di motivi, sono nate delle tecnologie di caching server side, che permettono di alleggerire molto la mole di dati gestita dai server e di rendere sempre più fluida l'interazione con il sito web, come ad esempio, nel mondo opensource, sono presenti memcache, APC (che è un sistema di caching dell'opcode di PHP che permette di cachare l'opcode generato dall'interprete di php per ogni richiesta, evitando di fatto la rinterpretazione dello script ad ogni esecuzione), XCACHE e altri sistemi analoghi.

Lo scopo di questi strumenti è di evitare l'elaborazione di un'informazione che non è cambiata in uno specifico arco temporale, alleggerendo quindi il carico di lettura che l'utente richiede navigndo le pagine del sito.

Il miglioramento delle performance di un sito web che si affida a questi mezzi può essere stimato intorno al 60-80% in più delle pagine elaborate al secondo (misurato in requests/seconds), riducendo anche i costi energetici delle macchine che risparmiano tempo di elaborazione.

Ci sono però delle controindicazioni nell'uso inappropriato di tali tecnologie, come l'effetto "dog-pile", che in alcuni casi rischia di creare dei disservizi e disagi all'utente, mostrando informazioni incongruenti con quelle salvate nella banca dati e che rischiano quindi di rendere il sistema instabile. Bisogna quindi bilanciare correttamente l'uso di tali mezzi impostando una scadenza dei dati in essi immagazzinati, limitandoli laddove si riscontri un rallentamento dell'elaborazione della pagina che richiede un'informazione particolarmente "pesante" da recuperare, e non impiegandoli ovunque, rendendo anche difficile agli sviluppatori il debugging.

In aggiunta a questi strumenti, grazie alla nascita di HTML5 e del nuovo standard W3C, sono nate altre tecnologie client side di caching, che permettono agli sviluppatori web di interagire in maniera sempre più forte con i web-browser, limitando anche il traffico web perché i dati vengono storati direttamente nel client, utilizzando ad esempio i localeStorage, sessionStorage, e webSQL, facendo diminuire quindi il numero di richieste che arrivano al server e svincolandolo anche dal rendering delle pagine che vengono costruite dinamicamente dai client in base ai dati forniti. Lo scambio dati può avviene, ad esempio, in maniera asincrona (AJAX), senza che il browser ricarichi l'intera pagina, ma richiedendo al server i dati necessari, che li fornirà in un formato XML/JSON.

Sia i localeStorage che i sessionStorage altro non sono che contenitori di informazioni nel formato "chiave" => "valore", che possono essere utili, ad esempio, al sito per salvare configurazioni utilizzate dall'utente in locale.

È interessante notare come il webSQL, che è nato per entrare nello standard W3C, ma che in realtà non è mai stato inserito in quanto essendo SQLite nativo del browser, non è un componente web indipendente per il quale è possibile definire uno standard, ed è quindi già deprecato in alcuni browser come Mozilla Firefox e IE, mentre continua ad essere supportato in altri browser come Google Chrome e Safari.