Un audit demandé par un client possédant sept extensions maison développées à des périodes différentes nous a donné l’occasion rare de comparer, sur des cas réels et non sur un exemple de démonstration, deux approches radicalement différentes pour un même besoin : un écran de réglages. Trois de ces extensions utilisaient la Settings API classique, les quatre autres un écran construit avec @wordpress/components et l’API REST.
Ce billet ne cherche pas à désigner un vainqueur universel, mais à présenter les chiffres réellement observés sur ce parc, en distinguant ce qui relève du coût de développement, du poids chargé en production, et de la maintenabilité constatée sur plusieurs années d’exploitation.
Le temps de développement initial
Pour un écran comparable, une dizaine de champs de réglages simples, texte, case à cocher, sélection, les développeurs ayant travaillé sur les deux approches chez nous rapportent un écart net. Un écran Settings API classique, avec ses fonctions register_setting(), add_settings_section() et add_settings_field(), se construit en une demi-journée pour un développeur WordPress expérimenté, y compris la validation et l’échappement des données.
L’équivalent en React, avec un composant Panel et des champs TextControl ou ToggleControl issus de @wordpress/components, une route REST personnalisée pour la lecture et l’écriture, et la configuration d’un build via @wordpress/scripts, a demandé sur ce même parc entre un jour et demi et deux jours et demi selon la familiarité préalable du développeur avec l’écosystème JavaScript de WordPress. Le facteur observé se situe entre deux et trois fois plus de temps initial.
Le poids réellement chargé
C’est sur ce critère que l’écart a le plus surpris le client lors de la restitution de l’audit. Le tableau suivant résume les mesures effectuées via l’onglet réseau du navigateur, sur l’écran de réglages de chaque extension, cache navigateur vidé :
| Approche | JS chargé sur l’écran | Requêtes réseau |
|---|---|---|
| Settings API classique | 4 Ko environ | 1 (chargement de la page) |
| Écran React (@wordpress/components) | 340 Ko en moyenne | 3 à 5 (page, bundle, appels REST) |
Ce poids provient essentiellement de la bibliothèque @wordpress/components elle-même et de ses dépendances internes, comme @wordpress/element ou @wordpress/i18n, même lorsque WordPress mutualise certaines de ces bibliothèques avec l’éditeur de blocs déjà chargé par ailleurs sur d’autres écrans. Sur un écran dédié, sans mutualisation effective, ce poids reste entièrement à la charge du chargement initial.
Ce que l’écran React apporte réellement
Ce constat ne condamne pas l’approche React pour autant. Sur les quatre extensions concernées chez ce client, l’écran construit ainsi permettait une validation en temps réel des champs, un aperçu instantané de certains réglages visuels, et une organisation en onglets fluide, sans rechargement de page. Ces éléments, difficiles à reproduire avec la même fluidité en Settings API classique, justifiaient le choix initial pour au moins deux de ces quatre extensions, dont l’une gérait un configurateur de couleurs avec prévisualisation en direct.
Le cas où React n’apportait rien
Pour les deux autres extensions React de ce parc, l’écran ne faisait au fond que reproduire un formulaire classique, sans interactivité particulière justifiant le choix technique. L’audit a recommandé leur réécriture en Settings API pour la prochaine version majeure, principalement pour réduire le poids chargé sur l’ensemble de l’administration et simplifier la maintenance à venir.
La maintenance sur la durée
Les trois extensions en Settings API n’avaient nécessité aucune intervention liée à un changement d’API sous-jacente sur plusieurs années d’exploitation, la Settings API étant restée stable depuis son introduction. Les extensions React, à l’inverse, avaient toutes connu au moins une intervention liée à une montée de version de @wordpress/scripts ou à une dépréciation de composant, notamment lors du passage de certains composants vers leurs équivalents plus récents dans @wordpress/components.
- Settings API : stabilité élevée, coût de développement initial faible, interactivité limitée.
- Écran React : interactivité riche possible, coût initial et poids chargé plus élevés, maintenance dépendante du cycle de vie des paquets
@wordpress. - Un chantier de build (
@wordpress/scripts, Webpack sous-jacent) doit être budgété dès le départ pour l’approche React, y compris son entretien.
La question que nous posons désormais avant tout choix d’écran de réglages : l’interactivité recherchée existe-t-elle réellement, ou l’écran React est-il choisi par habitude de stack plutôt que par besoin fonctionnel démontré ?
Notre verdict
Sur ce parc de sept extensions, le critère décisif n’était finalement pas la préférence technique de l’équipe, mais la nature du réglage concerné. Un formulaire de configuration standard, sans retour visuel immédiat nécessaire, gagne à rester en Settings API classique, pour son coût de développement réduit et son poids quasi nul. Un réglage qui bénéficie réellement d’une prévisualisation en direct ou d’une interactivité poussée justifie l’investissement supplémentaire d’un écran React, à condition d’accepter le poids et la maintenance qui l’accompagnent.
