A client sent us a theme link last spring with the note “the demo scores 99 on PageSpeed, so we’re good”. The demo did score 99. Their live site, three weeks after launch, was sitting at 41 on mobile with an LCP of 4.8 seconds. Nothing had gone wrong. The theme was doing exactly what it was built to do: render a homepage full of sliders, counters, animated icon grids and three Google Font families.

The gap between a theme demo and your actual site is where Core Web Vitals go to die. A demo is a controlled environment with optimised images, no tracking scripts, no marketing team adding a chat widget in month two, and often a CDN the vendor pays for. Your site is none of those things.

So here’s how we actually evaluate a theme before committing a client to it, including the tests that take ten minutes and the ones worth an hour.

What a theme actually controls, and what it doesn’t

Plenty of performance advice blames the theme for things the theme never touches. Your host controls TTFB. Your plugin stack controls most of the main-thread work after load. Your CDN controls transfer time.

The theme controls four things, and they happen to be the four things Core Web Vitals measure most directly:

• The critical rendering path. How many stylesheets load before first paint, whether they’re inline, whether the font is remote.
• The LCP element’s markup. Whether the hero image gets fetchpriority="high", whether it’s a background image in CSS (which delays discovery), whether it sits inside a JS-initialised slider.
• Layout stability. Reserved space for images, ad slots, sticky headers that push content, web font swaps without a matched fallback.
• Baseline JS. jQuery plus a slider plus a scroll animation library plus a mega menu script is 200KB of parse and execute before your analytics even loads. That’s your INP budget gone.

Everything else is your problem, not the theme’s. If you’re not sure which bucket your current slowness falls into, work through a proper diagnostic method rather than a plugin list before you blame the theme and rebuild.

Test the demo properly, not the homepage

Theme vendors optimise their marketing homepage. Of course they do. The demos are where the truth lives.

Pick the demo that most resembles your build. Building a shop? Test the shop demo with a category page of 24 products, not the hero-and-three-columns landing page. Then run these, in order:

1. PageSpeed Insights on the demo URL, mobile tab. Ignore the score. Read the LCP breakdown: TTFB, resource load delay, resource load duration, element render delay. Render delay over 40% means render-blocking assets.
2. Chrome DevTools, Network tab, disable cache, Fast 4G throttle. Count requests before DOMContentLoaded. Count separate CSS files. Look for fonts.googleapis.com.
3. Performance panel recording of a real interaction. Open the mobile menu. Filter a product. Watch the long tasks. This is your INP preview and nothing else will show it to you.
4. Coverage panel. Load the demo, open Coverage, reload. If 85% of the CSS is unused on a single page, the theme ships one stylesheet for 200 demos.

A quick server-side sanity check before any of that:

curl -o /dev/null -s -w "TTFB: %{timestarttransfer}s  Total: %{timetotal}s\n" \
  https://demo.example.com/shop/

Count the stylesheets the theme ships on one page
curl -s https://demo.example.com/shop/ | grep -o 'rel="stylesheet"' | wc -l

Eight or more stylesheets on a single template is a signal, not a verdict. Combined with HTTP/2 it may be fine. Combined with a 400KB main CSS file it is not.

Judging best WordPress theme performance claims against measurement

Every theme on every marketplace claims a 100/100 score. The screenshot is real and the context is missing. Here’s how we separate a genuinely fast WordPress theme from a well-photographed one.

Ask what happens with content in it

Scores taken on a near-empty page are meaningless. Load the demo’s blog archive, its single post template with comments enabled, and a page built with the theme’s own builder. If the score drops 30 points between homepage and archive, the theme’s baseline is heavy and the homepage was hand-tuned.

Check the CrUX data if the theme is popular

Popular themes have thousands of real sites in the Chrome UX Report. Run a few sites you know use the theme through PageSpeed Insights and read the field data section. Field data across several independent sites tells you far more than any lab number. If every site using the theme sits in the orange on INP, that isn’t coincidence.

Look at the changelog

Open the theme’s changelog and search for “fetchpriority”, “INP”, “speculative”, “jQuery”. A theme that has never mentioned INP since it replaced FID in March 2024 is not being maintained against current metrics. A theme that removed its jQuery dependency in 2025 is being actively worked on.

The red flags that predict trouble

These are the patterns we’ve seen wreck launches, roughly in order of how much damage they do:

