Laravel performance work is a sequence, not a bag of tricks. You measure to find the real bottleneck, fix the database access that causes most slowness, then layer on caching, queues and finally Octane. Doing it in that order means each step compounds the previous one instead of hiding a problem you never fixed.

Measure before optimizing

Never guess at a bottleneck. Use Telescope on staging to inspect queries, requests and jobs in detail (keep it behind auth, never open in production). Use Debugbar or Clockwork locally to see the query count and timing per request. For production, the database slow query log and a quick DB::listen probe tell you which queries actually hurt.

N+1 queries and eager loading

The single most common cause of a slow Laravel endpoint is a loop that lazy-loads a relation, turning one page into dozens of near-identical queries. Fix it with with, withCount and loadMissing, and in non-production call preventLazyLoading so any lazy load throws and the problem surfaces in tests instead of production.

// N+1: one query for orders, then one per order for the customer
$orders = Order::latest()->limit(50)->get();
foreach ($orders as $order) {
    echo $order->customer->name;
}

// Fixed: two queries total
$orders = Order::with('customer')->latest()->limit(50)->get();

// app/Providers/AppServiceProvider.php
Model::preventLazyLoading(! app()->isProduction());

Database indexes

Run EXPLAIN on the slow queries. Index the columns used in WHERE, ORDER BY and JOIN. For a composite index, order the columns from most selective to least, and match the order the query filters in. A query that filters and sorts on the same columns an index covers never touches the table rows.

Schema::table('orders', function (Blueprint $table) {
    $table->index(['status', 'created_at']); // filter by status, sort by date
});

Query hygiene for large datasets

Select only the columns you use, so a wide table does not ship megabytes you throw away. Never load a large result set into memory at once: use lazy or cursor to stream rows, chunkById for batch jobs, and paginate every list endpoint.

Order::where('status', 'pending')
    ->select(['id', 'customer_id', 'total'])
    ->lazy()
    ->each(fn (Order $order) => $order->reconcile());

Targeted caching

Cache expensive reads that are repeated far more often than they change, not every query. Cache tags let you invalidate one slice without flushing everything, which keeps writes cheap. Cache the computed result, not the whole HTTP response, unless the page is fully cacheable.

$topProducts = Cache::tags(['products', 'dashboard'])
    ->remember('top-products', now()->addMinutes(30), function () {
        return Product::withCount('orders')
            ->orderByDesc('orders_count')
            ->limit(10)
            ->get();
    });

// Invalidate only the products slice
Cache::tags(['products'])->flush();

Move heavy work to queues

Emails, exports, PDF generation and third-party calls do not belong in the request cycle. Dispatch them to a queue and return immediately. Horizon gives real-time metrics on throughput, wait time and failures, so jobs stop disappearing silently into failed_jobs. Use job batching when a task fans out into many units of work.

HTTP-level caching

Add ETag and Cache-Control headers to GET endpoints whose data changes slowly, so clients and proxies can serve a 304 instead of a full response. Serve assets from a CDN. For pages that are identical for every visitor, a full response cache in front of Laravel removes the framework from the hot path entirely.

Deployment-time caches

On every deploy, run config:cache, route:cache, view:cache and event:cache so Laravel does not rebuild them per request. Enable OPcache on the server, and install with composer install --optimize-autoloader --no-dev. These are free wins that are easy to forget.

Octane, last

Traditional PHP-FPM boots the whole framework on every request. Octane, on FrankenPHP or Swoole, keeps the application in memory between requests and cuts a meaningful slice off response time under load. It is a multiplier on an app that is already fast, not a fix for a slow one, and it introduces state-leak pitfalls: no mutable static state, careful handling of container singletons.

// Dangerous with Octane: static state persists across requests
class ReportCache
{
    private static array $cache = []; // leaks between requests, avoid
}

Follow the order: measure, fix queries and indexes, tidy the data access, then cache, queue and cache HTTP, and only then Octane. Most Laravel apps get the bulk of their speed back in the first two steps, and the rest of the list keeps it fast as traffic grows.