Le cache informatique

Le cache informatique

“C’est la faute du cache”, l’excuse préférée des développeurs. Vous l’avez sûrement entendue plusieurs fois lors d’une création de projet web ou d’une résolution de bug.

À quoi sert le cache s’il est si pénible que ça ? C’est ce qu’on va voir dans cet article.

Quelques notions

Avant de parler du cache, parlons rapidement de ce qu’il se passe quand vous souhaitez aller sur un site.

Lorsque vous renseignez une adresse dans la barre prévue à cette effet, ou que vous cliquez sur le résultat d’un moteur de recherche, votre navigateur envoie ce qu’on appelle une requête HTTP.

Schéma basique d'une requête HTTP
Schéma basique d'une requête HTTP

Une requête HTTP passe par différents systèmes, que l’on détaillera dans de futurs articles. La requête finit par arriver à un serveur web, qui va comprendre et traiter la requête. Bien souvent, il y a encore des étapes entre l’arrivée de cette requête et le code qui la traite, mais passons directement à ce qui nous intéresse.

Le serveur contient du code qui interprète la requête et formate un résultat. Ce dernier constitue la réponse, qui va peu ou prou suivre le chemin inverse et parvenir jusqu’à votre navigateur, qui l’affichera à l’écran.

Si vous envoyez 50 fois cette requête, elle fera 50 fois le même chemin, et le serveur fera 50 fois le même travail. Un serveur web n’est qu’un ordinateur. Comme tout ordinateur, il a une capacité de calcul maximale et peut arriver à saturation, les temps de réponse sont alors plus longs, et peuvent même bloquer l’accès à un serveur entier.

Lorsqu’un serveur ne répond plus à cause d’un trop gros nombre de requêtes, on appelle ça un “déni de service” ou “DDoS”. On appelle aussi une “attaque DDoS” lorsqu’un grand nombre d’usagers et de machines s’associent pour émettre un trop grand nombre de requêtes sur un même serveur, volontairement, dans l’objectif de le saturer et de le rendre inaccessible.

Pour améliorer les temps de réponses et réduire la charge des serveurs, il est devenu commun de mettre en place des mémoires temporaires, que l’on appelle “mémoire cache”. C’est un concept qui existe déjà en informatique depuis 1965.

Le principe est relativement simple : on enregistre la réponse d’une requête pour éviter d’effectuer à nouveau les calculs. La procédure est souvent la même :

  • Acteur A demande une information via une requête
  • On vérifie si la mémoire cache du support d’Acteur A contient déjà l’information pour cette requête
  • Si oui, la mémoire cache retourne directement l’information
  • Sinon, on interroge le destinataire de la requête, qui procède alors à sa procédure et retourne le résultat
  • On stocke dans la mémoire cache cette information
  • On traite finalement la réponse
Schéma d'une requête HTTP mise en cache
Schéma d'une requête HTTP mise en cache

Ce principe existe à de nombreux endroits. Vous pouvez le retrouver dans vos disques durs, vos microprocesseurs, des routeurs etc…

Ceux qui nous intéressent, ce sont ceux qui officient dans les sites et applications web : le cache navigateur et le cache serveur.

D’autres caches peuvent entrer en scène dans ces types de projet, mais ils sont en général contrôlés par d’autres acteurs du projet.

Cache navigateur

Ce cache est celui qui est géré par votre navigateur (Firefox, Chrome…). Il permet d’optimiser les performances à de nombreux niveaux puisqu’il garde l’information sur votre propre support. On évite donc l’envoi d’une requête, du calcul serveur et le traitement de la réponse.

L’inconvénient majeur de ce système de cache, c’est lorsque l’on souhaite changer le résultat d’une requête.

Schéma d'un cache invalide
Schéma d'un cache invalide

Pour cela, on définit une date d’expiration de chaque mémoire cache. Ce n’est pas spécifique au cache navigateur. Cela dépend de la politique de cache de chaque projet et du type de requête que l’on souhaite mémoriser.

Les requêtes HTTP

On parle plus haut à plusieurs reprises de requêtes HTTP et on a vu qu’elles retournent des résultats à interpréter. Une partie de cette interprétation se fait sur le format de la réponse. Il en existe énormément. Les principaux dans le cadre du web étant :

  • HTML
  • CSS
  • JS
  • JSON
  • Images (jpg, png, svg, webp…)

Quand une image s’affiche sur une page web, elle est le résultat d’une requête http retournant une image. Chaque image est en effet une longue suite de caractère, qui est traduite et transformée en image par votre navigateur.

Par exemple, si vous vous rendez sur https://www.webexmachina.fr, que vous ouvrez votre console avec F12 et que vous ouvrez l’onglet “Réseau / Network”, vous pouvez voir toutes les requêtes qui sont exécutées lors du chargement de la page.

Requêtes HTTP sur webexmachina.fr
Requêtes HTTP sur webexmachina.fr

Comme vous pouvez le constater, la majeure partie de ces requêtes ont pour valeur de transfert “mis en cache”. Mon navigateur a pour instruction de mettre en cache toutes ces requêtes pour permettre à ma page de s’afficher plus rapidement.

