Passer au contenu 
Je vais te montrer comment utiliser l'en-tête HTTP Contrôle du cache utilise de manière ciblée pour réduire les temps de chargement, limiter le nombre de requêtes et gérer efficacement les caches des navigateurs. Vous bénéficiez de consignes claires, de combinaisons judicieuses et de paramètres pratiques pour le HTML, le CSS, le JS, les images et les API – sans avoir à tâtonner, mais avec concrètes En quelques gestes.
Points centraux
Les points clés suivants te permettront à coup sûr d'obtenir un résultat rapide et fiable Stratégie de mise en cache.
- max-age en tant que temporisateur : contrôle la durée de conservation en secondes
- public/privé: définit qui est autorisé à mettre en cache
- no-cache vs. no-store: rééduquer plutôt qu'interdire
- ETag et Dernière modification: Les appels conditionnels permettent d'économiser des données
- Versionnement + immuable: caches longues sans vestiges
Principes de base : à quoi sert l'en-tête Cache-Control ?
L'en-tête contient des instructions qui déterminent si, pendant combien de temps et par qui une réponse sera envoyée dans le Cache peut se trouver. Je fais ici la distinction entre les caches client dans le navigateur et les caches partagés, tels que les proxys ou les CDN, qui desservent souvent plusieurs utilisateurs et génèrent ainsi des Efficacité apportent. Alors que l'en-tête „ Expires “, désormais obsolète, utilise une date, j'utilise avec « Cache-Control » des durées relatives via « max-age », ce qui est moins sujet aux erreurs. Je détermine ainsi combien de temps une ressource reste « à jour » et si elle doit être revalidée avant d'être utilisée. Cela me permet de conserver la possibilité de contrôler les contenus dynamiques et de conserver très longtemps les fichiers statiques en local.
Cache-Control s'applique aussi bien aux réponses qu'aux requêtes, ce qui m'est utile pour la revalidation, notamment en association avec ETag ou Last-Modified pour Conditionnel Requêtes. Je définis par exemple des paramètres agressifs pour les ressources inchangées et des règles prudentes pour le HTML. Cette distinction permet de s'assurer que les requêtes suivantes proviennent autant que possible du cache du navigateur, ce qui réduit ainsi la Charge du serveur diminue. Il est important de mettre en place une coordination bien planifiée afin de ne pas bloquer involontairement des ressources ou de les laisser s'épuiser trop tôt. En respectant ces principes fondamentaux, on pose les bases pour des temps de chargement courts et des règles claires concernant le comportement du cache.
Les principales directives expliquées de manière claire
Avec max-age Je définis la durée de vie d'une ressource en secondes, à compter de sa mise en ligne. Pour les images, les fichiers CSS, JS et les polices, je choisis souvent 31536000 (un an), afin que les visiteurs qui reviennent sur le site utilisent presque tout en local. Pour les pages HTML, je définis une durée plus courte, environ 300 secondes, ou je les associe à une revalidation afin que les modifications soient rapidement visibles. Une durée de validité trop longue sans gestion des versions des fichiers conduit facilement à la présence d’anciennes versions dans le cache ; c’est pourquoi je modifie les noms de fichiers à chaque mise à jour. Je combine ainsi une actualité rigoureuse avec haute Taux de réussite du cache.
Les directives public et privé définir qui est autorisé à mettre en cache. J’attribue le niveau « Public » aux contenus non personnalisés, afin que les proxys et les CDN puissent également les mettre en cache. J’attribue le niveau « Privé » lorsque seul le navigateur de l’utilisateur doit en conserver une copie, par exemple sur les pages de compte. J’évite ainsi que des données personnelles ne se retrouvent dans des caches partagés et y se tromper. Cette distinction permet d'éviter les désagréments et de protéger les informations sensibles.
no-cache est souvent mal interprété : il n'interdit pas la mise en cache, mais exige une revalidation auprès du serveur avant toute nouvelle utilisation. Cela convient aux contenus qui changent régulièrement, sans pour autant devoir être entièrement rechargés à chaque consultation. Grâce à l'ETag ou à l'en-tête « Last-Modified », le client conserve les données en local et vérifie simplement si elles sont toujours à jour. J'évite ainsi des octets superflus tout en conservant le Contenu récent. Pour les données hautement sensibles, « no-cache » reste toutefois trop laxiste.
no-store C'est la mesure la plus stricte, car elle interdit tout enregistrement dans le navigateur et dans les proxys. Je l'utilise pour les pages de connexion, les processus de paiement ou les documents contenant des données confidentielles. Ainsi, aucune copie ne se retrouve dans des dossiers temporaires qui pourraient tomber par inadvertance entre de mauvaises mains. Dès que j'utilise « no-store », je combine souvent cette option avec « max-age=0 » afin d'empêcher toute réutilisation exclure. Ici, la sécurité prime sur les performances.
must-revalidate impose une nouvelle requête auprès du serveur dès que le délai est écoulé. En cas de panne du serveur, le cache ne doit pas simplement continuer à servir la ressource. Cette directive est adaptée aux contextes où la cohérence prime sur une stratégie de tolérance aux pannes souple. Je l’applique lorsque des données obsolètes risqueraient d’entraîner des décisions erronées. Cette règle établit clairement caractère contraignant lors du déroulement.
Directives avancées pour les caches partagés et la résilience
Au-delà des paramètres de base, j'utilise s-maxage, stale-while-revalidate et stale-if-error, afin de gérer de manière ciblée les serveurs proxy et les CDN et d'assurer une expérience fluide aux utilisateurs, même en cas de perturbations. s-maxage définit un TTL spécifique uniquement pour les caches partagés (les navigateurs l'ignorent). Je peux ainsi, par exemple, limiter la durée de mise en cache dans le navigateur (max-age=600), tout en la prolongeant au niveau de la périphérie (s-maxage=86400). stale-while-revalidate Cela permet aux caches de continuer à diffuser des contenus périmés pendant une durée définie, tandis que la mise à jour s'effectue déjà en arrière-plan. stale-if-error intervient en cas d'erreur (par exemple, 500/timeout) et préserve l'expérience utilisateur en affichant une version légèrement plus ancienne plutôt que de signaler une erreur fatale.
Voici à quoi ressemble un modèle pratique pour les réponses API publiques, rarement modifiées, ou les plans de site JSON : Cache-Control : public, max-age=600, s-maxage=86400, stale-while-revalidate=30, stale-if-error=600. Ainsi, les navigateurs restent relativement à jour, les CDN sont efficaces et les utilisateurs ne ressentent ni brèves interruptions ni retards dans la mise à jour des pages. J’exclus délibérément les zones critiques ou personnalisées de ces directives souples.
Interaction avec les en-têtes « Expires », « ETag » et « Last-Modified »
J'utilise Expire Tout au plus comme solution de secours, car Cache-Control offre un contrôle plus précis et prévaut lorsque les deux sont définis. Avec ETag, je fournis une empreinte unique de la ressource, ce qui permet au navigateur de déclencher une revalidation simple via If-None-Match. Last-Modified fournit la date et l’heure de la dernière modification et fonctionne en association avec If-Modified-Since. Ces deux méthodes permettent d’économiser de la bande passante, car si le contenu n’a pas changé, le serveur renvoie uniquement le statut 304. Cette interaction maintient les données à proximité de l’utilisateur et réduit Allers-retours.
Est-ce que je vais l'acheter ? Demandes conditionnelles, les coûts par consultation de page diminuent considérablement, sans que je bloque l'affichage de nouveaux contenus. Cette technique complète les valeurs « max-age » restreintes en HTML et garantit des affichages à jour. En revanche, pour les ressources versionnées, je privilégie surtout une durée de validité longue et j'évite les validations inutiles. Je soulage ainsi le Serveur et accélère sensiblement les visites suivantes. Au final, on obtient un parcours de données simplifié, régi par des règles claires.
ETag/Last-Modified en pratique : puissant, faible et évolutif
Dans les configurations distribuées, je veille à ce que les ETags cohérent être calculés à tous les niveaux. Les ETags basés sur les fichiers, qui intègrent les inodes, entraînent des « misses » inutiles dans les clusters. Sous Apache, je configure donc délibérément le calcul des ETags :
# Apache : ETags cohérents pour les fichiers statiques
FileETag MTime Size
# Facultatif : supprimer l'ETag par défaut et définir sa propre logique
#Header unset ETag
Avec Nginx, il suffit souvent de étage activé ; pour les fichiers statiques. Pour dynamique Je génère moi-même les ETags dans les réponses – idéalement sous forme de hachage du corps de la réponse. Si j'ai besoin d'une certaine tolérance pour les modifications mineures (par exemple, des horodatages formatés), j'utilise ETags faibles (W/" ... "), qui permettent de reconnaître comme inchangés des contenus sémantiquement identiques malgré des différences au niveau des octets. À titre de solution de secours, j'utilise l'en-tête « Last-Modified », par exemple à la date de mise à jour de l'enregistrement. Important : ETag et Last-Modified en même temps Il n'y a pas de mal à proposer cette option : c'est le client qui choisit celle qu'il prend en charge.
Utiliser Vary à bon escient : la personnalisation sans chaos au niveau du cache
Vary détermine quels en-têtes de requête sont pris en compte dans la clé du cache. Je garde volontairement l'en-tête « Vary » aussi simple que possible : Accept-Encoding c'est la norme (Gzip/Brotli), Accepter la langue uniquement si je fournis des réponses spécifiques à la langue. De Vary : User-Agent Je le déconseille, car cela fait exploser la taille du cache. Si le contenu dépend des cookies, je préfère privé ou no-store, plutôt que de gérer des règles Vary trop complexes. Pour les ressources, je supprime si possible les cookies superflus afin que public- La mise en cache en périphérie est activée. Si l'authentification via l'API utilise l'en-tête, il est possible de Vary : Autorisation empêcher les caches partagés de mélanger les réponses de différents utilisateurs – mais souvent, dans ce cas, privé le choix le meilleur et le plus clair.
Je vérifie dans DevTools si l'en-tête Vary est défini de manière involontaire (par exemple par des middlewares), car un en-tête Vary „ trop large “ réduit considérablement le taux de réussite. Quelques en-têtes, choisis avec soin, permettent de garder le cache gérable et efficace.
Stratégies par type de contenu
Je fais une distinction stricte entre les contenus statiques et dynamiques afin de pouvoir tirer parti des avantages des deux. Les ressources statiques bénéficient d’une longue durée de vie et d’une identification claire grâce à des noms de fichiers versionnés. Je traite le code HTML et les contenus personnels avec plus de prudence, afin que les modifications soient rapidement disponibles et qu’aucune donnée ne se retrouve dans des caches erronés. Je classe les API en fonction de la fréquence des modifications et du caractère sensible des informations. Cette différenciation apporte Tempo sans compromettre la confidentialité et Correction.
Le tableau suivant résume les réglages pratiques et présente leurs avantages en un coup d'œil.
| Type de ressources | Exemple d'en-tête | Pourquoi | Remarque |
|---|---|---|---|
| CSS/JS/Images/Polices | Contrôle du cache : public, max-age=31536000, immutable | Utilisation prolongée à partir de Cache du navigateur, moins de requêtes | Numéroter les noms de fichiers pour plus de clarté Rolling Mise à jour |
| HTML non personnalisé | Cache-Control : no-cache, must-revalidate (ou max-age=300) | Le niveau d'actualité reste élevé, le volume de données reste faible | Avec ETag/Last-Modified pour une réhabilitation |
| HTML personnalisé | Cache-Control : private, no-cache, must-revalidate | Pas de mise en cache dans les caches partagés | Protéger les données de session et Leaks éviter |
| API statiques / évoluant rarement | Cache-Control : public, max-age=3600 | Un taux de réussite élevé chez de nombreux Clients | Restez flexibles pour des déploiements fréquents |
| API très dynamiques / sensibles | Cache-Control : no-store, max-age=0 | Ne pas enregistrer de données sensibles | Direct Actualité au lieu de « risque » |
Pour les galeries d'images, les gros bundles JS ou les polices web, les valeurs « max-age » élevées sont rapidement rentabilisées. Je veille à ce que les chaînes de version figurent dans les noms de fichiers, afin que les utilisateurs ne voient jamais de bundles obsolètes. Le code HTML reste concis et recourt à la revalidation, afin que même les petites corrections apportées aux textes ou aux prix soient mises en ligne rapidement. Les API se voient attribuer des règles en fonction du profil d'utilisation et des besoins de modification. Cette combinaison garantit une performance durable flotte Nombre de pages vues et économise Bande passante.
SPA vs MPA : HTML d'index court, ressources longues
En ce qui concerne les applications monopages, je considère que la Index HTML d'une durée de vie particulièrement courte (par exemple,. no-cache, must-revalidate ou max-age=60), car elle détermine quelle version des bundles est chargée. En revanche, tous les chunks, polices et images générés sont strictement versionnés et reçoivent public, max-age=31536000, immutable. Je m'assure ainsi qu'une nouvelle version avec un fichier HTML d'index mis à jour fasse immédiatement référence aux nouveaux noms de fichiers corrects, tandis que les utilisateurs existants continuent à utiliser le grands Récupérer les ressources depuis leur cache local.
Les chaînes de requête comme moyen de contourner la mise en cache (?v=123) Je ne l'utilise que lorsque les noms de fichiers ne peuvent pas être modifiés facilement. Il est préférable d'utiliser des noms de fichiers uniques (hachages), car ils permettent une segmentation plus précise des caches et génèrent moins de cas particuliers.
Configuration du serveur : Apache et Nginx
Sous Apache, je définis généralement les en-têtes dans le fichier .htaccess, à condition que le module mod_headers soit actif. J'attribue une durée de validité longue aux ressources statiques, tandis que le code HTML est traité de manière plus stricte. Sous Nginx, je gère cela dans des blocs « location », souvent en association avec la directive « expires » comme solution de repli. Je teste chaque modification avec DevTools dans l’onglet Réseau afin de voir les valeurs réelles des en-têtes. Cela me permet d’éviter les règles erronées qui, sinon, pourraient entraîner de coûteuses Demandes non pertinentes produire.
# Apache (.htaccess)
Header set Cache-Control "public, max-age=31536000, immutable"
Header set Cache-Control "no-cache, must-revalidate"
# Nginx (bloc serveur)
location ~* \.(jpg|jpeg|png|gif|css|js|woff2?)$ {
expires 365d;
add_header Cache-Control "public, immutable";
}
location ~* \.(html)$ {
add_header Cache-Control "no-cache, must-revalidate";
}
Je veille à ce qu'aucune règle concurrente dans les services en amont ne vienne interférer avec ces en-têtes. Un CDN en amont peut, par exemple, définir ses propres TTL, ce que je dois gérer de manière ciblée. Si tous les niveaux sont cohérents, les ressources restent fiables. facile à trouver et cohérentes. En vérifiant soigneusement ces points, on évite de longues sessions de débogage. De petites vérifications permettent d'économiser beaucoup de temps par la suite Temps.
Pratique du CDN et du proxy : configuration de « s-maxage » et des stratégies « Stale »
Pour les caches en périphérie, j'ajoute les éléments suivants à la configuration du serveur : s-maxage ainsi que les directives Stale. Exemple Apache :
# Apache : règles optimisées pour le CDN
Header set Cache-Control "public, max-age=600, s-maxage=86400, stale-while-revalidate=30, stale-if-error=600"
Et dans Nginx :
# Nginx : optimisation du cache partagé
location ~* \.(json|xml|map)$ {
add_header Cache-Control "public, max-age=600, s-maxage=86400, stale-while-revalidate=30, stale-if-error=600";
}
De nombreux CDN respectent directement ces directives. Si ta couche périphérique (Edge Layer) attend ses propres en-têtes (par exemple, des en-têtes « Surrogate »), j'y reproduis la même logique et je sépare clairement la stratégie du navigateur de celle du cache partagé. Grâce au versionnage, j'ai rarement besoin de purges ; lorsque c'est le cas, je les planifie comme une intervention ciblée et de faible ampleur.
Cas particuliers : redirections, pages d'erreur et workflows de formulaires
Redirections : Les réponses 301 sont, selon la spécification, mises en cache. Lorsque je configure des redirections temporaires (302/307), j'attribue des TTL clairs ou je définis délibérément no-store, afin d'éviter que rien ne devienne définitif. Les routes 301 permanentes peuvent avoir une valeur TTL modérée ; les modifications constituent alors une démarche délibérée et coordonnée.
Pages d'erreur : Les réponses 404/410 peuvent être mises en cache pendant une courte durée (par exemple,. max-age=60), afin de réduire la charge générée par les bots. Pour les 500, j'ai, selon l'environnement, stale-if-error active, afin que les utilisateurs préfèrent voir une page plus ancienne mais qui fonctionne plutôt qu'un message d'erreur.
POST/Téléchargement : En règle générale, les réponses aux requêtes POST ne sont pas mises en cache par le navigateur. Pour les exportations de fichiers contenant des données personnelles (par exemple, des factures), j'active systématiquement no-store ainsi qu'une distribution sécurisée (par exemple, Content-Disposition), afin que rien ne soit conservé par inadvertance. En revanche, les téléchargements volumineux non personnalisés (par exemple, les versions) peuvent tirer parti des caches publics pendant une longue période.
Éviter les erreurs typiques
Beaucoup confondent no-cache avec „ pas de cache du tout “, ce qui entraîne une charge inutile. À lire correctement, « no-cache » autorise la mise en cache, mais exige une revalidation. Autre erreur classique : des valeurs « max-age » trop longues sans gestion des versions pour les fichiers CSS ou JS, ce qui entraîne le maintien de fichiers obsolètes. L’absence de séparation entre le HTML et les ressources statiques nuit à la vitesse, car le HTML ne peut généralement pas être mis en cache de manière intensive. Ignorer cela ralentit le Expérience utilisateur de.
Les conflits entre le serveur, le CDN et l'application sapent les effets de la mise en cache sans que l'on s'en aperçoive. Vérifiez donc les écrasements et les niveaux intermédiaires lorsque les en-têtes changent „ comme par magie “. Il est utile ici d'examiner la logique et la chaîne des réponses pour mettre au jour les mauvaises priorités. Une liste de contrôle concise et les pièges typiques liés à Saboter les en-têtes de cache facilitent le contrôle. Des priorités bien définies permettent d'éviter Effets secondaires lors des déploiements.
Rendre mesurable le gain de performance
J'évalue les effets de Cache-Control à l'aide d'indicateurs tels que le TTFB, le LCP et le nombre de Requêtes par page consultée. Un coup d’œil dans les DevTools me permet de voir si les fichiers proviennent du „ cache disque “ ou du „ cache mémoire “. Lighthouse, WebPageTest et d’autres outils similaires indiquent si la mise en cache du navigateur fonctionne correctement. Je mesure les performances avant et après une modification afin de constater clairement les améliorations réelles. Cette rigueur permet d’optimiser compréhensible et ciblé.
Les images volumineuses, les polices Web et les ensembles de fichiers, qui ne sont plus chargés lors des consultations suivantes, ont un impact particulièrement important. Le code HTML reste ainsi proche du serveur, ce qui permet aux utilisateurs d’accéder rapidement aux nouveaux contenus. Les API en tirent un avantage notable lorsque les routes fréquemment utilisées sont associées à un TTL modéré. Les résultats se traduisent par des temps de chargement plus courts, une réduction du volume de données et une charge serveur plus stable. En vérifiant systématiquement ces éléments, on réalise des économies durables Ressources.
Service Worker et cache HTTP : ne pas les faire fonctionner en concurrence
Si j'utilise un Service Worker, sa stratégie doit correspondre à mes en-têtes HTTP. Pour les ressources statiques et versionnées, la stratégie „ cache-first “ avec un TTL long et immuable Excellent. Pour le HTML ou les données API qui changent fréquemment, je privilégie les méthodes „ network-first “ ou „ stale-while-revalidate “, afin que les utilisateurs voient rapidement les réponses et que les mises à jour soient effectuées en temps réel. Important : le Service Worker doit respecter les revalidations (transmettre les en-têtes If-None-Match/If-Modified-Since) au lieu de bloquer artificiellement le contenu.
Je tiens également à préciser clairement que le cache HTTP peut déjà prendre en charge une grande partie du travail ; le Service Worker vient compléter ce fonctionnement, il ne le remplace pas. Cela permet de garder le débogage et l'exploitation sous contrôle.
Comprendre les directives côté requête
Les requêtes peuvent également contrôler la mise en cache. Cache-Control : no-cache à l'adresse suivante : Demande force une revalidation au niveau du serveur, max-age=0 c'est pareil. no-store Dans la requête, cela empêche la mise en cache de la réponse tout au long de la chaîne. Pour les cas hors ligne, il est possible de uniquement si mis en cache être utile : le client n'accepte alors que les réponses provenant du cache. Ce mécanisme est utile dans les applications qui doivent offrir une expérience définie en cas de connexion faible.
Bonnes pratiques pour ton flux de travail
Je commence par faire le point : quels sont les types de fichiers disponibles, lesquels sont personnalisés, lesquels changent rarement ? Ensuite, je définis des règles adaptées à chaque cas afin que les ressources restent longtemps dans le Cache et que le code HTML reste à jour. La suppression des chaînes de version dans les noms de fichiers élimine le risque de bundles obsolètes et permet des temps d'exécution optimisés. Lors de fenêtres de maintenance régulières, je vérifie les en-têtes et les taux de réussite afin d'identifier rapidement les tendances. Cette routine permet de maintenir le site performant et prévisible.
Je documente les configurations de manière concise et claire afin d'éviter que de futures modifications ne causent des dysfonctionnements par inadvertance. Les scripts de déploiement mettent automatiquement à jour les hachages des fichiers, ce qui m'évite d'oublier des étapes. Pour les versions, j’utilise des déploiements à portée limitée afin de tester le comportement en production. Les retours d’expérience issus de la surveillance et des journaux sont directement intégrés dans les règles d’en-tête. Cela permet de garantir que la stratégie reste réaliste et efficace.
Gestion des versions et ressources immuables
J'ajoute des hachages aux noms de fichiers, par exemple app.20260817.js, puis je définis public, max-age=31536000, immuable. Le navigateur sait ainsi que le fichier ne change jamais „ en silence “, ce qui évite les revalidations. Lors de la prochaine mise à jour, le fichier reçoit un nouveau nom, ce qui permet au navigateur de charger précisément la nouvelle version. J’évite ainsi les versions obsolètes après un déploiement. Cette stratégie s’accorde avec de nombreuses Stratégies de gestion du cache des piles les plus diverses.
Pour le HTML, je n'utilise pas « immutable » car la page change souvent et je souhaite une revalidation flexible. Il en va de même pour les réponses API dont les données varient. Les polices et les images volumineuses sont particulièrement concernées, car les utilisateurs les réutilisent plusieurs fois sur différents appareils. Il reste important d'assurer une correspondance sans faille entre les hachages et les versions. La documentation et une Noms éviter les confusions au sein de l'équipe et dans les builds.
Étapes pratiques de test et de débogage
J'ouvre DevTools et j'examine, dans l'onglet « Réseau », les en-têtes de réponse pour vérifier les champs Cache-Control, ETag, Expires et Vary à vérifier. Un nouveau rechargement sans cache (Ctrl+F5) me permet de voir si les règles s'appliquent réellement. Ensuite, je recharge la page normalement et je vérifie quels éléments proviennent du cache. Pour les proxys et les CDN, je vérifie les en-têtes tels que « Age » ou « X-Cache », s’ils sont disponibles. Ces vérifications permettent de détecter les conflits et les erreurs Priorités rapidement sur.
Au niveau du serveur, je compare la configuration et les journaux afin de détecter d'éventuelles anomalies. Une erreur courante : une application ajoute des en-têtes a posteriori et écrase les règles du serveur. Dans les pipelines CI/CD, je teste automatiquement les en-têtes en environnement de préproduction afin d'éviter toute mauvaise surprise sur le système de production. En cas de problème, j'utilise temporairement des TTL courts jusqu'à ce que la cause soit identifiée. Grâce à des tests clairs, je garde Contrôle sur le comportement de mise en cache dans toutes les couches.
Réalité du navigateur : types de mémoire et libération de mémoire
Les navigateurs font la distinction entre le cache mémoire et le cache disque. Les petits fichiers fréquemment utilisés bénéficient du cache mémoire (accès extrêmement rapides), tandis que les ressources volumineuses sont souvent stockées sur le disque dur. Les appareils mobiles vident leur mémoire de manière plus agressive ; c’est pourquoi je ne prévois pas de stratégie reposant exclusivement sur une très longue persistance du navigateur, mais je me protège en mettant en place de bonnes méthodes de revalidation. immuable Cela permet certes d'éviter des réévaluations inutiles, mais uniquement tant que l'entrée n'a pas été supprimée par manque de place.
A emporter
Définir Contrôle du cache Ciblez précisément : des durées de validité longues et des valeurs « immutable » pour les ressources versionnées, des règles prudentes et une revalidation pour le HTML et les contenus personnels. Combinez « max-age » avec « ETag » ou « Last-Modified » afin d’économiser de la bande passante et de garantir l’actualité des contenus. Vérifie tous les niveaux, y compris le CDN, pour t'assurer que les règles ne se contredisent pas. Évite d’utiliser « no-store » par réflexe, et réserve-le aux cas où la protection des données est une priorité absolue. Grâce à une séparation claire par type de contenu, à un versionnage cohérent et à des mesures continues, tu obtiendras des pages nettement plus rapides et tu conserveras la Altesse à propos de ta pratique du géocaching.
