Vérifier le cache CDN et navigateur après une mise en ligne

Purger le CDN ne supprime pas les fichiers déjà stockés dans le navigateur. Vérifiez le chemin de réponse avant un purge large ou une hausse du TTL.

Comparez HTML et ressources versionnées

• Demandez la page et la ressource exactes dans une session propre. Relevez statut, Age, Cache-Control, ETag/Last-Modified et statut cache CDN éventuel.
• Vérifiez la revalidation HTML et le cache long des JS/CSS versionnés. N’appliquez pas un immutable annuel à une URL modifiable.

Purge uniquement la couche périmée

• Si le CDN renvoie d’anciens octets, purgez l’URL ou la version précise et vérifiez depuis deux réseaux. Si un seul navigateur est obsolète, testez un profil vierge avant de modifier les règles edge.
• Après changement, vérifiez séparément pages publiques et connectées. Les réponses personnalisées ne doivent pas entrer dans un cache partagé ; conservez en-têtes et retour arrière.

Exemple et résultat attendu

• Lancez curl -sS -D page.headers -o page.html PAGE_URL pour la page ; utilisez d’autres noms, comme asset.headers et asset.bin, pour le fichier hashé. Examinez le fichier page.html enregistré ou comparez l’identifiant de build avec l’origine. Répétez les deux requêtes GET après le déploiement et comparez Age et l’en-tête de statut CDN ; vérifiez aussi Cache-Control et ETag. Le HTML n’est pas toujours mis en cache par défaut ; vérifiez d’abord les règles réelles.
• Si un seul profil est obsolète, vérifiez service worker et cache local. Si le CDN renvoie un ancien HIT, purgez uniquement le chemin concerné et testez dans un profil neuf. Si l’origine est aussi obsolète, corrigez le déploiement d’abord.

Sources primaires

• Cloudflare · Cache-Control and origin caching
• Cloudflare · Default cache behavior