Laravel performance optimization tips

Hey, fellow PHP developers. Picture this: it's 2 AM, your Laravel app is buckling under traffic from a sudden viral post, and you're staring at the New Relic dashboard watching response times climb past 2 seconds. That sinking feeling in your gut? We've all been there. I've lost count of the nights I've pulled debugging that one rogue query killing the party.

But here's the thing—Laravel performance isn't some dark art. It's patterns, choices, and a bit of ruthless prioritization. Over years of shipping apps that handle thousands of users, I've learned what sticks. These aren't theoretical tips pulled from docs. They're scars from production fires, quiet wins in the glow of a terminal, and those rare moments when a deploy feels like poetry.

Let's dive in. We'll unpack the low-hanging fruit first, then the deeper cuts that separate good apps from bulletproof ones. Grab your coffee. This'll take a bit.

Why Laravel slows down (and why you care)

Laravel's magic—Eloquent, middleware, facades—comes at a cost. Every request boots the framework, scans routes, resolves dependencies, hits the database. Fine for prototypes. Murder for scale.

Remember that e-commerce site I worked on last year? Black Friday hit, and cart pages went from 200ms to 5 seconds. Not because of traffic alone. N+1 queries. Uncached views. A queue clogged with email jobs. Users bounced. Revenue dipped 15% that day.

You care because slow apps lose users. Google ranks fast sites higher. Users feel the lag subconsciously. And in PHP land, where we're often stereotyped as "slow," every millisecond counts toward proving Laravel's chops.

Have you profiled your app lately? Fire up Laravel Telescope or Pulse. Watch the queries fly. That's your wake-up call.

Caching: Your first line of defense

Caching isn't optional. It's oxygen.

Route and config caching

Routes get parsed every request. Brutal for apps with hundreds of them. Cache 'em.

php artisan route:cache
php artisan config:cache

Boom. Routes serialize to a single array. Config merges into one file. On a mid-sized API I optimized, this shaved 150ms off cold starts. But heads up: no closures in routes. Controllers only.

// Bad for prod
Route::get('/profile', function () { return view('profile'); });

// Good
Route::get('/profile', [ProfileController::class, 'show']);

Clear on deploys: php artisan route:clear && php artisan config:clear. Forget this, and you're debugging ghosts.

View caching

Blade compiles on-the-fly. Cache those views too.

php artisan view:cache

For a dashboard-heavy app, this cut render time by 40%. Views live in storage/framework/views—nuke 'em when templates change.

Application-level caching with Redis

File cache? Cute for toys. Redis for real apps. Install it, swap in config/cache.php:

'default' => env('CACHE_DRIVER', 'redis'),

Tag your cache:

Cache::tags(['users', 'posts'])->put('user.1', $user, 300);
Cache::tags(['users'])->flush(); // Invalidate smartly

I once cached a feed query fetching 50 user posts. Hit rate jumped to 85%. Pages flew.

Short tip: Lazy cache. Check Cache::has() before Cache::get() or remember().

Database: Where most pain hides

Databases are the silent killer. 80% of perf issues trace here.

Hunt the N+1 monster with eager loading

Eloquent's lazy loading is a trap. Loop over users, access posts? Boom, N+1 queries.

// Death: 1 + N queries
$users = User::all();
foreach ($users as $user) {
    echo $user->posts->count();
}

// Life: 2 queries total
$users = User::with('posts')->get();

On a forum app, this dropped query count from 500 to 20 per page. Users felt it instantly—scrolling buttery smooth.

Chunk large sets:

User::chunk(1000, function ($users) {
    foreach ($users as $user) { /* process */ }
});

No memory explosions.

Indexes and query tweaks

Profile with DB::enableQueryLog(). Spot slow ones. Index WHERE, JOIN, ORDER BY columns.

ALTER TABLE posts ADD INDEX idx_user_created (user_id, created_at);

Select lean:

Post::select('id', 'title', 'created_at')->where('published', 1)->get();

No SELECT *. Ever.

Real story: A client's analytics dashboard queried 10M rows unindexed. Added composite index—query from 8s to 50ms. They cried happy tears.

Queues: Offload the heavy lifting

Synchronous emails? Image resizing? PDF gen? You're poisoning your web requests.

Queues fix it. php artisan queue:work in Supervisor. Redis or database driver.

// In controller
SendWelcomeEmail::dispatch($user);

// Job class
class SendWelcomeEmail implements ShouldQueue
{
    public function handle()
    {
        Mail::to($this->user)->send(new WelcomeMail());
    }
}

That Black Friday site? Queued cartsync and emails. Web tier breathed free, handling 10x load.

Pro tip: Rate limiting. dispatch()->delay(now()->addMinutes(5)). Failed jobs? Horizon for monitoring.

Frontend and assets: Don't neglect the browser

Your backend might scream at 50ms, but bloated JS kills the page.

Vite and asset bundling

Laravel 9+ ships Vite. Minify, bundle, tree-shake.

// vite.config.js
export default defineConfig({
  plugins: [laravel(['resources/js/app.js', 'resources/css/app.css'])],
});

npm run build. CSS/JS into chunks. 200kb gzipped? Solid.

CDN it. Cloudflare or AWS. Static files from edge servers—latency plummets for global users.

Minimize requests

• Sprite images (or SVGs inline).
• Lazy-load below-fold images: <img loading="lazy">.
• Critical CSS inline, rest async.

A news site I tuned: Bundle + CDN dropped TTI from 3s to 800ms. Bounce rate halved.

Advanced: Octane, OPcache, and server tweaks

You're scaling now.

Laravel Octane

Boots once, serves thousands. Swoole or RoadRunner.

composer require laravel/octane
php artisan octane:install --server=swoole
php artisan octane:start

20x throughput on APIs I've tested. Memory persistent. Stateful? Careful with sessions.

PHP-FPM and OPcache

opcache.enable=1 in php.ini. Preload classes:

// bootstrap/preload.php
<?php
require __DIR__.'/../vendor/autoload.php';
app('Illuminate\\Contracts\\Console\\Kernel')->bootstrap();

FPM pools tuned: pm.max_children=50, match your CPU.

Nginx? Static files direct, gzip on.

Monitoring: Know before it breaks

Telescope for dev. Pulse for prod—lightweight dashboards.

New Relic or Blackfire for deep profiles. Set alerts on 500ms thresholds.

A/B test changes. ab -n 1000 -c 50 url. Before/after.

Common pitfalls I wish I dodged earlier

• Forgotten caches on deploy. Script it: php artisan optimize:clear && php artisan config:cache.
• Over-eager eager loading. with('posts.comments.users') explodes if deep. Scope wisely.
• Sessions in files. Redis. Files block under load.
• No database connection pooling. PGBouncer for Postgres.
• Ignoring composer autoload. composer install --optimize-autoloader --no-dev.

Here's a deploy checklist:

• composer install --optimize-autoloader --no-dev
• php artisan config:cache
• php artisan route:cache
• php artisan view:cache
• php artisan queue:restart
• php artisan octane:reload (if using)

When to call in reinforcements

Some apps need pros. If you're hiring, look for Laravel badges on find-php.com. Resumes with Octane/Redis experience. Interviews? Ask for N+1 fixes.

I've mentored devs who turned sluggish monoliths into lean machines. That shared spark when metrics drop—pure joy.

Friends, optimization isn't a one-off. It's rhythm. Profile often. Cache aggressively. Queue everything slow. Your users will thank you in silence, sticking around longer, converting higher.

Next time that 2 AM alert pings, you'll smile. You've been here before. And you know exactly what to do.

That quiet confidence? It grows with every tuned deploy. Keep building.