Laravel

Consultant web performance expert Laravel

Optimiser la web performance des applications Laravel

Laravel est rapide à développer, mais l'écriture rapide ouvre la porte aux N+1 Eloquent, queries non-indexées, jobs synchrones et opcache mal configuré. J'interviens sur le backend Laravel pour faire baisser le TTFB et stabiliser les Core Web Vitals.

100% de clients satisfaits Données 2023-2026 8+ ans XP 35+ clients accompagnés
Voir mes cas clients

Ils me font confiance

CHANEL
DIOR
Decathlon
April Moto
SiriusXM
Make Up Forever
Camif
RIMOWA
Jimmy Fairly
Wecasa
Chronovet
CHANEL
DIOR
Decathlon
April Moto
SiriusXM
Make Up Forever
Camif
RIMOWA
Jimmy Fairly
Wecasa
Chronovet

Les symptômes Laravel qui appellent un audit

Les applications Laravel mal cadrées présentent des symptômes spécifiques que le diagnostic backend expose en quelques heures.

🔁 TTFB qui grimpe linéairement avec le volume de données

Pattern N+1 sur Eloquent : la page boucle sur N entités et requête leurs relations une par une. Telescope expose le motif, le refactor with() descend le TTFB de 30 à 60%.

🐢 Bootstrap Laravel non-optimisé en production

Sans config:cache, route:cache, view:cache et optimize, chaque requête recharge la config et compile les routes. Activation correcte gagne 50 à 150ms de TTFB.

💾 Sessions en database, pas en Redis

Avec sessions en BDD, chaque requête lit et écrit en SQL. Le passage en Redis sessions (et cache global Redis) descend le TTFB et libère MySQL pour les vraies queries.

📧 Envois d'emails et appels API synchrones

Un Mail::send() synchrone ajoute 200-500ms au temps de réponse. Le passage en queue Redis + Horizon déplace ces tâches hors du request lifecycle. Le TTFB ressenti utilisateur s'effondre.

⚙️ PHP 7.x ou opcache désactivé en production

PHP 8.x avec opcache et JIT divise le temps d'exécution par 2 à 4 sur du code Laravel. La mise à jour PHP et l'activation opcache + JIT sont les gains les plus rentables d'une stack PHP.

🚀 Trafic en hausse mais latence qui dérive

Sans Octane (Swoole, RoadRunner, FrankenPHP), Laravel bootstrap à chaque requête. Octane garde l'app en mémoire et descend le TTFB de 40 à 100ms gratuitement. À envisager dès 500 req/s soutenu.

Méthodologie d'optimisation Laravel

4 étapes pour transformer votre performance

1
Étape 1

1. Profiling Telescope ou Debugbar

Identification des N+1, des queries SQL lentes, des appels synchrones. Cartographie des endpoints LCP-critiques.

2
Étape 2

2. Optimisation Eloquent et MySQL

Refactor des N+1 (with(), load(), eager loading), ajout d'indexes SQL sur les vrais usages, optimisation des queries lentes via explain().

3
Étape 3

3. Caching et async

Redis pour cache et sessions, queue Horizon pour les jobs async (emails, exports, appels API), cache de routes/config/views en production.

4
Étape 4

4. Octane si pertinent

Évaluation Octane (Swoole, RoadRunner, FrankenPHP) selon le profil de trafic. Migration incrémentale avec tests de compatibilité (singletons, mémoire partagée).

Engagements de la mission

-50% TTFB Laravel typique
N+1 éliminés sur templates critiques
Continu Eloquent profilé sur chaque release
Queues async sur jobs lourds
FAQ

Questions fréquentes

