Comprendre la mise en cache conditionnelle HTTP avec ETag et Last-Modified

La mise en cache HTTP permet de gagner du temps et d'économiser des données, car je ne recharge les ressources que lorsqu'elles ont réellement changé. Via ETag et Dernière modification Je vérifie, à l'aide d'une requête conditionnelle, si le serveur répond par un code 304 Not Modified, ce qui réduit considérablement le volume de données transférées et la charge du serveur.

Points centraux

Les points clés suivants montrent ce à quoi je fais attention lors de la mise en cache conditionnelle avec ETag et Dernière modification huit.

• Moins de trafic: Les fichiers inchangés renvoient un code 304, et non l'intégralité du corps de la requête, ce qui réduit sensiblement le volume de données et la latence.
• Meilleure performance: Des temps d'attente plus courts améliorent l'expérience utilisateur et les Core Web Vitals, ce qui SEO aide.
• Deux mécanismes: Les en-têtes Last-Modified/If-Modified-Since et ETag/If-None-Match permettent de valider le cache de manière fiable.
• Contrôle du cache: Les directives contrôlent la durée de validité, la mise à jour et le comportement dans les caches intermédiaires.
• Combinaison: Ces deux méthodes combinées offrent une grande précision et des solutions de secours simples.

Je commence par vérifier quelles ressources changent vraiment souvent et lesquelles changent rarement. Pour les fichiers rarement modifiés, je définis un Dernière modification- et j'ajoute un ETag. Pour les réponses dynamiques, je préfère utiliser le ETag, car toute modification du contenu est immédiatement perceptible. Cela me permet de soulager les serveurs, de réduire les temps de latence et d'offrir des pages très rapides aux visiteurs réguliers. Cette stratégie renforce la Core Web Vitals et donc, indirectement, la visibilité.

Mise en cache conditionnelle HTTP : comment vérifier la validité

Lors d'une nouvelle requête, le client envoie, en plus de la requête GET, des en-têtes supplémentaires que j'analyse côté serveur. Si la ressource porte le même ETag Si le contenu correspond à celui du cache (If-None-Match), je renvoie un 304 Not Modified sans corps. Si l'horodatage n'a pas changé (If-Modified-Since), le serveur répond également par un 304. Si le jour ou la date ne correspondent plus, j'envoie un 200 OK avec un nouveau contenu et une version mise à jour Dernière modification et ETag. Cela me permet d'économiser de la bande passante, de maintenir le cache à jour et d'assurer des temps de chargement nettement plus rapides.

« Last-Modified » et « If-Modified-Since » au quotidien

L'en-tête Dernière modification Je me base sur la date et l'heure réelles de modification du fichier, provenant par exemple du système de fichiers. Si une requête est ensuite envoyée avec l'en-tête « If-Modified-Since » et que la ressource n'a pas changé depuis, je renvoie un code 304. Cette méthode est simple, facile à comprendre et idéale pour les ressources statiques telles que les fichiers CSS, JS ou les images. Elle présente toutefois des limites liées à la résolution en secondes des horodatages HTTP et aux situations où le contenu change de manière logique sans qu’il existe de date de modification précise du fichier. Là où Last-Modified atteint ses limites, un ETag le contrôle.

ETag et If-None-Match dans les systèmes dynamiques

A ETag Je le génère sous forme de hachage, d'identifiant de version ou à partir d'une colonne de base de données qui signale les changements d'état. Lors d'un nouvel accès, le navigateur envoie un If-None-Match ; je compare le tag à ma valeur actuelle et je réponds en conséquence avec un 304 ou un 200. Cette comparaison détecte toute modification significative du contenu sans s'appuyer sur les horodatages des fichiers. Cela fournit des résultats très précis, en particulier pour les API, les pages composites ou les fragments personnalisés. Il est important de veiller à ce que les ETags restent cohérents dans les environnements en cluster, afin qu’aucun serveur n’en attribue accidentellement un autre Jour produit.

