# Fastly contre Bunny.net pour invalider le rendu d’un bloc modifié

> Comparatif des API de purge ciblée de Fastly et Bunny.net pour invalider le rendu mis en cache d'un bloc dynamique après sa modification.

- Auteur : Clément Hadrot
- Publié le : 2026-04-30
- Mis à jour le : 2026-04-30
- Catégorie : Blocs Gutenberg
- URL : https://wpmoderne.dev.wordpress-developpement.fr/blocs/fastly-bunny-net-invalider-rendu-bloc-modifie/

## L’essentiel

- Fastly permet une purge par clé de substitution (surrogate key)
- Bunny.net purge par URL ou par motif, sans clé de substitution native
- Le choix dépend surtout de la granularité de purge réellement nécessaire

Un bloc dynamique mis en cache en périphérie pose une question simple en apparence, mais structurante : comment invalider précisément son rendu quand son contenu change, sans purger inutilement des milliers d'autres pages qui n'ont pas changé ? Sur un site éditorial diffusant un bloc de bandeau d'alerte partagé sur plusieurs centaines d'articles, ce choix de granularité de purge a occupé l'essentiel de l'arbitrage entre Fastly et Bunny.net, les deux CDN alors en short-list pour ce projet.

Cloudflare, déjà comparé ailleurs dans nos colonnes, n'entre pas dans ce comparatif : l'objectif ici est de départager précisément Fastly et Bunny.net sur un seul critère technique, la purge ciblée du rendu d'un bloc modifié, sans revenir sur des critères déjà tranchés par ailleurs comme le prix global ou la couverture géographique.

## Le modèle de Fastly : la clé de substitution

Fastly propose un mécanisme natif de **surrogate keys** : chaque réponse HTTP mise en cache peut être associée à une ou plusieurs clés arbitraires, transmises dans un en-tête `Surrogate-Key`. Purger une clé précise invalide instantanément toutes les réponses qui la portent, quel que soit leur nombre :

```
add_filter( 'wp_headers', function( $headers ) {
    if ( has_block( 'editorial/bandeau-alerte' ) ) {
        $headers['Surrogate-Key'] = 'bandeau-alerte-global';
    }
    return $headers;
} );

// Depuis WordPress, à chaque modification du bloc :
wp_remote_request( 'https://api.fastly.com/service/XXXX/purge/bandeau-alerte-global', array(
    'method'  => 'POST',
    'headers' => array( 'Fastly-Key' => FASTLY_API_TOKEN ),
) );
```

Cette approche permet de purger en une seule requête API toutes les pages portant le bandeau, sans connaître à l'avance la liste exhaustive de leurs URL — un avantage décisif quand le bloc apparaît sur un nombre de pages qui évolue dans le temps.

## Le modèle de Bunny.net : purge par URL ou par motif

> L'essentiel à retenir : Fastly permet une purge par clé de substitution (surrogate key) ; Bunny.net purge par URL ou par motif, sans clé de substitution native ; Le choix dépend surtout de la granularité de purge réellement nécessaire

Bunny.net ne propose pas de mécanisme de clé de substitution équivalent : sa purge cible soit une URL précise, soit un motif de correspondance sur l'arborescence de chemins, via son API de gestion de zone de cache :

```
wp_remote_request( 'https://api.bunny.net/purge', array(
    'method'  => 'POST',
    'headers' => array( 'AccessKey' => BUNNY_API_KEY ),
    'body'    => wp_json_encode( array(
        'url' => 'https://exemple.fr/*',
    ) ),
) );
```

Sans clé de substitution, invalider précisément les seules pages contenant le bandeau d'alerte suppose de maintenir soi-même, côté WordPress, la liste des URL concernées — par exemple dans un `transient` mis à jour à chaque insertion du bloc — puis de purger chaque URL individuellement ou par lot, un motif générique risquant de purger bien plus large que nécessaire.

## Comparatif synthétique

| Critère | Fastly | Bunny.net |
| --- | --- | --- |
| Granularité de purge par contenu | Native, via clé de substitution | À reconstruire manuellement côté WordPress |
| Nombre d'appels API pour purger un bloc partagé | Un seul, quel que soit le nombre de pages | Un par URL, ou un motif large |
| Complexité d'intégration initiale | Plus élevée, apprentissage du modèle de clés | Plus simple, purge par URL directe |
| Coût pour un usage similaire | Généralement plus élevé | Généralement plus accessible |

## Ce que ce choix implique côté code WordPress

Avec Fastly, l'intégration se limite à ajouter systématiquement l'en-tête `Surrogate-Key` correspondant au bloc concerné, puis à déclencher un unique appel de purge lors de sa modification, via `save_post` ou un hook dédié à la sauvegarde du contenu du bloc. Avec Bunny.net, il faut construire et maintenir soi-même une table de correspondance entre blocs et URL, ce qui ajoute une dépendance supplémentaire à surveiller — une table qui peut elle-même se désynchroniser si une page change de statut sans déclencher le bon hook.

> Le vrai coût d'un CDN sans clé de substitution n'est pas dans son prix, mais dans le code de maintenance qu'il faut écrire pour compenser cette absence.

## Le critère qui a tranché sur ce projet

Le bandeau d'alerte de ce site éditorial pouvant apparaître ou disparaître de plusieurs centaines de pages en quelques minutes lors d'un événement d'actualité, la capacité de Fastly à purger une clé unique sans maintenir de liste d'URL a fait pencher la balance malgré un coût plus élevé. Sur un projet où le bloc à invalider reste toujours localisé sur un nombre restreint et stable de pages, Bunny.net aurait suffi, à un coût nettement moindre.

## Notre verdict

Fastly l'emporte dès qu'un bloc partagé apparaît sur un nombre de pages difficile à énumérer à l'avance, grâce à ses clés de substitution qui évitent toute reconstruction manuelle de la correspondance bloc-URL. Bunny.net reste un choix pertinent et plus économique quand la purge peut se limiter à un motif d'URL stable et prévisible, sans logique de correspondance complexe à maintenir côté WordPress.