01 · Start with constraints
Define the real job before looking at scores
A theme is part of a system. Hosting produces the initial response; WordPress and plugins generate the document; the theme defines templates and much of the CSS; a builder may add markup and runtime code; editors add images, embeds and fonts. Selecting a theme without defining that system encourages false precision.
Write down the page types that must work: article, landing page, product archive, product page, cart, account and search. Then record the non-negotiable visual and operational requirements. A publishing team may value native blocks and restrained templates. A store may need reliable WooCommerce states. An agency may accept a builder dependency in exchange for client editing.
Prefer the least complex stack that meets the requirements—not the fewest bytes at any cost.
Separate necessities from imagined flexibility
“We might need it later” often turns into sliders, animation libraries, icon packs and global scripts paid for by every visitor. Mark each requirement as essential now, probable within 12 months, or speculative. A feature that can be added to one template should not automatically become a site-wide dependency.
- List representative templates and the heaviest expected page.
- Choose native blocks, a builder or hybrid workflow deliberately.
- Record accessibility, localization and commerce requirements.
- Define who maintains the site after launch.
02 · Classify the claim
Do not treat every performance number as the same evidence
A Lighthouse run is controlled lab evidence. Chrome UX Report data describes eligible real-user visits. A vendor demo run measures one configured demo. A developer saying “vanilla JavaScript” is a technical claim. All can be useful; none is interchangeable.
| Evidence | What it answers | Main limitation |
|---|---|---|
| Controlled lab test | How variants behave under the same simulated conditions | Not real traffic or a production build |
| Field data | What eligible visitors experienced over time | Includes hosting, content, traffic mix and configuration |
| Vendor demo | How that exact demo behaves now | May use atypical optimization or content |
| Official specification | Supported features, requirements and dependencies | Does not prove runtime performance |
| User report | Possible workflow and compatibility problems | Configuration is usually uncontrolled |
Look for the URL, date, theme version, device model, network and CPU assumptions, cache state and run count. One screenshot of “100” cannot tell you whether a theme is consistently fast, whether the tested page resembles your site, or whether its primary builder was absent.
Compare direct metrics, not mystery scores
LCP, bytes, request count and DOM size describe different constraints. Lighthouse Performance is a weighted diagnostic score that can hide different bottlenecks behind the same number. A transparent comparison should expose its underlying metrics and avoid blending popularity, star ratings and speed into a pseudo-scientific total.
03 · Follow dependencies
Evaluate what the theme needs to become useful
A sparse shell can look exceptionally light because its intended builder, widgets and real template are missing. That is a legitimate baseline, but a poor proxy for a completed site. Conversely, a self-contained theme can ship more at baseline yet need fewer additions to reach the target design.
For each candidate, map the likely stack: companion plugin, page builder, block library, commerce integration, font source, analytics, consent system and caching layer. Ask whether assets load globally or only when a component is used. Check whether a theme can disable unused modules, localize fonts and avoid duplicate icon systems.
Does it provide usable layouts without a required builder?
How much markup, CSS and JavaScript does a representative page add?
Do forms, search or commerce assets load on unrelated pages?
Are hero media, cards and embeds designed within a budget?
Design quality is part of performance
An attractive, legible native pattern that needs little alteration can outperform a nominally lighter blank canvas after reconstruction. Review responsive typography, focus states, navigation behavior, layout stability and template coverage. Avoid choosing an unusable theme for a marginal synthetic gain.
04 · Reduce uncertainty
Build a three-theme shortlist with explicit trade-offs
Start with evidence profiles, but rank candidates by project fit rather than a universal winner. We suggest a simple decision record: required stack, expected customization effort, baseline lab evidence, support/update status, accessibility concerns, and the most important unresolved risk.
- Reject dependency mismatches. If the team requires native blocks, remove builder-first options. If rapid visual editing is mandatory, price the complete builder stack.
- Reject functional gaps. Confirm every critical template and interaction instead of trusting a feature-grid checkmark.
- Compare transparent baselines. Prefer same-date, same-host, same-page-type measurements and read their limitations.
- Prototype the top two. Recreate one representative page with production-like content.
- Choose on measured risk. Include maintainability and editor behavior, not just first-load metrics.
Our theme finder follows this sequence. Its fit score is editorial and intentionally separate from measured Lighthouse data.
05 · Test your implementation
Verify a representative page before committing
Create a staging site on the intended host. Use the planned theme, builder, header, footer, fonts, plugins and image treatment. Test a homepage or landing page plus the heaviest business-critical template. Run at least three clean lab tests and use the median; test logged-out pages with production caching behavior.
Inspect the result rather than stopping at the score. Is LCP a hero image, heading or delayed slider? Is layout shift caused by an image without dimensions, font swap or consent banner? Is main-thread time coming from the theme, builder, analytics or another plugin? Fix the owning layer.
- Test mobile first and record tool settings.
- Confirm responsive and keyboard behavior manually.
- Keep image dimensions and compression production-realistic.
- After launch, monitor field data at the 75th percentile.
- Repeat after major theme, builder or template changes.
No pre-purchase benchmark can certify your future Core Web Vitals. A good selection process lowers risk; representative implementation testing resolves it.
Reference desk
Primary sources
- web.dev: Web Vitals — current metric definitions and “good” thresholds.
- Chrome for Developers: Lighthouse performance scoring — how weighted lab scoring works.
- Chrome for Developers: Chrome UX Report — field-data scope and eligibility.
- WordPress Theme Handbook — theme architecture and standards.
- Fast Loading Themes methodology — our launch study conditions and evidence boundaries.