_embed en cascade : un menuisier dont le front charge cent requêtes

Cent seize requêtes HTTP au chargement d’une seule page de listing des réalisations d’un menuisier : c’est le chiffre relevé dans l’onglet réseau du navigateur, pour un front qui n’affichait pourtant que vingt fiches de projets avec leur image et leur catégorie associée.

La cause s’est révélée être une utilisation trop généreuse du paramètre _embed de l’API REST, combinée à une extension de galerie qui déclenchait elle-même des sous-requêtes pour chaque image liée à un article.

Symptôme : une cascade invisible au premier regard

Le code côté front semblait pourtant raisonnable, un unique appel avec _embed pour récupérer en une fois les articles, leur image mise en avant et leurs termes de taxonomie associés :

GET /wp-json/wp/v2/realisations?_embed&per;_page=20

Le problème n’apparaissait pas dans cet appel unique, correctement formé, mais dans le comportement d’une extension de galerie installée sur le site : chaque image embarquée par _embed déclenchait, côté client cette fois, un appel supplémentaire vers un service de génération de variantes d’image non intégré au flux _embed initial.

Diagnostic : isoler la source réelle des appels

L’onglet réseau du navigateur, filtré sur les requêtes vers le domaine de l’API, a permis de constater qu’un seul appel initial partait bien vers /wp/v2/realisations, mais que chacune des vingt images renvoyées déclenchait ensuite un appel individuel vers une route de redimensionnement, faute d’avoir anticipé ce comportement lors de l’intégration de l’extension de galerie.

Correctif : un champ agrégé plutôt qu’une cascade

Plutôt que de laisser le front recomposer les données à partir de plusieurs ressources embarquées puis de multiples appels annexes, un champ personnalisé agrégé, calculé côté serveur, a remplacé l’ensemble de la cascade en une seule propriété directement exploitable :

add_action( 'rest_api_init', function() {
    register_rest_field( 'realisation', 'vignette', array(
        'get_callback' => function( $post ) {
            $id_image = get_post_thumbnail_id( $post['id'] );
            return array(
                'url_large'  => wp_get_attachment_image_url( $id_image, 'large' ),
                'url_vignette' => wp_get_attachment_image_url( $id_image, 'medium' ),
            );
        },
    ) );
} );

Le front n’a ensuite plus qu’à lire directement vignette.url_vignette depuis la réponse de l’article, sans déclencher la moindre résolution supplémentaire du côté du navigateur.

Prévention : la pagination par curseur en complément

Au-delà du champ agrégé, la pagination classique par numéro de page pose elle-même un problème de cohérence si des réalisations sont ajoutées entre deux chargements. Une pagination par curseur, basée sur un identifiant plutôt que sur un numéro de page, évite ce décalage tout en réduisant le risque de recharger inutilement des éléments déjà affichés.

• Éviter _embed dès qu’une extension tierce peut interférer avec les ressources embarquées
• Préférer un champ agrégé calculé côté serveur pour les besoins d’affichage récurrents
• Envisager une pagination par curseur pour les listings à fort renouvellement

Un seul appel bien formé ne garantit rien si les données qu’il renvoie déclenchent, en aval, une cascade de requêtes qu’on n’a jamais mesurée.

Ce que cet incident a changé dans la méthode de travail

Depuis cet épisode, chaque nouvelle intégration d’extension sur ce projet fait l’objet d’une vérification systématique de l’onglet réseau avant validation, sur une page représentative du volume réel de contenu attendu en production, pas sur un jeu de données de test réduit à quelques éléments qui masque artificiellement ce type de cascade.

Cette simple habitude, coûtant quelques minutes par extension testée, a permis de repérer deux autres cas similaires sur d’autres projets de la même équipe avant leur mise en production, plutôt qu’après coup lors d’un incident constaté par un visiteur.

En résumé

Le paramètre _embed reste un outil pratique, mais il ne dispense pas de vérifier ce qui se passe réellement, côté client, une fois les ressources embarquées reçues. Un champ agrégé, taillé pour l’usage exact du front, élimine souvent des cascades de requêtes qu’aucun outil de mesure ne révèle avant un vrai audit réseau. Cet article ne traite pas la mise en cache CDN des réponses, qui viendrait compléter utilement cette optimisation.