La première règle de l'optimisation : ne pas optimiser sans mesurer. Trop de développeurs achètent un serveur plus puissant ou passent des heures à optimiser un code qui n'est pas le goulot d'étranglement réel. La bonne démarche : instrumenter, mesurer avec des données réelles, identifier le vrai problème, puis corriger de manière ciblée.
1. Les commandes de cache Laravel : le premier réflexe
En production, ces quatre commandes sont obligatoires et doivent faire partie de votre script de déploiement :
php artisan config:cache— fusionne tous les fichiers de config en un seul fichier PHP compiléphp artisan route:cache— compile le routing en un tableau PHP statique (x5 à x10 sur le routing)php artisan view:cache— pré-compile toutes les vues Bladephp artisan event:cache— compile les listeners d'événements
N'oubliez pas php artisan optimize:clear avant de les relancer après chaque déploiement.
2. OPcache PHP : activer et configurer correctement
OPcache met en cache le bytecode PHP compilé, évitant de recompiler les fichiers PHP à chaque requête. Sur un projet Laravel typique, activer OPcache correctement (avec opcache.validate_timestamps=0 en production) réduit le temps de réponse de 30 à 50 %. Assurez-vous que opcache.memory_consumption est suffisamment grande (128 Mo minimum) et que opcache.max_accelerated_files est supérieure au nombre de fichiers PHP de votre projet (10000+ pour Laravel avec ses dépendances).
3. Éliminer les requêtes N+1 avec Telescope
Le problème N+1 est la cause la plus fréquente de lenteur dans les applications Laravel : vous chargez 50 articles, puis pour chaque article vous faites une requête séparée pour charger son auteur — soit 51 requêtes au lieu de 2. Laravel Telescope (en staging) ou Debugbar (en local) révèlent immédiatement ces anti-patterns. La solution : l'eager loading avec with(), ou le lazy eager loading avec loadMissing().
4. Jobs asynchrones : sortez les traitements longs du cycle HTTP
Chaque opération qui prend plus de 200 ms et qui n'est pas nécessaire pour afficher la réponse doit être déportée dans un Job Laravel (queue). Envoi d'e-mails, génération de PDF, appels d'API tierces, redimensionnement d'images, exports CSV — tous ces traitements appartiennent aux queues. En production, utilisez Redis comme driver de queue (pas database, qui sollicite trop votre base de données). Supervisord gère les workers Laravel en production.
5. Assets : Vite, compression et lazy loading
Vite (intégré dans Laravel depuis la version 9.19) génère des assets optimisés avec chunking automatique, tree shaking et fingerprinting pour le cache. En production, activez la compression gzip ou Brotli dans Nginx pour les assets CSS/JS. Pour les images, convertissez en WebP, utilisez l'attribut loading="lazy" sur les images non critiques, et spécifiez toujours les dimensions (width, height) pour éviter le Cumulative Layout Shift (CLS).
6. Configuration Nginx et PHP-FPM optimisée
Côté serveur, augmentez pm.max_children dans PHP-FPM selon la RAM disponible (formule approximative : RAM disponible / 30 Mo par worker), activez fastcgi_cache dans Nginx pour les pages publiques non personnalisées, et configurez correctement les timeouts pour éviter les requêtes zombie qui bloquent les workers.
Conclusion
L'optimisation de performance est un travail de detective : mesurer, identifier, corriger, vérifier. Ces 6 actions couvrent l'essentiel des goulots d'étranglement courants sur les projets Laravel en production. Appliquez-les dans l'ordre présenté — les premières ont le plus grand impact pour le moins d'effort — et mesurez l'impact de chaque action avant de passer à la suivante.