« Ça ne devrait prendre que quelques millisecondes », c’est souvent ce qu’on se dit à propos d’un autoloader, et c’est en général vrai. Mais sur une extension maison développée pour un site de gestion de flotte de véhicules, avec plusieurs dizaines de classes PHP organisées selon les standards PSR-4 et gérées via Composer, ces quelques millisecondes se sont révélées suffisamment significatives pour justifier une mesure précise, une fois cumulées à chaque requête du site.
L’extension embarquait 340 classes au total, réparties entre la logique métier propre au site et plusieurs bibliothèques tierces installées via Composer pour la génération de rapports PDF et l’intégration avec une API de géolocalisation.
Comment fonctionne l’autoloader Composer par défaut
Sans optimisation explicite, l’autoloader généré par Composer pour un espace de noms conforme PSR-4 résout la classe demandée en construisant dynamiquement le chemin de fichier probable à partir du nom de la classe, puis en vérifiant l’existence de ce fichier. Ce mécanisme reste rapide pour un petit nombre de classes, mais implique des appels système de vérification de fichier répétés, dont le coût grandit avec le nombre de classes réellement chargées à chaque requête.
Le mode optimisé de Composer
La commande composer dump-autoload --optimize génère, en amont, une carte statique associant directement chaque nom de classe à son fichier exact, sous forme d’un tableau PHP précompilé. À l’exécution, l’autoloader n’a plus besoin de deviner ni de vérifier l’existence d’un fichier : il consulte directement cette carte :
composer dump-autoload --optimize --no-devL’option --no-dev exclut par ailleurs les dépendances de développement, comme les outils de test, qui n’ont aucune raison d’être chargées en production et alourdissent inutilement la carte de classes générée.
Le protocole de mesure
Le temps consacré à l’autoloading a été isolé avec Blackfire, en comparant deux déploiements identiques de l’extension, l’un avec l’autoloader par défaut, l’autre après exécution de la commande optimisée, sur un échantillon de cinquante requêtes vers une page utilisant intensivement l’extension.
Les résultats mesurés
| Configuration | Temps moyen d’autoloading | TTFB moyen de la page |
|---|---|---|
| Autoloader Composer par défaut | 18 ms | 212 ms |
| Autoloader optimisé (–optimize) | 3 ms | 197 ms |
Le gain de 15 millisecondes sur l’autoloading représente une fraction modeste mais non négligeable du TTFB total de la page, obtenue sans changement de code applicatif, uniquement par une commande de build exécutée au déploiement.
Comparaison avec l’autoloader natif de WordPress
Ce cas ne porte pas sur une comparaison entre Composer et l’autoloader natif de WordPress lui-même, qui ne suit d’ailleurs pas le même modèle : WordPress charge historiquement ses fichiers via des inclusions explicites plutôt qu’un autoloading PSR-4 générique. La question posée ici concerne uniquement l’optimisation de Composer pour une extension qui a fait le choix, de plus en plus répandu, de s’appuyer sur cet outil pour gérer ses propres dépendances.
Intégrer cette étape au déploiement
- Ajouter systématiquement
composer install --no-dev --optimize-autoloaderdans le script de déploiement en production. - Ne jamais versionner le dossier
vendornon optimisé directement copié depuis un environnement de développement. - Vérifier après déploiement, via un outil de profilage, que le gain est bien effectif et que la carte de classes générée correspond à la version réellement déployée.
En résumé
Optimiser l’autoloader Composer d’une extension maison est une action simple, sans risque et sans coût de développement, qui réduit mesurablement le temps consacré au chargement des classes à chaque requête. Ce gain reste modeste isolément, mais s’additionne à d’autres optimisations similaires pour construire un TTFB global plus bas, sans jamais nécessiter de changement de code métier.