Bien combiner les en-têtes Cache-Control

Avec Contrôle du cache Je définis la durée pendant laquelle le contenu est considéré comme à jour sans vérification et à quel moment le navigateur procède à une revalidation. Je définis des valeurs max-age adaptées en fonction de la fréquence des modifications et j'utilise must-revalidate lorsque des données obsolètes pourraient avoir des conséquences critiques. Une longue durée de validité convient aux fichiers versionnés, tandis que les réponses fréquemment modifiées ont une durée de vie plus courte et peuvent ensuite être vérifiées de manière fiable via l'ETag ou la date. Je combine ainsi des temps de réponse courts avec une actualité correcte. Si vous souhaitez approfondir le sujet, vous trouverez de nombreux exemples sous Stratégies de gestion du cache, que j'utilise dans mon cabinet.

Déroulement étape par étape d'une requête GET conditionnelle

Lors de la première requête, le serveur renvoie un code 200 OK avec l'en-tête Cache-Control, Dernière modification et l'ETag, le navigateur enregistre tout. Lors de la visite suivante, c'est l'ancienneté dans le cache qui détermine si une revalidation est nécessaire. Si c'est le cas, le navigateur envoie une requête avec les en-têtes If-None-Match et/ou If-Modified-Since. Si les valeurs correspondent à l'état actuel, j'envoie un 304 Not Modified, et le client continue d'utiliser son cache. Si elles ne correspondent plus, un 200 OK est renvoyé avec un nouveau corps et des données mises à jour données de validation.

Comparaison : ETag et Last-Modified

Ces deux méthodes me permettent d'exercer un contrôle, mais elles diffèrent en termes d'effort, de précision et d'adéquation. Dernière modification se distingue par sa simplicité de mise en œuvre et sa sémantique claire, à condition que je dispose d'horodatages précis. L'ETag reflète le contenu avec une grande précision, mais sa génération nécessite un peu de logique. Dans de nombreuses configurations, je combine les deux et bénéficie ainsi à la fois de la simplicité et d'une reconnaissance précise. Le tableau suivant résume les caractéristiques typiques et aide à prendre une décision.

Aspect	Dernière modification	ETag	Remarque
Identité	Date et heure de la dernière modification	Hachage du contenu ou identifiant de version	Temps vs. identifiant basé sur le contenu
Détection des modifications	Résolution à la seconde près, indirecte	Directement axé sur le contenu	ETag détecte les plus infimes Différences
mise en œuvre	Très léger, le système de fichiers suffit	Nécessite une génération et une cohérence	Les clusters ont besoin de la même chose ETags
Utilisation	Ressources statiques	Réponses dynamiques	Cette combinaison couvre de nombreux cas à partir de
Réponses	304 sans modification de l'horodatage	304 pour une balise identique	200 en cas de modifications avec un nouveau Valeur

En pratique : diffusion efficace des ressources statiques

Les fichiers statiques tels que les fichiers CSS, JS et les images changent rarement et se prêtent bien à une longue max-age-Durées. Pour les fichiers versionnés, je définis des durées élevées pouvant aller jusqu'à un an et je les marque comme immuables afin que le navigateur les charge sans demander de confirmation. Pour les ressources non versionnées, je choisis des délais plus courts et je m'appuie sur la revalidation via ETag et Last-Modified. Cela me permet d'éviter les contenus obsolètes et de maintenir un trafic faible. Je veille à ne pas Saboter les en-têtes de cache En laissant cela tel quel, j'obtiens un taux de réussite élevé dans le cache.

En pratique : API et pages dynamiques

En matière d'API, je mise généralement sur ETags, que je génère à partir du résultat sérialisé ou d'une colonne de version. Si l'enregistrement change, je génère une nouvelle balise, ce que les clients détectent immédiatement. Pour les contenus dont l'horodatage est incertain, je renonce souvent à utiliser « Last-Modified » afin de ne pas donner une fausse impression de fraîcheur. En complément, je contrôle la durée de vie via « Cache-Control » et impose une revalidation après expiration. Je maintiens ainsi la fraîcheur des données de manière fiable, sans alourdir inutilement les réponses.

