7 things that actually move WordPress Core Web Vitals (with code)

Cambria Digital — Mon, 01 Jun 2026 14:44:09 +0000

Most advice for speeding up WordPress stops at "install a caching plugin." That helps, but it hides the work instead of doing it. I've built more than 100 WordPress sites, including a property platform that serves 300+ auto-imported listings and still loads in under two seconds. These are the changes that actually made a difference, with the code to go with them.

No plugin shopping list. Just the parts that matter.

The short version

Ship less CSS and JS by removing what the page doesn't use
Self-host your fonts, use font-display: swap, and preload the one that matters
Put width and height on every image so nothing jumps around
Add fetchpriority="high" to the LCP image and loading="lazy" to images below the fold
Defer the scripts that don't need to run right away
Use a persistent object cache and fix N+1 queries
Judge yourself on field data (CrUX and INP), not just a Lighthouse score

1. Stop shipping CSS and JS the page never uses

This is the biggest win on most themes. WordPress and its plugins load everything on every page, whether the page needs it or not. Trim it per template:

add_action('wp_enqueue_scripts', function () {
    // Example: drop block-library CSS on a template that uses no blocks
    if (is_page_template('landing.php')) {
        wp_dequeue_style('wp-block-library');
        wp_dequeue_style('classic-theme-styles');
    }
}, 100);

Open the Coverage tab in Chrome DevTools and look at how much of each file is unused on a given page. If 70% of a stylesheet does nothing there, that's render-blocking weight you're paying for and getting nothing back.

2. Self-host your fonts and preload the important one

Loading fonts from Google means an extra connection and a request that can block rendering. Host them yourself, set swap, and preload only the weight you actually use above the fold:

<link rel="preload" href="/fonts/dm-sans-latin.woff2" as="font" type="font/woff2" crossorigin>

@font-face {
  font-family: "DM Sans";
  src: url("/fonts/dm-sans-latin.woff2") format("woff2");
  font-weight: 400 700;
  font-display: swap;
}

font-display: swap gets rid of the moment where text is invisible while the font loads. If your largest element is text, that moment is hurting your LCP.

3. Set width and height on every image

Every image, and embeds too. When you give the browser the dimensions, it reserves the space before the file arrives, so the page doesn't shift while things load:

<img src="/img/hero.webp" width="1200" height="630" alt="...">

This one pair of attributes fixes most of the layout shift that people usually blame on ads or fonts.

4. Prioritise the LCP image and lazy-load the rest

Your hero image is often the largest thing on screen, so it's your LCP element. Tell the browser it matters, and do not lazy-load it. Lazy-loading the LCP image is one of the most common mistakes I see:

<!-- Above the fold: the LCP image -->
<img src="/img/hero.webp" width="1200" height="630"
     fetchpriority="high" decoding="async" alt="...">

<!-- Below the fold -->
<img src="/img/section.webp" width="800" height="500"
     loading="lazy" decoding="async" alt="...">

5. Defer the JavaScript that doesn't need to block

Most theme scripts don't have to run before the page renders. Add defer instead of dropping everything in the head:

add_filter('script_loader_tag', function ($tag, $handle) {
    $defer = ['theme-main', 'carousel'];
    return in_array($handle, $defer, true)
        ? str_replace(' src', ' defer src', $tag)
        : $tag;
}, 10, 2);

Ship a small critical bundle and defer the rest. You'll usually see INP improve once the main thread isn't blocked while the page loads.

6. Use a persistent object cache and fix N+1 queries

TTFB feeds into LCP. A persistent object cache (Redis or Memcached) stops WordPress from re-running the same queries on every request. And in custom loops, fetch your data once instead of querying inside the loop:

// N+1: one meta query per post, which gets slow fast
foreach ($ids as $id) {
    $price = get_post_meta($id, 'price', true);
}

// Better: warm the cache once, then read from memory
update_meta_cache('post', $ids);
foreach ($ids as $id) {
    $price = get_post_meta($id, 'price', true); // served from cache now
}

7. Measure the thing your users actually feel

Lighthouse is a lab test on one simulated phone. Real visitors are field data. Watch INP (the metric that replaced FID), along with LCP and CLS, in CrUX and Search Console, and fix what people actually hit. A perfect Lighthouse score with bad field INP still means a slow site for the people using it.

So why not just use a page builder?

Builders are quick to start with and slow to live with: nested divs, a stack of separate stylesheets, and JavaScript you can't fully remove. For a marketing site where speed is part of the point, hand-written templates win on every metric above. For a quick internal tool, a builder is fine. Pick the right one for the job.

Written by the team at Cambria Digital, a Cardiff-based studio that hand-codes WordPress sites and web apps. Happy to talk through Core Web Vitals in the comments.

DEV Community: Cambria Digital