Si2Ra, comme beaucoup d'autres Systèmes de publication, est basé sur le couple PHP / MySql. PHP permet d'écrire un site dynamique, et MySql de conserver les données des différentes pages dans une base de données, cette dernière facilitant grandement l'inclusion, la modification et la suppression de pages dans le site. Cependant, les requêtes MySql (et c'est un problème partagé par toutes les bases de données) utilisent beaucoup de ressources serveur. L'interprétation d'un script PHP, même sans appel à la base de données est également plus lente et lourde pour le serveur, que la simple lecture d'une page HTML.

Outre l'excès de dépense énergétique (le processeur fonctionne d'avantage, s'échauffe, et donc consomme d'avantage d'énergie), la consultation du site peut être sensiblement ralentie, notamment en cas d'hébergement mutualisé (= de nombreux sites se partageant les ressources d'un même serveur).

Or, si 10, 1000 ou 1OO OOO personnes consultent les mêmes pages d'un site, ce sont toujours les mêmes requêtes qui seront effectuées. C'est pourquoi les CMS proposent généralement un système de cache. Lorsqu'un visiteur demande une page, le système vérifie si elle existe en cache, et si ce dernier n'est pas périmé. Il affiche alors la page mémorisée sans avoir besoin de la recomposer à partir de la base de données. Si le cache est trop ancien -ou absent- la page est recalculée, affichée et le cache est (re)créé. C'est de cette façon que fonctionne par exemple SPIP, et c'est une très bonne méthode pour les gros sites, fréquemment mis à jour, et ayant une forte fréquentation.

Pour les sites beaucoup plus ordinaires, comme le mien, avec une faible fréquentation, et pouvant passer longtemps sans être modifiés, ce système de cache temporaire n'est plus adapté. Les rares visiteurs ont une forte probabilité de tomber sur un cache périmé, de subir le calcul des pages qu'ils consultent, et donc de ressentir le site comme étant lourd et lent...

En fait, Si2Ra dispose d'un double système de cache :

• Un cache par rapport à la base de donnée : lors de la publication d'un article, un script contenant toutes les données est écrit (mais pas la mise en forme), ce qui fait qu'il n'y a pas d'appel à la base de donnée lors de la lecture de celui-ci.
• Les pages publiques sont enregistrée une deuxième fois dans un fichier .html destiné aux visiteurs non connectés (il n'est alors pas nécessaire de rechercher les messages personnels, ni de vérifier les droits...). Le site devient alors presque aussi rapide que s'il était statique. Ce deuxième cache, incluant fond et forme, n'est calculé qu'en cas de besoin, c'est à dire lors de la première lecture de l'article par un visiteur non connecté.

Dans les deux cas, il ne sera effacé et recalculé que si la page est modifiée, directement, ou indirectement par une modification de sa rubrique (pour permettre la mise à jour des liens), ou encore si le squelette du site est altéré.

Observation : le temps d'élaboration de la page (en pied de page) n'est pas correcte pour les pages publiques super-cachées. Il correspond au temps qui a été nécessaire à la composition de la page à partir du premier cache, et avant que le chache .html ne soit écrit.