Knowledge

How to improve Laravel performance

#Performance

Laravel performance is mostly a configuration problem. Here are the production caches, queue offloading, and server tweaks that give you the biggest speedups for the least effort.

Published by Mark van Eijk on June 23, 2026 · 4 minute read

  1. Run the production caching commands
  2. Optimize the Composer autoloader
  3. Fix N+1 queries with eager loading
  4. Offload slow work to queues
  5. Use a fast cache and session driver
  6. Enable OPcache on the server
  7. Speed up the frontend
  8. Conclusion

Laravel is fast out of the box, but the default development setup leaves a lot on the table. Most Laravel performance problems aren't the framework, they're a missing cache or an N+1 query. This guide walks through the changes that actually move the needle, in rough order of impact: production caching, the autoloader, query patterns, queues, drivers, and OPcache.

Run the production caching commands

In development, Laravel re-parses your config, routes, and views on every request so changes show up instantly. In production that's wasted work. The framework can compile each of these into a single cached file.

php artisan config:cache
php artisan route:cache
php artisan view:cache
php artisan event:cache

Or run them all at once:

php artisan optimize

This is the single biggest Laravel performance win and it costs nothing. The catch: these caches are snapshots. Any change to a config, route, or .env value won't take effect until you rebuild them, so the caches must be cleared and rebuilt on every deploy. See clearing Laravel caches for the full set of clear commands.

One gotcha with config:cache: once config is cached, env() returns null outside of config files. Always read environment values through config() in your app code.

Optimize the Composer autoloader

By default Composer's autoloader maps namespaces to directories and hits the filesystem to find each class. In production you want a flat, pre-computed class map instead, and you want to skip dev dependencies entirely.

composer install --optimize-autoloader --no-dev

--optimize-autoloader builds a single classmap so every class resolves in one lookup. --no-dev drops packages like PHPUnit and Faker that have no business running in production. Run this as part of your deploy, not on your laptop.

Fix N+1 queries with eager loading

After caching, the most common Laravel performance killer is the N+1 query. It happens when you loop over a collection and lazily access a relationship, firing one query per row.

// 1 query for posts, then 1 query per post for its author = N+1
$posts = Post::all();

foreach ($posts as $post) {
    echo $post->author->name; // queries the authors table every iteration
}

Eager load the relationship with with() so it's fetched in a single extra query:

// 2 queries total, no matter how many posts
$posts = Post::with('author')->get();

foreach ($posts as $post) {
    echo $post->author->name; // already loaded
}

You can catch these automatically in development with Model::preventLazyLoading() in a service provider, which throws when a relationship is lazy-loaded.

Eager loading reduces the number of queries. The speed of each query is a database concern: make sure the foreign-key columns you join on are indexed, or every query still does a full table scan. See how database indexing works for the underlying DB side.

Offload slow work to queues

Sending email, processing images, calling third-party APIs, generating PDFs, none of it needs to happen inside the request. Push it onto a queue so the user gets an instant response and the work runs in the background.

// Instead of sending inline
Mail::to($user)->send(new WelcomeEmail($user));

// Queue it
Mail::to($user)->queue(new WelcomeEmail($user));

Any job can be queued by dispatching it:

ProcessPodcast::dispatch($podcast);

Run a worker to process the queue, and keep it alive with a process manager like Supervisor:

php artisan queue:work --tries=3

This moves latency out of the request path, which is often the difference between a 1.5-second page and a 150-millisecond one.

Use a fast cache and session driver

The default file driver writes cache and session data to disk, which is slow and doesn't scale across multiple servers. Switch to Redis for both.

CACHE_STORE=redis
SESSION_DRIVER=redis
QUEUE_CONNECTION=redis

Redis is an in-memory store, so reads and writes are sub-millisecond, and it works as a shared backend when you scale to more than one app server. See using Redis for the Laravel cache for setup and patterns. If your worker can't reach it, check Redis connection refused in Laravel.

Enable OPcache on the server

PHP recompiles your scripts to bytecode on every request unless OPcache is enabled. OPcache keeps the compiled bytecode in memory, eliminating that work entirely. It's the highest-impact server-side change you can make and applies to any PHP app. See enabling OPcache in PHP for the recommended php.ini settings, and general PHP performance tuning for more.

Speed up the frontend

Backend speed is only half the page. Bundle and minify your assets with Vite, which ships with modern Laravel:

npm run build

This produces hashed, minified, tree-shaken bundles and lets the browser cache them aggressively. On the response side, cache rendered output for pages that don't change per-user (marketing pages, docs) and lean on HTTP caching headers so repeat visits skip the server entirely.

Conclusion

Laravel performance comes down to a short checklist: run php artisan optimize and clear it on deploy, build the autoloader with --optimize-autoloader --no-dev, eliminate N+1 queries with with(), push slow work to queues, use Redis for cache and sessions, and enable OPcache. Do these and a stock Laravel app handles serious traffic before you ever need to think about the framework itself.

Subscribe to our newsletter

Do you want to receive regular updates with fresh and exclusive content to learn more about web development, hosting, security and performance? Subscribe now!

Related articles

How to optimize server performance

Laravel performance is mostly a configuration problem. Here are the production caches, queue offloading, and server tweaks that give you the biggest speedups for the least effort.

Read more →

How to measure TTFB (Time To First Byte)

Laravel performance is mostly a configuration problem. Here are the production caches, queue offloading, and server tweaks that give you the biggest speedups for the least effort.

Read more →