Stratégies de mise en cache en périphérie pour les applications React

L'en-tête de réponse Cache-Control contrôle pendant combien de temps Cloudflare (et les autres CDN) mettent en cache vos réponses SSR. Les principales directives sont : max-age (cache du navigateur), s-maxage (durée du cache du CDN ou du cache partagé) et stale-while-revalidate (servir du contenu obsolète pendant sa revalidation en arrière-plan).

s-maxage est pris en compte par les caches partagés (CDN), tandis que max-age concerne les caches du navigateur. Pour les pages SSR, vous choisirez généralement s-maxage=60 (le CDN met en cache pendant 60 secondes) et max-age=0 (le navigateur revalide toujours), afin que tous les utilisateurs reçoivent un contenu raisonnablement récent depuis le cache en périphérie.

Ajouter stale-while-revalidate=30 à votre en-tête Cache-Control indique à Cloudflare de servir instantanément la page mise en cache tout en récupérant une version à jour en arrière-plan. Les utilisateurs obtiennent toujours une réponse rapide ; l'ancienneté maximale est de s-maxage + stale-while-revalidate secondes.

Le contenu personnalisé (fondé sur la session de l'utilisateur ou sa langue et sa région) ne doit pas être fourni par un cache partagé au mauvais utilisateur. L'en-tête Vary: Cookie indique à Cloudflare de traiter chaque valeur Cookie unique comme une entrée de cache distincte, empêchant ainsi les données d'un utilisateur d'être fournies à un autre.

Un schéma courant consiste à rechercher un cookie de session dans le Worker avant de décider s'il faut utiliser le cache. Si un cookie de session est présent, contournez entièrement le cache et générez une réponse personnalisée. Si aucun cookie de session n'est présent, la page est publique et peut être fournie depuis le cache.

Cloudflare KV est un magasin clé-valeur distribué à l'échelle mondiale, qui stocke les données à proximité des utilisateurs. Vous pouvez mettre en cache du HTML rendu dans KV : stockez la page rendue comme valeur avec un TTL, puis les requêtes suivantes la lisent depuis KV en périphérie au lieu de la générer à nouveau avec React.

Les lectures KV sont rapides, car les données sont répliquées sur le PoP périphérique qui traite la requête ; leur latence typique est inférieure à 5 ms. Les écritures KV utilisent toutefois une cohérence éventuelle : une écriture effectuée dans une région est propagée à tous les PoPs du monde en moins de 60 secondes, ce qui signifie que certains utilisateurs peuvent brièvement voir des données obsolètes.

Cloudflare R2 est un service de stockage d'objets compatible avec S3, sans frais de sortie. Il convient aux ressources volumineuses qui ne tiennent pas dans KV : modules WASM, images OG pré-rendues et grands jeux de données JSON. Les Workers accèdent à R2 via des liaisons, comme à KV.

Cloudflare Enterprise prend en charge les étiquettes de cache : vous étiquetez une réponse avec Cache-Tag: product-42 et, lorsque le produit 42 change, vous appelez l'API de Cloudflare pour purger toutes les réponses portant l'étiquette product-42. Cela permet une invalidation ciblée du cache sans purger l'intégralité de celui-ci.

Lorsque vous déployez une nouvelle version de votre Worker, le HTML déjà mis en cache peut faire référence à d'anciens noms de fichiers de regroupement JS. Une stratégie robuste consiste à inclure la version du déploiement dans vos clés de cache, ou à utiliser des noms de fichiers de regroupement versionnés (grâce au hachage du contenu de Vite), afin que l'ancien HTML fasse toujours référence à des fichiers JS valides et mis en cache.

Un Worker qui met en cache du HTML SSR dans KV suit ce schéma : calculez une clé de cache à partir de l'URL (et éventuellement de la langue et de la région), vérifiez dans KV si elle existe, puis renvoyez immédiatement le HTML mis en cache si c'est le cas. En cas d'absence, effectuez le rendu avec React, stockez le résultat dans KV avec un TTL, puis renvoyez le HTML fraîchement rendu.

Quel modèle de cohérence Cloudflare KV utilise-t-il pour les écritures ?

La mise en cache en périphérie des applications React combine plusieurs stratégies : s-maxage de Cache-Control pour la mise en cache CDN des pages publiques, Vary: Cookie pour empêcher le partage des réponses personnalisées, KV pour le HTML rendu mis en cache en périphérie et les étiquettes de cache pour une invalidation précise. Le modèle de cohérence éventuelle de KV signifie que la propagation des écritures peut prendre jusqu'à 60 secondes ; concevez donc vos TTL et votre stratégie d'invalidation en conséquence.