Un client dans l’agroalimentaire, gérant un catalogue de recettes en ligne, se plaignait depuis plusieurs semaines d’un site « devenu lent ». Le premier réflexe a été de lancer un test PageSpeed classique sur les pages publiques : les scores étaient excellents, autour de 95 sur mobile, avec un LCP inférieur à 1,5 seconde. Le problème ne se situait donc manifestement pas côté visiteur.
En creusant avec l’équipe éditoriale, le vrai problème est apparu : c’était l’ouverture de l’éditeur de blocs en back-office qui prenait entre huit et douze secondes, un délai devenu insupportable pour une équipe qui publiait plusieurs recettes par jour.
Isoler le problème : public rapide, back-office lent
Ce cas illustre un piège de diagnostic fréquent : mesurer uniquement la performance perçue côté visiteur donne une fausse impression de bonne santé générale du site. Le back-office WordPress a son propre profil de performance, largement indépendant du rendu public, puisqu’il charge un ensemble de scripts et de données entièrement différent (React de l’éditeur, JSON des blocs disponibles, bibliothèque de patterns).
Profiler l’écran de l’éditeur avec les outils du navigateur
Le panneau Performance des outils de développement Chrome, lancé pendant l’ouverture de l’éditeur sur une recette existante, a révélé un pic d’activité JavaScript prolongé, avec un appel réseau vers l’endpoint REST /wp/v2/blocks retournant une réponse de plus de 3 Mo. Cet endpoint correspond précisément à la liste des patterns personnalisés du site, chargés intégralement à chaque ouverture de l’inserteur de blocs.
wp post list --post_type=wp_block --post_status=publish --format=countCette commande a révélé deux cent dix patterns personnalisés enregistrés en base, accumulés au fil de trois années d’utilisation du site sans jamais avoir été nettoyés. En examinant leur usage réel dans le contenu publié, seuls quarante-cinq d’entre eux étaient encore effectivement utilisés sur des recettes en ligne.
Correctif : nettoyer et archiver les patterns inutilisés
La correction a consisté à passer en statut draft l’ensemble des patterns non détectés dans le contenu publié, plutôt que de les supprimer définitivement par prudence, le temps de valider avec l’équipe éditoriale qu’aucun n’était réservé à un usage ponctuel futur.
wp post list --post_type=wp_block --post_status=publish --field=ID --format=csv > patterns-actifs.csv
# Après croisement avec les patterns réellement utilisés dans le contenu :
wp post update 1842 1845 1850 --post_status=draftUn pattern en statut draft n’apparaît plus dans l’inserteur de blocs ni dans l’appel REST correspondant, ce qui a immédiatement allégé la charge de l’éditeur sans supprimer la possibilité de le republier plus tard si besoin.
Résultat mesuré après nettoyage
| Mesure | Avant nettoyage | Après nettoyage |
|---|---|---|
| Patterns publiés en base | 210 | 45 |
| Taille de la réponse /wp/v2/blocks | 3,1 Mo | 580 Ko |
| Temps d’ouverture de l’éditeur | 8 à 12 s | 2,5 à 3 s |
Un deuxième facteur : les images d’aperçu des patterns
Un facteur aggravant, découvert en creusant la requête réseau, concernait les images d’aperçu de chaque pattern dans l’inserteur, générées à partir du contenu réel des blocs plutôt que d’une miniature statique. Avec deux cent dix patterns, ce rendu de prévisualisation représentait à lui seul une part non négligeable du temps de traitement côté navigateur, indépendamment du poids réseau.
Prévention pour la suite
- Un nettoyage trimestriel de la bibliothèque de patterns, avec archivage en brouillon plutôt que suppression définitive.
- Une catégorisation stricte des patterns dès leur création, pour distinguer rapidement les patterns d’essai des patterns de production.
- Une vérification périodique, via WP-CLI, du nombre de patterns publiés, en fixant un seuil d’alerte pour l’équipe technique.
Une bibliothèque de patterns qui grossit sans jamais être nettoyée finit toujours par peser sur l’expérience d’édition, même quand le site public reste rapide et irréprochable pour le visiteur final.
En résumé
La lenteur perçue par ce client ne concernait que le back-office, un angle mort fréquent des audits de performance centrés uniquement sur le rendu public. Un nettoyage périodique de la bibliothèque de patterns, couplé à une vérification du poids de l’endpoint REST correspondant, permet d’éviter que ce type de dégradation ne s’installe durablement sans que personne n’en comprenne la cause.
