préchauffer le cacher

Dans cet article, nous vous invitons à décortiquer la problématique du préchauffage du cache. Nous l'aborderons dans un premier temps sous l'angle de vue général, puis nous vous détaillerons les actions que nous avons mises en place chez Fasterize.

Chez Fasterize, nous accompagnons nos clients dans la mise en place d’une stratégie de mise en cache de leurs pages, cohérente et performante. L’arsenal d’outils est varié : le smart cache qui permet la mise en cache de page dynamique, le cookie less cache qui permet la mise en cache de pages pour les utilisateurs sans sessions actives ou encore le cache gérant plusieurs variations de page pour le mobile, la langue ou le magasin.

Cependant, le cache de Fasterize n’est performant que s’il est chaud et correctement alimenté. L’alimentation du cache se fait de façon passive au fur et à mesure des requêtes entrantes effectuées par les visiteurs. Le préchargement du cache via un crawler est d’autant plus intéressant lorsque :

    • le trafic du site est faible en comparaison de la taille du catalogue produit
    • ou que la probabilité que plusieurs utilisateurs requêtent la même variation d’une page est faible.

Cache hit vs cache miss

Le cache de Fasterize stocke une ou plusieurs variations des fichiers constituant une page Web afin de les distribuer plus rapidement. En mettant en cache des copies des images, CSS et HTML au niveau de Fasterize, le serveur d'origine n'a pas besoin de générer ces fichiers chaque fois qu'un nouveau visiteur accède au site Web. Cela améliore le temps de chargement de la page et réduit la pression sur le serveur d'origine. Ainsi, un site Web peut servir plus de visiteurs à la fois.

Les sites de e-commerce mettant constamment à jour l'inventaire de leur produit, les fichiers expirent après une période définie, qui peut aller d’une minute à plusieurs heures. Chaque fois qu'un fichier dans le cache expire, celui-ci doit être récupéré à nouveau depuis le serveur d'origine.

Cache hit vs cache miss

Source : section.io

Le premier internaute à visiter un site Web après l’installation initiale d’un cache ou l’expiration d’un cache, passe par un cache vide ou froid et rencontre un « cache miss ». Le cache transmet la requête au serveur d’origine pour récupérer le fichier et le transmettre au visiteur. Bien sûr, il conserve par la même occasion le fichier dans le cache, qui est donc complet ou chaud. Chaque utilisateur suivant qui visite ce même site avant l'expiration du cache, sera servi depuis le cache. On parle alors d’un «cache hit».

En résumé, un cache hit correspond à une requête ayant été servie par le cache alors qu’un cache miss correspond à une requête servie par l’origine. Un cache froid ne contient pas encore les fichiers et un cache chaud contient déjà des fichiers et est prêt à servir les visiteurs.

Préchauffage du cache: avantages et inconvénients

En général, les sites Web veulent que les visiteurs rencontrent un cache hit afin qu’ils soient servis plus rapidement. Cependant, à moins que les sites ne se mettent à préchauffer le cache, certains visiteurs rencontrent un cache miss après l'expiration du contenu ou le vidage du cache. L’expérience est alors dégradée pour ceux-là.

Le préchauffage du cache consiste donc à remplir artificiellement le cache, de sorte que les visiteurs réels obtiennent toujours un accès au cache. Essentiellement, cela prépare le cache pour les visiteurs (d'où le terme «préchauffage», comme dans le moteur chaud d'une voiture), plutôt que de laisser le premier visiteur obtenir un cache miss. Cela garantit que chaque visiteur a la même expérience.

Si le pré-chargement du cache est une technique intéressante à bien des niveaux, il faut cependant rester vigilant à quelques points. Voici différents problèmes pouvant arriver lors de la mise en place d’un préchargement de cache :

Trop de serveurs de cache à préchauffer

Si les pages sont mises en cache sur un CDN ayant plusieurs centaines de serveurs edge, le système devra mettre en place tous ces caches. Le site peut utiliser un robot d'indexation ou crawler. Ce robot devra se rendre sur le site Web à plusieurs reprises et à partir de plusieurs emplacements pour s'assurer que chaque cache est rempli.
Dans ce cas, la stratégie la plus raisonnable est de ne cibler que certains noeuds du CDN dit principaux (origin shield de KeyCDN, regional edge cache de Cloudfront). Cela réduit l’ampleur de la tâche.

