Trust the method—or challenge it.

01 / Principles

What a fair theme test must protect

Theme performance is easy to oversimplify. A minimal theme can look unbeatable on an empty page, while a polished demo can be penalized for carrying the very design and content a buyer wants. Hosting, cache warmth, traffic, plugins, image choices and measurement variance can overwhelm a small theme-level difference. Our method therefore uses five guardrails.

1. Compare like with like. Themes in the same table run against the same platform, preview service, test tool, form factor and collection window.
2. Repeat and preserve. We run three times, report the median for each metric and publish the individual JSON reports in the raw archive.
3. Label the evidence. Lab measurements, field data, official facts and editorial interpretation are never silently merged.
4. Prefer representative scenarios. A content-rich business page, article and store route are more useful than an empty install. When that is not available, the result is explicitly named a preview baseline.
5. Do not reward unusable minimalism. A theme that needs a builder to become useful is evaluated as a dependency shell, not crowned on its empty-theme metric.

02 / Evidence labels

Every datum has a provenance class

Vendor claims would receive a separate “Vendor claim” label if quoted. No current profile relies on a vendor speed claim.

03 / Current study

Study FLT-WP-001: official preview baseline

The launch dataset measures ten themes on wp-themes.com, the official WordPress.org preview service. These pages use the service’s shared preview content and infrastructure. That reduces cross-host variation, but it does not produce a completed representative business, publication or WooCommerce site.

Throttling configuration

Theme selection

The sample is purposeful, not exhaustive. It covers popular multipurpose themes (Astra, GeneratePress, Kadence, Blocksy, Neve and OceanWP), a native block-theme control (Twenty Twenty-Five), an Elementor shell (Hello Elementor), and two WooCommerce-oriented options (Storefront and Botiga). Popularity, workflow variety, official metadata availability and direct user decision relevance drove inclusion.

Run and aggregation procedure

1. Resolve the official preview URL over HTTPS.
2. Launch a fresh Lighthouse navigation with mobile form factor and storage reset.
3. Collect performance category results and network records.
4. Repeat two more times in the same collection window.
5. Take the median of each individual metric, rather than selecting one whole “best” run.
6. Store tested theme version and date next to the aggregate.

We do not discard slow runs merely because they look inconvenient. A failed run would be reported and repeated with the failure retained in the study log; this collection completed all 30 navigations.

Per-run variation

Aggregate cards can conceal normal run noise. The table exposes all three captured values as score / LCP / transferred bytes. “LCP spread” is the slowest minus the fastest run; it is descriptive, not a confidence interval.

GeneratePress shows the widest LCP spread in this small collection: 568 ms between its first and fastest runs. That is why differences of only a few hundred milliseconds should not override stack and workflow fit. All 30 raw Lighthouse JSON reports are retained in the study archive.

04 / Metrics

What each number can—and cannot—say

Core Web Vitals are field metrics judged at the 75th percentile. Google’s current “good” thresholds are LCP ≤ 2.5 s, INP ≤ 200 ms and CLS ≤ 0.1. A Lighthouse run is not field compliance.

Source: Google’s Web Vitals guidance and threshold methodology.

05 / Recommendation rules

Fit and evidence remain separate

We do not calculate a universal Fast Loading Themes score. The Lighthouse performance score is shown as produced by Lighthouse, but rankings use named raw metrics such as LCP or transferred bytes. This avoids burying weighting choices inside a proprietary number.

Editorial recommendations consider:

• site and content type;
• editing workflow and builder requirement;
• design quality and how much work is needed to reach an acceptable result;
• dependency surface and likely companion plugins;
• current maintenance signals from the repository;
• measured baseline results, with their scenario limits;
• commercial constraints only after usefulness and fit.

The finder uses visible fit points to order candidates. Measured metrics are displayed beside the match result; they are not secretly folded into that editorial score. A hard mismatch—such as selecting full-site editing for a classic theme—carries a larger penalty than a small LCP difference.

Affiliate independence

The launch dataset links to WordPress.org and contains no affiliate links. If affiliate relationships are added later, they will not determine sample inclusion, ranking or outcome. A visible disclosure will appear beside commercial links and on the disclosure page.

06 / Sources

Current data provenance

07 / Limitations

Known constraints in this dataset

• Preview content is not a full representative site. It offers cross-theme control but limited real-world depth.
• No WooCommerce route was measured. Store-oriented profiles clearly state this gap.
• No field data is attributed to individual WordPress themes. Reliable detection and sufficient CrUX coverage are not available in this release.
• INP is unavailable. A scripted lab interaction would still not be field INP; we show TBT as a diagnostic and label it accordingly.
• Third-party and font analysis is scenario-bound. The preview does not activate the starter sites or production integrations many users will install.
• Lighthouse variance remains. Three medians reduce—but do not eliminate—environmental noise. Differences of a few hundred milliseconds should not dominate a decision.
• Repository install counts are buckets. “500K+” is not an exact current count.
• Pricing is omitted. We will not publish pricing until a repeatable freshness and region/tax disclaimer process is implemented.

08 / Updates

Freshness, corrections and version history

Each measured profile stores test date, theme version, scenario and run count. A new test adds a history row; it does not silently rewrite the old result. Official metadata is re-retrieved before a study. Profiles older than 90 days or superseded by a major version should be visibly flagged before appearing in a current leaderboard.

Factual errors are corrected promptly and recorded in a study changelog when they affect a metric, rank or recommendation. Send a reproducible correction through the contact page. Theme vendors may point out errors but cannot pay to remove a limitation or alter a ranking.