Fixing Core Web Vitals in WordPress

Where WordPress sites lose their Core Web Vitals

The thresholds are the same as on any site: LCP 2.5 seconds or less, INP 200 milliseconds or less and CLS 0.1 or less at the 75th percentile of real visits. What is specific to WordPress is where the weight comes from, and the fact that most of it was added by installing something rather than writing code.

What recent WordPress versions already do for you

• Image dimensions and lazy loading. Core adds width and height to images inserted through the editor and adds loading="lazy" to images it expects to be below the fold.
• Hero image priority. Since WordPress 6.3, core tries to skip lazy loading on the image most likely to be the LCP element and adds fetchpriority="high" to it.
• Script loading strategies. Since 6.3, themes and plugins can register scripts with a defer or async strategy.
• Local fonts. The Font Library added in 6.5 stores fonts installed through it on your own site rather than loading them from a third party.
• Responsive images. Core has generated srcset and sizes for content images for many years.

These only help if the theme and plugins do not work around them. A builder that outputs its own image markup, or a theme that prints the hero through CSS, bypasses all of it.

The fix, step by step

Snippets for child themes and site plugins

Put these in a child theme's functions.php or, better, a small site-specific plugin so theme updates do not remove them. Test on staging first.

Dequeue a plugin's files where they are not used

add_action( 'wp_enqueue_scripts', function () {
    // Handles found in Query Monitor's "Scripts" and "Styles" panels.
    if ( ! is_front_page() ) {
        wp_dequeue_script( 'example-slider' );
        wp_dequeue_style( 'example-slider' );
    }
    if ( ! is_page( array( 'contact', 'book-a-visit' ) ) ) {
        wp_dequeue_script( 'example-forms' );
        wp_dequeue_style( 'example-forms' );
    }
}, 100 );

The priority of 100 makes the snippet run after most plugins have enqueued their files. Handle names differ between plugins, so copy them exactly from Query Monitor.

Load your own scripts with defer

add_action( 'wp_enqueue_scripts', function () {
    wp_enqueue_script(
        'site-menu',
        get_stylesheet_directory_uri() . '/js/menu.js',
        array(),
        '1.4.0',
        array( 'strategy' => 'defer', 'in_footer' => true )
    );
} );

Give a theme's hero image priority

If your theme outputs the hero with wp_get_attachment_image(), you can pass the loading attributes directly:

echo wp_get_attachment_image(
    $hero_id,
    'full',
    false,
    array( 'loading' => 'eager', 'fetchpriority' => 'high', 'sizes' => '100vw' )
);

Optimisation plugins: what helps and what backfires

Performance plugins bundle many options together. Some settings are reliably helpful; others trade one problem for another.

WooCommerce specifics

Shops add work that brochure sites do not have. Product, category and basket pages all have different needs.

• Cart fragments. Some themes refresh the mini-basket with a request on every page load. That request cannot be cached and adds main thread work. Many themes and recent WooCommerce versions limit this; check whether yours still does it on every page.
• Uncacheable pages. Basket, checkout and account pages must bypass the page cache, so their speed depends on the database and plugins. An object cache such as Redis and a review of slow queries in Query Monitor help most here.
• Product galleries. Galleries with zoom and lightbox scripts are often the heaviest part of a product page. Make sure the main image is an ordinary image with dimensions, and that zoom scripts load without blocking it.
• Filters. Category filter plugins can run heavy queries and re-render large parts of the page on each click, which hurts INP.

For crawl and indexing issues on shops, see the WooCommerce crawl guide.

Edge cases

• Fast when logged in, slow for visitors, or the reverse. Administrators usually bypass the page cache and load the admin bar. Always test logged out in a private window.
• Scores change after a plugin update. Updates can add new scripts or change how assets load. Recheck key templates after updating large plugins or the theme.
• Host-level optimisation. Some managed hosts rewrite HTML, add their own lazy loading or minify files. If a change you make seems to have no effect, check whether the host is overriding it.
• Front-end admin-ajax requests. Front-end requests to admin-ajax.php from plugins bypass page caching and can be slow. Query Monitor and the DevTools Network panel show them.
• Emoji and embed scripts. Core's emoji detection and oEmbed discovery scripts are small; removing them saves very little and is rarely the reason a page fails.

Keeping a WordPress site fast

• Treat every plugin as a cost. Before installing one, check what it loads on the front end and on which pages.
• Keep a staging site and test theme, builder and plugin updates there before production.
• Review plugins twice a year and remove anything unused; some leave code behind in the database or theme, so check after removing.
• Set editor rules for image size and for how many embeds and widgets a page may use.
• Watch the field data for each template group in Search Console, not just the home page.

For the individual metrics, see slow LCP, poor INP, slow TTFB and CLS in WordPress.