Chez Fasterize, les pages sont généralement mises en cache au niveau de la plateforme. Le problème ne se pose donc pas.

Une durée de vie des pages trop courtes

Si la durée de cache est de quelques minutes, la mise en place d’un crawler ne sera pas efficace. Le crawler n’aura pas le temps de parcourir l’ensemble du catalogue que les pages visitées auront déjà expiré.

Dans ce cas de figure, il faudra trouver un compromis : précharger les pages clés du site.

Un serveur d’origine ne pouvant pas tenir la charge d’un crawling régulier

Le passage d’un crawler peut générer une charge non négligeable sur des origines sous-dimensionnées. En effet, le crawler va demander des pages peu chargées à l’origine ce qui peut induire des requêtes sollicitant fortement la base de données à l’origine.

Dans ce cas de figure, il faudra trouver un compromis : précharger les pages clés du site.
Dans ce cas, il faut soit :

  • réduire le nombre de pages crawlées,
  • soit réduire la vitesse de crawling
  • ou encore effectuer un crawling aux heures creuses de la journée.

Trop de variations possibles par page

Si la page produit se décline sous des centaines de versions (une version par magasin physique par exemple), le nombre de pages à traiter peut être trop important par rapport aux temps de crawling alloués. Dans ce cas, il est souhaitable de prioriser les versions pour ne crawler que les versions majeures de chaque page.

Le crawler de Fasterize

Le crawler de Fasterize est une fonctionnalité disponible pour nos clients souscrivant au plan Entreprise. Celui-ci est mis en place par nos Customer Success Engineer après l’étude d’impacts liés aux branchements de Fasterize.
Le crawler a deux modes de fonctionnements :

  • le parcours des URL présentes dans le sitemap du site
  • le parcours d’une liste d’URLs fournis par le client

Le crawler ne prend en compte que les URLs des pages du sitemap. Les URLs des images ne sont pas crawlées. Ce mode est le mode que nous conseillons en raison de sa simplicité. Cependant, si le sitemap n’est pas exploitable car, trop large ou non à jour, il est possible de fournir une liste statique d’URLs. Cette liste est alors parcourue du début à la fin.

La vitesse de crawling est paramétrable. Nous pouvons régler deux éléments :

  • le nombre de robots crawlant en parallèle (par défaut 4)
  • le temps d’attente entre chaque requête (par défaut 0.2 sec).

Il est également possible de configurer l’entête User-Agent utilisé par le crawle. Il s’agit par défaut du : Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/47.0.2526.111 Safari/537.36k FstrzCrawler.

Enfin, les entêtes de la requête sont elles aussi personnalisables. Cela donne beaucoup de flexibilité dans différents cas :

  • adresser plusieurs variations selon le cookie de variation fstrz_vary
  • imposer un rafraîchissement obligatoire ou optionnel de chaque page.
  • rafraîchir plusieurs caches de Fasterize : le cache principal ou le cookieless cache.

Ce crawler est actuellement utilisé par de nombreux clients avec des résultats très intéressants en termes de performance.

Restez informé.e de notre actualité, inscrivez-vous à notre Newsletter :


VOUS AIMEREZ PEUT-ÊTRE AUSSI...

We Love Speed 2018 : la 1ère édition en vidéo La première édition de We Love Speed s’est tenue en octobre 2018 à Bordeaux. Co-organisé par Fasterize, l’événement a rassemblé les amoureux...
TLS 1.3, la nouvelle version du web sécurisé, plus... En août dernier, l’IETF (Internet Engineering Task Force) approuvait la version 1.3 de TLS, une version qui se veut plus sécurisée et plus p...
5 bonnes pratiques pour un Black Friday réussi +48% de transactions enregistrées en 2017, en comparaison à 2016*. Et selon Google, les requêtes "Black Friday" ont augmenté de 125% en 2017...
La Check-list webperf avant les soldes Les soldes approchent (J-3) et la performance de votre site web sera un axe important de votre réussite. Améliorer les temps de chargement p...