fastly-debug: 1 : sur un site à audience internationale, cet en-tête de débogage propre à Fastly avait fini par devenir un réflexe pour l’équipe technique, utilisé quotidiennement pour comprendre pourquoi telle page se retrouvait servie depuis le cache et telle autre non. Migrer vers Bunny.net signifiait perdre cet outil de diagnostic précis, et reconstruire ailleurs une visibilité équivalente sur le comportement du cache.
La bascule elle-même, faire pointer un domaine vers un nouveau CDN, ne pose techniquement pas de difficulté majeure. Ce qui rend l’opération délicate sur un site déjà optimisé depuis plusieurs années, c’est de reproduire fidèlement des règles de cache affinées avec le temps, sans repartir d’une configuration générique qui dégraderait les performances au moment même où l’objectif est de réduire les coûts sans perdre en vitesse.
Cartographier les règles existantes avant de migrer
La première étape a consisté à extraire, règle par règle, la configuration VCL en place sur Fastly : durées de cache par type de contenu, exceptions pour les pages avec paramètres de requête, purge automatique déclenchée à la publication d’un article via l’API. Chacune de ces règles a été consignée dans un tableau de correspondance avant même de toucher à la configuration du nouveau service, pour éviter d’en oublier une seule au moment de la reconstruction.
| Règle Fastly | Équivalent visé sur Bunny.net |
|---|---|
| TTL 7 jours sur les images | Règle de cache par extension de fichier |
| Purge par tag lors de la publication | Purge par URL via l’API Bunny.net |
| Bypass du cache sur /wp-admin | Règle d’exclusion de chemin identique |
Reconstruire la purge déclenchée par WordPress
Le site s’appuyait sur un hook déclenché à chaque publication d’article pour purger la page correspondante et la page d’accueil sur Fastly, via son API de purge par tag de substitution. Bunny.net fonctionne différemment, avec une purge par URL explicite plutôt que par tag, ce qui a nécessité d’adapter la fonction PHP appelée sur ce hook plutôt que de simplement changer une clé d’API :
add_action( 'transition_post_status', function ( $new_status, $old_status, $post ) {
if ( 'publish' !== $new_status ) {
return;
}
$urls = [
get_permalink( $post ),
home_url( '/' ),
];
foreach ( $urls as $url ) {
wp_remote_post( 'https://api.bunny.net/purge', [
'headers' => [ 'AccessKey' => BUNNY_API_KEY ],
'body' => [ 'url' => $url ],
]);
}
}, 10, 3 );
Les en-têtes Cache-Control, un socle commun aux deux CDN
Un point rassurant de cette migration a été de constater que les en-têtes Cache-Control envoyés directement par WordPress et par la configuration Nginx du serveur d’origine restaient la base de référence pour les deux CDN, quel que soit le fournisseur en façade. Fastly et Bunny.net respectent tous deux ces en-têtes par défaut, ce qui a permis de conserver la même logique de durée de cache côté serveur et de ne redéfinir, au niveau du CDN lui-même, que les exceptions spécifiques à chaque fournisseur.
Organiser la période de recouvrement DNS
Plutôt qu’une bascule nette, l’équipe a choisi une période de recouvrement de vingt-quatre heures pendant laquelle une partie du trafic, réparti par un enregistrement DNS à poids variable chez le registraire, était dirigée vers le nouveau CDN pendant que le reste continuait de passer par Fastly. Cette approche a permis de repérer, sur un volume de trafic réel mais limité, deux règles de purge mal reproduites avant qu’elles n’affectent l’ensemble des visiteurs.
; Exemple d'enregistrement DNS pondéré chez un registraire le supportant
www 300 IN CNAME 10 cdn-bunny.example.net.
www 300 IN CNAME 90 cdn-fastly.example.net.
Ce qui a été découvert pendant le recouvrement
La première règle mal reproduite concernait les pages de résultats de recherche interne du site, exclues du cache sur Fastly par une condition VCL spécifique mais accidentellement mises en cache sur la nouvelle configuration Bunny.net, provoquant l’affichage de résultats obsolètes pour certains visiteurs. La seconde concernait un en-tête personnalisé utilisé par le site pour varier le cache selon la langue de l’utilisateur, une configuration qui nécessitait une règle Vary explicite sur le nouveau CDN, absente de la configuration initiale.
Une migration de CDN réussie ne se mesure pas à la facture réduite le mois suivant, mais à l’absence totale d’incident de cache pendant les premières semaines qui suivent la bascule complète.
En résumé
Changer de CDN sur un site à forte audience internationale se prépare comme une migration de base de données : par une cartographie exhaustive des règles existantes, une reconstruction méthodique plutôt qu’approximative, et une période de recouvrement qui permet de détecter les écarts avant qu’ils ne touchent l’ensemble du trafic. La réduction de coût visée par la bascule ne vaut la peine que si le comportement de cache reste, au minimum, aussi fin que celui qu’il remplace.
