This synthetic WooCommerce example demonstrates the intended diagnosis workflow. Its timings are illustrative, not a benchmark or a claim about your site.
Bounded request capture
Partial means the recorded spans remain useful, while unavailable telemetry stays explicitly unknown. Standard mode is not arbitrary function-level PHP profiling.
Observed from the earliest WP Flame bootstrap represented by this fixture.
Supported spans after database capture registration; earlier queries are not implied.
Supported WordPress HTTP API activity only.
Standard mode does not provide callback-level detail. Use a one-shot Deep capture.
Unknown in this fixture; unavailable never means zero.
Select any measured span to inspect its evidence and a cautious next action.
On smaller screens, use the span selector above or swipe the timeline horizontally.
Evidence before diagnosis
65ms measured in this supported span, based on one bundled observation. Treat it as a place to investigate, not a confirmed root cause.
Inspect the normalized fingerprint and caller, test one staging change, then compare compatible product-route cohorts.
Illustrative compatible-cohort example
A credible result compares the same normalized route, request type, capture mode, capability set and score version — not one before request against one after request.
Check the route, capture mode, completeness, and unavailable telemetry before interpreting a number.
Use the timeline to inspect measured duration, WordPress ownership, and the evidence supporting a likely next action.
A single trace suggests where to investigate. Compatible baseline and after samples help show whether a change improved it.