Pre-release Paid design-partner programme

Use case · wp-admin

Turn a slow admin complaint into a reproducible, bounded investigation.

Editors often report that publishing, saving, searching, or opening a plugin screen feels slow. Those requests are authenticated and dynamic, so page-cache changes and public-page speed tests usually do not explain the delay.

Apply as a design partner Explore the sample trace
Design-partner workflow, not a public capability promise

This guide describes the intended public-v1 workflow. During pre-release, captures are founder-guided and every conclusion remains limited by the trace’s reported capabilities, completeness, and supporting evidence.

Where WP Flame fits

Start with the request that still executes WordPress.

The investigation

Diagnose slow wp-admin

Editors often report that publishing, saving, searching, or opening a plugin screen feels slow. Those requests are authenticated and dynamic, so page-cache changes and public-page speed tests usually do not explain the delay.

Tool boundary

Use the right evidence source

A browser test can show that the response was late, while a current-request debug panel can expose useful detail to a developer. The intended WP Flame workflow adds a retained, capability-labelled trace and a repeatable path for comparing the same admin action after a change.

Controlled capture plan

Make the workflow reproducible before reading the graph.

  1. Name one exact action, such as opening the post list or saving a known post.
  2. Record the route, user role, relevant filters, and expected result before capturing.
  3. Run a bounded Standard capture; use one-shot Deep only when callback detail is required and the operator accepts the additional work.
  4. Check the capture report before interpreting database, callback, or early-lifecycle gaps.
  5. Repeat the identical action enough times to build a compatible baseline before making a change.

Useful output

Evidence should change the next action.

A graph is supporting detail. The useful outcome is a measured opportunity, the evidence behind it, a safe action, and a way to verify the result.

Largest measured contributor

A supported plugin, theme, database, HTTP, or lifecycle span with duration and ownership evidence.

Capability report

Which instrumentors were requested, captured, unavailable, or failed for this trace.

Repeatable route context

The normalized admin route, request type, environment snapshot, and capture mode needed for a defensible comparison.

Measurement boundaries

What this investigation cannot claim

  • WP Flame does not measure browser rendering or the user’s network connection.
  • A trace starts at the earliest WP Flame bootstrap point available, not at the web server’s absolute request start.
  • Standard mode cannot promise database detail on every custom database layer.
  • The largest measured contributor is evidence for the next investigation, not automatic proof of the definitive root cause.

Developer or client handoff

What to include

  • The exact admin action and affected role.
  • A redacted trace or report with capability and completeness information.
  • The measured contributor, supporting samples, and confidence.
  • The proposed change and instructions for repeating the same workflow.

Continue the investigation

Investigate a plugin-update regressionFind external APIs slowing WordPressCreate a client performance report Review capability and compatibility status Read the design-partner quickstart

Current route to release

Bring a real slow WordPress workflow.

The paid design-partner programme pairs controlled captures with founder-led review while the public release gates are completed.

See the programme