A Laravel list gets slower with every row: find the N+1 query

A project list loads quickly with three records but slows down with fifty. Each row displays its category, and the template causes another relationship query for every project. The number of queries grows with the list.

Load the relationship with the list

$projects = Project::query()
    ->with('category')
    ->latest()
    ->paginate(12);

This example assumes a Project model with a category relationship. Render the category from that loaded relationship rather than issuing a separate query in the template.

Measure the request you are fixing

Capture query count and total query duration for the list request in a development environment. Inspect duplicate queries and their bindings. Do not collect sensitive query bindings indiscriminately in production logs.

Then compare the same fixture before and after eager loading. Query count is useful, but response size, rendering cost, and slow individual queries can still dominate. Reducing fifty tiny queries does not prove the entire page is fast.

Keep the selected columns sufficient

If you narrow the relationship's columns, include its primary key and any keys required to connect the relationship. Accidentally omitting those keys can make a loaded relationship appear empty.

For large lists, paginate instead of rendering every record. An eager-loaded relationship can still consume significant memory if the application loads thousands of complex objects at once.

A regression worth keeping

Use fixtures with several categories and projects, including one project without a category if that is valid in your schema. Assert the rendered labels and watch for a query count that scales linearly with the number of rows.

Laravel's eager loading reference explains relationship loading. Apply it where the interface actually consumes that relationship rather than eager-loading every association by default.