Laravel performance: speeding up an application without a rewrite

A Laravel application is most often slow not because of the framework but because of excessive database queries, missing caches and heavy work inside the user's request. Speeding it up usually starts with profiling, fixing N+1 queries, indexes, caching and moving long operations into queues. These steps deliver multi-fold gains without rewriting the project.

Here is how to find the slow parts, which optimisations give the biggest effect and when to move to Octane.

How do you find what is slow?

Profiling finds the slow parts: tools show how many database queries each page runs, which are slow and how much time goes to external calls. Optimising blind is pointless — you can spend a week on something that takes 2% of the time.

What to use:

• Laravel Debugbar or Telescope — in development, see the number and duration of queries on each page;
• the database slow query log in production;
• an APM service — shows the slowest endpoints and their breakdown on real traffic;
• a load test — shows how the application behaves at peak; see load testing.

How do you get rid of N+1 queries?

The N+1 problem occurs when code loads a list of records in one query and then runs another query per record for related data. For 50 orders that is 51 queries instead of two. The fix is eager loading with with().

// Bad: 1 query for orders + 50 queries for customers
$orders = Order::latest()->take(50)->get();
foreach ($orders as $order) {
    echo $order->customer->name;
}

// Good: 2 queries
$orders = Order::with('customer')->latest()->take(50)->get();

// Forbid lazy loading in development to catch N+1 immediately
Model::preventLazyLoading(! app()->isProduction());

Selecting only needed columns, withCount() instead of counting in a loop and indexes for frequent conditions also help — see PostgreSQL indexes.

Photo: Unsplash

Which settings speed up any Laravel application?

A set of settings speeds up any production application without code changes: caching config, routes, events and views, OPcache and a current PHP version. Put them in your deployment script.

Action	Effect
php artisan optimize	Caches config, routes, events and views
OPcache with file checks disabled	PHP does not compile code on every request
composer install --optimize-autoloader --no-dev	Fast class autoloading, no dev packages
Current PHP version	A speed gain from each language release
Redis for cache and sessions	Faster than files or the database

We wrote about new language versions in PHP 8.6 release candidate, and about Redis in Redis in a web project.

What should go into cache and queues?

Cache what is expensive to compute and rarely changes: the catalogue, menus, settings, heavy report results. Queue everything the user does not need to wait for: sending emails, generating PDFs, processing images, calling external APIs.

Caching:

1. Cache query results under a clear key and clear the cache when data changes.
2. Use cache tags to clear related entries at once.
3. Never cache personal data under a shared key.

Queues:

1. The user's request only dispatches a job and returns immediately.
2. Different jobs go to different queues with priorities.
3. Failed jobs are retried and, after several attempts, land in a separate list for review.

More in caching web applications and job queues.

When should you move to Laravel Octane?

Consider Octane when database queries and caching are already optimised and a significant share of response time goes to bootstrapping the framework. Octane keeps the application in memory between requests and removes that overhead, but you must watch for state leaking between users.

Before switching, check:

• that no static properties or singletons hold user data;
• that your packages work with a long-lived process;
• that a load test will show the real gain.

In short

• Start with profiling, not guesses.
• Fix N+1 with with() and forbid lazy loading in development.
• Enable config and route caching, OPcache and a current PHP version.
• Cache heavy data and move long operations into queues.
• Octane is the next step once everything else is optimised.