Contenu statique ou dynamique : le guide complet du cache en périphérie

« Statique » et « dynamique » sont des étiquettes de développement utiles, mais elles ne constituent pas des politiques de cache complètes. Une page produit peut être générée depuis une base de données tout en pouvant être mise en cache brièvement en toute sécurité. Un document HTML à l'apparence statique peut contenir une recommandation ou un cookie propre à l'utilisateur et ne doit pas être partagé. Le cache en périphérie fonctionne lorsque vous classez la réponse, ses entrées, sa tolérance à la fraîcheur et l'impact d'une défaillance.

L'objectif n'est pas de maximiser le taux de succès du cache à tout prix. Il consiste à réutiliser les réponses sûres, garder les données personnalisées privées, réduire le travail de l'origine et rendre la fraîcheur prévisible.

Ce que signifient réellement statique et dynamique

Le contenu statique est généralement identique pour de nombreux utilisateurs : JavaScript avec hash, feuilles de style, polices, logos, images publiques, téléchargements et médias versionnés. Ces objets sont d'excellents candidats à une mise en cache longue durée, car un changement d'URL peut représenter un changement de contenu.

Le contenu dynamique est produit ou sélectionné au moment de la requête : résultats de recherche, stock, recommandations, pages de compte, paniers, paiement et API. Dynamique ne signifie pas automatiquement non cacheable. Une réponse de catalogue public peut être réutilisée brièvement si sa clé de cache capture la requête. À l'inverse, un endpoint fondé sur un cookie ou un jeton d'autorisation ne peut pas être partagé en toute sécurité simplement parce que l'URL est stable.

Un modèle de classification pratique

Utilisez quatre catégories lors de la conception des règles en périphérie :

1. Ressources publiques immuables. Les fichiers versionnés peuvent avoir de longues durées de vie dans les caches partagés et les navigateurs. Gardez les anciennes versions disponibles tant que du HTML mis en cache les référence encore.
2. Contenu public sensible au temps. Les actualités, pages de catégorie et données produit publiques peuvent utiliser un TTL partagé limité, des validateurs, des balises ou une revalidation en arrière-plan.
3. Contenu public mais spécifique à la requête. La recherche et les listes filtrées peuvent être mises en cache si la clé inclut la requête significative, la locale, la devise et les autres entrées. Ne normalisez les paramètres de suivi que lorsqu'ils ne modifient pas la réponse.
4. Contenu privé ou personnalisé. Les réponses de compte, panier, paiement et API spécifiques à l'utilisateur devraient généralement utiliser private ou no-store, ou contourner entièrement le cache partagé.

La norme de cache HTTP définit les caches partagés et privés, la fraîcheur, la validation, les clés de cache et les restrictions liées à l'autorisation. Utilisez-la comme référence plutôt que le comportement par défaut d'un fournisseur.

Concevoir le cache en périphérie étape par étape

1. Commencez à l'origine

Faites en sorte que l'application émette une politique intentionnelle. Cache-Control: public indique qu'une réponse peut être partagée lorsque les autres conditions sont remplies. max-age contrôle la fraîcheur générale, tandis que s-maxage peut définir une durée de vie différente pour les caches partagés. private empêche la réutilisation partagée, et no-store indique aux caches de ne pas stocker la réponse. no-cache signifie qu'une réponse stockée doit être validée avant réutilisation ; cela ne veut pas simplement dire « ne pas mettre en cache ».

Associez la fraîcheur à des validateurs. Un ETag permet à un cache de demander si la représentation a changé sans la télécharger à nouveau. Last-Modified permet une validation fondée sur le temps. Envoyez Vary lorsque la représentation change selon un en-tête de requête tel que Accept ou Accept-Language.

2. Définissez la clé de cache

Au minimum, la clé inclut généralement la méthode et l'URI cible. Examinez chaque dimension supplémentaire :

• Les paramètres de requête qui modifient le filtrage, le tri, la devise ou la pagination.
• La sélection de langue et de pays.
• Les valeurs Accept lorsque la négociation de format modifie le corps.
• Les signaux d'appareil ou de client, uniquement si la sortie diffère réellement.
• Les cookies et l'autorisation, qui sont souvent une raison de contourner le cache plutôt que d'étendre la clé.

Une clé trop spécifique crée de nombreuses variantes froides et renvoie les requêtes vers l'origine. Une clé insuffisamment spécifique peut servir le mauvais contenu. Ne normalisez que les entrées dont l'absence de pertinence est démontrée et testez le résultat avec deux requêtes qui doivent produire des réponses différentes.

3. Séparez le HTML public des fragments privés

Pour une page avec des zones publiques et personnalisées, mettez en cache la structure publique et récupérez les données privées séparément, ou composez la réponse à l'aide d'un mécanisme conçu pour un assemblage sûr en périphérie. Ne mettez pas en cache l'intégralité du document HTML en supposant qu'un cookie sera ignoré. Un CDN peut réutiliser le document pour un autre utilisateur sauf si la politique ou la clé l'empêche.

