Getting Started

Install with composer require symfinity/ui-profiler --dev (this is a local-development tool; keep it out of production dependencies where possible).
Publish the config: php artisan vendor:publish --tag="ui-profiler-config". The config controls whether the profiler is enabled, which environments it runs in, and what it measures.
Enable it in .env for your local environment (typically UI_PROFILER_ENABLED=true), then load any route in the browser. The profiler surfaces a per-request overlay/panel showing render timings, query counts, memory, and view/component breakdown.
First use case: open your slowest page and read the view/component timing breakdown to find the Blade partial or Livewire/Blade component dominating render time. That single loop (load page → read breakdown → refactor the hot component) is the core day-to-day workflow.
Skim the source's src/ and the README before relying on it — at v0.1.0 the public API is thin and likely to shift.

Implementation Patterns

Automatic request profiling — the package registers middleware, so once enabled every request is profiled without code changes. Use this for exploratory profiling on existing apps.
Opt-in per route — restrict profiling to specific routes (via config allow/deny lists or a route middleware) to reduce noise and overhead on a large app.
Component-level focus — use the view/component breakdown to attribute time to individual Blade partials and components rather than whole-request totals. This is the highest-signal workflow for UI performance work.
Before/after comparison — capture metrics for a page, make one change (e.g. eager-load a relation, extract a component, cache a fragment), reload, and compare. Keep a scratch note of baseline numbers since there's no built-in history at this version.
Pair with Laravel's built-ins — use Telescope/DB::listen for query detail alongside this package's UI-render focus; the profiler complements query-level tooling rather than replacing it.
CI/dev parity — treat it strictly as a developer aid; if you want performance guardrails in CI, keep those in dedicated benchmarks rather than relying on this profiler.

Never enable in production. A UI profiler adds memory and request overhead; guard it behind environment checks and the --dev requirement.
Config caching — after changing profiler config, run php artisan config:clear. Stale config is a common reason the panel "doesn't appear."
v0.1.0 API instability — config keys, middleware names, and output format may change between 0.x releases. Pin the version and read the CHANGELOG before upgrading.
Timing accuracy — render timings from an in-process profiler can be skewed by the profiler's own instrumentation and by opcache state; use relative comparisons (before/after) rather than treating absolute numbers as precise.
Memory overhead — on large pages the collected data itself is non-trivial; profile a single route at a time rather than enabling globally on a big app.
Extension points — check whether the package exposes a config-driven list of metrics or a custom collector interface before building your own dashboards around it; at this version assume minimal extensibility and keep customizations thin.
Debugging "no output" — verify in order: package enabled, correct environment, middleware registered, config published and not cached.