Pre-release Paid design-partner programme

Use case · REST and AJAX

Give background and interactive requests a useful WordPress identity.

REST and admin-ajax requests power editors, filters, search, dashboards, carts, integrations, and headless applications. Their generic URLs can hide very different operations unless the route or action is normalized.

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 REST and AJAX latency

REST and admin-ajax requests power editors, filters, search, dashboards, carts, integrations, and headless applications. Their generic URLs can hide very different operations unless the route or action is normalized.

Tool boundary

Use the right evidence source

Browser tooling shows the client-visible wait and generic APM can show broader backend execution. The intended WP Flame workflow adds WordPress route/action context and supported ownership so repeated operations can be grouped without mixing unrelated request populations.

Controlled capture plan

Make the workflow reproducible before reading the graph.

  1. Name the REST route or AJAX action and the user-visible behavior that triggers it.
  2. Use a test account and redact request values that may include personal data.
  3. Capture a bounded set of the same operation and confirm its normalized identity.
  4. Inspect supported database, callback, and HTTP evidence only where the capability report permits.
  5. Repeat the same operation after one change and reject incompatible samples.

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.

Normalized operation

A route or action key that separates this request population from unrelated REST and AJAX traffic.

Server-side contributors

Supported lifecycle, plugin, theme, database, callback, and external-service work observed for the operation.

Failure context

HTTP status, incomplete-trace reasons, and instrumentor failures that affect interpretation.

Measurement boundaries

What this investigation cannot claim

  • WP Flame does not measure frontend state updates, JavaScript rendering, or client network quality.
  • Authentication and sensitive parameters must not be placed in shared reports.
  • Different REST routes or AJAX actions must not be combined into one performance conclusion.
  • Supported GraphQL operations remain a separate compatibility gate.

Developer or client handoff

What to include

  • Route/action and reproduction steps.
  • Authentication context without credentials.
  • Redacted trace evidence and capability report.
  • Compatible sample definition for verifying the proposed fix.

Continue the investigation

Find external APIs slowing WordPressDiagnose cron and Action Scheduler workInvestigate a plugin-update regression 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