Measure the slow request before changing queries A dashboard can feel slow for several reasons: too many SQL statements, one expensive SQL statement, exces...
Measure the slow request before changing queries
A dashboard can feel slow for several reasons: too many SQL statements, one expensive SQL statement, excessive serialization, or a large response. Start with a reproducible request and record query count, duration, memory use, and response time. Keep a representative dataset; a query that looks fine with twenty records may fail with millions.
Laravel's Eloquent relationships make data access readable, but a loop that loads a related record on demand can issue one query for every row. The classic N+1 pattern is easy to miss in a Blade template or API resource.
Remove N+1 queries deliberately
If a project listing displays each project's category, eager load the relationship in the query:
$projects = Project::query()
->with('projectCategory:id,name')
->select(['id', 'project_category_id', 'name', 'slug'])
->paginate(24);
The selected foreign key is essential for Eloquent to match categories. Compare query counts before and after. Eager loading everything is not a universal fix: large nested relations can transfer more data than the page needs. Use relationship counts when the UI needs a number, and fetch detailed records only on the detail view.
Inspect indexes with the database planner
For a filter such as tenant_id plus published_at, inspect the generated SQL and run EXPLAIN on the production database engine or a representative copy. A useful index depends on predicates, sort order, cardinality, and data distribution. Adding indexes blindly increases write cost and storage while failing to accelerate the real query.
When a report groups large tables repeatedly, consider precomputed aggregates or a reporting table. Define the acceptable freshness first. A cached count that is five minutes old may be fine for an overview but unacceptable for a finance reconciliation screen.
Limit the work per request
Paginate listings and select only columns the response uses. Keep unbounded exports out of an HTTP request; a queued export can stream or process records in batches. For long scans, use chunking or cursor approaches appropriate to whether records can change while the job runs.
Avoid paginating after calling get(), since that loads the full result into memory. If a listing uses client side filters, check whether fetching all records is still reasonable as the dataset grows.
Cache only after the query is correct
Cache a stable, expensive result when there is a clear invalidation or expiry strategy. Include tenant, user permission, filter, and locale in the cache key where they affect the response. A globally cached query can leak one customer's data to another if the key omits the access boundary.
Invalidate affected entries after writes, or use a bounded TTL when slightly stale data is acceptable. Monitor hit rate and database load to prove the cache helped.
Test the real shape of data
Create tests with enough related records to reveal N+1 behavior. Use query logging in a nonproduction environment and compare counts for ten versus a hundred rows. Run EXPLAIN for the largest report filters and keep the plan with the performance note. Do not treat a single local timing as a production benchmark.
Conclusion
Performance work is a sequence: measure, inspect SQL, limit transferred data, choose indexes from query plans, then consider caching. This is also relevant to data analytics and reporting, where metric definitions and query cost must both be clear.
References