Debugging workflows
Find where the request spent its time
Use the overview to choose a direction, then follow ordered work, queries, HTTP calls, rendering, models, and events to the code you can change.
Measure a stable request
Local timings move with cold caches, debugger overhead, machine load, and the amount of data on the page. Make comparisons useful before drawing a conclusion.
- Compare the same method, path, request type, and realistic data.
- Use a second warm request when startup, compilation, or cache warming affects the first one.
- Repeat the request more than once when the difference is small.
- Use production monitoring for production latency; use New Debug Bar to explain local work.
Use the overview to choose a direction
| Signal | Useful next section |
|---|---|
| Query time explains much of the request | Queries and Models |
| Total duration is high but query time is low | Timeline, HTTP client, Views, and Events |
| Peak memory is unexpectedly high | Models, Views, returned data, and large captured operations |
| One Livewire update is slow | Livewire, Timeline, Queries, and Views for that update profile |
Read work in execution order
The Timeline joins supported activity into one ordered view. Use it to see whether expensive work is isolated, repeated, or waiting on another operation.
Open a timeline item for its source and related detail. A long outbound request, a sequence of repeated queries, repeated view rendering, or a burst of model work gives you a concrete section to inspect next.
Follow the bottleneck to its cause
-
Open the dominant operation
Choose the largest credible source of time or memory, not merely the section with the most rows. -
Inspect its application source
Use the file, line, and retained application stack to find the caller that controls the work. -
Check related evidence
Connect a model retrieval to its queries, an HTTP call to its response, or a repeated view to the data and loop that rendered it. -
Change one cause
Reduce duplicate work, request less data, batch a remote call, cache a stable result, or move work only when the evidence supports it.
Verify the improvement
Repeat the same warm request and compare the metric your change was meant to improve. Also check status, response behavior, query count, and findings so a faster result did not hide missing work.
For a path with a stable budget, use New Debug Bar’s profile assertions to protect maximum duration, query count, query time, peak memory, and error-free behavior in a Laravel test.
Next step
Protect a performance budget
Read a profile from the response header and assert the limits that matter for an important Laravel path.
Open the testing guide