Tests et surveillance du taux de réussite du cache

Je vérifie les en-têtes tels que ETag, Last-Modified, If-None-Match et If-Modified-Since dans les outils de développement. Je prête alors attention aux codes de réponse, en particulier 304 par rapport à 200, afin d'évaluer l'efficacité de ma revalidation. Si le code 304 est rare, j'ajuste le Cache-Control, les durées de validité et la génération d'ETag. Les logs et les métriques m'indiquent quels chemins génèrent des réponses inutilement volumineuses. Pour des améliorations groupées, j'utilise volontiers un Pack « Requêtes conditionnelles », qui regroupe la configuration et les tests.

Architecture d'hébergement et pièges ETag

Dans les configurations multi-serveurs, il faut un ETag être indépendant de l'instance, sinon la reconnaissance échoue. Je veille à ce que tous les nœuds utilisent la même logique et la même clé pour la génération. Les proxys inversés ou les CDN ne doivent pas modifier les ETags et doivent transmettre correctement les en-têtes de condition. Lors de déploiements avec des empreintes d'actifs, j'évite le recalcul des ETags côté serveur si le fichier possède déjà une URL versionnée. Des règles uniformes empêchent les réponses incohérentes et maintiennent un taux de réussite élevé du cache.

Actualisation vs validation : utiliser les directives avec précision

Je fais clairement la distinction entre fraîcheur (pendant combien de temps un cache peut-il utiliser une copie sans demander de confirmation ?) et Validation (comment vérifier si elle est toujours valable ?). À propos de Contrôle du cache Je contrôle les deux avec une grande précision : max-age définit la durée de vie chez le client, s-maxage pour les caches partagés tels que les proxys. public permet la mise en cache dans des caches partagés, privé il le limite au navigateur final. must-revalidate oblige à demander des précisions à l'expiration, tandis que immuable évite les revalidations inutiles pour les ressources versionnées. no-cache n'interdit pas la mise en cache, mais exige systématiquement une revalidation ; no-store interdit en revanche totalement l'enregistrement. Les anciens ExpireJe n'utilise les en-têtes - que comme solution de secours ; je privilégie systématiquement l'utilisation de Cache-Control. Et si je veux pallier les pannes, stale-while-revalidate et stale-if-error, afin de continuer à diffuser les contenus dont la validité a expiré récemment, pendant que je procède à des mises à jour en arrière-plan ou que je contourne des erreurs.

ETags forts et faibles, compression et variantes

Je fais délibérément la distinction entre les validateurs forts et les validateurs faibles. ETags forts identifient exactement la même représentation, octet par octet – idéal si je veux aussi Demandes de gamme souhaite exploiter efficacement. ETags faibles (Préfixe W/) suffisent lorsque l'équivalence sémantique est suffisante, par exemple dans le cas de modifications de format mineures et sans incidence. Ce qui importe, c'est la manière de traiter Compression: Si je fournis à la fois du contenu encodé en gzip et en Brotli, un seul ETag ne doit pas s'appliquer à toutes les variantes. Soit je génère l'ETag à partir de la version non compressée, soit j'ajoute en plus un Vary : Accept-encodage, ou bien je génère des ETags cohérents mais différents pour chaque variante. Cela me permet d'éviter les résultats erronés et les réponses 200 qui devraient en réalité être des 304. Dans le cas de If-Range Je combine les requêtes de mise à jour avec un validateur : si l'ETag ou la date correspondent, je renvoie un statut 206 (Partial Content) ; sinon, je renvoie un statut 200 avec un corps complet, afin que le client dispose d'une base cohérente.

Maîtriser parfaitement les en-têtes Vary et la négociation de contenu

