Web performance consultant back-end
Server TTFB under control, performant backend
ORM N+1, unindexed queries, blocking synchronous jobs. I optimize Laravel, Symfony, Django and infrastructure to bring server response time down for the long run.
Ils me font confiance
Backend symptoms calling for an audit
Backend sets the performance ceiling. As long as it's not addressed, frontend optimizations have limited effect.
⏱️ TTFB above 600ms on strategic pages
PageSpeed flags a red TTFB without giving the cause. APM traces immediately surface the slow SQL query, the blocking third-party service, the costly deserialization.
🔁 N+1 queries nobody sees
ORM makes joins invisible. A page looping on 50 entities and accessing relations without with() triggers 51 queries. Telescope, Symfony Profiler, django-silk expose the pattern immediately.
📊 Non-indexed SQL queries on hot tables
EXPLAIN on slow queries identifies full scans. Adding indexes adapted to the access pattern drops query time 10x to 100x.
🔌 Third-party calls blocking rendering
Synchronous authentication, fraud scoring, marketing webhooks, remote cache. APM Service Map makes them visible. We desync, we cache, we move.
💾 No object cache, no Redis
DB sessions, options re-queried every page, uncached fragments. Redis for cache and sessions drops TTFB without touching application code.
⚙️ PHP 7.x or Python 3.10, opcache disabled
PHP 8.x + opcache + JIT divides execution time by 2 to 4. Python 3.11+ brings significant interpreter gains. Runtime upgrade is the most cost-effective stack gain.
The backend stacks I optimize
Laravel (Eloquent, opcache, Octane), Symfony (Doctrine, HTTP cache, FrankenPHP), Python (Django ORM, async, gunicorn). With Datadog or Dynatrace instrumentation based on what's in place.
Mission commitments
Frequently asked questions
Laravel, Symfony, Django: which has the best performance?
How do I know if my backend is the bottleneck?
Should I move to async (Octane, FrankenPHP, FastAPI)?
How are your backend engagements structured?
Drop your backend TTFB
Data 2023-2025
Ce qu'en disent mes clients
Excellent work.
Paul has significantly improved the site's speed and perfectly aligned it with Google's recommendations.
Professional, thorough, and efficient, I highly recommend.
Nicolas - April Moto
Digital & E-commerce Director
We are very satisfied with Paul's work. He is quick, available, and particularly effective. Since his arrival, very good results have been observed, both in terms of performance and responsiveness. A real asset for our team.
Léo - Luxury brand
E-commerce Product Owner
I don't know if we've said it enough.
But if you want to improve your loading speed,
Make Google happy and get your Core Web Vitals in the green,
Contact Paul Delcloy.
Florian Darroman - Les Makers
Co-founder
TTFB, the glass ceiling of performance
Time To First Byte sets the floor of the entire rendering chain. The browser can't start anything until the server has responded. An 800ms TTFB means that even with a perfectly optimized frontend, LCP won't drop below 1.5 to 2 seconds.
It's a finding I make regularly in audits: teams invest weeks on lazy loading and image compression, while the real bottleneck is a 1.2-second server response time on category pages. As long as the backend isn't addressed, frontend optimizations have limited effect.
The usual causes
Backend performance problems look the same from one project to the next. N+1 queries turning the display of a 50-product catalog into 200 database calls. Application cache configured but invalidated too often, or not at all. Synchronous calls to third-party APIs (ERP, search engine, stock service) blocking rendering until they respond.
Instrumentation is the starting point. Without visibility into what happens inside a request, you guess. Dynatrace, Datadog, New Relic: the tool matters little — what counts is being able to trace an HTTP request end-to-end and see exactly where time is spent. On an e-commerce checkout, the difference between "the server takes 8 seconds" and "the server takes 8 seconds, including 5 waiting on the ERP response" completely changes the approach.
Cache and invalidation strategy
Cache is probably the most powerful and most underused lever in backend. A well-configured page cache can divide TTFB by 10 on high-traffic pages. The complexity sits in invalidation: when a price changes, when a product runs out, when a promotion starts.
Most implementations I see are either too aggressive (5-minute cache serving stale prices), or too conservative (global invalidation on every modification, which amounts to having no cache at all). An efficient strategy is granular: it invalidates precisely what changed, not the whole catalog.
Performance and infrastructure costs
A backend consuming less CPU per request needs fewer servers to handle the same traffic. On cloud architectures billed by usage, code optimization translates directly to the bill. Optimized SQL queries, efficient cache, parallelized external calls: it adds up. The user performance gain is almost a bonus next to the cost reduction.
My backend expertise pages
- Laravel: Eloquent N+1, opcache, Octane, async queues
- Symfony: Doctrine, HTTP cache, ESI, FrankenPHP
- Python: Django ORM, async views, gunicorn, FastAPI
- Datadog: APM, traces, P95, continuous profiling
- Dynatrace: Smartscape, PurePath, auto baseline
On CMSs, my backend interventions cover WordPress, Drupal, Magento, Shopify and Prestashop.
For a complete intervention covering backend + frontend + CDN, my web performance audit remains the most effective entry point.
Explorer mes autres pages consultant
Web performance consultant CDN
Independent web performance consultant — I optimize your CDNs (Akamai, Cloudflare, Fastly) to drop TTFB, accelerate LCP and stabilize Core Web Vitals.
DécouvrirWeb performance consultant front-end
Independent front-end web performance consultant. I optimize your React, Angular, Astro, third-party scripts and critical path for green Core Web Vitals.
Découvrir