Laravel performance optimization for slow apps and heavy databases

This service is about the server side of a Laravel or PHP application: how long the app takes to build a response, how hard it works the database, and how it behaves as data and traffic grow. The symptoms are a high time to first byte, a dashboard that takes ten seconds to open, reports that time out, API calls that a mobile app gives up on, or a server whose CPU sits at full load every month end.

It is not front-end speed work. If your problem is heavy images, render-blocking scripts and Core Web Vitals on a content site, that is a different job, covered on my WordPress speed optimization page. A fast front end cannot hide a six-second database query, and a fast backend cannot fix an oversized hero image. Often both matter, and I will tell you which one is costing you more.

The causes repeat from app to app. Eloquent makes it easy to write code that is correct on test data and slow on real data, and the slowdown arrives gradually, so nobody notices the week it started.

• N+1 queries. A list of 50 orders that loads each customer separately runs 51 queries. Eager loading with with() makes it two. Model::preventLazyLoading() in development catches new ones before they ship.
• Missing or misordered indexes. An index on status does not help a query filtering on company_id and a date range. Column order in a composite index matters, and wrapping a column in a function (whereDate() compiles to DATE(created_at)) stops MySQL using the index at all.
• Loading too much. Model::all() on a two-million-row table, or get() followed by a count in PHP, instead of chunkById(), lazy() or a SQL aggregate.
• Deep offset pagination. Page 5,000 of a list makes MySQL read and throw away every row before it. Cursor pagination stays quick at any depth.
• Work done inside the request. Sending mail, building PDFs or calling a slow external API while the user waits, instead of in a queued job.
• Leading wildcards. LIKE '%term%' cannot use a normal index; a FULLTEXT index or a dedicated search tool can.
• Untuned production settings. APP_DEBUG left on, no config or route cache, OPcache disabled, file sessions on a busy server.

I measure first and change second. On a copy of production data, or a realistic volume of seeded data, I record response times, query counts and memory use, then read the EXPLAIN plan for each slow query. EXPLAIN ANALYZE in MySQL 8 shows where the rows and the time actually go, which is often not where the code suggests.

Then I fix in order of payoff. Query and index changes usually come first because they are cheap and low risk. Caching comes second, and only with a clear rule for when each cache is cleared, because a fast page showing yesterday's balance is a bug, not a gain. Queues and structural changes such as partitioning come last, because they change how the system runs day to day.

Laravel performance tuning must not change behavior. Every change is checked against the same results as before, and anything involving money, stock or document numbering keeps its transactions and row locks exactly as they were.

On a brokerage risk platform where I was a core developer, report tables gained rows every day across more than 1,000 trading accounts, and deleting history was not an option. The largest tables are partitioned by week, and a scheduled job adds the next partition automatically, so a report reads only the weeks it needs. The trade-off is honest: partition maintenance becomes a job that must never be missed, so it is watched.

On the same platform, data arrives from external trading systems on their own schedules, so ingestion runs in scheduled and queued jobs rather than in web requests. That pattern (accept quickly, process in the background, make each job safe to retry) is what keeps response times flat as volume grows. Uploads follow the same thinking: on an export operations ERP, large order batches are imported in batches instead of in one long request that times out halfway.

You work directly with the developer who profiles and changes the code. I write Laravel and MySQL every day, including queues, transactions and row-level locking, so I can tell a slow query from a slow design and fix the right one. I am based in India and work remotely with clients in different time zones; we agree on update times at the start.

I also explain what I find. You get the numbers before and after, the reason for each change, and a short list of what to watch as data grows, so your own team can keep the app quick. If you want to check the basics yourself first, my Laravel performance checklist is a free starting point.

Cost depends on how many slow areas there are, the size of the data, whether I can test against a production-sized copy of the database, whether automated tests exist to confirm nothing changed, and whether server tuning is in scope. One slow report is a small job; an app that slows down everywhere under load is a larger one.

I usually start with a short audit: a profile of your slowest pages and jobs and a prioritized list of fixes with the expected effect of each. You then get a fixed quote for the fixes after a short call or written brief. A hosting upgrade is the last resort, not the first, because more CPU rarely makes up for a missing index.