Controlled WordPress performance comparison

Controlled WordPress Core Web Vitals lab: slow and fixed builds

The paired builds use the same dummy business, route set, page purpose, section order, hero source, reviews, gallery, FAQ, testimonials, and post-grid pattern. Media delivery, script execution, layout stability, and cache behavior are the implementation variables.

This is an inspectable live comparison, not a score card. The clean implementation is public. No numeric performance, field Core Web Vitals, ranking, traffic, or client-result claim is made without a dated raw artifact.

RELEASE GATE / EXTERNAL LINKS WITHHELD

Proof content is code-complete; dependent lab evidence is not release-complete.

External lab and source links are withheld until the seeded unsupported metric table is removed from the live evidence route and both lab installers require explicit production administrator credentials.

ROUTESLOW BASELINEFIXED BUILD
HomeLink withheld pending release gateLink withheld pending release gate
CaseLink withheld pending release gateLink withheld pending release gate
EvidenceLink withheld pending release gateLink withheld pending release gate
ChangelogLink withheld pending release gateLink withheld pending release gate
Public clean source

Inspect the fixed implementation, not a screenshot claim

The clean WordPress implementation, dummy content, custom theme, setup script, and safe lab notes are public. The deliberately overloaded source remains private because it contains fault-injection code; the observable slow routes remain available for comparison.

Controlled inputs

What stayed the same

  • the same dummy business and core route structure;
  • the same page purpose, section order, and content pattern;
  • the same hero source subject, reviews, gallery, FAQ, testimonials, and post-grid pattern;
  • no client data, contact form, payment flow, or visitor tracking.
Clean implementation

What the fixed build changes

  • removes artificial origin delay and the no-store fault injector;
  • removes parser-blocking JavaScript and deliberate long main-thread tasks;
  • serves responsive WebP derivatives from the same hero source;
  • restores image dimensions and below-fold lazy loading;
  • replaces an automatically loaded chat widget with a click-opened static stub;
  • removes late layout-shift injections and unnecessary global DOM/widget bloat;
  • uses stable file-based asset versions and a system font stack.
Reproduction method

Compare like with like

  • test the matching slow and fixed route in the same tool, browser mode, region, and time window;
  • record cache state and repeat both cold and warm requests where server response is relevant;
  • save raw Lighthouse or PageSpeed JSON before quoting a number;
  • compare the LCP element, request priority, main-thread work, layout shifts, transfer path, and cache response—not only an aggregate score;
  • treat the 28-day field dataset as separate evidence from a current lab trace.
Scope boundary

What this controlled lab does not prove

Hosting, network, browser, cache, and dependency state can change a live demo. The lab does not prove a historical score, a field Core Web Vitals pass, a ranking or traffic change, a client outcome, or the result another production site will achieve. Production WordPress sites also carry consent tools, analytics, ads, ecommerce behavior, third-party widgets, editorial constraints, and rollback requirements that this dummy lab does not reproduce.

Related read-only tool

Inventory the assets loaded by selected WordPress pages

IndexLane Core Web Vitals Asset Snapshot lists scripts, styles, WordPress plugin/theme asset paths, and third-party domains found in selected same-site HTML. It exports evidence; it does not run Lighthouse, calculate Core Web Vitals, or change the site.

Production path

Have a production WordPress performance failure?

Send the affected URL and current field or lab symptom. The first task is to locate the dominant bottleneck and define a verifiable change.

Send the slow URL