Slow Laravel apps usually do not happen because Laravel is inherently slow. They happen because an application has crossed a complexity threshold: more tenants, larger tables, longer reports, heavier integrations, and more user workflows than the original design anticipated. For a SaaS company or operational platform, that slowdown is not cosmetic. It affects support volume, revenue, adoption, and trust.
The right question is not: How do we make Laravel faster? The better question is: Which part of this system is consuming time, memory, IO, or human confidence, and what is the safest fix?
Below is a pragmatic guide to the Laravel performance bottlenecks we see most often, how to diagnose them, and how to fix them without turning a live product into a rewrite project.
Start with evidence, not opinions
Performance work goes sideways when teams start with preferred solutions. Someone wants Redis. Someone wants Octane. Someone wants to rewrite the front end. Those may be valid later, but first, you need a baseline.
For each important workflow, capture:
Response time at p50, p95, and p99
Number of database queries per request
Slowest queries and their execution plans
Queue depth and job duration
External API latency and failure rate
Memory usage, timeouts, and error rate
Front-end load time for user-facing screens
Use Laravel Telescope, Debugbar, Clockwork, query logs, and local profiling during development. In production, use application performance monitoring, structured logs, database slow query logs, and metrics. Ravenna has a separate guide to Laravel observability with logs, metrics, and traces if you need the operational layer around this work.
Performance is not a single metric. A screen can feel slow because the controller runs 80 queries, because one query scans millions of rows, because a third-party API blocks the request, or because the browser receives a huge payload. The fix depends on the bottleneck.
Symptom | Likely bottleneck | First place to look |
|---|---|---|
Local page is fast, production page is slow | Data volume, indexes, external services, infrastructure | Slow query logs, APM, database metrics |
Page runs hundreds of queries | N+1 relationships or serialization | Telescope, Debugbar, Eloquent resource code |
API times out during checkout, signup, or upload | Synchronous IO or heavy processing | Controller actions, jobs, HTTP client calls |
Admin reports lock up the system | Reporting queries on transactional tables | EXPLAIN plans, indexes, report design |
Users see stale or incorrect data after caching | Cache invalidation or tenant scoping | Cache keys, events, authorization boundaries |
Releases make performance unpredictable | Missing test coverage and no performance baseline | CI checks, smoke tests, deployment runbooks |
1. N+1 queries and over-chatty Eloquent
N+1 queries are the classic Laravel performance issue. They happen when a list of records is loaded, then each record triggers additional relationship queries during rendering or serialization. A page showing 50 projects can become 101 queries, then 300 queries after the next feature.
This often appears in Blade templates, API resources, Livewire components, policies, notification templates, and accessors. The application works fine with small seed data, then becomes painfully slow with real customers.
The fix is not to avoid Eloquent. The fix is to use it deliberately.
Use eager loading for relationships you know the view or response needs. Use withCount when you need counts instead of entire collections. Select only the columns needed for the workflow. Watch for hidden relationship calls inside accessors or computed attributes.
$projects = Project::query()
->with(['client', 'owner'])
->withCount('tasks')
->latest()
->paginate(50);Laravel can also help you catch accidental lazy loading in non-production environments. That turns a class of performance bugs into something developers see before it reaches production. See the Laravel Eloquent documentation for relationship loading patterns and constraints.
The key trade-off: do not eager-load everything by default. Over-eager loading can move the problem from too many queries to too much memory. Load what the user needs for that screen, not what might be useful someday.
2. Missing indexes and inefficient database access
If Eloquent N+1 issues are the visible performance problem, missing or poorly chosen indexes are the quiet one. The app may have reasonable query counts, but a single-table scan can dominate response time as a table grows.
Common triggers include filtering bytenant_id, sorting by created_at, searching by status, joining on foreign keys, and looking up records by external IDs. Multi-tenant SaaS apps are especially sensitive because every important query should usually be scoped to the current tenant.
A practical fix starts with the actual query plan. Run EXPLAIN on the slow query. Confirm which indexes the database uses, whether it unnecessarily scans rows, and whether the order of columns in a composite index matches your filters and sort order.
For example, if a common page queries invoices by account, status, and date, an index that reflects that access pattern may matter more than several isolated single-column indexes.
Schema::table('invoices', function (Blueprint $table) {
$table->index(['account_id', 'status', 'created_at']);
});Database performance is application design. A feature that lets users filter across ten optional fields may need a different approach than adding ten indexes and hoping. You may need denormalized search tables, dedicated reporting views, full-text search, or a search service, depending on scale and requirements.
Be cautious with:
Leading wildcard searches such as
LIKE '%term%'on large tablesOffset pagination on very deep result sets
Sorting by computed values that cannot use an index
Reports that join large transactional tables during business hours
Polymorphic relationships that hide expensive joins
The most important habit is reviewing query plans before a workflow becomes critical. Indexes are cheap compared with emergency rewrites after customers are already waiting.
3. Unbounded pages, huge payloads, and memory pressure
Many Laravel performance problems come from loading too much at once. The database query might be acceptable, but the application hydrates thousands of models, transforms them into nested JSON, and sends a response the user never needed.
This is common in admin dashboards, exports, search pages, and internal tools where the first version was built for a small team. Later, the same workflow carries years of data.
Fix this at the product boundary. Paginate lists. Use cursor pagination for large, continuously ordered datasets. For APIs, return the fields needed for the screen, not the entire object graph. For exports, stream or queue the work rather than building one massive in-memory response.
This matters in regulated and workflow-heavy domains. Consider a mortgage or lending platform, where users may upload documents, track approvals, review terms, and complete e-signatures. Providers such as New Era Lending show how much modern financial workflows depend on fast, clear, secure digital interactions. In a Laravel product serving similar operational workflows, an unbounded document list or slow status screen can quickly become a business problem.
Laravel gives you tools such as pagination, lazy collections, chunking, and queues. The architectural decision is deciding which workflows must be immediate and which can be generated in the background with a notification when ready.
4. Synchronous work in the request cycle
A request should do the minimum work needed to give the user a correct response. It should not generate a large PDF, send a dozen emails, resize images, call three external APIs, reconcile billing, and update analytics before the browser receives anything.
Synchronous work is one of the biggest causes of timeouts in Laravel applications. It also makes reliability worse because an external service outage can take down a core user workflow.
Good candidates for queues include:
Email, SMS, and push notifications
PDF and spreadsheet generation
Image resizing and media processing
Webhook delivery and retry
Third-party API synchronization
Billing reconciliation and post-payment workflows
Long-running imports and exports
Laravel queues are mature, but using queues well is more than dispatching a job. Jobs need timeouts, retries, backoff, idempotency, and failure handling. Queue workers need monitoring and deployment discipline. If a job can run twice, it should not double-charge a customer or duplicate a record.
For business-critical workflows, design the request around state transitions. For example, mark an export aspending, dispatch the job, show the user progress, then mark it ready when the file is available. That is usually better than making the user stare at a spinner for 45 seconds.
5. Cache problems: not enough, too much, or the wrong key
Caching can make Laravel feel dramatically faster, but poor caching can lead to data leaks, stale screens, and debugging nightmares. The goal is not to cache everything. The goal is to cache expensive work for which freshness requirements are well understood.
Start with safe framework-level optimizations. In production, Laravel recommends caching configuration, events, routes, and views where appropriate. The Laravel deployment documentation covers these optimization commands and related production concerns.
Application-level caching requires more design. Cache expensive lookup data, permission maps, navigation structures, computed dashboard numbers, or API responses when the expiration and invalidation rules are clear.
The dangerous cases are usually tenant-specific or user-specific. A cache key dashboard_stats is a bug waiting to happen in a multi-tenant SaaS application. Prefer keys that include the tenant, user, filters, and version when needed.
A useful caching checklist:
Question | Why it matters |
|---|---|
Who is allowed to see this cached data? | Prevents tenant or permission leaks |
How stale can it be? | Defines TTL and refresh strategy |
What event should invalidate it? | Keeps data correct after writes |
How expensive is regeneration? | Prevents cache stampedes |
What happens if the cache is empty? | Ensures the app degrades safely |
If you cannot answer those questions, you may not have a caching problem yet. You may have a data modeling or query design problem.
6. Slow third-party integrations
Modern Laravel applications rarely live alone. They talk to Stripe, QuickBooks, Google APIs, S3, CRMs, ERPs, analytics tools, identity providers, and internal services. When those calls occur within user-facing requests, performance depends on someone else’s network and uptime.
The fix is to treat external systems as unreliable by default. Set timeouts. Use retries carefully. Make requests idempotent. Store external IDs and sync state locally. Move non-essential calls into background jobs. Use webhooks where appropriate, but verify signatures and handle duplicate deliveries.
For example, a user should not be blocked from viewing a local order record because an accounting API is slow. The application can show the locally known state, queue a sync, and communicate that the external status is being refreshed.
This is where performance and product design overlap. Users do not need every integration to be real-time. They need clear state, trustworthy data, and workflows that do not fail mysteriously.
7. File uploads, media processing, and storage bottlenecks
Uploads look simple until they become central to the product. A school safety app, insurance workflow, lending portal, or education platform may depend on photos, PDFs, videos, or signed documents. If those files are served by the web server inefficiently, performance and reliability suffer.
Common fixes include direct uploads to object storage, queued media processing, virus scanning outside the immediate request when feasible, signed URLs for private downloads, and a CDN for public assets. Large files should not force PHP workers to sit idle while users wait on slow networks.
Image transformations are another common hotspot. Resizing every image during upload can make the upload feel slow. Resizing on first view can make the first viewer pay the cost. For predictable workflows, queued transformations with stored variants are often safer.
The key is deciding where to spend the time. If the user needs confirmation that a file was received, give that quickly. If the system needs to process, scan, or classify the file, make that a visible background state.
8. Inefficient authorization, policies, and middleware
Authorization code is often overlooked during performance reviews because each policy check feels small. In aggregate, it can be expensive. A table with 100 rows might call a policy 100 times, and each policy might query roles, teams, subscriptions, or tenant settings.
The same applies to middleware. Middleware that calls external services, loads large account graphs, or recalculates permissions on every request can quietly slow the entire app.
Fix this by keeping request-wide context explicit and cheap. Load the current tenant once. Cache stable permission data with correct scoping. Avoid relationship queries inside tight loops. Move complex authorization decisions into query scopes where possible, so the database returns only records that the user can access.
This is also a security concern. Performance shortcuts must not bypass authorization. If access control is scattered and slow, the better answer is often a clearer authorization model rather than a risky cache.
9. Front-end and API chattiness
Not every Laravel performance issue lives in PHP. A page can be slow because the browser makes too many requests, because Livewire components rehydrate more data than necessary, because an Inertia response includes oversized props, or because a mobile app calls several endpoints sequentially.
For Laravel-backed front ends, look at the full interaction. How many requests happen when the page loads? How much JSON comes back? Are typeahead searches debounced? Are filters server-side or client-side? Does the mobile app fetch data in parallel, where safe?
Good fixes include purpose-built endpoints, lean resources, debounced search, pagination, server-side filtering, and careful component boundaries. If a screen needs a summary, return a summary. Do not ship the entire dataset and ask the browser to figure it out.
This is especially important for React Native mobile apps, where network conditions vary. A backend that feels fine on office Wi-Fi can feel broken on cellular if it requires too many round-trip requests.
10. Runtime, infrastructure, and deployment configuration
Sometimes the bottleneck is not application logic. It is a production configuration.
Common issues include debug mode enabled, no OPcache, under-provisioned PHP-FPM workers, queue workers sharing resources with web traffic, missing route or config caches, slow disk IO, database connections exhausted, or a server sized for last year’s traffic.
Infrastructure tuning should happen after you understand the workload. Adding servers can hide inefficient queries for a while, but it rarely fixes the underlying system. On the other hand, a well-written app can still struggle if PHP workers are starved or the database is overloaded.
Laravel Octane can be useful for certain high-throughput applications because it keeps the framework bootstrapped between requests. But it is not a universal fix. Long-running workers require care with memory leaks, request state, singleton usage, and code that assumes a fresh process for each request. Use Octane when the app and team are ready for that operational model, not just because the word "performance" appears in a planning meeting.
A practical prioritization framework
Performance backlogs can get messy. Every slow screen feels urgent, and every developer has a preferred fix. Use a simple prioritization model that balances user impact, risk, and effort.
Fix type | Typical effort | Risk level | When to prioritize |
|---|---|---|---|
Add obvious missing indexes | Low to medium | Medium, because indexes affect writes and migrations | A known slow query scans too many rows |
Remove N+1 queries | Low to medium | Low | A route runs excessive repeated queries |
Move work to queues | Medium | Medium | Requests time out or depends on external services |
Reduce payload size | Low to medium | Low | APIs return more data than screens use |
Introduce caching | Medium | Medium to high | Expensive data has clear freshness rules |
Redesign reporting | Medium to high | Medium | Reports compete with transactional workflows |
Rework the data model or tenancy | High | High | Performance issues come from core assumptions |
The safest performance work usually starts with measurement, indexes, query reduction, and request-cycle cleanup. The riskiest work is changing data models, caching security-sensitive data, or adding infrastructure complexity without operational maturity.
How to run a focused Laravel performance review
A performance review does not need to become an endless audit. For many teams, one or two weeks of focused work can expose the highest-value fixes.
Start by choosing the workflows that matter most to the business. For a SaaS product, that may be signup, dashboard load, billing, core CRUD operations, search, reporting, and background imports. For an internal operations platform, it may be daily queues, approvals, document handling, and manager dashboards.
Then baseline the system with real data. Synthetic test data often hides the problem. Use a production-like database snapshot with sensitive data handled appropriately. Capture route timings, query counts, slow queries, queue metrics, error rates, and external call timings.
Next, inspect the code paths behind the slowest workflows. Look for relationship loading, loops, policies, accessors, middleware, jobs, and integrations. Identify whether the problem is local to a screen or systemic across the application.
After that, fix in small slices. A good performance pull request should include before-and-after measurements. It should explain the trade-off. If an index is added, document the query it supports. If caching is added, document invalidation. If a job is moved to the queue, document the retry and failure behavior.
Finally, add guardrails. A few targeted tests, dashboards, alerts, and review habits can prevent the same issue from returning. If performance problems are connected to broader architecture problems, Ravenna’s article on Laravel architecture mistakes that hurt SaaS teams is a useful companion.
When a performance problem is really technical debt
Some bottlenecks can be fixed in an afternoon. Others are signals that the system has outgrown its original architecture.
You may be dealing with deeper technical debt if:
Every feature makes the same slow query slower
Tenant boundaries are unclear or inconsistently enforced
Reports run directly against the tables needed for daily operations
Critical workflows depend on long synchronous chains
No one trusts deployments because performance changes unpredictably
Developers avoid touching certain modules because the side effects are unknown
At that point, the goal is not just speed. It is change tolerance. You want a system where performance can be improved without breaking core business logic. That may mean introducing clearer service boundaries, redesigning data access, separating reporting workloads, adding observability, or refactoring high-risk modules. For teams that need an outside assessment, a Laravel code audit can help distinguish quick wins from structural risk.
Frequently Asked Questions
Is Laravel fast enough for serious SaaS applications? Yes, Laravel is fast enough for many serious SaaS and operational platforms when the application is well designed, deployed, and maintained. Most bottlenecks come from database access, synchronous work, large payloads, integrations, and architecture choices rather than Laravel itself.
What should we optimize first in a slow Laravel app? Start with the workflows that affect revenue, retention, support volume, or daily operations. Measure them, then look for N+1 queries, missing indexes, slow external calls, and long-running work inside requests. Those fixes often produce the best early return.
Should we use Laravel Octane to fix performance? Octane can help specific workloads, but it should not be the first answer. If the app is slow due to inefficient queries, large payloads, or blocking APIs, Octane may only mask the issue. Use it when profiling shows framework boot time is a meaningful bottleneck and the team can operate long-running workers safely.
How do we know if the database is the bottleneck? Look at slow query logs, query counts, execution plans, database CPU, locks, and response timing. If one or two queries dominate a request, or performance degrades sharply as data grows, the database access pattern deserves attention.
Can caching create security issues in Laravel? Yes. Caching tenant-specific or user-specific data with broad keys can expose data to the wrong user. Always include the right scope in cache keys, define invalidation rules, and treat authorization-sensitive caching as a design decision rather than a quick fix.
How often should a Laravel application get a performance review? Review performance before major launches, after significant data growth, during infrastructure changes, and whenever support complaints mention slowness. For active SaaS platforms, lightweight performance checks should be part of normal development, not a once-a-year emergency.
Need help finding the real bottleneck?
Slow Laravel systems rarely need random optimization. They need senior diagnosis, careful trade-offs, and fixes that improve reliability without creating new risk.
Ravenna is an official Laravel Partner that helps teams stabilize, modernize, and evolve business-critical Laravel applications. If your platform is slowing down, timing out, or becoming harder to change safely, contact Ravenna to start a practical conversation about what is actually happening and what to fix first.