The Laravel system is slow and nobody can say why. Measure first, then fix, without stopping the people who use it
For software houses and companies with a Laravel system in production for years, where every screen is heavy and every change is scary. A senior joins the repository on Monday; the numbers arrive within the week.
Do you recognise at least two of these?
- The order list takes eight seconds to open, and "with more data it will get worse".
- The customer calls in the morning because the system "is down", and the cause is not in the logs.
- Every optimisation attempted broke something else: now nobody touches that part.
- Someone proposed rewriting everything: eighteen months and a six-figure quote.
- The server has already been doubled twice, and the slowness came back.
If you said yes at least twice, the problem is not the server: it is that nobody has measured where the time goes yet.
What does a slow screen really cost?
- Eight seconds to open a list used twenty times a day by ten people is more than 100 hours a year spent watching a spinner.
- One half-day outage a month, for ten people, is 60 hours a year plus the customers kept waiting.
- A doubled server costs every month; the query without an index costs one hour, once, if someone finds it.
- An eighteen-month rewrite also costs the eighteen months in which the old system stays slow.
Where do you start with a slow Laravel system?
With measurement, not opinion. The first week produces numbers, not promises.
- Query log per screen: how many, how heavy, which repeat (the classic Eloquent N+1, one query per row).
- Profile of the slowest requests in production, with real user timings, not the developer's laptop.
- Missing indexes and hot tables: often 20% of tables take 80% of the time.
- Work outside the request: emails, PDFs, exports and calls to external services that block the user today and belong in a queue tomorrow.
- Cache where it helps, and only there: a cache placed at random hides the problem for a month.
At the end of the week there is a report with the ten causes ranked by cost and risk, and the first fix already in production.
How do you fix it without stopping the people who use it?
- A test before every fix, describing the current behaviour: so the fix does not break something else. My own repository runs 1,480 tests on every push, and PHPStan blocks regressions before deploy.
- Small, measured fixes: one query, one index, one queue at a time, with the before and after times written in the ticket.
- No rewrite: the work happens in your repository, with your pipeline; the code stays yours, with tests.
- Users do not notice: releases are small and reversible, outside peak hours.
The three fixes worth most, in almost every system seen in fourteen years: N+1 on lists, indexes on filter keys, and heavy work moved to a queue. A rewrite is rarely needed, and when it is, it happens one module at a time.
Who does it, and why you can trust it
Fourteen years of PHP and Laravel in five software houses, the last six as tech lead; today industrial systems in production in six sectors. The method is public: this site's repository has 350,000 lines, PHPStan in CI and an error baseline that can only go down. Interventions with before-and-after numbers are anonymous and told in the call, with the consent of those who commissioned them.
How much does it cost?
By the day, at market rates: from 600 to 800 € a day for a senior Laravel developer inside your team, from 700 to 900 € for application security and penetration testing with a report. The first week is by the day and can be stopped: if after five days you do not see better numbers, you keep the report anyway. The full price list and the page senior Laravel developer for software houses.
The next step is small: 30 free minutes with read access to the repository or one day of logs. You get a document with the three points to start from, yours even if you stop there.