La directive HTTP Cache-Control stale-while-revalidate permet aux navigateurs de diffuser immédiatement du contenu mis en cache tout en le revaluant de manière asynchrone en arrière-plan. Cette fonctionnalité est une méthode principale pour améliorer les performances du site en réduisant le temps que les passent les utilisateurs à attendre le téléchargement de contenu frais depuis le serveur. En définissant cet en-tête, vous indiquez au navigateur d’afficher une version existante et mise en cache d’une page ou d’une ressource si elle se trouve toujours dans la fenêtre obsolète, tandis que le navigateur vérifie simultanément sur le serveur si une version plus récente existe.
Pourquoi devriez-vous utiliser stale-while-revalidate ?
Les performances web reposent largement sur la minimisation de la latence pour les visiteurs récurrents. Dans un compte type, un utilisateur peut visiter une page de destination plusieurs fois par jour. Si vos en-têtes de cache sont trop stricts, le navigateur demande constamment une confirmation au serveur, ce qui ralentit l’expérience. L’utilisation de stale-while-revalidate équilibre efficacement le besoin de données fraîches et la vitesse du cache local. Elle maintient l’interface utilisateur réactive en évitant d’avoir à attendre une réponse réseau pendant la phase de rendu initial d’une ressource.
Cette directive est particulièrement utile pour les ressources qui ne nécessitent pas une précision parfaite à la milliseconde près. Par exemple, considérez une page de tarification de produits ou un flux de blog qui se met à jour plusieurs fois par jour. En utilisant cette directive, vous permettez au navigateur d’afficher immédiatement le contenu mis en cache. Si ce contenu est plus ancien que votre max-age spécifié mais se trouve dans la fenêtre stale-while-revalidate, le navigateur récupère la mise à jour en arrière-plan. L’utilisateur voit la page instantanément, et lors de sa prochaine visite, il verra les nouvelles données.
Quelle est la syntaxe de la directive ?
La directive est implémentée via l’en-tête HTTP Cache-Control. Vous définissez un max-age pour indiquer au navigateur pendant combien de temps le contenu est considéré comme frais, puis vous ajoutez le paramètre stale-while-revalidate. Par exemple, une configuration courante ressemble à ceci : Cache-Control: max-age=60, stale-while-revalidate=3600. Cette configuration indique au navigateur que la ressource est fraîche pendant 60 secondes. Si une requête se produit après 60 secondes mais avant 3600 secondes, le navigateur diffuse le contenu obsolète et lance une récupération en arrière-plan.
- max-age : Définit la durée pendant laquelle le contenu est considéré comme frais.
- stale-while-revalidate : Définit la fenêtre de temps après l’expiration de max-age pendant laquelle le navigateur peut utiliser du contenu obsolète tout en récupérant une mise à jour.
- Privé ou Public : Ces en-têtes peuvent être combinés avec des directives privées ou publiques pour contrôler où le contenu est stocké, comme dans le cache du navigateur par rapport à un cache CDN partagé.
Comment configurer votre serveur pour cet en-tête
Pour implémenter cela sur votre serveur, vous devez modifier les en-têtes de réponse envoyés au client. Si vous utilisez Nginx, vous ajusteriez votre fichier de configuration dans le bloc location pour vos ressources statiques ou vos points de terminaison d’API. Une ligne d’exemple serait : add_header Cache-Control ‘public, max-age=86400, stale-while-revalidate=86400’;. Cette approche garantit que votre serveur communique clairement la stratégie de mise en cache à chaque navigateur qui demande vos ressources, ce qui conduit à une expérience plus cohérente pour vos utilisateurs finaux.
Pour les développeurs utilisant Apache, vous pouvez utiliser le module mod_headers pour obtenir le même résultat. Vous ajouteriez une ligne à votre fichier .htaccess comme : Header set Cache-Control ‘max-age=604800, stale-while-revalidate=86400’. Une fois ces modifications déployées, il est recommandé de vérifier les en-têtes de réponse dans les outils de développement du navigateur. Ouvrez l’onglet Réseau, actualisez la page et sélectionnez la ressource pour confirmer que la valeur de Cache-Control correspond à la configuration souhaitée.
Comparaison des stratégies de mise en cache
| Stratégie | Vitesse immédiate | Fraîcheur |
|---|---|---|
| Cache standard | Élevée | Faible |
| No-Cache | Faible | Élevée |
| Stale-While-Revalidate | Élevée | Élevée |
Comment Alien Road applique stale-while-revalidate
Chez Alien Road, nous examinons souvent les métriques de performance des clients lors de la création ou de l’optimisation d’interfaces web. Dans le cadre d’une mission type, nous examinons d’abord les temps de réponse actuels du serveur et la nature du contenu servi. Si nous identifions qu’un site s’appuie sur des ressources statiques ou des données fréquemment consultées qui changent lentement, nous recommandons de mettre en œuvre cette directive. Nous veillons à ce que l’implémentation ne soit pas en contradiction avec les exigences de sécurité, en particulier pour les pages contenant des données utilisateur sensibles.
Notre processus implique la vérification des configurations d’en-têtes existantes et le test des temps de chargement sur différents navigateurs. Nous ajustons ensuite les intervalles max-age et stale-while-revalidate en fonction de la fréquence de mise à jour spécifique du contenu. Par exemple, un site d’actualités peut nécessiter des intervalles plus courts, tandis qu’une page de portfolio d’entreprise pourrait bénéficier d’intervalles plus longs. Nous documentons ces paramètres afin que l’équipe du client comprenne pourquoi certaines ressources apparaissent en cache et comment les mises à jour en arrière-plan affectent l’expérience utilisateur globale.
Quelles ressources conviennent le mieux à cette approche ?
Toutes les ressources de votre site web ne sont pas candidates à stale-while-revalidate. Vous devez prioriser les ressources qui ne sont pas critiques pour la sécurité immédiate ou celles où un léger retard dans la mise à jour du contenu est acceptable. Les images, les fichiers CSS, les bundles JavaScript et les réponses API semi-statiques sont des candidats idéaux. En utilisant cette directive sur ces fichiers, vous réduisez la charge sur votre serveur d’origine et garantissez que les visiteurs bénéficient des temps de rendu les plus rapides possibles.
- Fichiers CSS et JavaScript : Ceux-ci changent rarement de manière assez drastique pour nécessiter des mises à jour instantanées.
- Images de produits : Les stocker avec une longue fenêtre de revalidation permet d’économiser une bande passante importante.
- Flux de données JSON : Les données non sensibles qui se mettent à jour périodiquement fonctionnent bien avec la revalidation en arrière-plan.
Pièges courants à éviter
Une erreur fréquente consiste à définir une fenêtre de revalidation trop longue pour du contenu qui nécessite une haute précision. Si un utilisateur s’attend à voir le cours d’une action en direct ou une alerte critique, diffuser du contenu obsolète peut être contre-productif. Évaluez toujours l’impact commercial de la diffusion d’informations datant de plusieurs minutes ou heures. De plus, évitez d’appliquer cela aux jetons d’authentification ou aux jetons CSRF, car ceux-ci doivent toujours être frais pour éviter les vulnérabilités de sécurité lors de la soumission de formulaires ou d’actions sur le compte.
Par où commencer cette semaine
Commencez par identifier les cinq ressources statiques les plus consultées sur votre site web. Utilisez les outils de développement de votre navigateur pour inspecter l’en-tête Cache-Control actuel de chacune d’elles. Si vous voyez un max-age sans composant stale-while-revalidate, calculez une fenêtre de revalidation appropriée en fonction de la fréquence à laquelle ce fichier spécifique change. Appliquez d’abord la modification à la configuration de votre serveur dans un environnement de staging pour vérifier que le comportement du navigateur correspond à vos attentes avant de la déployer sur votre site de production en direct.
Foire aux questions
Est-ce que cela fonctionne dans tous les navigateurs ?
La plupart des navigateurs modernes prennent en charge la directive stale-while-revalidate. Comme elle fait partie de la spécification standard Cache-Control, les navigateurs qui ne reconnaissent pas le paramètre l’ignoreront tout simplement et suivront les instructions standard de max-age. Cela en fait une amélioration progressive et sûre à ajouter à votre stratégie de mise en cache existante sans perturber l’expérience des navigateurs plus anciens qui ne prennent peut-être pas en charge le processus de revalidation en arrière-plan.
Puis-je utiliser cela avec un CDN ?
Oui, de nombreux réseaux de diffusion de contenu (CDN) modernes prennent en charge stale-while-revalidate. Lorsqu’un CDN reçoit cet en-tête de votre serveur d’origine, il peut mettre en cache le contenu et gérer lui-même le processus de revalidation en arrière-plan. C’est extrêmement efficace pour réduire le trafic d’origine. Consultez la documentation de votre fournisseur de CDN pour confirmer s’il prend en charge cette directive et si des étapes de configuration spécifiques sont requises pour l’activer au niveau de la couche edge.
Que se passe-t-il si la mise à jour en arrière-plan échoue ?
Si la requête de revalidation en arrière-plan échoue, le navigateur continuera généralement à utiliser la version obsolète du contenu qu’il a déjà dans son cache. L’expérience utilisateur reste ininterrompue, car le navigateur n’affiche aucune erreur au visiteur. La prochaine fois que l’utilisateur demandera la ressource, le navigateur pourra tenter à nouveau le processus de revalidation, en fonction de la logique interne du navigateur et de l’état du cache.
Est-ce mieux que la validation ETag ?
Ces deux méthodes servent des objectifs différents. La validation ETag nécessite un aller-retour vers le serveur pour vérifier si le contenu a changé, ce qui introduit toujours une certaine latence. La directive stale-while-revalidate élimine complètement cette latence en affichant immédiatement le contenu mis en cache. Vous pouvez les utiliser ensemble pour vous assurer que, même lorsque le cache est revalidé, le navigateur ne télécharge la charge utile complète que si le contenu a réellement changé, ce qui permet d’économiser encore plus de bande passante.
Continuer la lecture : Conception et développement web · Conception web