A slow application costs money in ways that are easy to miss. Visitors leave pages that take too long to load, staff lose patience with sluggish dashboards, search engines favour fast sites and servers that work harder than they should drive up hosting bills. Laravel is a capable framework and can power very fast applications, but it does not make every application fast automatically. Speed comes from good decisions, and a few common mistakes cause most slowdowns.
This guide walks through fourteen practical ways to improve Laravel performance, in the order that usually pays off: measure first, fix the database, then add caching and background processing, then tune the framework and infrastructure. It is written for developers and for the people who manage them, so each section explains why something matters as well as what to do. If you are not sure whether your application has deeper problems, our article on signs your Laravel application needs a technical review is a good companion, and our Laravel development page explains how we approach this kind of work.
Step zero: measure before you change anything
The most common performance mistake is optimising the wrong thing. Guessing wastes time and adds complexity. Before changing code, find out where the time actually goes.
1. Find the slow pages and queries
Useful tools include:
- Laravel Debugbar in development, which shows queries, timings and memory for each page.
- Laravel Telescope, for inspecting requests, queries, jobs and exceptions in development and staging.
- The database's slow query log, which records queries over a chosen time.
- Application performance monitoring services for production, showing real user experience.
- Browser developer tools, to separate server time from front-end loading time.
Start with the pages users actually complain about, or the ones with the most traffic. Note the response time, the number of queries and the memory used. Those become your baseline, so you can tell whether a change helped.
Often the answer is surprising. A page that feels slow because of a huge image or heavy JavaScript will not be helped by database tuning, and a page with a hundred queries will not be helped by a faster server.
The database: where most problems live
In typical business applications, the majority of slowness comes from the database, and usually from a handful of patterns.
2. Fix the N+1 query problem
This is the single most common Laravel performance issue. It happens when the code loads a list of records and then runs an extra query for each one to fetch related data. Showing 100 orders with their customers can silently become 101 queries.
Fix it by eager loading related data in advance with with(), so Laravel fetches everything in a few queries instead of hundreds. You can also configure Laravel to throw an error during development whenever lazy loading happens, which catches the problem before it reaches users.
3. Add the right indexes
Without an index, the database reads every row to find what you asked for. On a small table this is unnoticeable; on a large one it is painfully slow. Add indexes to columns you frequently filter, sort or join on, such as foreign keys, status fields and dates.
Use the database's query analysis tools, for example EXPLAIN, to confirm a query uses an index. Do not index everything: each index slows writes and uses storage, so add them where they are earned.
4. Select only what you need
Loading whole records with every column, including large text fields, when you only need a name and an email wastes memory and time. Select specific columns. For large result sets, process data in chunks or use lazy collections so the application does not load hundreds of thousands of records into memory at once.
5. Paginate and limit
Never load an unbounded list. Use pagination for lists shown to users, and limits for everything else. Consider simple pagination, which avoids an expensive total count, on very large tables.
6. Push work into the database
Sorting, filtering, grouping and summing are things databases do extremely well. Doing them in PHP after loading all the records is usually far slower. Use queries, aggregates and, when appropriate, database views or summary tables for heavy reports.
Caching: do the work once
7. Cache expensive results
If a query or calculation is expensive and its answer does not change on every request, such as a dashboard total, a product list or a configuration lookup, store the result in a cache for a short time instead of recomputing it each time.
- Use a fast cache driver such as Redis in production rather than the file driver.
- Choose sensible expiry times and invalidate the cache when underlying data changes.
- Cache carefully. Stale data can be worse than slow data when accuracy matters, for instance in stock levels or balances.
8. Use HTTP and page caching where suitable
Public pages that rarely change can be cached at the web server or a content delivery network (CDN), so most visitors never reach PHP at all. Set proper cache headers for static assets so browsers reuse files instead of downloading them again.
Do not make users wait
9. Move slow work to queues
Anything that takes more than a moment and does not need to finish before the user sees a response belongs in a background job: sending emails and notifications, generating PDFs and reports, processing images and files, calling slow third-party services and syncing with other systems.
Laravel's queue system makes this straightforward. The user gets an immediate response, and workers handle the job in the background with retries if something fails. Use Redis or a reliable queue backend, and monitor the queues so failures do not go unnoticed. Laravel Horizon offers a dashboard for Redis queues.
10. Schedule heavy tasks off-peak
Reports, clean-up, imports and syncs can run during quiet periods through Laravel's scheduler, instead of competing with users during busy hours.
The framework and server
11. Use Laravel's built-in optimisation commands in production
Laravel can cache several things so it does less work on each request.
- Configuration cache (
php artisan config:cache) combines configuration into a single file. - Route cache (
php artisan route:cache) speeds up route registration. - View cache (
php artisan view:cache) precompiles templates. - Event cache precomputes event discovery.
php artisan optimizeruns the main caching steps together.
Run these as part of your deployment, and remember to clear or rebuild them when configuration changes. Also install production dependencies with an optimised autoloader (composer install --optimize-autoloader --no-dev).
12. Tune PHP and the server
Basic infrastructure settings make a real difference.
- Use a current PHP version. Each release brings performance improvements.
- Enable OPcache, which stores compiled PHP code in memory. This is one of the biggest easy wins.
- Size PHP workers and memory appropriately for your traffic and your server.
- Use a fast database server with enough memory, and configure it sensibly.
- Keep the database near the application to reduce network delay.
- Consider Laravel Octane, which keeps the application in memory between requests using Swoole or RoadRunner. It can significantly increase throughput for suitable applications, but requires care about state that persists between requests, so it is not a default choice.
13. Optimise the front end and assets
Server speed is only part of what users feel.
- Compress and resize images, and use modern formats such as WebP.
- Minify and bundle CSS and JavaScript with your build tool, and load only what each page needs.
- Defer non-critical scripts and lazy-load images below the fold.
- Serve assets through a CDN close to your users.
- Avoid heavy third-party scripts that delay rendering.
- Enable compression such as gzip or Brotli on the server.
Front-end work is often the quickest way to improve how fast a page feels, and it affects search rankings too.
14. Keep dependencies and code lean
- Remove unused packages. Each adds loading and upkeep.
- Avoid doing heavy work in service providers, middleware or global scopes that run on every request.
- Be careful with large collections in memory; use database operations or lazy collections.
- Profile regularly. Performance slips as features are added, so check it as part of ongoing development, not only when users complain.
A quick reference table
| Symptom | Likely cause | First thing to try |
|---|---|---|
| Page makes hundreds of queries | N+1 problem | Eager loading with with() |
| One query takes seconds | Missing index or heavy query | EXPLAIN, add an index, rewrite the query |
| Dashboard is slow | Expensive repeated calculations | Cache results or use summary tables |
| Form submit hangs | Slow work in the request | Move to a queued job |
| Every request is slightly slow | Framework overhead | Config, route and view cache, OPcache |
| Memory errors on large lists | Loading too much at once | Chunking, lazy collections, pagination |
| Fast server, slow page | Heavy front end | Compress images, reduce scripts, use a CDN |
| Slow under traffic spikes | Too few workers, no caching | Caching, more workers, consider Octane |
Common mistakes
- Optimising without measuring. You may fix the wrong thing.
- Caching everything. Stale or inconsistent data causes bugs that are hard to trace.
- Adding indexes blindly, slowing writes without helping reads.
- Ignoring the N+1 problem because it is invisible with small test data.
- Testing only with tiny data sets. Performance problems appear at realistic scale.
- Running production with debug mode or development settings.
- Using the file cache and sync queue in production.
- Treating performance as a one-time project instead of a habit.
- Forgetting the front end.
- Scaling hardware before fixing the code. A bigger server hides a problem at higher cost.
Performance and the wider picture
Speed is not only a technical matter. It affects conversion, search visibility, hosting costs and staff productivity. It also connects to maintainability: clean, tested code with sensible structure is easier to optimise safely. That is one reason we encourage investing in quality early, as described in software maintenance costs, and choosing the right technology for the job, which we discuss in Laravel vs Node.js.
If you are planning a larger application, performance should be part of the design from the start: thinking about data volume, expected traffic and what can be cached or queued. Our web application cost guide and Laravel cost guide show how scale and performance needs influence budgets.
A simple performance routine
- Set a target, for example pages under two seconds for most users.
- Measure key pages and record the baseline.
- Fix the biggest problem first, usually a database issue.
- Re-measure to confirm improvement.
- Add caching and queues where they remove repeated or slow work.
- Apply production optimisations in your deployment process.
- Monitor continuously and review after each major release.
Final thoughts
Most Laravel performance problems come from a short list of causes: too many queries, missing indexes, slow work done while the user waits and missing production optimisations. Measure, fix the database first, cache and queue what you can, tune the framework and server, and keep the front end light. Small, well-chosen changes routinely make applications several times faster without a rewrite.
If your application is slow and you are not sure why, get in touch. We can review it, find the real bottlenecks and propose a prioritised plan, or, if you need extra hands on an ongoing basis, you can hire Laravel developers to work alongside your team.