• A hero slider on by default. Sliders are LCP poison: the image is usually discovered late, initialised by JS, and often has no reserved height. If the demo you like has a slider, price in replacing it.
• Remote web fonts with no local option. A call to fonts.googleapis.com adds a DNS lookup, a connection, a CSS round trip and then the font file. Self-hosted with a preload is typically 300 to 600ms faster on mobile, and it is 2026, there is no GDPR-comfortable reason to do otherwise.
• Icon fonts. Font Awesome’s full CSS plus font files is a render-blocking cost for icons you could inline as SVG in a fraction of the bytes.
• Mandatory page builder. If the theme only works with a specific builder, you inherit that builder’s DOM depth and script weight permanently.
• “Demo import” as the only setup path. These usually install 6 to 12 plugins. Import one on a staging site and look at the plugin list before deciding.
• No conditional enqueueing. This is the one that removes your escape route. Check the theme’s functions.php: if every script loads on every page regardless of whether the feature is used, you cannot optimise your way out.

Here’s the snippet we drop into a child theme on day one of an audit to see what’s actually loading:

addaction( 'wpprintfooterscripts', function () {
    if ( ! currentusercan( 'manage_options' ) ) {
        return;
    }
    global $wpscripts, $wpstyles;
    // Printed in the footer so it captures late enqueues too
    echo '<!-- JS: ' . eschtml( implode( ', ', $wpscripts->done ) ) . ' -->';
    echo '<!-- CSS: ' . eschtml( implode( ', ', $wpstyles->done ) ) . ' -->';
}, 9999 );

View source, read the comments, and you have the real asset inventory in thirty seconds. Then you know exactly which handles you’d need to dequeue and whether that’s even possible.

Fonts, heroes and CLS: where themes fail hardest

Three fixes cover most of what a theme gets wrong. If a theme already does all three, it’s in the top 10% of what’s on sale.

Self-host the font and match the fallback metrics. font-display: swap stops the invisible text but causes the layout shift. The fix is a metric-adjusted fallback, and you should generate the numbers rather than guess them:

@font-face {
  font-family: "Inter";
  src: url(/fonts/inter-var.woff2) format("woff2");
  font-weight: 100 900;
  font-display: swap;
}
/ Generated with a fallback metrics tool, not hand-tuned /
@font-face {
  font-family: "Inter Fallback";
  src: local("Arial");
  size-adjust: 107%;
  ascent-override: 90%;
  descent-override: 22%;
  line-gap-override: 0%;
}
body { font-family: "Inter", "Inter Fallback", sans-serif; }

Make the LCP image an <img> with high priority. WordPress core has applied fetchpriority="high" to the likely LCP image since 6.3, but themes that render heroes as CSS backgrounds bypass that entirely. In a template you control:

thepostthumbnail( 'hero-1600', array(
    'fetchpriority' => 'high',
    'loading'       => 'eager',   // never lazy-load the LCP element
    'decoding'      => 'sync',
    'sizes'         => '(max-width: 782px) 100vw, 1600px',
) );

Getting the formats and the srcset right is a separate job, and we’ve covered it in detail in our WordPress image optimisation guide.

Reserve space for everything that arrives late. Width and height attributes on every image, explicit min-height on cookie bars and notification strips, and no sticky header that changes height on scroll without position: sticky handling it.

Block themes, classic themes and builders in 2026

Block themes win on baseline weight. No jQuery, no builder runtime, styles generated from theme.json rather than a global stylesheet. On the builds we’ve done, a well-made block theme starts around 60 to 90KB of CSS and near-zero JS on a content page. A classic theme with a builder rarely starts under 400KB combined.

That doesn’t make block themes the automatic answer. Two honest caveats. First, the editing experience is still harder to lock down for non-technical clients, which is why guardrails on the admin matter more with full site editing than they ever did with a classic theme and ACF. Second, a badly built block theme can still ship enormous theme.json output and a hundred registered patterns you’ll never use.

If you want the performance profile of a hand-built front end without writing it from scratch, starting from a maintained Bootstrap 5 codebase is a legitimate route. That’s the reasoning behind CanvasWP: the markup and CSS come from a template that was built for production sites rather than for a demo screenshot, which means the asset budget is already sane before you add anything.

After you’ve chosen: the first week

Theme choice sets your ceiling. The first week of configuration decides whether you hit it.

1. Deactivate every bundled plugin you didn’t consciously decide to keep. Demo importers are generous.
2. Disable the theme’s built-in “optimisation” panel if you’re also running a caching plugin. Two systems minifying and deferring the same scripts is the single most common cause of “the site broke on mobile only”.
3. Enable core speculative loading (shipped in WordPress 6.8) and measure. On content sites with internal navigation it’s close to free.
4. Set a performance budget in writing and put it in the handover doc: 200KB JS, 120KB CSS, LCP under 2.0s on the staging environment. Budgets that live in someone’s head get broken in month two.
5. Re-measure with field data 28 days after launch. Lab numbers at launch are a hypothesis, and the 2026 performance playbook walks through what to do when the field data disagrees.