Chapitre 4.3.1
Introduction au cache

C'est parce qu'il y a du cache ! Il faut le vider.

Le cache : source de nombreux problèmes. Omniprésent dans les conversations dès que tu travailles sur un produit web et excuse numéro 1 des développeurs qui veulent éviter un diagnostic.

Qu'est-ce qu'un cache ?

Un cache est un système, un logiciel, qui garde en mémoire le résultat d'un traitement. Pas besoin de réexécuter toute la chaîne, tu as déjà la réponse sous le coude.

Un cache peut contenir plein de choses : le résultat d'un traitement coûteux, des images, des vidéos, des données qui changent rarement etc...

Le but est d'améliorer la performance en réduisant :

• Le temps de réponse : moins de traitement, proximité géographique avec le client...
  Moins de délais = un client heureux et une amélioration du référencement par les moteurs de recherche.
• Les ressources mobilisées : puissance de calcul, charge sur les machines protégées par le cache...
  Moins de ressources = moins de consommation d'énergie et de coûts d'infrastructure.

Le cache renforce les systèmes, mais il a aussi quelques points négatifs :

• Il a lui-même des coûts d'infrastructure. Notamment, la plupart des caches se reposent sur les mémoires à accès rapide des serveurs (comme la RAM). Il faut donc des machines spécifiques, à la mémoire dopée.
• Il ajoute de la complexité et des compromis à gérer pour les développeurs. Quoi mettre en cache ? Quand ? Pour combien de temps ? Quand le vider ? Comment gérer les erreurs ? Un cache mal géré introduit des incohérences dans le système avec des données pas à jour.
  
  Nous approfondirons ces compromis dans les prochains chapitres.

Tu utilises des caches tous les jours !

Chaque affichage de page web déclenche des dizaines de caches répartis dans différents systèmes : ton navigateur web, ta box, ton fournisseur d'accès internet, l'hébergeur du site, les logiciels internes du site etc…

Chaque couche de cache a son propre but, impliquant différentes technologies et nécessitant une stratégie de gestion dédiée.
Quelques exemples :

• Le site peut indiquer comment les navigateurs et les intermédiaires doivent cacher (mettre en cache) son contenu. Ils gardent en mémoire certaines ressources déjà téléchargées. C'est pour ça que quand tu visites de nouveau une page, elle se charge beaucoup plus vite que la première fois.
  
  En pratique, les règles de cache ne sont pas les mêmes selon le type de ressource. On évite de demander la mise en cache de données qui changent trop souvent : le panier sur un site e-commerce par exemple. À l'inverse, les images, les fichiers de code statique (CSS, JavaScript) et autres données qui changent rarement sont gardés parfois plusieurs jours en cache. Note que "rarement", s'entend ici au sens informatique : 1 minute peut sembler une éternité pour une image que 10 000 clients souhaitent visionner simultanément.
  
  Certains systèmes, comme Akamai ou Cloudflare, permettent de découper un contenu pour appliquer une stratégie différente par morceau. Par exemple, si j'ai une page qui affiche le résultat d'un match de football en cours, je peux réduire la durée de vie de la zone de score, tout en gardant plus longtemps la majorité des autres éléments (nom des équipes, historique des joueurs...).
  Cette approche, appelée "cache fragmenté" ou "Edge Side Includes (ESI)", permet de combiner performance et fraîcheur des données : la majorité du contenu reste servie depuis le cache, tandis que seules les parties critiques sont mises à jour en direct.
• Un réseau de diffusion de contenu, ou Content Delivery Network (CDN), est un ensemble de serveurs répartis dans le monde. Les CDN sont des structures privées gérées par de grosses entreprises comme Amazon, Google etc... Ils rapprochent géographiquement le contenu des utilisateurs pour réduire le temps de transfert et la latence. La requête d’un internaute européen sera par exemple traitée par une machine européenne.
  
  Les CDN sont principalement, mais pas seulement, utilisés pour distribuer les fichiers statiques : images, vidéos, code frontend…
• Un proxy inverse, ou reverse proxy, est un système placé directement devant les serveurs applicatifs (les machines qui exécutent le code). Il intercepte les requêtes entrantes et peut fournir une réponse précalculée.
  
  Un CDN repose sur le même principe, agissant comme un reverse proxy distribué à l’échelle mondiale, en servant depuis ses propres noeuds le contenu mis en cache. Les entreprises peuvent ajouter un proxy inverse interne en complément du CDN pour disposer d’un cache plus finement contrôlé. Cette seconde couche de protection sert souvent du contenu moins statique, avec une durée de vie plus courte : le stock restant pour un produit, la page d’accueil d’un média, ou des données semi-dynamiques.
  
  Technologies les plus connues : Varnish, Nginx.
• Plusieurs types d'intermédiaires peuvent garder une copie des pages les plus demandées pour réduire la charge sur le réseau. Avant la démocratisation d'HTTPS, c'était le cas de la plupart des fournisseurs d’accès internet et des forwards proxy.
  
  Un forward proxy, à l'inverse d'un reverse proxy, sert pour les requêtes sortantes, c'est-à-dire les requêtes émises de l'intérieur du réseau vers l'extérieur. Il est mis en place dans les entreprises pour contrôler le réseau.
  
  HTTPS, en chiffrant le contenu des requêtes, a fortement compliqué la mise en cache des intermédiaires, rendant cette technique de moins en moins utilisée.
• Le cache applicatif est une couche de cache directement manipulée par les développeurs pour optimiser leurs programmes.

Cette liste non exhaustive présente surtout les caches de haut niveau qu’on croise sur le web. Mais ce n’est que la partie visible de l’iceberg, les caches sont partout : du système d’exploitation au processeur, en passant par la résolution des noms de domaines ou les équipements réseau. Nous en croiserons tout au long de ce guide.

Dans les prochains chapitres, nous étudierons plus en détail le fonctionnement du CDN et l'utilisation du cache applicatif par les développeurs.