Introduction

Cache Rocket garde votre site Web et vos caches API au chaud. Il visite vos URL selon un calendrier, de la même manière qu'un vrai visiteur le ferait, de sorte que le travail coûteux de création d'une page a déjà été effectué avant que quiconque ne le demande.

Vous n’installez rien sur votre serveur pour commencer. Vous vérifiez que vous possédez un domaine, créez un warmer et Cache Rocket fait le reste via les requêtes HTTP ordinaires.

Sur les offres payantes, Cache Rocket propose également [Managed CDN](/documentation/managed-cdn) et l'optimisation Media dans le cloud — formats d'image, Critical CSS, LQIP et PageSpeed Insights — principalement via le plugin WordPress, ainsi que les intégrations CDN pour la purge → réchauffage sur votre edge existant.

Le problème : le premier visiteur paie#

Presque tous les sites Web rapides sont rapides parce que quelque chose est mis en cache : un nœud périphérique CDN, un proxy inverse comme nginx ou Varnish, un cache de page WordPress ou le propre cache de rendu de votre framework. Les caches sont merveilleux, mais ils expirent tous.

Lorsqu'une copie en cache expire, elle disparaît. La prochaine personne qui demande cette page n’obtient pas la version mise en cache rapide. Leur demande parvient à votre serveur d'origine, qui doit reconstruire la page à partir de zéro : exécuter le code, interroger la base de données, restituer le modèle et le renvoyer. Cette personne attend. Nous appelons cela une page à froid, et le délai est la *pénalité de démarrage à froid*.

C'est pire qu'il n'y paraît, car les demandes froides atterrissent exactement sur les personnes qui vous tiennent le plus à cœur :

• Le lecteur qui clique sur votre article nouvellement publié trente secondes après sa mise en ligne.
• L'acheteur arrivant d'une campagne publicitaire sur une page de destination que personne n'a touchée de la nuit.
• Tout le monde en même temps, juste après le déploiement et chaque cache est vidé simultanément.
• Visiteurs dans une région dont le nœud périphérique CDN n’a jamais servi cette page auparavant.

La solution : réchauffez-le d'abord#

Cache Rocket supprime la pénalité de démarrage à froid en étant lui-même le premier visiteur. Il demande vos URL avant de vraies personnes, ce qui oblige chaque couche de cache située devant votre origine à stocker une nouvelle copie. Au moment où un humain arrive, la page est déjà en cache et est servie instantanément.

C'est toute l'idée. Tout le reste existe pour le rendre pratique : décider *quelles* URL, *à quelle fréquence*, *d'où*, *à quelle vitesse* et prouver que cela a réellement fonctionné.

Ce que tu peux réchauffer#

Est-ce que Cache Rocket vous convient ?#

Cela est particulièrement utile lorsque les pages sont coûteuses à créer et que le trafic est suffisamment inégal pour que les caches se refroidissent entre les visiteurs.

Cela aide moins si vos pages sont déjà des fichiers statiques servis à partir du disque sans expiration, ou si chaque réponse est personnalisée par utilisateur et ne peut donc jamais être mise en cache en premier lieu.

Comment utiliser ces documents#

Les pages sont écrites pour être lues dans l’ordre, mais chacune est autonome. Si vous êtes nouveau, voici l'itinéraire le plus rapide :

1. 1

   Lire Comment ça marche

   Dix minutes sur ce qui se passe réellement lors d'un run à chaud. Cela vaut le coup avant de commencer à modifier les paramètres.

2. 2

   Suivez le Démarrage rapide

   Une première configuration guidée : créez un compte, vérifiez un hostname, créez votre premier warmer et confirmez que cela a fonctionné.

3. 3

   Survoler Concepts de base

   Le vocabulaire - URL d'entrée, profondeur, intervalles, score de chaleur. Le reste des documents assume ces mots.

4. 4

   Ensuite, allez plus loin là où vous en avez besoin

   La barre latérale est regroupée par tâche : configuration, réchauffement, surveillance, intégrations, compte et aide.