Ce qu’on voit régulièrement en revue de code, sur des blocs dynamiques construits rapidement : un composant ServerSideRender branché directement sur les attributs du bloc, sans aucune protection, qui déclenche une requête HTTP complète vers render_callback à chaque frappe de clavier dans un champ de l’inspecteur. Sur un article avec plusieurs blocs de ce type, l’éditeur devient perceptiblement plus lent, parfois au point de devenir irritant pour l’auteur.
Pourquoi ServerSideRender existe
ServerSideRender, du paquet @wordpress/server-side-render, permet d’afficher dans l’éditeur exactement le même rendu HTML que celui généré côté front par la fonction render_callback PHP du bloc. L’intérêt est réel pour un bloc dont le rendu dépend d’une logique PHP lourde ou d’un plugin tiers non réécrit en JavaScript : plutôt que de dupliquer cette logique dans edit, on affiche directement le résultat serveur.
import ServerSideRender from '@wordpress/server-side-render';
<ServerSideRender
block="mon-projet/derniers-avis"
attributes={ attributes }
/>Pourquoi c’est un piège en pratique
Latence perceptible à chaque changement
Chaque modification d’attribut relance une requête REST complète vers le serveur, qui exécute à nouveau tout le render_callback PHP, potentiellement avec des requêtes à la base de données. Sur un hébergement mutualisé ou un serveur déjà chargé, ce délai se traduit par un aperçu qui « saute » de manière visible, quelques centaines de millisecondes après chaque interaction.
Requêtes REST en rafale
ServerSideRender n’applique aucun anti-rebond (debounce) par défaut. Un utilisateur qui ajuste un RangeControl à la souris peut déclencher une dizaine de requêtes en quelques secondes, dont la plupart deviennent obsolètes avant même de recevoir leur réponse — un gaspillage de ressources serveur qui ne profite à personne.
Aucune interaction possible dans l’aperçu
Le HTML renvoyé par le serveur est statique : aucun gestionnaire d’événement JavaScript ne s’y attache. Un bloc qui doit rester cliquable ou manipulable directement dans l’éditeur (un carrousel, un accordéon interactif) ne peut tout simplement pas fonctionner correctement avec ServerSideRender, quelle que soit la qualité du rendu PHP sous-jacent.
Les alternatives, par ordre de préférence
- Reproduire le rendu en JavaScript dans edit, en dupliquant la logique d’affichage (mais pas nécessairement la logique métier lourde) directement en React. C’est l’option la plus rapide pour l’utilisateur, au prix d’un entretien du code à deux endroits.
- Charger les données via apiFetch ou les stores de @wordpress/data, puis les afficher avec un composant React léger, en laissant le rendu final complexe au véritable
render_callbackuniquement côté front. - Accepter un aperçu simplifié dans l’éditeur (une maquette statique ou un texte descriptif du contenu réel), réservant le rendu fidèle au seul front public, quand la fidélité pixel-perfect dans l’éditeur n’apporte pas de valeur réelle à l’utilisateur.
Quand ServerSideRender reste acceptable
- Un bloc de configuration rare, modifié une seule fois puis jamais retouché (un shortcode de formulaire tiers, par exemple).
- Un rendu qui dépend d’une extension tierce dont la logique PHP ne peut raisonnablement pas être portée en JavaScript à court terme.
- Dans ces cas, ajouter un anti-rebond manuel autour des changements d’attributs limite au moins la fréquence des requêtes déclenchées.
Un bloc dynamique qui « rame » dans l’éditeur finit presque toujours par être évité par les rédacteurs, même quand son rendu final sur le site est irréprochable : l’expérience d’édition compte autant que le résultat publié.
Notre verdict
ServerSideRender reste un outil de dépannage, pas une solution par défaut pour un bloc dynamique. Investir dans un rendu JavaScript côté edit, même partiel, améliore presque toujours l’expérience d’édition de façon suffisamment nette pour justifier l’effort supplémentaire, hors des cas vraiment marginaux évoqués ci-dessus.
