# ServerSideRender : pourquoi l’aperçu PHP dans l’éditeur est un piège

> Latence perceptible, requêtes REST en rafale, interactions impossibles dans l'aperçu : les vraies raisons d'éviter ServerSideRender, et ce qu'on fait à la place.

- Auteur : Clément Hadrot
- Publié le : 2021-10-21
- Mis à jour le : 2021-10-21
- Catégorie : Blocs Gutenberg
- URL : https://wpmoderne.dev.wordpress-developpement.fr/blocs/serversiderender-piege-apercu-php-editeur/

## L’essentiel

- Chaque frappe dans l'inspecteur peut déclencher une requête REST complète
- ServerSideRender ne permet aucune interaction dans l'aperçu
- Un rendu JavaScript côté edit reste plus rapide et plus interactif

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

> L'essentiel à retenir : Chaque frappe dans l'inspecteur peut déclencher une requête REST complète ; ServerSideRender ne permet aucune interaction dans l'aperçu ; Un rendu JavaScript côté edit reste plus rapide et plus interactif

`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

1. **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.
2. **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_callback` uniquement côté front.
3. **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.