Stratégie de mise en cache par type de ressource
Les pages HTML statiques utilisent un TTL CDN de 24 heures avec revalidation stale-while-revalidate de 60 secondes. Ce paramètre permet au CDN de servir une version légèrement périmée pendant 60 secondes le temps de revalider en arrière-plan, évitant ainsi un miss de cache visible par l’utilisateur lors d’une invalidation.
Les assets statiques (images, polices, JS, CSS) sont servis avec un TTL d’un an (Cache-Control: max-age=31536000, immutable). Le nom de fichier intègre le hash du contenu (ex : styles.a1b2c3d4.css), ce qui garantit que tout changement de contenu produit une nouvelle URL et invalide naturellement le cache sans purge forcée.
Purge de cache après déploiement
Après chaque déploiement de production, le pipeline purge automatiquement le cache CDN pour les URLs modifiées depuis le dernier déploiement. La liste des URLs modifiées est extraite du diff des manifestes de build (même liste utilisée pour IndexNow). Cette purge ciblée est préférable à une purge globale qui crée un pic de charge sur le serveur d’origine.
La purge globale est réservée aux déploiements qui modifient des éléments partagés entre toutes les pages : la navigation, le pied de page, les feuilles de style communes. Dans ce cas, toutes les URLs sont purgées en batch et le serveur d’origine doit absorber un pic de trafic de revalidation. Un load balancer devant l’origine gère ce pic sans dégradation de service.
Exécution edge pour les redirections et les réécritures d’URL
Les règles de redirection (301 permanents, redirections de langue, canonical enforcement) sont exécutées au niveau edge par des workers Cloudflare. Cette exécution évite un aller-retour vers le serveur d’origine pour chaque redirection, ce qui réduit la latence et le coût d’infrastructure. Les workers sont déployés via le pipeline CI/CD en même temps que les pages.
Les réécritures d’URL complexes (slugs avec caractères spéciaux dans certaines langues, normalisation de casse) sont également gérées au niveau edge. Un test de régression vérifie que les règles de réécriture produisent les URLs canoniques attendues après chaque modification des workers.
Questions fréquentes
Comment gérez-vous la cohérence du cache entre plusieurs PoP CDN ?
La purge CDN se propage à tous les PoP via l’API du fournisseur. La propagation prend en général moins de 30 secondes. Pendant cette fenêtre, certains PoP peuvent servir l’ancienne version. Ce comportement est acceptable pour notre cas d’usage : les mises à jour de contenu ne sont pas temps-réel.
Le cache CDN interfère-t-il avec le bot de Google ?
Non, à condition que les headers de cache ne contiennent pas de directives no-store ou private. Googlebot respecte les TTL CDN et peut recevoir une version mise en cache légèrement périmée. Nos sitemaps avec lastmod exacts permettent à Googlebot de savoir quelles pages ont réellement changé indépendamment du cache.