Quand l'instinct remplace la mesure, c'est une semaine de perdue
Une interface Filament qui tarde à répondre génère rapidement un réflexe : on met à jour les packages, on supprime des colonnes, on allège les filtres. Résultat : une semaine d'efforts, et la page reste lente. Le problème ? On a optimisé à l'aveugle. Le vrai goulot d'étranglement était ailleurs, et on ne l'a jamais cherché correctement.
Filament repose sur Laravel et Livewire. Une page d'administration lente peut tenir à des requêtes SQL mal indexées, à l'hydratation Livewire, à des politiques d'autorisation coûteuses, ou à une configuration de tableau qui recalcule trop. Impossible de savoir sans mesurer. C'est précisément ce que propose le workflow décrit dans l'article original de Saqueib Ansari : établir un benchmark rigoureux avant de toucher la moindre ligne de code.
Poser un benchmark reproductible
La première règle : ne pas benchmarker tout le panneau d'administration en même temps. On choisit une seule page, celle dont les utilisateurs se plaignent concrètement. Un index de ressource avec des filtres complexes, une page d'édition chargée de relation managers, ou un tableau de bord qui empile les widgets : on prend la pire, et on l'isole.
Pour que les mesures soient comparables d'une session à l'autre, quelques contraintes s'imposent :
- Utiliser le même snapshot de base de données à chaque run
- Travailler avec un volume de données réaliste, pas dix lignes de seeds
- Mesurer un chargement à froid et une interaction courante (recherche, filtre appliqué)
- Fermer les onglets et extensions inutiles pour ne pas polluer les métriques
- Écrire les chiffres avant de modifier quoi que ce soit
Ces contraintes peuvent sembler excessives. Elles ne le sont pas. Sans elles, on compare des mesures qui ne sont pas comparables, et on finit par confondre un pic réseau avec un vrai problème applicatif.
Identifier où le temps est vraiment dépensé
Un chargement de page Filament cumule plusieurs couches. Pour savoir laquelle coûte cher, on décompose :
Les requêtes SQL. Laravel Debugbar ou Telescope permettent de lister toutes les requêtes exécutées lors du chargement d'une page. On regarde le nombre total, la durée cumulée, et on repère les requêtes N+1 classiques (celles qui se répètent pour chaque ligne d'un tableau, par exemple). Un with() bien placé dans la query Eloquent suffit souvent à diviser le temps par dix.
L'hydratation Livewire. Chaque interaction sur une page Filament déclenche un cycle Livewire : sérialisation de l'état, requête HTTP, désérialisation, re-rendu. Si ce cycle prend 800 ms sur un simple changement de filtre, le problème n'est pas SQL. On mesure ce temps séparément, dans l'onglet Réseau des devtools, en filtrant sur les requêtes XHR vers /livewire/update.
Les politiques d'autorisation. Filament vérifie les permissions sur chaque action, parfois ligne par ligne dans un tableau. Une policy qui elle-même charge des relations ou frappe la base de données à chaque appel multiplie les requêtes invisiblement. On active le query log de Laravel autour du rendu du tableau pour les débusquer.
La configuration du tableau. Les colonnes calculées, les badges conditionnels, les icônes dynamiques : tout ce qui appelle une méthode PHP pour chaque ligne du tableau s'accumule. Parfois un état de colonne recalcule inutilement une relation déjà chargée. On revoit la configuration de chaque colonne en se posant la question : est-ce que ce calcul peut être mis en cache ou déplacé dans une propriété Eloquent ?
Corriger dans l'ordre, pas dans la panique
Une fois les métriques posées et les couches décomposées, on obtient une liste courte de candidats sérieux. On les classe par impact estimé, on corrige le premier, on remesure, on compare avec les chiffres de départ.
Ce point mérite d'être souligné : on ne change qu'une chose à la fois. Corriger simultanément une requête N+1 et alléger la configuration du tableau empêche de savoir ce qui a vraiment aidé. Si la page ralentit à nouveau dans six mois, on n'a aucun point de référence.
Le workflow complet ressemble à ceci :
- Mesurer le chargement initial et une interaction type, noter les chiffres
- Lister les requêtes SQL (nombre, durée cumulée)
- Mesurer le temps de cycle Livewire sur une interaction courante
- Vérifier les politiques d'autorisation sous query log
- Inspecter les colonnes et widgets pour les calculs répétitifs
- Choisir le candidat avec le plus grand impact, corriger, remesurer
- Répéter jusqu'à atteindre un seuil acceptable
Conclusion
Benchmarker une page Filament n'exige pas d'outillage exotique. Laravel Debugbar, Telescope, les devtools du navigateur et un tableur pour noter les chiffres : c'est suffisant. Ce qui change, c'est la discipline : mesurer avant de modifier, décomposer les couches, corriger une chose à la fois.
Ce workflow est documenté plus en détail dans l'article original de Saqueib Ansari sur dev.to, qui propose également des outils complémentaires pour aller plus loin sur les cas complexes.