Chaque fois que le serveur fournit différentes représentations en fonction de la requête, je définis Vary correct. Les candidats typiques sont Accept-Encoding (compression), Accepter la langue (localisation) ou des indicateurs de fonctionnalité spécifiques. J'évite d'utiliser des en-têtes volatiles tels que Agent utilisateur ou même Cookie de varier, car cela réduit considérablement le taux de réussite du cache. Lorsque la personnalisation est nécessaire, je marque les réponses comme privé ou no-store et les distingue clairement des ressources pouvant être mises en cache publiquement. Important : les variantes concernent également les ETags – chaque variante doit disposer de son propre validateur cohérent. Je m'assure ainsi que les navigateurs, les proxys et les CDN appliquent la même logique et qu'aucune variante ne soit confondue par inadvertance avec une autre.

Requêtes conditionnelles au-delà de GET

Les requêtes conditionnelles ne s'appliquent pas uniquement à la lecture. Pour les méthodes d'écriture, j'utilise If-Match ou If-Unmodified-Sinceafin de mises à jour manquantes pour éviter cela. Si, lors d'une requête PUT ou DELETE, le client fournit l'ETag le plus récent via If-Match si c'est le cas, je n'effectue la modification que si l'état du serveur est toujours identique – sinon, je réponds par 412 Échec de la condition préalable. Pour contrôler les clients, le serveur peut également 428 Condition préalable requise mettre en place. Pour des tests rapides sans body, j'utilise HEAD, qui me renvoie les mêmes en-têtes qu'une requête GET ; c'est idéal quand je veux tester des métadonnées. Et avec 304- Dans les réponses, je renvoie tous les en-têtes pertinents pour la mise en cache (Cache-Control, ETag, Expires, Last-Modified) afin que le client actualise ses métadonnées sans transmettre le corps du message.

Sécurité, protection des données et conformité

Je ne stocke pas de données à caractère personnel ou de contenu sensible dans le cache public. À cet égard, j'applique Contrôle du cache : private ou no-store, afin qu'aucun navigateur ni aucune instance ne conserve le contenu. Attention aux comptes utilisateurs et aux tableaux de bord : les réponses contenant Cookie de configuration ou Autorisation ne doivent pas être accidentellement accessibles en cache. Les ETags eux-mêmes peuvent être utilisés à des fins de suivi s'ils restent stables pendant une longue période. Je remédie à cela en n'utilisant activement les validateurs que là où la mise en cache est souhaitée, et en les désactivant pour les routes spécifiques à l'utilisateur ou en limitant leur durée de vie. Je concilie ainsi performances et exigences en matière de protection des données.

Détails de mise en œuvre et impact sur les performances

La création d'une balise ETag ne doit pas coûter plus cher que les avantages qu'elle procure. Pour les fichiers volumineux ou les rendus coûteux, j'enregistre la balise avec des métadonnées (somme de contrôle du fichier, hachage de la version, base de données-version de la ligne) et ne le récapitule pas à chaque requête. Pour les pages composites, une Stratégie de gestion des versions: Je construis l'ETag à partir d'ETags partiels stables (par exemple, un modèle, un fragment de données, une configuration), de sorte que de petites modifications donnent lieu à une nouvelle valeur ciblée mais reproductible. Dans les clusters, je synchronise la logique de génération dans une bibliothèque commune et je la vérifie en CI afin qu'aucune instance ne s'écarte. Pour les blobs extrêmement volumineux, j'utilise des sommes de contrôle rapides (CRC64) ou j'enregistre des hachages de build au lieu de hacher le corps à la volée. Lorsque l'égalité absolue des octets n'est pas nécessaire, il suffit de ETags faibles comme un compromis pragmatique.

Erreurs fréquentes et comment les éviter

