Actualiser JavaScript et CSS sans laisser d'anciennes versions en cache

Séparer le document HTML des ressources versionnées

Le HTML sert de manifeste. La version A référence app.4c21.js et site.19ab.css ; B utilise app.9d80.js et peut conserver le CSS si ses octets sont identiques. Ces empreintes sont illustratives, pas calculées.

Les ressources inchangées restent réutilisables, les autres gagnent une nouvelle identité. Un HTML conservé un an peut continuer à demander les anciens fichiers et retarder la découverte d'une publication.

Choisir les directives selon ce contrat

Pour un fichier public immuable à cette URL, un long max-age avec immutable peut convenir. Pour le HTML, no-cache autorise le stockage mais impose une validation avant réutilisation ; no-store demande de ne pas stocker. Choisissez par ressource.

Les en-têtes montrés illustrent une stratégie. Vérifiez les réponses publiques de l'hébergement et la configuration du cache périphérique. Un fichier local ne prouve pas ce que le navigateur et la CDN ont reçu.

Versioned public asset: /assets/app.9d80.js
Cache-Control: public, max-age=31536000, immutable

HTML document: /index.html
Cache-Control: no-cache

The URL /assets/app.9d80.js must continue to serve the same bytes.

Inclure la version de requête dans la clé de cache

/app.js?v=release-b peut se distinguer de /app.js?v=release-a si chaque cache concerné tient compte du paramètre. Une règle CDN qui ignore la requête peut servir le même objet pour les deux.

Évitez une valeur aléatoire à chaque visite : elle supprime la réutilisation. Une empreinte ou version stable ne change qu'avec la ressource. Un fragment comme /app.js#release-b n'est pas envoyé en HTTP et ne remplit pas cette fonction.

Diagnostiquer la couche qui sert les anciens octets

Comparez réponse HTML, URL référencée et octets reçus. Ancienne empreinte dans le HTML : vérifiez sa fraîcheur. Nouvelle empreinte avec ancien contenu : examinez publication, clés et origine. Réseau correct mais comportement ancien : recherchez une page déjà exécutée ou un service worker.

Purger la CDN ne retire pas une réponse fraîche stockée dans chaque navigateur. Un rechargement forcé ne corrige que le test local. Notez la couche contournée pour rendre chaque contrôle reproductible.

• Consigner l'URL finale du HTML et du script ou CSS.
• Vérifier état, Content-Type, Cache-Control, ETag et en-têtes de cache.
• Confirmer les bons octets, pas une page HTML de secours.
• Contrôler séparément les règles du service worker éventuel.
• Tester une visite neuve et une page ouverte pendant la publication.

Préserver les pages anciennes et le retour arrière

Téléversez les nouveaux fichiers avant le HTML, ou basculez la publication complète ensemble. Conservez les anciens assez longtemps pour le HTML en cache et les onglets ouverts ; un module peut être demandé plusieurs heures après.

Publiez B en conservant A et B, vérifiez B et gardez la possibilité de revenir à A. Supprimer immédiatement app.4c21.js casse les anciennes pages. Réutiliser ce nom pour de nouveaux octets viole le contrat et complique le retour arrière.

Mesurer la réutilisation après validation

Contrôlez une première visite, une seconde et une nouvelle publication : téléchargement initial, réutilisation possible puis seuls fichiers modifiés. Examinez les transferts réels, dont les revalidations, sans assimiler toutes les réponses de cache.

Les calculateurs d'économie de cache et de transfert comparent des hypothèses explicites de taux de succès, volume et taille. Ils ne remplacent pas la mesure des en-têtes déployés ni du taux réel de succès.