DEV Community

Cambria Digital
Cambria Digital

Posted on

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

#wordpress #webperf #performance #webdev

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);
Enter fullscreen mode Exit fullscreen mode

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>
Enter fullscreen mode Exit fullscreen mode 
@font-face {
  font-family: "DM Sans";
  src: url("/fonts/dm-sans-latin.woff2") format("woff2");
  font-weight: 400 700;
  font-display: swap;
}
Enter fullscreen mode Exit fullscreen mode

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="...">
Enter fullscreen mode Exit fullscreen mode

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="...">
Enter fullscreen mode Exit fullscreen mode

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);
Enter fullscreen mode Exit fullscreen mode

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
}
Enter fullscreen mode Exit fullscreen mode

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.

Top comments (0)