• ETags aléatoires: Si les balises sont régénérées à chaque requête, toute revalidation perd tout son intérêt. Je veille à ce que les valeurs soient déterministes et ne changent qu'en cas de modification réelle.
• Mauvais mélange des directives: no-store L'utilisation de l'ETag ne sert à rien : le navigateur ne met de toute façon pas en cache. Je choisis des combinaisons cohérentes pour obtenir le comportement souhaité.
• Vary excessif: Les variations sur les cookies ou l'agent utilisateur vident le cache. Je limite l'utilisation de Vary aux véritables changements de représentation.
• Pièges de compression: Un ETag commun pour gzip et br entraîne des erreurs de reconnaissance. J'associe correctement les ETags à la variante spécifique et je définis correctement l'en-tête Vary.
• Décalage horaire: Des horloges de serveur imprécises faussent la date « Last-Modified ». Je synchronise les sources de temps afin que l'en-tête « If-Modified-Since » fonctionne correctement.
• Confusion avec « no-cache »: Beaucoup interprètent cela comme „ ne pas mettre en cache “. Cela signifie en réalité „ toujours revalider “. Pour une interdiction effective, j'utilise no-store.

Dépannage, indicateurs et flux de travail

Pour le dépannage, je commence par l'onglet Réseau : c'est bon Contrôle du cache? Intervient lors de la rééducation 304 au lieu de 200 ? Ça me va ETag et Dernière modification entre la demande et la réponse ? Je vérifie Vary, pour vérifier si les variantes sont correctement détectées. Dans les journaux, je fais afficher Réussite/Échec- Afficher les taux de 304 et la taille moyenne des réponses par chemin. Lorsque le taux de 304 augmente, le volume de données et le TTFB diminuent généralement de manière notable. Lors des tests de charge, je simule des requêtes répétitives afin de mesurer les coûts de revalidation plutôt que les coûts de transfert. En cas d'anomalies, j'élimine progressivement les facteurs perturbateurs : Set-Cookie, règles Vary trop strictes, en-têtes contradictoires comme Pragma. Je repère ainsi rapidement le goulot d'étranglement qui fait baisser le taux de réussite.

Les Service Workers comme couche de mise en cache complémentaire

Si j'utilise un Service Worker, je l'utilise comme une couche supplémentaire, et non comme une couche contradictoire. Je lui confie les mêmes Contrôle du cache- Respecter les signaux et combiner des stratégies telles que stale-while-revalidate avec une validation HTTP via ETag et Last-Modified. En mode hors ligne, le worker peut fournir des ressources légèrement obsolètes et les revalider en arrière-plan. Il est toutefois essentiel qu'il transmette correctement les en-têtes de condition, sinon je perds les avantages du 304 sur la liaison réseau. Ainsi, les scénarios PWA bénéficient également d'une mise en cache HTTP propre, au lieu de contourner ses mécanismes.

Impact sur le référencement naturel et Core Web Vitals

Améliorer les réponses rapides UX et les signaux des utilisateurs, ce qui favorise le référencement. Les visiteurs réguliers en bénéficient tout particulièrement, car leur navigateur récupère de nombreux fichiers directement depuis le cache ou via une réponse 304. Cette latence réduite a un effet positif sur les indicateurs FCP, LCP et TTFB, que je réduis grâce à une revalidation ciblée. De plus, le serveur économise du temps de calcul, que je peux utiliser pour les pics de charge ou les requêtes complexes. Je maintiens ainsi la performance tout en garantissant que le contenu s'affiche correctement et rapidement.

Résumé : mon plan d'action

Je mise sur une politique claire Combinaison à partir des en-têtes Cache-Control, Last-Modified et ETag. Pour les ressources statiques, j'opte pour des durées de vie longues et je m'assure de la revalidation lorsque les fichiers ne sont pas versionnés. Pour les réponses dynamiques, je génère des ETags fiables et assure la cohérence des clusters. Je vérifie ensuite à l'aide d'outils, de métriques et de journaux si les codes 304 apparaissent suffisamment souvent et j'ajuste les paramètres en conséquence. Je garantis ainsi une diffusion rapide, une charge réduite et une meilleure expérience utilisateur grâce à une gestion efficace Mise en cache HTTP.