Un réseau de diffusion de contenu peut servir des réponses réutilisables plus près des visiteurs et limiter les requêtes répétées à l’origine. Il aide surtout lorsque les ressources qui ralentissent la page sont cacheables et que le nœud choisi détient une copie exploitable. Il ne corrige pas automatiquement application lente, images lourdes ou JavaScript coûteux. Le cache de pages complètes demande davantage de précautions que celui des fichiers publics.
Suivez une requête du visiteur à l’origine
Le navigateur se connecte au CDN. Le nœud vérifie si une réponse stockée correspond à la requête et peut être réutilisée. Un succès frais évite l’origine. Un échec peut nécessiter un téléchargement, suivi d’une décision sur l’éligibilité de la réponse au stockage.
Un objet expiré n’équivaut pas à un cache vide. Le CDN peut valider, remplacer ou servir selon une politique autorisant l’ancien contenu. En-têtes et configuration déterminent ce comportement. Consultez la documentation des états au lieu d’assimiler tous les résultats différents de HIT.
Un CDN peut aussi terminer TLS, proposer HTTP/2 ou HTTP/3, compresser ou transformer les images. Ces capacités sont distinctes du cache et peuvent dépendre de réglages ou d’une offre. Elles ne garantissent pas une accélération. Un visiteur déjà proche d’une origine rapide ou une page toujours exclue du cache peut peu bénéficier d’une couche supplémentaire.
Le guide du temps de réponse serveur distingue connexion, traitement et livraison. Il permet de vérifier que le CDN traite le vrai problème. Un CSS servi rapidement ne compense pas un document bloqué sur une requête de base de données.
Identifiez les règles par défaut
Il n’existe pas de comportement universel. Beaucoup de services cachent images, CSS et JavaScript publics, mais exigent des en-têtes ou règles adaptés pour HTML et API. D’autres dépendent du produit, de l’origine ou du mode choisi. Une extension ne prouve pas le stockage ; l’éligibilité ne garantit pas le maintien de l’objet.
Examinez documentation et réponse représentative de chaque classe. Notez clé, méthodes, états admissibles, cookies, autorisation, fraîcheur et expiration. N’appliquez pas une option de type tout mettre en cache aux comptes parce qu’elle accélère une page de test.
Ces modèles imposent des contrôles différents.
| Modèle | Utilité | Contrôle nécessaire |
|---|---|---|
| Fichiers publics avec empreinte | Réutiliser les mêmes fichiers entre visiteurs | Changer l’URL avec les octets |
| HTML public en périphérie | Éviter une génération répétée | Éligibilité, fraîcheur et invalidation explicites |
| Pages personnelles hors cache partagé | Isoler chaque utilisateur | Vérifier session et autorisation |
| Structure publique et requêtes privées | Partager la présentation stable en protégeant les données | Endpoints privés, rendu et authentification sûrs |
Le guide du cache du navigateur couvre la couche cliente. Coordonnez les politiques : une purge CDN ne révoque pas sûrement une copie encore réutilisable dans un navigateur.
Construisez une clé correspondant à la réponse
La clé décide quelles requêtes peuvent partager un objet. Elle inclut souvent hôte, chemin et certains paramètres, avec d’autres variantes selon le service. Si langue, devise ou dimensions modifient le contenu, cette différence doit apparaître dans la clé ou être exclue du partage.
Ignorer des paramètres de suivi peut regrouper des réponses publiques identiques. Tous les ignorer risque de mélanger filtres, transformations d’images et requêtes signées. Utilisez une liste explicite justifiée par l’application. Un paramètre d’apparence secondaire n’est pas nécessairement ignoré du backend.
À l’inverse, une clé trop fragmentée limite la réutilisation. Un identifiant unique sur une réponse identique pour tous empêche le partage ; l’en-tête Cookie complet multiplie les combinaisons. Préférez quelques variantes publiques explicites si elles correspondent au fonctionnement réel. Les données privées de compte doivent rester hors de ce modèle.
Écrivez deux requêtes qui doivent partager une réponse et deux qui ne doivent pas. Testez-les avant lancement et après modification de personnalisation. Cette vérification relie la configuration au contenu réellement reçu.
Définissez la fraîcheur du HTML public
Ne mettez le HTML en cache partagé qu’après exclusion des identités de session, comptes, tokens privés et autres personnalisations. Limitez routes et méthodes, contournez le cache pour les requêtes authentifiées et cookies de session pertinents. Le fournisseur doit respecter private et no-store ; une dérogation annule leur protection.
Pour du HTML réellement public, cet exemple sépare fraîcheur navigateur et cache partagé.
Cache-Control: public, max-age=0, s-maxage=300La copie du navigateur devient immédiatement périmée, tandis qu’un cache partagé conforme peut la considérer fraîche 300 secondes, sous réserve de l’âge HTTP et des autres règles. Ces valeurs illustrent un choix, pas une recommandation universelle. Fixez la durée selon le retard de publication acceptable et la fiabilité de l’invalidation.
Pour une sortie personnelle sensible, associez une réponse restrictive à une règle explicite de contournement CDN.
Cache-Control: no-storeNe retirez pas Set-Cookie simplement pour rendre une réponse cacheable sans comprendre sa fonction. Inversement, un cookie analytique peut ne pas personnaliser une page publique. La règle suit la réponse réelle ; les cas ambigus restent hors cache partagé jusqu’à vérification.
Mesurez les succès avec un dénominateur explicite
Le taux de succès par requête divise les succès par les requêtes du rapport. Les services peuvent compter les requêtes éligibles, toutes les requêtes ou certains états. Vérifiez cette définition avant comparaison. Le taux par octets répond à une autre question.
Segmentez HTML, images et autres fichiers, puis régions si nécessaire. Un excellent résultat sur les fichiers peut masquer presque aucune réutilisation HTML. Une page rare demandée sur de nombreux nœuds peut rater souvent tandis qu’un fichier populaire reste chaud. Une longue durée n’empêche pas l’éviction et un grand réseau ne garantit pas chaque objet partout.
Reliez succès, échecs et contournements au TTFB, aux requêtes d’origine et aux temps visibles. Séparez premier accès froid après déploiement et trafic stable. Retenir le meilleur rechargement d’une URL chaude ne représente pas tous les visiteurs. L’analyseur PageSpeed aide au contrôle d’une page, sans mesurer le taux de succès du CDN entier.
Purgez précisément et publiez dans le bon ordre
Pour un fichier avec empreinte, une nouvelle URL est généralement plus simple que son remplacement. Publiez les fichiers avant le HTML et conservez les versions antérieures pour pages et sessions ouvertes. Une purge ne remplace pas ce versionnement.
Pour une URL HTML stable, invalidez par URL ou, si disponible, par une étiquette regroupant les dépendances. Modifier un article peut toucher catégorie, accueil et blocs associés. Couvrez ces dépendances sans évincer inutilement les autres fichiers.
Une purge globale peut créer une vague d’échecs et de travail à l’origine. Définissez qui la déclenche, la procédure d’échec et la détection d’ancien contenu. Testez publication, aperçu et retour arrière complets, pas seulement l’acceptation d’une requête API. Propagation et garanties de fin varient selon le service.
Certains CDN proposent un origin shield, cache intermédiaire recevant les échecs périphériques. Il peut regrouper les requêtes d’origine, mais ajoute une couche à diagnostiquer et invalider. Il convient lorsque charge et configuration le justifient, pas parce qu’une couche de plus serait toujours bénéfique.
Repérez les erreurs entre couches superposées
Cache d’hébergement, CDN et navigateur peuvent chacun définir différemment la fraîcheur. Documentez où la réponse est produite et réutilisée. Age aide à examiner son âge, tandis que les états propriétaires nécessitent leur documentation. Un seul en-tête ne révèle pas tout le parcours.
Vérifiez redirections HTTPS, hôtes et routage canonique pour éviter des allers-retours superflus. Maintenez certificat et authentification de l’origine même si les visiteurs utilisent uniquement le CDN. Une connexion périphérique rapide ne justifie pas une origine exposée ou mal routée.
Les transformations d’images créent des variantes par dimensions, format et qualité. Incluez-les dans le cache, limitez les variantes arbitraires et contrôlez dimensions et octets. Le guide d’optimisation des images traite ce que la proximité seule ne corrige pas.
Autoriser de l’ancien contenu exige une décision adaptée au sujet. Un article public légèrement retardé diffère de droits de compte ou d’un état de transaction périmés. Ne transposez pas une règle statique à des endpoints sensibles. Fraîcheur et autorisation y restent des exigences de correction.
Déployez progressivement avec retour arrière
Commencez par une classe de fichiers publics, puis une route HTML vérifiée si cela convient. Testez requête froide, répétée, document modifié et erreur. Deux sessions indépendantes doivent garder leurs données privées séparées ; connexion et déconnexion doivent modifier correctement le comportement.
Enregistrez les en-têtes avec GET sur la véritable URL publique de votre environnement.
curl -sS -D - -o /dev/null https://example.com/news/Examinez état documenté, Cache-Control, Age lorsqu’il existe et corps réel. Comparez à l’origine par une voie diagnostique autorisée. Un bon état avec un mauvais contenu n’est pas un test réussi.
Rassemblez éligibilité, invalidation et retour arrière. Consultez la collection sur les performances serveur et la présentation officielle des CDN avant extension. Ajoutez une classe seulement lorsque son bénéfice mesuré et son actualisation sont établis.
