use-siteation-debugbar

Use Siteation Debug Bar

Read exact, stored Magento request data instead of guessing from a screenshot or a log. Every profile is already redacted and bounded. The tools are read only and change nothing.

Find the right request

1. If you have the X-Siteation-DebugBar-Profile response header, use that id directly. It is the only reliable way to say which request you are looking at.
2. Otherwise call list_debug_profiles. Match on method, path, status and duration. Do not assume the newest profile is the one you want. Storefront pages fire background AJAX, and those are profiled too.
3. Pass only_with_findings: true when you are hunting for a problem rather than describing a specific request.

Read in the right order

1. get_debug_findings first, always. It is the module's own conclusion about the request and it is small.
2. Then the smallest section that tests that conclusion, with get_debug_profile_section. It serves one of request, queries, events, observers, blocks, cache, interception or timeline, a page at a time: pass limit, and feed the next_cursor it returns back as cursor to read the next page. timeline is the whole request in order, which is the fastest way to see where the time went when no single section stands out.
3. inspect_debug_queries only when the evidence points at the database. Start with filter: "slow" and limit: 5.

Ask for small limits. Start with 10 profiles, 10 findings, 5 items. Increase or page with cursor only when the answer actually needs more.

Measure a change, do not guess at it

compare_debug_profiles takes two profile ids and reports what moved between them: duration, memory, queries, cache and findings, with query shapes matched by fingerprint so a repeated query that went away is visible as such.

Profile the page, make the change, load the page again, then compare. Two ids and one call is a stronger answer than reading two profiles side by side, and it is the only way to say that a fix helped rather than that it looks like it should have.