WordPress Core Web Vitals: Fixing LCP First

On most WordPress sites, a failed Core Web Vitals assessment means slow LCP. Fix it by finding which of its four parts is slow, not by switching on every optimisation toggle at once.

Read the field report first

Core Web Vitals are measured on real visitors, not in a lab test. Three metrics count, each judged at the 75th percentile of page loads:

INP replaced First Input Delay in March 2024, so older guides that talk about FID are out of date.

In Search Console's Core Web Vitals report, failing URLs are grouped by similar templates, so one failing group usually means one failing template: all product pages, or all posts. Open a sample URL in a page speed tool to see the lab breakdown. The field data behind the report covers a rolling 28 days, so even a correct fix takes weeks to turn the group green. Site Kit shows the same data inside the admin, but it measures nothing new.

Mobile and desktop are reported separately. Mobile almost always fails first.

LCP, split into its four parts

LCP is not a single delay. It is the sum of four parts, and each one has a different fix:

A page speed tool's LCP breakdown shows these four numbers directly. Work on the largest one.

Time to first byte. If it is above about 800 ms, nothing on the front end will rescue LCP. The server side is covered in reducing server response time.

Load delay. This is the most common WordPress-specific cause. Since WordPress 6.3, core leaves the first few content images eager (three by default, adjustable with the wp_omit_loading_attr_threshold filter) and adds fetchpriority="high" to the likely LCP image. A theme template, page builder or plugin that outputs its own markup often puts loading="lazy" back on the hero, or uses it as a CSS background the browser only finds after parsing the stylesheet. In a template, ask for the opposite explicitly:

<?php
// Hero image in a theme template: never lazy, fetched first.
echo wp_get_attachment_image(
    get_post_thumbnail_id(),
    'large',
    false,
    [
        'loading'       => false,
        'fetchpriority' => 'high',
    ]
);

Do not lazy-load the LCP image anywhere. That includes a performance plugin's JavaScript lazy loader, which hides the image from the browser until the script runs.

Load duration. An image sized for a 2560px screen and displayed at 800px carries about ten times the pixels it needs. WordPress's srcset normally prevents this, so when it happens a theme or builder is usually outputting the full-size file. Size and format work is in optimising images.

Render delay. The image arrived, but the browser is still waiting on stylesheets and synchronous scripts. Removing, deferring and delaying them is in render-blocking resources.

First Contentful Paint is affected by the same server time and render-blocking resources. A slow FCP alongside a slow LCP points at the server or blocking CSS, not at the image.

INP: too much JavaScript on the main thread

INP fails when a tap triggers work that keeps the main thread busy, or when the thread is already busy with something else. On WordPress the usual sources are:

• third-party scripts — chat, heat maps, ad and consent tools — running long tasks;
• sliders and animation libraries initialising on every page;
• page builders that ship large JavaScript bundles for interactive widgets.

Delay third-party scripts until the first interaction where the vendor allows it, and remove what no page uses. Delaying moves the cost rather than removing it: every delayed script runs on the first tap, which can make that first interaction the slowest one. Remove first, delay second, and check INP after enabling it. Anything that still takes hundreds of milliseconds after a click is a code problem in that widget.

CLS

Layout shift has its own causes — images without dimensions, ads, embeds, banners and fonts — and they are covered one by one in fixing cumulative layout shift.

What a plugin can and cannot fix

That is the honest answer to "which Core Web Vitals plugin": on hosting without server-level caching, an all-in-one plugin such as WP Rocket covers the first three rows; caching and image handling work out of the box, and the CSS options are worth enabling one at a time. The other three rows need work no plugin does for you.

Common mistakes

• Optimising for the lab score. A 95 in a page speed tool does not change a failed field report on its own. Mobile visitors on slow networks decide the 75th percentile.
• Lazy-loading everything. Including the hero, which turns load delay into the largest part of LCP.
• Preloading several images. Preload the one LCP image. Preloading five means none of them is prioritised.
• Treating INP as a server problem. Caching does not help a slow click handler.
• Validating the fix the same day and concluding it did not work.

Verify

1. Run the failing template's sample URL through a page speed tool and note the four LCP parts.
2. Check the page source: the LCP image has no loading="lazy" and does have fetchpriority="high" — core adds it automatically on 6.3+; if it is missing, the markup did not come through core.
3. Retest logged out, with the cache warm, on a mobile profile.
4. In Search Console, click Validate fix on the URL group and allow 28 days for the field data to turn over.

The wider order of work is in how to speed up a WordPress site.