01 · Capture
Record one bounded workflow
Choose a route or action, select an appropriate mode, and record what the capture could and could not observe.
Current phase: paid design partners
The core tracing architecture exists, but public-v1 correctness, safety, comparison, benchmark, compatibility, packaging, and release gates have not been publicly passed. This page describes the product direction—not a finished general-availability feature list.
The job
When a WordPress request is slow, produce evidence for the next action.
WP Flame focuses on dynamic requests that still execute WordPress: wp-admin, checkout, logged-in pages, REST, AJAX, cron, CLI, and other eligible workflows. It is not a browser speed score or an automatic optimization plugin.
02 · Understand
See measured contributors
Lead with supported ownership, impact, evidence, confidence, completeness, and the safest next action.
03 · Verify
Repeat a compatible workflow
Compare compatible route, request type, mode, capability, score, and environment cohorts instead of two convenient screenshots.
Capture modes
Increase detail deliberately.
Every mode adds work. The capture report must make requested, available, failed, and intentionally excluded telemetry visible.
| Mode | Intended observation | Boundary | Use |
|---|---|---|---|
| Safe | Supported lifecycle and WordPress HTTP API activity. | Database and callback capture are intentionally not requested. | Low-risk observation and initial health checks. |
| Standard | Safe-mode evidence plus compatible database capture. | Custom database layers may be unavailable and must remain untouched. | Default manual diagnosis when compatibility succeeds. |
| Deep | Supported WordPress hook-callback timing in addition to available Standard evidence. | Not arbitrary PHP functions; one-shot or time-boxed because it adds more work. | Focused developer diagnosis when callback detail is necessary. |
Product truth
What a trace can describe
- Observed duration from the earliest available WP Flame bootstrap point.
- Supported lifecycle, WordPress HTTP, compatible database, and optional callback spans.
- Best-supported WordPress ownership across core, plugins, themes, mu-plugins, and supported drop-ins.
- Capture mode, origin, sampling policy, capabilities, dropped data, and incomplete reasons.
- Compatible request cohorts when the comparison release gate passes.
Deliberate boundary
What WP Flame is not
- A page cache, CDN, image optimizer, or CSS/JavaScript optimization suite.
- A Core Web Vitals or full browser-experience measurement product.
- A complete PHP call-stack profiler or generic infrastructure APM.
- A promise that every host, database layer, or request exposes identical detail.
- An automatic plugin-disabling, code-rewriting, or site-repair system.
Capability-aware evidence
Unavailable is unknown, never zero.
A trace should record a status for each requested instrumentor so missing evidence cannot silently improve a score or confidence.
- Captured
- The requested capability registered and produced supported evidence for this trace.
- Not requested
- The selected mode intentionally excluded this capability; that absence is expected.
- Unavailable
- The environment could not support the requested capture path, such as an incompatible database layer.
- Failed
- The requested instrumentor encountered an error. The trace must explain the degradation.
Local-first by default
Trace data stays on the WordPress installation unless a separately disclosed service is explicitly chosen.
Public v1 is intended to work without a required SaaS service. Any future licensing, analytics, hosted report, AI, or fleet request must be separately disclosed, minimized, and consented to. Redacted local export remains the default handoff direction.
Start with a real incident