Sur un mutualisé PHP, la page d'accueil affiche 180 ms côté TTFB. L'équipe optimise les requêtes SQL — gain de 30 ms. Puis un audit révèle que le bootstrap Composer seul consomme 40 ms par requête : des centaines de lookups PSR-4, des dev-dependencies encore présentes en prod, et un autoload jamais dumpé en mode optimisé après le dernier deploy.
Composer est invisible tant qu'il fonctionne. Pourtant chaque requête HTTP commence par vendor/autoload.php, qui charge le mapping des namespaces et résout les classes à la volée. Sur Laravel, Symfony ou WordPress moderne, des milliers de fichiers peuvent entrer dans le graphe — même si la page n'en utilise qu'une dizaine.
PSR-4, classmap et ce que PHP charge vraiment
Composer supporte plusieurs stratégies :
- PSR-4 : résolution par namespace → dossier, flexible, un peu plus coûteux à l'exécution.
- Classmap : liste exhaustive class → fichier, générée par
dump-autoload. - Authoritative classmap (
--classmap-authoritative) : Composer ne tombe jamais back sur PSR-4 — erreur si classe absente de la map.
| Commande | Effet | Quand |
|---|---|---|
composer dump-autoload | Regénère l'autoload | Après chaque deploy |
composer dump-autoload -o | Classmap optimisée | Production standard |
composer dump-autoload -o -a | Mode authoritative | Prod stable, pas de classes dynamiques |
composer install --no-dev | Retire dev-dependencies | Toujours en prod |
Optimiser l'autoload, c'est réduire le nombre de filesystem stat() avant même que votre contrôleur s'exécute.
Dev dependencies, autoload files et bruit inutile
Une erreur classique : déployer avec vendor/ complet incluant PHPUnit, fixtures et outils CI. Non seulement le disque grossit — l'autoload indexe davantage de namespaces.
La section "autoload": { "files": [...] } est pire : ces fichiers sont require à chaque requête. Réservez-la aux polyfills ou helpers réellement globaux. Préférez l'injection de services ou des imports explicites.
Sur hébergement mutualisé sans accès SSH, un pipeline CI qui exécute composer install --no-dev -o avant rsync évite de laisser le vendor local de développeur en production.
Opcache, APCu et invalidation au deploy
OPcache met en cache le bytecode PHP — indispensable, mais distinct de l'autoload. APCu peut cacher le classmap Composer en mémoire partagée entre workers PHP-FPM.
Piège fréquent : deploy sans restart PHP-FPM → workers servent encore l'ancien classmap ou un mélange incohérent. Intégrez php-fpm reload ou un touch contrôlé après synchronisation du vendor.
Vérifiez aussi opcache.validate_timestamps=0 en prod (avec redeploy propre) pour éviter les stat() répétés sur des milliers de fichiers — selon votre politique de release.
Autoload et frameworks : Laravel, Symfony, WordPress
Laravel charge beaucoup via service providers — l'autoload Composer reste le premier maillon. Symfony 6+ avec flex génère un autoload lean, mais les bundles tiers regonflent vite le vendor.
WordPress avec Bedrock ou composants Composer hérite du même enjeu : plugins qui ship leur propre vendor nested doublonnent parfois des packages (Guzzle, Symfony components) — autoload plus lourd et risque de conflits de versions.
Audit rapide : composer du (duplicate) et composer why pour repérer les packages redondants retirables.
Mesurer avant de micro-optimiser
Profilez une requête représentative (page panier, dashboard admin). Si autoload > 5–10 % du temps CPU request, le dump optimisé mérite le pipeline. Sinon, attaquez d'abord SQL, cache HTTP et sessions.
En CLI long-running (workers queue), l'autoload n'est payé qu'une fois au boot — l'enjeu est surtout PHP-FPM et les sites request/response.
Le sommet : le vendor copié depuis le laptop de dev
Tant que le pipeline de deploy ne garantit pas install --no-dev -o et un reload PHP-FPM, optimiser le code applicatif reste du cosmétique sur la latence globale.
Décider et avancer sans angle mort
Ajoutez au pipeline composer install --no-dev --prefer-dist -o -a si compatible, un rechargement PHP-FPM, et un audit des entrées files de l'autoload. Mesurez une requête représentative avant et après optimisation.
Pour choisir un hébergement PHP avec OPcache et APCu correctement configurés, parcourez l'annuaire et le comparateur. Les guides détaillent le cadrage performance PHP.
Questions fréquentes
Que fait composer dump-autoload -o ?
Il génère une classmap optimisée pour résoudre les classes sans parcourir PSR-4 à chaque lookup — à exécuter en production après chaque deploy.
Faut-il utiliser APCu pour l'autoload ?
Utile sous PHP-FPM concurrent ; invalidez le cache au deploy via reload FPM.
Pourquoi éviter d'autoload des fichiers non-classes ?
La section "files" est incluse à chaque requête — gardez-la minimale.
Comment mesurer l'impact avant d'optimiser ?
Profile request (Blackfire, Xdebug) ou chronométrez require autoload.php ; comparez avant/après dump optimisé.
Avant d'acheter un plan supérieur, vérifiez une chose : votre vendor de production est-il aussi lean que votre code ?