La mise en cache de longue durée des ressources
Conservez durablement vos ressources dans le navigateur et ne retéléchargez que ce qui change vraiment grâce au versionnage et au découpage du code.
Une fois la taille de vos fichiers optimisée, la mise en cache est le deuxième levier qui réduit le temps de chargement. Elle consiste à conserver des parties de votre site dans le navigateur de l’utilisateur pour éviter de les retélécharger à chaque visite. Bien menée, cette stratégie accélère nettement les visites répétées, ce qui pèse dans les Core Web Vitals et donc dans la perception de qualité par les moteurs. Mal menée, elle sert des versions périmées ou invalide trop largement le cache. L’objectif est de conserver longtemps ce qui ne change pas et de ne retélécharger que ce qui a réellement évolué.
La mise en cache de longue durée est l’un de ces leviers où une bonne configuration se voit immédiatement sur les visites répétées. Le piège classique, c’est de fixer un cache long sans versionner les fichiers : on se retrouve à servir des ressources périmées. Versionner d’abord, mettre en cache ensuite, et isoler les dépendances pour ne pas tout invalider à la moindre modification.
Versionner le fichier et fixer un cache long
L’approche classique combine deux gestes. D’abord, demander au navigateur de conserver un fichier très longtemps, par exemple un an. Ensuite, renommer ce fichier lorsqu’il change pour forcer un nouveau téléchargement. Tant que le nom reste identique, le navigateur réutilise sa copie locale, conformément au fonctionnement du cache HTTP, et n’interroge le réseau que si le nom change ou si l’année s’écoule.
Cache-Control: max-age=31536000Au lieu d’un numéro de version géré à la main, on insère le hachage du contenu dans le nom du fichier. Avec Webpack, le motif [chunkhash] s’en charge automatiquement à chaque build.
<!-- Avant la modification -->
<script src="./index-v15.js"></script>
<!-- Apres la modification -->
<script src="./index-v16.js"></script>Isoler les dépendances et l'environnement d'exécution
Les dépendances changent moins souvent que votre code applicatif. En les plaçant dans un fichier distinct (un bloc fournisseur), le navigateur les met en cache séparément et ne les retélécharge pas chaque fois que votre code évolue. Webpack permet d’activer ce découpage intelligent, qui extrait automatiquement le code tiers volumineux.
Cela ne suffit pourtant pas. Webpack inclut un petit environnement d’exécution dans le dernier bloc généré ; or ce code change à chaque modification, ce qui invalide tout le bloc fournisseur. La solution est d’extraire cet environnement d’exécution dans son propre fichier afin de stabiliser le cache des dépendances.
Voici les principales techniques pour préserver le cache sur la durée et leur effet concret.
| Technique | Mise en oeuvre | Bénéfice cache |
|---|---|---|
Versionnage par hachage |
Motif [chunkhash] dans le nom de sortie |
N’invalide que le fichier réellement modifié |
Extraction des dépendances |
Découpage en bloc fournisseur séparé |
Les bibliothèques restent en cache entre les versions |
Extraction de l’exécution |
Bloc runtime dédié |
Empêche le bloc fournisseur d’être invalidé sans raison |
Identifiants de module stables |
Hachage des chemins de module |
Ajouter un module ne casse pas le cache des autres |
Découpage par routes |
Une entrée par page ou import dynamique |
L’utilisateur ne charge que le code de sa page |
Webpack peut produire un hachage différent même si le contenu du bloc est inchangé, par exemple après un renommage de fichier ou une compilation sur un autre système d’exploitation. Stabilisez les identifiants de module pour qu’un nouveau module n’invalide pas inutilement le cache des fichiers voisins.
À faire
- combiner cache long et nom de fichier versionné
- isoler dépendances et environnement d’exécution
- découper le code par routes
- charger en différé le code non critique
À éviter
- gérer les numéros de version à la main
- regrouper tout le code dans un seul bloc
- laisser l’environnement d’exécution dans le bloc fournisseur
- servir aux visiteurs du code de pages qu’ils ne consultent pas
Points clés à retenir
- Conserver les ressources un an avec un nom de fichier portant un hachage de contenu.
- Extraire les dépendances dans un bloc fournisseur mis en cache à part.
- Isoler l'environnement d'exécution pour ne pas invalider le bloc fournisseur.
- Stabiliser les identifiants de module pour limiter les invalidations en chaîne.
- Découper le code par routes et charger en différé le code secondaire.
La mise en cache de longue durée repose sur des fichiers stables et un versionnage automatisé.
Quiz : testez vos connaissances
Quiz : testez vos connaissances
-
Quelle est l'approche classique pour une mise en cache de longue durée ?
- Garder le même nom de fichier quoi qu'il arrive
- Conserver le fichier très longtemps et le renommer dès qu'il change
- Désactiver le cache pour forcer un téléchargement à chaque visite
L’approche combine deux gestes : demander au navigateur de conserver le fichier très longtemps, puis le renommer lorsqu’il change. Tant que le nom reste identique, le navigateur réutilise sa copie en cache.
-
Pourquoi isoler les dépendances dans un fichier distinct ?
- Parce que les dépendances doivent être rechargées à chaque visite
- Parce qu'elles changent moins souvent, donc le navigateur ne les retélécharge pas quand votre code évolue
- Parce que cela réduit la taille totale du code applicatif
Les dépendances évoluent rarement. En les plaçant dans un bloc fournisseur dédié, le navigateur les met en cache séparément et ne les retélécharge pas à chaque modification de votre code.
-
Comment générer automatiquement un nom de fichier versionné ?
- En insérant le hachage du contenu dans le nom, par exemple avec le motif [chunkhash] de Webpack
- En gérant les numéros de version à la main
- En ajoutant la date du jour au nom du fichier
Plutôt qu’un numéro géré manuellement, on insère le hachage du contenu dans le nom du fichier. Avec Webpack, le motif
[chunkhash]s’en charge automatiquement à chaque build.
À propos de l'auteur
Besoin d'un accompagnement SEO ?
Un cache mal versionné peut ralentir chaque retour de vos visiteurs sur votre site.