Mettre en place une politique de cache

Il s’agit de définir les temps d’expiration pour chaque type de requête. Si vous utilisez un CMS, cette politique est bien souvent définie à l’avance. De manière générale ou spécifique.

Cela se passe au niveau du serveur, dans un fichier .htaccess, qui permet de définir des règles variées concernant les requêtes qui atteignent votre site.

Dans Contao 4,  une instruction globale indique de mettre en cache toute requête commençant par assets/ ou bundles/
Dans Contao 4, une instruction globale indique de mettre en cache toute requête commençant par assets/ ou bundles/

Les règles de cache peuvent aussi ressembler à ça, avec des indications pour chaque type de résultat retourné. Dans l’exemple ci-dessous, un navigateur conserve chaque image 2 semaines avant de la revalider.

Chaque extension à sa règle ici
Chaque extension à sa règle ici

Contourner le cache client

Vous avez remplacé une image sur votre site et c’est toujours l’ancienne qui s’affiche ? Il existe une manière simple et rapide de vérifier si c’est le cache qui est en cause.

Faites un clic droit sur l’image et ouvrez-la dans un nouvel onglet. Puis dans la barre d’adresse, ajoutez un ?v=2 à la fin.

Ce qu'il se passe quand vous faites un clic droit sur une image
Ce qu'il se passe quand vous faites un clic droit sur une image

Si l’image change, c’est que cela vient de votre cache ! En effet, le cache navigateur se base sur l’URL de la requête pour mettre sa mémoire en place. Si vous changez la requête, même avec un élément qui n’impacte pas la logique de la procédure, le cache n’agit pas sur celle-ci et va interroger le serveur.

Dans une URL, on appelle “paramètres d’URL” ce qui se trouve après un ?. Il y a bien des raisons d’utiliser ces paramètres et l’une d’entre elles et de faire des versions de fichiers, pour forcer les caches navigateurs à s’actualiser.

Rafraichir son cache

Faire un F5 va actualiser votre page, mais n’a aucun effet sur le cache navigateur. Pour réinitialiser le cache sur un site, vous devez utiliser le raccourci suivant : Ctrl+F5

Certains supports sont un peu durs de la feuille, vous pouvez insister en le faisant 2 fois d’affilée. Si cela ne change toujours pas, recommencez avec le raccourci suivant : Ctrl+R.

Consultez la page Wikipédia à ce sujet, qui reste à jour au fil des mises à jour des navigateurs : https://fr.wikipedia.org/wiki/Aide:Purge_du_cache_du_navigateur

Cache serveur

Le cache serveur fait la même chose qu’un navigateur, mais pour tout le monde en même temps. Cela permet de mutualiser d’autant plus le gain de ressources, car si vous faites une requête pour la première fois, vous bénéficierez quand même d’un gain de performances puisque le serveur aura mémorisé le résultat demandé.

Schéma d'une mise en cache serveur
Schéma d'une mise en cache serveur

Il existe plusieurs façons de mettre en place un cache serveur. On peut même en mettre plusieurs, à différents niveaux, comme dans la base de données.

De plus en plus d’infrastructures sont découpées en web services qui s’appellent les uns les autres lorsqu’une requête est émise sur un serveur. On pourrait imaginer un cache serveur dans chaque web service pour optimiser le traitement d’une requête à tous les niveaux.

Cas pratique : les vues SQL

Lorsqu’on gère une base de données, on suit quelques règles fondamentales. Le moins de doublons possibles, aucune donnée calculée n’est stockée etc.

Par exemple, dans un site qui gère des paniers, le montant de votre panier n’est jamais stocké, il est calculé par le serveur. Vu qu’il est susceptible de changer, et que l’on veut un calcul “en temps réel”, le stocker dans des mémoires temporaires peut créer des écarts non souhaitables.

Mais sur certaines infrastructures, notamment sur des énormes devis, tout recalculer est parfois très long. Et on n’affiche pas le prix en direct. À la place, vous pouvez avoir un bouton “Calculer mon devis”. Ce bouton va compiler et stocker toutes les informations nécessaires dans une table temporaire que l'on appelle "vue", pour pouvoir ressortir votre devis rapidement.

Par contre, dès qu’un mouvement sera fait, il faut régénérer la vue, qui est alors marquée comme invalide, ou tout simplement supprimée, pour laisser place à la nouvelle, à jour. Sur des grosses infrastructures, ce traitement est potentiellement transparent, mais économise de nombreux calculs à chaque affichage.

Mettre en place une politique de cache, navigateur ou serveur est primordiale pour accélérer le temps de chargement d’une page web. Attention toutefois à bien le maîtriser pour ne pas créer des décalages de comportements entre les résultats prévus et les caches de vos usagers !

Cette vitesse de chargement et d’affichage est d’ailleurs un critère majeur pour les moteurs de recherche. C’est un sujet que nous traiterons dans un article futur.

Dans la même catégorie