Pour les API, utilisez des règles spécifiques à chaque endpoint. Un flux de produits public et un endpoint de commande client peuvent partager un nom d'hôte, mais ne doivent pas partager une politique de cache globale. Ne laissez jamais une règle générale fondée sur l'extension de fichier déterminer si du JSON peut être réutilisé en toute sécurité.

4. Choisissez la fraîcheur et le comportement du contenu périmé

Définissez les TTL selon la tolérance métier, pas selon un nombre générique. Un logo peut rester frais un jour ou plus lorsqu'il est versionné. Une page de catégorie peut tolérer quelques minutes. La disponibilité et le prix peuvent nécessiter une fenêtre bien plus courte ou une requête en direct. Lorsque cela est acceptable, stale-while-revalidate peut masquer la latence de revalidation, et stale-if-error peut préserver le contenu public durant une panne de l'origine. Les extensions RFC 5861 décrivent ces comportements.

Ne servez jamais de données de compte, de panier, de paiement ou sensibles à l'autorisation devenues périmées simplement pour améliorer la disponibilité. Le coût d'un ancien titre public n'est pas celui d'un ancien prix ou solde privé.

5. Planifiez les mises à jour et les purges

Versionnez ce qui peut l'être. Pour les URL stables, attachez des balises de contenu ou des clés de substitution afin qu'une mise à jour de produit puisse invalider la page produit, la liste et les fragments associés sans vider l'intégralité du cache. Une purge d'URL convient à un seul objet ; un préfixe ou une purge complète doit avoir un rayon d'impact documenté.

Lisez le guide de purge du cache pour une séquence de mise en production qui publie avant d'invalider. Le guide CDN managé d'Optimi couvre la couche de diffusion en périphérie et la visibilité sur les succès de cache.

Vérifiez la justesse et la rapidité

Construisez une matrice de tests avant la production :

• Visiteur anonyme ou visiteur authentifié.
• Première requête ou requête répétée.
• Ordinateur de bureau ou mobile, ou signaux client.
• Chaque langue, pays, devise et format pris en charge.
• Paramètres de requête pertinents avec des résultats attendus différents.
• Comportement en cas de réussite, délai d'expiration et erreur de l'origine.

Inspectez Cache-Control, Age, ETag, Vary, Set-Cookie, le traitement de l'autorisation et les en-têtes d'état du cache du fournisseur. Une réponse avec Set-Cookie mérite un examen attentif, mais son absence ne prouve pas qu'une réponse est publique. Comparez les corps ou un marqueur de version, et pas seulement HIT et MISS.

Mesurez le volume de requêtes vers l'origine, le taux de succès du cache, l'âge de la réponse, le TTFB, le taux d'erreur et les Core Web Vitals par type de page. PageSpeed Insights rapporte les expériences terrain au 75e percentile lorsqu'il existe suffisamment de données ; utilisez les données terrain avec des tests contrôlés plutôt que de substituer l'un à l'autre.

Retour arrière et reprise

Conservez un interrupteur simple pour chaque modification de politique : désactivez la nouvelle règle, restaurez la configuration précédente ou acheminez le chemin affecté vers l'origine en contournant le cache. Si la mauvaise réponse publique a été mise en cache, purgez son URL ou sa balise de contenu après correction de l'origine. Si des données privées ont pu être partagées, traitez-le comme un incident de sécurité : arrêtez immédiatement la réutilisation, purgez toutes les variantes affectées, renouvelez ou invalidez les sessions exposées selon le cas et examinez les journaux.

En cas de régression de performance, n'écourtez pas aveuglément tous les TTL. Identifiez si la cause est la fragmentation de la clé, une règle de contournement, un validateur manquant, une erreur de l'origine ou une tempête de remplissage. Corrigez la règle défaillante et préchauffez progressivement des objets représentatifs.

Erreurs courantes

• Qualifier toutes les pages rendues côté serveur de dynamiques et n'en mettre aucune en cache.
• Mettre en cache toutes les réponses GET réussies sans examiner les cookies ou l'autorisation.
• Ignorer Vary après avoir servi plusieurs représentations d'image ou de langue.
• Mettre chaque paramètre de requête dans la clé ou supprimer des paramètres qui modifient le contenu.
• Utiliser no-cache lorsque le véritable besoin est no-store, ou l'inverse.
• Servir des prix, stocks, paniers ou données de compte périmés pour la disponibilité.
• Ne mesurer qu'un navigateur chaud et conclure qu'il s'agit de la performance en périphérie.

Pour les décisions propres aux images, lisez l'optimisation des images pour l'e-commerce et la page Images adaptatives d'Optimi. Les équipes e-commerce peuvent relier ces règles à la solution e-commerce, et les équipes qui prévoient plusieurs chemins de diffusion peuvent lire le guide de résilience.

Il n'y a que deux choses difficiles en informatique : l'invalidation du cache et nommer les choses.