Core Web Vitals on WordPress: A Practical Fix List

Core Web Vitals on WordPress come down to three measurements Google uses to judge how a page feels to real visitors: Largest Contentful Paint (how fast the main content appears), Interaction to Next Paint (how fast the page responds to a tap or click) and Cumulative Layout Shift (how much the layout jumps while loading). On WordPress, most problems with all three come from oversized images, too many scripts and styles, and a slow server response.

This is the fix list I work through, in the order that usually gets the biggest results first.

The numbers Google wants

Google’s own guide to Web Vitals sets the targets. A page passes when at least 75% of real visits meet these:

• LCP: 2.5 seconds or less. The biggest image or text block in view should be on screen by then.
• INP: 200 milliseconds or less. After a tap or click, the page should visibly respond within a fifth of a second.
• CLS: 0.1 or less. Content should not shove itself around as images, ads and fonts load.

Check your pages in PageSpeed Insights. The top section shows real-visitor data when Google has enough of it, and that is the part that counts. The lab score below it is useful for finding causes.

Fixing LCP: get the main content on screen

On most WordPress sites, the LCP element is the hero image or the main heading. The LCP guide breaks the time into stages, and these fixes cover the common ones:

1. Resize the hero image. Serve it at the size it is shown, in WebP or AVIF. A 3 MB photo is the single most common LCP problem I find.
2. Do not lazy load it. Lazy loading is great below the fold and harmful for the main image. The hero should load right away, ideally with a high fetch priority.
3. Cut what blocks the first paint. Stylesheets and scripts in the page head delay everything. Remove the ones the page does not use.
4. Speed up the server response. Page caching and a decent host bring the time to first byte down, and every later step starts sooner.
5. Self-host or preload web fonts. A heading waiting on a font from another server is a heading that paints late.

Fixing INP: make taps feel instant

INP replaced First Input Delay in 2024 and it is stricter: it looks at interactions during the whole visit, not only the first one. Slow INP almost always means too much JavaScript running on the main thread. The INP guide goes deep, but on WordPress the usual fixes are:

• Remove plugins that load scripts everywhere. Sliders, popups, chat widgets and tracking tools often run on every page whether they are used or not.
• Delay third-party scripts like chat and some trackers until the visitor interacts or the page has loaded.
• Trim the page builder. Fewer add-on widgets and fewer animations mean less script per page. I cover how I keep builds lean in Elementor website design your team can edit.
• Watch the menu and forms. Mega menus and multi-step forms are where heavy scripts show up as a laggy tap.

This is the same plugin stack problem I describe in why your WordPress site is slow. It is also why the plugins I build load their files only on the pages that use them.

Fixing CLS: stop the layout jumping

Layout shift is the most annoying of the three for visitors: you go to tap a button and the page moves. The CLS guide lists the causes, and on WordPress they are usually these:

• Images without dimensions. Give every image a width and height so the browser saves the space.
• Banners and bars that push content down after the page loads, like cookie notices and announcement bars. Reserve their space or overlay them.
• Fonts that swap in at a different size. Pick fallback fonts with similar metrics and preload the real ones.
• Embeds and ads with no reserved height.

The WordPress-specific checklist

1. List every plugin and remove what does not earn its place.
2. Make sure each remaining plugin loads its files only where they are needed.
3. Turn on page caching, at the server if your host offers it.
4. Convert images to WebP or AVIF and resize them to their display size.
5. Set the hero image to load first and lazy load everything below it.
6. Host fonts locally and preload the ones above the fold.
7. Clean up the database: old revisions, expired transients and autoloaded options left by deleted plugins.
8. Re-test on mobile, then check Search Console’s Core Web Vitals report over the following weeks.

If the site is due for a bigger change, fold these into the plan from the start. My website redesign checklist shows where they fit.

Do Core Web Vitals affect rankings?

They are part of how Google judges page experience, but content still comes first. A fast page with thin content will not outrank a slower page that answers the question. Where they matter most is between close competitors, and in conversions: a page that loads fast and does not jump keeps more visitors long enough to call. I build speed into every site from the start, which is easier than fixing it later. My Plugin Stack page shows how.

Frequently asked questions

Why does my PageSpeed score change every time I test?

The lab score is a single simulated load, and it varies with server response and network timing. The real-visitor data at the top of the report is the stable number, and it is the one Google uses.

Can a plugin fix my Core Web Vitals?

A good caching or image plugin can help a lot. It cannot fix a page that loads too many scripts, a theme that shifts its layout or a server that is too slow. Those need changes to the site itself.

How long until Google sees my improvements?

The real-visitor data covers the previous 28 days, so improvements show up gradually over about a month.