# Mettre en cache un flux externe affiché dans un template avec wp_remote_get

> Afficher un flux tiers dans un gabarit expérimental sans le requêter à chaque visite : une transient bien posée suffit à protéger un temps de chargement correct.

- Auteur : WordPress Développement
- Publié le : 2020-09-07
- Mis à jour le : 2020-09-07
- Catégorie : Éditeur de site (FSE)
- URL : https://www.wpmoderne.fr/fse/cache-flux-externe-template-wp-remote-get/

## L’essentiel

- Une requête HTTP par visite ruine la performance
- Les transients WordPress suffisent sans plugin
- Prévoir un contenu de repli en cas d'échec

Quinze minutes. C'est la durée qu'il suffit de choisir pour transformer une donnée tierce, lente à récupérer, en un affichage instantané dans un gabarit — sans jamais toucher à la donnée elle-même, seulement à la fréquence à laquelle on va la chercher.

Ce billet s'adresse à qui affiche, dans une zone de gabarit expérimentale du plugin Gutenberg, une donnée provenant d'un service tiers : un indicateur météo, un taux de change, un statut de disponibilité. Il ne traite pas de l'affichage de cette donnée dans un bloc dynamique dédié, seulement de la stratégie de cache autour de la récupération.

## Le problème d'une requête à chaque visite

Appeler `wp_remote_get()` directement dans le rendu d'un gabarit revient à faire dépendre le temps de chargement du site entier de la disponibilité et de la vitesse d'un service externe. Si ce service répond en trois secondes, chaque page utilisant ce gabarit hérite de ces trois secondes. Si le service tombe en panne, c'est tout le gabarit qui risque de se bloquer.

```
// À éviter : appel direct à chaque affichage
$reponse = wp_remote_get( 'https://api.exemple.tld/statut' );
$donnee  = wp_remote_retrieve_body( $reponse );
```

Ce code fonctionne, mais il fonctionne mal : il n'y a aucune protection contre la lenteur ou l'indisponibilité du service distant.

## Introduire une transient

WordPress propose depuis longtemps un mécanisme de cache léger, les transients, qui ne nécessitent aucune extension supplémentaire. Une transient se comporte comme une option classique, mais avec une durée de vie définie :

```
function recuperer_statut_service() {
    $cle = 'statut_service_externe';
    $donnee = get_transient( $cle );

    if ( false === $donnee ) {
        $reponse = wp_remote_get( 'https://api.exemple.tld/statut', array(
            'timeout' => 5,
        ) );

        if ( is_wp_error( $reponse ) || 200 !== wp_remote_retrieve_response_code( $reponse ) ) {
            return null;
        }

        $donnee = wp_remote_retrieve_body( $reponse );
        set_transient( $cle, $donnee, 15 * MINUTE_IN_SECONDS );
    }

    return $donnee;
}
```

> L'essentiel à retenir : Une requête HTTP par visite ruine la performance ; Les transients WordPress suffisent sans plugin ; Prévoir un contenu de repli en cas d'échec

Le paramètre `timeout` mérite une attention particulière : sans lui, une requête peut rester bloquée bien plus longtemps que raisonnable si le service distant ne répond jamais.

## Choisir la bonne durée de vie

Quinze minutes n'est pas une valeur magique, mais un compromis raisonnable pour une donnée qui change lentement. Pour un contenu qui évolue toutes les secondes, une transient n'a aucun sens : on se dirigerait alors vers une solution côté client, en JavaScript, plutôt que côté serveur.

- Donnée stable sur plusieurs heures : transient de longue durée, voire une option régénérée par une tâche planifiée.
- Donnée qui change toutes les quinze à trente minutes : transient classique, comme dans l'exemple ci-dessus.
- Donnée quasi temps réel : la transient n'est pas le bon outil, il faut regarder du côté du chargement asynchrone en JavaScript.

## Prévoir l'échec du service distant

Un point souvent négligé : que se passe-t-il si le service distant tombe en panne au moment précis où la transient expire ? Sans précaution, le gabarit affichera une absence de donnée, ou pire, une erreur PHP si le code suppose que la réponse est toujours valide. La fonction ci-dessus retourne `null` en cas de problème, à charge pour le gabarit d'afficher un contenu de repli sobre plutôt qu'un vide brutal.

> Une donnée tierce absente doit rester discrète dans l'affichage : mieux vaut un gabarit silencieux qu'un gabarit qui expose une erreur technique à un visiteur.

## Nettoyer proprement

Il est tentant d'oublier qu'une transient reste stockée dans la table `wp_options` tant qu'elle n'a pas expiré ou n'a pas été explicitement supprimée. Sur un site où de nombreuses transients de ce type s'accumulent, un appel régulier à `delete_transient()` lors de la désactivation d'une extension évite de laisser des résidus inutiles en base.

## En résumé

Une transient bien dimensionnée suffit, dans la grande majorité des cas, à protéger un gabarit affichant une donnée tierce contre la lenteur et les pannes d'un service externe. Pas besoin d'extension supplémentaire ni de file d'attente complexe : le cœur de WordPress fournit déjà l'outil, à condition de le paramétrer avec un minimum de rigueur.