Laravel Octane vaut-il la complexité ?
Sur des applications à fort trafic (>500 req/s soutenu) ou à TTFB critique, oui. Octane descend le TTFB de 40 à 100ms gratuitement. Sur des apps à trafic modéré, l'investissement (refactor singletons, gestion mémoire) ne se justifie pas systématiquement. L'audit tranche.
Telescope ou Debugbar pour le profiling ?
Debugbar pour le développement local et le quick-debug (overhead acceptable). Telescope pour le diagnostic continu, en local ou en staging : surtout utile pour identifier les N+1 et les queries lentes sur un trafic réaliste. Telescope en production reste possible mais à scoping serré pour éviter les coûts mémoire.
Faut-il passer à FrankenPHP ?
FrankenPHP combine PHP + serveur web (Caddy) + worker mode + early hints natif. C'est une alternative moderne et performante à PHP-FPM. À évaluer sur les nouveaux projets, à migrer prudemment sur des projets existants (compatibilité des extensions, monitoring).
Comment se structurent vos accompagnements Laravel ?
Mes accompagnements Laravel se déroulent en sprints continus. Le premier sprint cadre la stack (Eloquent, opcache, queues, Octane si pertinent) et la roadmap. Les sprints suivants déroulent les optimisations avec mesure avant/après et validation des releases. Une application Laravel active continue d'évoluer : la dette N+1 se reconstitue si personne ne profile à chaque release.

Faire baisser votre TTFB Laravel

Eloquent N+1 éliminés
Cache + queues optimisés
Octane si pertinent
100% de clients satisfaits
Données 2023-2026
Témoignages

Ce qu'en disent mes clients

Excellent travail.
Paul a nettement amélioré la vitesse du site et l’a parfaitement aligné avec les recommandations Google.
Professionnel, rigoureux et efficace, je recommande vivement.

Nicolas - April Moto

Directeur digital & e-commerce

Nous sommes très satisfaits du travail de Paul. Il se montre rapide, disponible et particulièrement efficace. Depuis son arrivée, de très bons résultats ont été constatés, tant en termes de performance que de réactivité. Un vrai atout pour notre équipe.

Léo - Maison de luxe

E-commerce Product Owner

Je sais pas si on l'a assez répété.
Mais si vous voulez améliorer votre vitesse de chargement,
Faire plaisir à Google et mettre vos Signaux Web Essentiels dans le vert,
Contactez Paul Delcloy.

Florian Darroman - Les Makers

Co-fondateur

Laravel, productivité haute et perf à cadrer

Laravel équipe une part importante du backend PHP français et international, des PME aux scale-ups. Sa productivité (Eloquent, queues, broadcasting, Livewire) permet de livrer vite, mais cette vitesse de développement masque facilement des problèmes de performance qui n'apparaissent qu'à charge réelle : queries N+1 sur Eloquent, jobs synchrones qui devraient être async, opcache désactivé en production, cache de routes et de config oubliés.

L'angle d'optimisation web performance sur Laravel est essentiellement backend : Eloquent profilé avec Telescope ou Debugbar, MySQL indexé sur les vrais usages, opcache + JIT PHP 8.x activé, Redis pour cache et sessions, Octane (Swoole ou RoadRunner) quand le profil de trafic le justifie, queues async via Horizon.

Eloquent et N+1, premier chantier

L'ORM Eloquent rend les jointures presque invisibles, ce qui est sa force et son piège. Une page qui boucle sur 50 entités et accède à leurs relations sans with() génère 51 queries SQL. Sur des templates LCP-critiques, ce pattern est l'une des premières causes de TTFB qui dérive.

Le diagnostic Laravel Telescope ou Laravel Debugbar expose les N+1 immédiatement. Le refactor (with(), load(), scopes optimisés) descend le TTFB de 30 à 60% sur les pages concernées. Sur certaines applications, c'est le levier qui suffit à passer les Core Web Vitals au vert.

Octane et queues pour la scale

Au-delà des optimisations classiques, Laravel propose Octane (Swoole, RoadRunner, FrankenPHP) qui maintient l'application en mémoire entre les requêtes. Le bootstrap Laravel n'est plus exécuté à chaque requête, le TTFB descend typiquement de 40 à 100ms gratuitement. Sur des stacks à fort trafic, Octane change l'économie de scale.

Les queues (via Redis ou SQS, monitorées par Horizon) déplacent tout ce qui peut être asynchrone hors du request lifecycle : envoi d'emails, génération de PDF, appels à des services tiers, calculs lourds. Chaque appel synchrone qui devient asynchrone libère de la latence ressentie utilisateur.