Back-office Drupal lent : le guide d’un mainteneur d’Admin Toolbar

« Le site est rapide, mais l’admin est inutilisable. » J’entends cette phrase en permanence chez les équipes éditoriales — et comme co-mainteneur d’Admin Toolbar (environ 290 000 sites), je lis aussi la file d’issues où ces plaintes finissent par atterrir. La vérité inconfortable : la barre d’administration est accusée en premier, et c’est rarement elle la principale coupable. Voici ce qui rend vraiment les back-offices Drupal lents, classé par fréquence dans mes audits.

Pourquoi les pages d’admin sont structurellement plus lentes

Les pages anonymes volent parce qu’elles sortent du cache de pages. Les pages d’admin ne le peuvent pas : elles sont personnalisées (vos permissions, vos menus, vos brouillons), donc chaque requête fait un vrai travail — routage, contrôles d’accès sur chaque élément, construction de formulaires, chargement d’entités. Cette base-là est normale. Ce qui transforme « non caché » en « pénible », c’est tout ce qui suit.

Les vrais coupables, classés

1. Un hébergement réglé pour le trafic anonyme uniquement

Le grand classique : un CDN et le cache de pages masquent une origine lente aux visiteurs, donc personne ne remarque que PHP est sous-dimensionné — jusqu’à ce que les éditeurs, qui contournent tous les caches, le sentent à chaque clic. Vérifiez d’abord les choses ennuyeuses : OPcache correctement dimensionné, workers PHP non saturés, base de données sur du stockage rapide, et pas d’extension Xdebug activée en production (je l’y ai trouvée plus d’une fois — à elle seule, elle peut doubler les temps de réponse).

2. Des formulaires d’entités coûteux

Le formulaire de nœud est le poste de travail de l’éditeur, et c’est là que meurent les secondes : une douzaine de champs de référence d’entités qui chargent chacun leurs options ; des Paragraphs imbriqués ou des formulaires d’entités inline qui construisent des sous-formulaires entiers ; des widgets médias qui rendent des aperçus. Les corrections qui paient tout de suite : élaguer le mode d’affichage de formulaire à ce que les éditeurs utilisent vraiment, préférer l’autocomplétion aux listes déroulantes sur les gros champs de référence, et scinder les types de contenu monstres — un formulaire de 60 champs est un problème d’architecture de l’information déguisé en problème de performance.

3. Des vues d’administration sans limites

Des pages de gestion de contenus et de médias construites sur Views, qui listent des dizaines de milliers de lignes avec des tris sur des colonnes non indexées et des filtres exposés qui déclenchent des parcours complets. Ajoutez des index pour les colonnes de tri et de filtre, gardez des pagers courts, et évitez de rendre des entités dans les lignes d’admin quand des champs suffisent.

4. L’arbre de menus — là où Admin Toolbar gagne sa réputation

Le menu déroulant d’administration est construit à partir de l’arbre de menus complet, avec un contrôle d’accès sur chaque lien — et les modules n’arrêtent pas d’en ajouter. Sur les sites aux gros arbres de menus, ce coût est réel ; c’est exactement le genre de signalement que nous traitons dans la file d’issues, et les versions récentes vont vers un chargement plus paresseux et un meilleur cache de l’arbre. Conseil de mainteneur : utilisez la dernière version (le travail de performance atterrit en continu), passez en revue ce que la contrib injecte dans le menu d’admin, et si un site a des milliers de liens de menu, interrogez l’architecture du site avant d’accuser le module qui l’affiche.

5. Du code custom hostile au cache

Un seul bloc custom ou hook d’accès avec max-age: 0 (ou un contexte de cache user sans granularité) peut sortir des pans entiers de l’expérience connectée du Dynamic Page Cache. Auditez les métadonnées de cacheabilité de votre code custom — j’ai décrit le même mécanisme côté visiteurs dans mon guide Core Web Vitals ; côté éditeurs, il mord deux fois plus fort.

6. L’empilement de contrib sur les routes d’admin

Indicateurs d’environnement, tableaux de bord, thèmes d’admin aux assets lourds, modules « pratiques » qui injectent du JavaScript sur chaque page d’administration. Chacun est petit ; ensemble, c’est la raison pour laquelle l’admin charge deux mégaoctets d’assets. Deux fois par an, désinstallez sans pitié.

Le diagnostic en 30 minutes

1. time drush status en production — si la CLI est lente, c’est l’infrastructure, pas Drupal.
2. Ouvrez la page d’admin la plus lente avec le panneau réseau du navigateur : le temps part-il en TTFB (serveur) ou en assets/JS (front) ?
3. Activez Webprofiler en préproduction, rejouez la page, lisez les panneaux base de données et cache : la requête coupable est généralement gênante une fois visible.
4. Vérifiez la barre d’administration en dernier. Si tout le reste est propre et que l’arbre est énorme, là, on peut en parler.

Un back-office rapide n’est pas un luxe : les éditeurs y passent huit heures par jour, et chaque seconde du formulaire de nœud est multipliée par chaque enregistrement de chaque éditeur. Cette multiplication est généralement le retour sur investissement performance le moins cher de toute la plateforme.

Envie que vos éditeurs arrêtent de soupirer ? Le passage en revue du back-office fait partie de mon offre d’audit — diagnostic chiffré, corrections incluses.