Passer au contenu 
HTTP Conditionnel Les requêtes réduisent les coûts de transmission en permettant au client de ne charger complètement une ressource que si elle a vraiment été modifiée depuis la dernière requête. Je montre comment Validation du cache avec ETag, Last-Modified, If-None-Match, If-Modified-Since et 304 Not Modified fonctionne de manière fiable et que les temps de chargement diminuent sensiblement.
Points centraux
- Validation au lieu du téléchargement complet : 304 permet d'économiser de la bande passante et du temps.
- ETag et Last-Modified travaillent ensemble pour un contrôle propre.
- Contrôle du cache définit la fraîcheur, Expires ne fait que compléter.
- Préconditions comme If-Match sécurisent les écritures.
- Sécurité exige private/no-store pour les contenus sensibles.
Ce que les demandes conditionnelles apportent au quotidien
Je mets Conditionnel Requests pour poser une question claire au serveur : Dois-je vraiment transmettre de nouvelles données ou ma mémoire cache suffit-elle ? Le navigateur ou un proxy envoie des conditions, le serveur vérifie si un fichier a été modifié et répond en cas d'égalité par 304 Not Modified sans Body. Ce modèle permet de maintenir à jour le HTML, le CSS, le JavaScript, les images et les réponses API et de décharger sensiblement l'infrastructure. Pour les assets valables plus longtemps, j'utilise des valeurs max-age longues et je m'assure de l'actualité par la validation. Ceux qui ont les bons Stratégies de contrôle du cache permet de tirer le meilleur parti des caches sans risquer de rendre le contenu obsolète.
En-têtes permettant la validation de la mémoire cache
Pour des résultats fiables Cache-Pour prendre des décisions, le client a besoin de signaux clairs provenant de la réponse. J'utilise Cache-Control pour la fraîcheur et les règles, Expires occasionnellement en complément, ainsi que Last-Modified et ETag pour la validation proprement dite. Last-Modified fournit une date de modification qui peut être rapidement vérifiée, tandis qu'ETag fournit un identifiant de version qui porte également sur les contenus dynamiques. Il est important de noter que no-cache signifie valider avant utilisation et non pas supprimer. Celui qui applique proprement cette sémantique obtient une réduction sensible du trafic de données pour la même actualité des données. Contenu.
Déroulement d'une requête conditionnelle sans détours
Lors du premier appel, le client enregistre le fichier et les valeurs de validation telles que ETag ou Last-Modified dans le cache. Plus tard, la ressource expire ou demande une nouvelle vérification avant d'être utilisée, et le client envoie également If-None-Match ou If-Modified-Since. Le serveur compare les données avec l'état actuel et renvoie soit 200 OK avec un nouveau corps, soit 304 Not Modified sans charge utile. Le client réutilise alors la copie existante et économise la transmission, la charge de travail TLS et le temps. Ce ping-pong paraît anodin, mais la Effet sur la sensation de chargement et la charge du serveur est évidente.
ETag vs. Last-Modified en comparaison directe
J'utilise Dernière modification comme une indication rapide et simple, mais je préfère utiliser des ETags pour un contrôle plus détaillé. L'horodatage peut se heurter à des limites lorsque les intervalles de modification sont très courts ou peut fausser les sorties dynamiques. Je crée des ETags à partir de hachages de fichiers, de versions de bases de données ou de variantes de rendu, ce qui permet de générer un nouvel identifiant à chaque modification de contenu. Les deux mécanismes peuvent être combinés : Le client peut envoyer en parallèle If-None-Match et If-Modified-Since, et le serveur choisit la vérification appropriée. Comment assurer une fiabilité Validation, Le système de gestion des ressources de l'UE, qui s'applique aussi bien aux ressources statiques qu'aux ressources dynamiques.
| Critère | Dernière modification | ETag |
|---|---|---|
| Précision | Résolution en secondes, adaptée aux fichiers | Identification de la version pour chaque modification de contenu |
| Dynamique | Faible en cas de modifications fréquentes non basées sur des fichiers | Fort pour les API et les contenus rendus |
| Charges | Faible, disponible à partir du système de fichiers | Faible à modéré, génération dans App/Proxy |
| Conflits | Différences de montres possibles | Possibilité de tags Weak/Strong mal configurés |
Paramètres corrects pour la mise en cache du navigateur et les API
Pour les actifs statiques, j'utilise de longues max-age et je sécurise par ETag ou par hachage du nom de fichier afin que les mises à jour soient immédiatement reconnues. Je marque souvent les réponses HTML et API avec no-cache, afin que le client valide avant l'utilisation sans devoir tout recharger à chaque fois. Je marque les pages personnalisées avec private, afin que les caches partagés ne transmettent rien de retenu aux autres. Les erreurs sont souvent dues à des directives contradictoires ou à des en-têtes de validation manquants, ce que j'évite avec des règles claires. Si l'on connaît les écueils typiques, on les contourne facilement ; l'article sur les Les pièges des en-têtes dans la mise en cache, J'aime m'en inspirer.
Utiliser efficacement les codes d'état et les conditions
Je classe Codes d'état 200 OK fournit le contenu, 304 Not Modified confirme l'utilisation du cache et 412 Precondition Failed s'interrompt si une condition n'est pas remplie. Pour les opérations d'écriture sécurisées, j'utilise If-Match pour que les mises à jour n'interviennent que si l'ETag correspond à la version attendue. La lecture avec If-None-Match ou If-Modified-Since évite les charges utiles superflues et maintient les clients synchronisés. Il est important d'adopter un comportement cohérent : Le même point final devrait répondre de manière identique pour des conditions préalables identiques. Pour le SEO et les bots, je fais attention à la manière dont les caches et les crawlers interprètent les messages d'état ; un bon aperçu de Codes d'état HTTP et crawling aide à prendre des décisions propres.
Sécurité et confidentialité de la mise en cache
Je traite les contenus sensibles avec no-store et ne leur donne ainsi aucune chance de se retrouver dans le cache du navigateur ou du proxy. Je signale les pages personnalisées avec Cache-Control : private et je vérifie qu'aucune donnée personnelle n'apparaît dans les URL mises en cache à long terme. Je conçois les balises ET de manière neutre, sans permettre d'identifier les comptes d'utilisateurs ou les identifiants internes. Je désactive systématiquement tout stockage intermédiaire pour les vues de connexion et les flux bancaires. En combinant la minimisation des données, des directives appropriées et des en-têtes propres, on réduit les risques et on préserve la sécurité. Confidentialité.
Mise en œuvre : étapes pour le serveur et l'application
Au début, je sépare statique de ressources dynamiques et décide où les longs délais sont utiles et où la validation est prioritaire. Dans Nginx, Apache ou un serveur d'applications, je configure le contrôle du cache et j'active le Last-Modified ainsi que les ETags, en confiant la génération des ETags à l'application pour les points de terminaison dynamiques. Lors du traitement des requêtes entrantes, j'évalue If-None-Match et If-Modified-Since et réponds par 304 si la condition est remplie. Pour les opérations d'écriture, j'utilise If-Match et renvoie 412 en cas d'écart afin d'éviter les écrasements. Il en résulte un comportement cohérent qui utilise efficacement les caches et qui, en même temps Correction de l'entreprise.
Utiliser judicieusement les métriques, les tests et le monitoring
Je vérifie dans le Réseau-Je vérifie dans l'onglet DevTools si les ressources sortent du cache, sont validées ou fraîchement chargées. J'observe l'état, les valeurs d'âge, les balises ET et la taille de la réponse transmise. Sous charge, je mesure la latence, le volume de transfert et l'unité centrale du serveur afin de voir l'effet réel des réponses 304. Les journaux du reverse proxy montrent si les caches partagés jouent leur rôle et combien de validations ont réussi. Avec ces données, j'ajuste le max-age, les directives de contrôle du cache et les stratégies d'ETag jusqu'à ce que les temps de réponse et les performances des serveurs soient optimisés. Taux de réussite voter.
Performance de l'hébergement : pourquoi les requêtes conditionnelles permettent d'économiser de l'argent
Tout 304-La réponse en cache permet d'économiser de la bande passante, de réduire l'overhead TLS et de raccourcir le temps de réponse, ce qui est particulièrement important en cas de nombreuses demandes similaires. Dans les configurations d'hébergement avec proxys inversés, load balancers et CDN, je déploie le plus grand effet si j'autorise clairement les caches partagés ou si je les exclue de manière ciblée. Moins de transfert signifie souvent aussi moins de coûts de trafic en euros et plus de réserves pour les véritables pics de charge. En outre, l'expérience utilisateur s'améliore car les appels de page répétés et les API polls réagissent plus rapidement. J'exploite ainsi le potentiel de performance que les seules mises à niveau matérielles ne peuvent fournir, et j'utilise les ressources existantes. Infrastructure mieux
Erreurs fréquentes et solutions pragmatiques
contradictoire En-tête comme no-cache, associées à des dates d'expiration très éloignées dans le temps, embrouillent les caches ; je définis des règles claires sans doublons. Les ETags manquants pour les points de terminaison dynamiques entraînent des téléchargements complets inutiles ; j'ajoute un identifiant fiable et j'évalue le match if-none. Des valeurs max-age trop courtes gaspillent le potentiel des fichiers rarement modifiés ; j'étire les délais et les sécurise malgré tout avec une validation. Une mise en cache agressive du HTML retarde les modifications visibles ; je combine no-cache avec ETag et maintiens les contenus à jour. En prenant des décisions claires en matière de fraîcheur, de validation et de validité, je résous ces écueils et renforce les Planification.
Utiliser Vary proprement et contrôler les représentations
Pour que les requêtes conditionnelles fonctionnent en toute sécurité dans les caches partagés, je veille à ce que l'utilisation de Vary. L'en-tête définit les en-têtes de requête qui influencent la représentation. Des exemples typiques sont Accept-Encoding (gzip, br), Accepter la langue et Accept. Lorsque je fournis un contenu par langue, je définis Vary : Accept-Language pour éviter qu'un proxy ne partage la version allemande en réponse à une requête française. Pour les contenus personnalisés, je renonce délibérément à Vary : Cookie et j'utilise à la place Contrôle du cache : private, Je ne veux pas d'une explosion incontrôlable des clés de cache. Pour les ressources qui ne sont livrées qu'avec une autorisation valable, j'utilise soit private, soit j'assure une séparation claire avec Vary : Authorization ou Vary sur les en-têtes pertinents. La cohérence est importante : le jeu de dimensions Vary choisi doit rester stable, sinon le taux d'utilisation du cache et les avantages de la validation s'effondrent parce que de nouvelles variantes sont constamment créées.
ETags forts vs. faibles, compression et égalité des octets
ETags forts caractérisent des représentations identiques octet par octet et permettent une validation précise, également en combinaison avec des Range Requests. ETags faibles (W/...) signalent uniquement l'égalité de contenu, pas nécessairement des octets identiques. Dans la pratique, j'utilise des ETags forts lorsque je peux générer un identifiant unique par représentation (y compris la compression). Dès qu'un reverse proxy utilise gzip ou brotli à la volée, j'adapte la génération d'ETags ou je passe à des ETags faibles, afin que le serveur et le client ne considèrent pas à tort des octets différents comme identiques. Une variante robuste consiste à générer l'ETag à partir des octets finaux de la réponse livrée et, en même temps Vary : Accept-encodage pour chaque fichier. Cela permet de garantir que „gzip“ et „br“ reçoivent chacun leur propre balise valide. Lorsque je ne peux pas garantir l'égalité des octets (par exemple des horodatages différents dans le HTML), je choisis des balises ET faibles qui permettent malgré tout d'obtenir des réponses 304 fiables, tant que la signification de la page n'a pas changé.
Contrôle du cache en réglage fin : s-maxage, must-revalidate, stale-while-revalidate
En plus de max-age j'utilise de manière ciblée des directives plus fines. s-maxage s'adresse exclusivement Caches partagés (CDN, proxies) et me permet d'y mettre en cache de manière plus agressive que dans le navigateur. must-revalidate oblige les clients à ne pas utiliser les contenus expirés de manière heuristique, mais à toujours les valider - ce qui est utile pour les données critiques. proxy-revalidate adresse cette obligation spécifiquement aux caches partagés. Avec stale-while-revalidate je permets de livrer brièvement une copie légèrement obsolète pendant que la validation est en cours en arrière-plan ; les utilisateurs voient immédiatement quelque chose et la demande suivante bénéficie de métadonnées fraîches. stale-if-error je le tiens à disposition comme filet de sécurité : Si Origin tombe en panne ou fournit des erreurs, le cache peut fournir la dernière copie connue pendant une durée définie. Pour les actifs hachés à la construction, je combine max-age long avec immuable, car le nom de fichier change avec le contenu et les validations intermédiaires sont inutiles. Pour le HTML et les API, le no-cache plus le validateur reste l'étalon-or pour garantir l'actualité tout en économisant de la bande passante.
Autres conditions et méthodes : HEAD, Range et conflits d'écriture
Les requêtes conditionnelles ne se limitent pas à GET. Un HEAD-Request ne fournit que des en-têtes et convient parfaitement aux validations rapides sans corps. Pour les gros fichiers, je mets gamme-avec If-Range je m'assure que les sous-domaines ne sont envoyés que si la ressource correspond toujours à la version attendue - sinon je réponds avec 200 et le corps complet. Pour les opérations d'écriture, j'assure la cohérence avec If-Match ab : PUT, PATCH ou DELETE n'ont d'effet que si l'ETag du client correspond à la version actuelle ; sinon, je réponds avec 412 Precondition Failed. Là où je veux forcer des pré-conditions, par exemple pour des ressources sujettes à des conflits, j'utilise 428 Precondition Required pour inciter les clients à utiliser If-Match. Je choisis délibérément entre 409 Conflict et 412 : 412 signale les préconditions violées, 409 souligne les conflits de contenu (par exemple les règles de la logique commerciale). Cette clarté facilite les implémentations de clients et évite les écrasements aveugles.
Personnalisation, cookies et protection des données dans la pratique
Pour les pages personnalisées, je marque les réponses avec privé ou no-store. J'évite de coder les états des utilisateurs dans des ETags, car de tels ETags „per-user“ peuvent devenir involontairement des marqueurs de suivi. Au lieu de cela, je fais une distinction stricte entre les représentations publiques et privées. Je ne place des cookies dans la clé de cache (Vary : cookie) que si c'est absolument nécessaire, car ils augmentent la diversité des variantes et réduisent dramatiquement le taux de réussite. Pour les réponses API autorisées, je m'en tiens aux règles suivantes Contrôle du cache : private et, si nécessaire, à Vary sur le format d'en-tête Authorization. Je m'assure ainsi que les caches partagés ne partagent pas par inadvertance des réponses confidentielles. Dans les applications à contenu mixte (base publique, sous-parties personnalisées), j'utilise une mise en cache fragmentée ou Edge-ESI/SSI, tandis que les parties critiques restent privées. Le résultat est une protection des données sans baisse de performance.
Exploitation : CDN, substituts et invalidations
Dans les configurations CDN, je combine s-maxage avec des validateurs clairs et utilise - si disponible - des directives spécifiques au surrogate pour contrôler les caches Edge séparément du navigateur. La revalidation réduit la charge à l'origine, mais une invalidation sévère est parfois nécessaire (par ex. correction de sécurité). Je prévois alors deux méthodes : Cache-busting sur les hachages de noms de fichiers pour les actifs statiques et Purge/invalidation pour le HTML et les API. J'évite ainsi les „tempêtes de purge“ tout en maintenant un temps de réponse court. Il est également important d'avoir une clé de cache cohérente dans le CDN (y compris l'hôte, le chemin, les paramètres de requête et les en-têtes Vary pertinents). Pour les paramètres de requête, je fais sciemment la distinction entre les paramètres sémantiques (par ex. ?lang=) et les paramètres de suivi ; j'ignore ces derniers dans la clé de cache afin d'éviter la fragmentation. Ainsi, la chaîne du cache du navigateur, du proxy intermédiaire et du CDN reste transparente et prévisible.
304 en détail : Mettre à jour correctement les en-têtes et les métadonnées
Il y a aussi une 304-La réponse porte des métadonnées importantes. Je retransmets Date, Cache-Control, ETag/Last-Modified et - si pertinent - Expires et Vary, afin que le client puisse mettre à jour ses entrées de cache. Le type de contenu et l'encodage du contenu ne doivent pas nécessairement être répétés, mais peuvent contribuer à la clarté. Il est important que 304 ne contienne pas de charge utile de corps et que j'envoie des validateurs cohérents : Un changement d'ETag dans la 304 sans modification de la représentation entraîne une confusion. Si des directives sont adaptées (par ex. max-age plus long), le client peut reprendre les métadonnées sans devoir recharger le body - un petit levier avec un grand effet sur la performance perçue.
Stratégies de test et de débogage pour une validation propre
Dans les DevTools, je contrôle de manière ciblée les points suivants : à partir du cache disque vs. de la mémoire cache vs. revalidated; l'état 200/304 ; les en-têtes Age dans les réponses des caches partagés ; la cohérence ETag/dernier modifié ainsi que l'effet de Vary. Pour des tests reproductibles, je désactive temporairement le cache du navigateur ou j'utilise un mode privé. Du côté du serveur, j'évalue les logs concernant le rapport 200/304, la taille moyenne des réponses et l'utilisation du CPU. Les signaux d'alarme sont par exemple un grand nombre de réponses 200 pour des ressources avec des intervalles de modification courts (validateurs manquants), des boucles de revalidation (temps divergents/dérive d'horloge) ou un nombre inhabituel de variantes par URL (vary excessif). Grâce aux tests de charge, je vérifie comment s-maxage, stale-while-revalidate et If-None-Match se comportent sous pression - et j'ajuste les directives jusqu'à ce que le débit et la latence soient compatibles.
Edge Cases et par défaut robustes
Toutes les ressources n'ont pas de règles de modification claires. Pour les plans de site générés, les flux ou les tableaux de bord, je définis des valeurs par défaut prudentes : no-cache plus ETag/Last-Modified. En cas d'horloges instables entre les systèmes en amont, j'évite les comparaisons rigides des secondes et je préfère les ETags qui sont indépendants des horodatages. Si la compression est variable (différents niveaux de gzip), j'intègre le résultat de la compression dans la génération d'ETags ou je passe à des ETags faibles. Et si les clients demandent sans validateurs, je donne des signaux clairs : Soit une fraîcheur claire (max-age/immutable), soit une validation claire (no-cache + ETag). Ces robustes par défaut veillent à ce que même les clients incomplets ou défectueux ne déclenchent pas de pics de charge intempestifs.
Bref résumé
Relier les requêtes conditionnelles Tempo et l'actualité, en ne demandant aux clients des ressources complètes que si le contenu a été modifié. J'utilise le contrôle de cache pour la fraîcheur, je combine Last-Modified et ETag pour des vérifications fiables et je réponds systématiquement par 304 si les conditions sont remplies. J'isole les contenus personnalisés et confidentiels avec private ou no-store, afin qu'aucune donnée ne se retrouve dans des caches partagés. Les mesures dans DevTools, les logs et les métriques me montrent où je peux étirer les délais ou affûter la logique de validation. En combinant ces éléments, on obtient des pages plus rapides, des serveurs moins sollicités et une meilleure qualité de service. plus rond Expérience utilisateur sans gaspillage de données.
