Core Web Vitals for WordPress: What Actually Matters?

Core Web Vitals can sound more complicated than they need to be.

If you have ever tested your WordPress site in PageSpeed Insights, you have seen the terms: LCP, INP, CLS, render-blocking resources, unused JavaScript. It is a lot. But for most sites the goal isn’t a perfect score. It is a site that feels fast, stable and easy to use for real visitors. That is what Core Web Vitals are trying to measure.

The numbers above are from a site that had already been tuned as far as its page builder allowed. I rebuilt it as a custom block theme, keeping the same design and content, and it became four times quicker on a phone. Most sites don’t need a rebuild, though. The fixes further down cover the photos, fonts and scripts I find on nearly every slow WordPress site.

LCP, INP and CLS: the three Core Web Vitals

Google judges each one on the slowest quarter of real visits, so a fast result on your own laptop doesn’t mean much on its own.

LCP: how long the main content takes to appear

Largest Contentful Paint is the moment the biggest thing on the first screen, usually the hero image or the headline, has loaded. Good is 2.5 seconds or less. Over 4 seconds is poor. It is often the most important of the three on a WordPress site, because it is how fast the page feels when someone lands on it.

What I usually find behind a slow LCP:

• Large hero images and sliders
• Slow hosting or no page caching
• Heavy themes and page builders
• CSS that blocks the page from drawing
• Fonts that load too slowly
• The hero image being lazy-loaded, so the browser fetches it last

Images are the usual winner. On one small business site the header images alone came to 16.2 MB. Converting them to the right format, with no resizing and no visible change, took the home page from about 6 MB to 1 MB.

Page weight measured logged out at phone width. Photos saved as PNG converted to JPEG at quality 90, checked pixel by pixel against the originals.

INP: how quickly the page responds

Interaction to Next Paint measures the delay between a tap or click and the page reacting to it. Good is 200 milliseconds or less. Over 500 is poor. It can only be measured with real visitors, which is why PageSpeed’s lab test shows Total Blocking Time instead.

The cause is nearly always JavaScript:

• Page builder scripts
• Plugins loading their files on every page
• Tracking and tag manager scripts
• Chat widgets, popups and cookie banners
• WooCommerce scripts on pages that sell nothing

Tracking is the one people don’t expect. On a brand new site that scored 99 to 100 on mobile, adding the standard Google Tag Manager snippet dropped it to 75–85 and pushed the main content from 1.7 to 4.5 seconds. Loading the tag manager after the visitor’s first tap or scroll brought all 13 pages back to 98–100.

PageSpeed Insights, mobile. If you run Google Ads, visitors arriving from an ad still need the tag straight away, so they are exempt; otherwise the delay costs you the click data.

CLS: whether the page holds still

Cumulative Layout Shift adds up how much things jump around while the page loads. Good is 0.1 or less. Over 0.25 is poor. It is why you sometimes tap the wrong link while a page is still loading.

• Images without set dimensions
• Web fonts swapping in at a different size
• Cookie banners and announcement bars pushing the page down
• Ads, embeds and form widgets that appear late
• Sliders and sticky headers

The fixes are usually small once you know which element moves. Each of these took about an hour or less:

Layout shift on desktop, two client sites, one fix each. Google’s limit for good is 0.1.

Your PageSpeed score isn’t the whole story

A good score helps, but sites can score well and still feel slow, or score lower because of a few warnings while feeling fine. PageSpeed Insights actually shows two different things. The section at the top, when your site gets enough traffic, is real Chrome visitors over the last 28 days. The score underneath is one simulated phone on one connection.

For a business site, a fast, clear, reliable experience matters more than a perfect score.

How to improve Core Web Vitals on WordPress

Not every PageSpeed warning deserves the same attention. This is the order I work in on most WordPress sites:

You don’t need to fix everything at once. Start with your most important pages and your mobile visitors.

Check your own site for free

My free health check runs these tests for you. It reads eight pages of your site the way a visitor on a phone sees them, then sends a two-page report in plain English covering four things:

• SpeedHow long your main content takes on real visitors’ phones, against Google’s “good” range.
• Google basicsPage titles, descriptions and how your pages look when shared.
• AI-readyWhether AI assistants and agents can read and use your pages.
• Trust and mobileSecure connection, and how easy you are to contact from a phone.

It ends with what is already working and what to fix first.

Get your free health check

When to get help with WordPress speed

Some of this you can do yourself: removing plugins you no longer use, compressing large images, setting up caching, replacing a heavy slider. If the site still feels slow, or Search Console is reporting Core Web Vitals problems, it is worth a proper review. Especially if your site:

• Uses a page builder
• Has a lot of plugins
• Is slow on phones
• Runs WooCommerce
• Feels slow despite a decent PageSpeed score
• Has had optimisation work before without a clear result
• Brings in leads, bookings or sales

My performance audit finds what is actually holding the site back and turns it into a clear plan. If you would rather not think about it again, a maintenance plan keeps the site fast as it changes. You can see what the work did for other sites in the case studies.