Tracing Blade views and slow queries in Laravel

"The page is slow" is not a bug report you can act on. Slow where? In the controller? In a heavy Blade view? In one query that quietly does a table scan? Without a trace you're guessing, and guessing usually means rewriting the part that was already fast.

Lookout's request traces answer the where. This is how to turn them on and read them.

Errors are automatic; traces you opt into

After composer require lookout/tracing and php artisan lookout:install, unhandled exceptions already report — that part needs nothing else. Full request performance traces are a separate, deliberate switch, because timing every request has a cost you should choose.

To see the config and every knob, publish it:

php artisan vendor:publish --tag=lookout-tracing-config

Then enable performance tracing via the published config (or the LOOKOUT_ performance env values it documents), add the package's performance middleware to your web middleware group, and register lookoutTracing.continueTrace on the routes you want stitched into a single end-to-end trace. The service provider is auto-discovered, so there's no manual registration beyond the middleware.

What a trace shows you

With performance tracing on, a request becomes a timeline of spans instead of a single number. For a typical Laravel page you'll see:

• Blade view rendering — how long the template (and its partials) took to render. A surprising amount of "slow page" is sometimes a view doing work in a loop.
• Database queries — each query as its own span, with the slow ones standing out by duration.
• the surrounding request handling, so the spans add up to the wall-clock time the user felt.

Reading it is mostly visual: the longest bar is where to look first. If Blade dominates, you've got view work to move or cache. If one query span is wide, that's your slow query.

Slow queries get called out on their own

You don't have to hunt through every span. Lookout flags slow queries automatically (the same way it flags N+1s), so the worst offenders surface as issues without you reading every trace. Use the trace to understand a specific slow request; use the flagged slow-query issue to catch the pattern across all of them.

From "it's slow" to a fix

The workflow is the point:

1. A page feels slow → open its trace.
2. The widest span tells you whether it's Blade, a query, or something else.
3. Fix that one thing — add an index, cache the view fragment, eager-load the relationship.
4. Reload, open the new trace, and watch the wide bar shrink.

No more rewriting the fast parts.

Try it on a real page

Performance tracing works on the free Starter tier — 10,000 events a month, one project, no credit card. Turn it on for your slowest page and let the trace tell you where the time actually goes.

Create your free project and trace the page everyone complains about.