WP Flame records a bounded dynamic WordPress request, shows the largest supported measured contributors, and helps you verify whether the next change improved it.
A slow checkout, admin screen, API request, or cron task is rarely explained by a browser score. These requests still execute PHP and often depend on plugins, hooks, compatible database activity, and external services.
WP Flame is being built to turn that supported request evidence into a defensible next action—not to cache pages, optimise assets, or modify a site automatically.
Understand the product boundaryChoose an eligible route or workflow and record a bounded request with an appropriate capture mode.
See what was observed, what was unavailable, and which supported measured contributor deserves attention.
Implement or hand off the next action, then repeat compatible captures to see whether the workflow improved.
WP Flame is not a PageSpeed replacement. Its useful territory is the uncached, logged-in, transactional, API, and background work that remains.
Investigate slow dashboards, editors, searches, and internal workflows.
→ 02Inspect uncached cart, checkout, payment, shipping, and session work.
→ 03Find supported WordPress HTTP API calls delaying a dynamic request.
→ 04Capture comparable evidence before and after a suspected change.
→ 05Trace eligible application requests that browser page tests do not explain.
→ 06Investigate supported scheduled and asynchronous WordPress activity.
→Open a supported span to see its measured duration, attribution, and likely next action. The bundled data is synthetic and is not presented as a benchmark.
Open the full sample and limitationsBounded 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
155ms measured in this supported span, based on one bundled observation. Treat it as a place to investigate, not a confirmed root cause.
Run a one-shot Deep capture to resolve supported callbacks, make one scoped change, then compare compatible 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.
WP Flame's public-v1 goal is a compatible before/after workflow. It should preserve route, capture capability, and evidence thresholds rather than compare unrelated traces or imply causation from one sample.
Read the intended diagnosis workflowBefore“The client says checkout is slow. We think a plugin may be involved.”
With evidence“These compatible captures show the same supported HTTP span dominating the workflow. Here is the next test and the after-capture plan.”
Trace data is intended to remain in the WordPress installation by default. Any future connected service requires separate disclosure and consent.
Data handling →Unavailable database, early-bootstrap, or instrumentor detail is unknown—not zero. Each trace should state what it did and did not capture.
Compatibility and limits →Overhead, compatibility, capacity, and performance claims will be published only with dated methodology, environment, samples, and limitations.
Benchmark methodology →The initial offer being tested is $99/year for up to five authorised production sites, with direct onboarding and regular evidence review. Final public packaging remains subject to validation.
No lifetime entitlement. Currency, tax, payment, cancellation, renewal, and refund terms are confirmed in writing before payment. Every client site and trace review requires separate authorisation; testimonials and case studies require separate consent.
No. WP Flame is a diagnosis and verification product. It is intended to identify supported measured contributors, recommend a safe next action, and help check the result. Public v1 will not rewrite code, change settings, disable plugins, cache pages, or optimise assets automatically.
WP Flame measures observed WordPress server execution from its earliest available bootstrap point. Depending on capture mode and compatibility, a trace may include supported lifecycle work, WordPress HTTP API calls, compatible database activity, and focused WordPress callback spans. It is not the web server request start and is not a complete arbitrary PHP call stack.
Every profiler adds some work. WP Flame is being designed around bounded capture and mode-specific limits, with focused Deep diagnostics reserved for short investigations. Fixed overhead claims will not be published until dated, reproducible evidence is available.
Query Monitor is an excellent developer tool for inspecting the current WordPress request. WP Flame’s intended public-v1 difference is retained bounded evidence, guided diagnosis, visible capture capability, compatible before-and-after comparison, and an agency-friendly handoff workflow.
The launch direction is local-first: trace data remains in the WordPress installation by default. Any future licensing, analytics, hosted report, or fleet service must be separately disclosed and consented to. Design-partner trace review also requires explicit site-specific authorisation.
Not yet. WP Flame is in a paid design-partner phase while measurement correctness, operational safety, compatibility, evidence, and release gates are completed. The current call to action is to apply with a real eligible workflow or explore the illustrative sample trace.
Applications require a real dynamic WordPress workflow and someone able to act on or delegate the evidence.