WordPress Core Web Vitals: how to pass them, step by step

Passing Core Web Vitals on WordPress means your pages load, respond and settle quickly for real visitors: LCP of 2.5 s or less, INP of 200 ms or less and CLS of 0.1 or less, at the 75th percentile. You get there by measuring first, adding page caching, keeping lazy loading off the main image and trimming plugin JavaScript.

To check it on your own site: SEO audit

Web performance optimisation is the set of changes that reduce how long a page takes to render, to respond and to stop moving. On WordPress, part of that work is done by core and part depends on your own choices: the host, the theme, the page builder and every plugin you activate. This guide separates what is already done for you from what you need to do, with exact versions and official sources. The current version of WordPress is 7.1 (7.1.3, released on 6 October 2026)1.

Measure before you change anything

Core Web Vitals are three user-experience metrics: LCP (how long the main element takes to render), INP (how long the page takes to respond to a click or tap; it replaced FID in March 2024) and CLS (how much the content shifts while loading).

There are two kinds of data, and they should not be mixed up:

• Field data. PageSpeed Insights shows the experience of real Chrome users over the previous 28 days2. This is what Google uses. If the URL does not have enough traffic, it falls back to data for the whole origin, and if there is not enough of that either, it shows nothing2.
• Lab data. Lighthouse simulates a page load under fixed conditions. It is useful for debugging and for before-and-after comparisons, but it is not the score Google sees.

The Core Web Vitals report in Search Console uses the same field data, groups URLs that offer a similar experience and splits mobile from desktop3. On WordPress this is handy: if a group of blog posts fails, the cause is usually the single post template, not each article.

Measure three templates rather than one page: the home page, a blog post and a service or product page. Note the field values for each before you touch anything.

What does WordPress already do for speed?

Before installing anything, find out what core already handles. This table summarises what the WordPress team has published on make.wordpress.org/core:

Three details that change decisions:

1. Automatic lazy loading needs dimensions. WordPress only adds loading="lazy" to images with width and height4, and since 6.3 it skips the first three images by default7. Markup printed by a page builder, or an image set as a CSS background, may fall outside that logic.
2. Neither WebP nor AVIF converts your existing images. Version 6.5 lets you upload AVIF but does not transform what you already have; generating them on upload needs a filter or a plugin9.
3. Speculative loading has limits. It is on for logged-out visitors on sites with pretty permalinks, uses prefetch with conservative eagerness and excludes URLs with query parameters10.

Performance Lab: the Performance Team's plugin

Performance Lab is the official plugin from the WordPress Performance Team. It bundles features under test, most of which are meant to end up in core11. Its current version requires WordPress 6.9 or later11.

From it you can switch on individual modules, each shipped as its own plugin. The ones listed on its official page include Image Prioritizer, Modern Image Formats, Enhanced Responsive Images, Embed Optimizer, Optimization Detective, Speculative Loading and View Transitions (experimental)11. Two rules for using it well:

• Turn them on one at a time and measure between changes. These are features under test: if something breaks, you will know which one did it.
• Do not duplicate features. If your caching or image plugin already converts to WebP or defers scripts, leave the equivalent module off.

Page caching: plugin or server

A page cache stores the generated HTML for each URL and serves it without running PHP or querying the database. The WordPress documentation describes caching as "the biggest benefit for the smallest hassle" and explains that caching plugins store posts and pages as static files12.

There are three places to put it, and one is enough:

1. At your host. Many managed WordPress hosts run a server-side page cache already. Ask before installing a plugin.
2. In the web server or a proxy. The WordPress documentation mentions Varnish as an example of server-side caching12. If you manage the server yourself, the guides to compression and caching in Apache and gzip, Brotli and caching in Nginx cover that layer.
3. With a caching plugin. There are several free ones in the WordPress directory. None is "the best" in the abstract: pick one your host recommends, or at least does not advise against.

To find out whether you already have a page cache, open Tools > Site Health. Since 6.1, WordPress detects page caching from the response headers and treats a server response under 600 ms as acceptable6.

Fix the metric that fails

Start with whichever metric is red in the field data, on the template where it fails. This table sums up the causes that come up most often on WordPress and the fix according to web.dev:

LCP: the main image

On most WordPress pages the LCP element is an image: the post's featured image or the home page hero. web.dev asks for three things: no lazy loading, an image present in the initial HTML so the browser finds it early, and fetchpriority="high"13. WordPress handles the last two through its image functions7, but a theme or an "optimisation" plugin can undo that. View the page source and look at the tag for that image.

INP: plugin and third-party JavaScript

INP gets worse when the main thread is busy with long tasks, and during page load every script being evaluated adds delay to the first interaction15. On WordPress, that JavaScript mostly comes from plugins that load their files on every page even when only one page uses them, and from third-party services. web.dev suggests an order: remove whatever does not add clear value, then defer the rest14.

CLS: dimensions, fonts and notices

CLS on WordPress nearly always has a specific culprit: an image without dimensions in a custom block, a consent banner that appears at the top and pushes the page down, or a web font that changes the size of the text as it loads. All three are fixed by reserving the space before the content arrives16.

What not to touch

Some advice that still circulates for WordPress does not hold up today, or only applies in certain cases:

• Combining all CSS and JavaScript into one file. The WordPress documentation recommends this only "when still using HTTP/1.x"12. With HTTP/2 or HTTP/3 it does not ask for it; only turn it on if a before-and-after measurement backs you up.
• Lazy-loading every image. The main image should never be lazy-loaded13. Check that your optimisation plugin leaves it out.
• Two caching plugins at once. They duplicate work and make it hard to tell which version of a page is being served. Use one, and confirm it in Site Health.
• Chasing a Lighthouse score of 100. It is a lab test. Google assesses field data at the 75th percentile3.

How to check it

1. Run the home page, a blog post and a service page through PageSpeed Insights and note the field data.
2. Review the Core Web Vitals report in Search Console, for mobile and desktop separately.
3. Open Tools > Site Health and look for the page cache and response time notices.
4. After each change, compare the lab results straight away. Field data takes longer: PageSpeed Insights summarises the previous 28 days2, so an improvement needs weeks to show in full.

What SmoothSeen does with this

SmoothSeen measures the speed of the page you give it using the real-user Core Web Vitals published by PageSpeed Insights and Google's thresholds; if the page lacks enough field data, it uses the Lighthouse lab test instead. Speed sits in the search visibility score alongside text compression, HTTPS and the other checks, and turns into tasks in a prioritised action plan.

What to do this week

Measure your three main templates in PageSpeed Insights and note which metric fails on each. Fix the main image on the template that fails LCP first, and confirm in Site Health that you have a page cache. If you want those measurements side by side with your competitors', analyse your site with SmoothSeen.

Frequently asked questions

Which caching plugin is best for WordPress?

There is no single best one. First find out whether your host already runs a server-side page cache, because then a plugin is redundant. If it does not, any caching plugin from the official directory that works well with your theme will do. Judge the outcome in Site Health and in the PageSpeed Insights field data, not by the plugin's reputation.

Why does PageSpeed Insights give me a different score every time?

The performance score at the top comes from the Lighthouse lab test, which varies with network conditions and server load at that moment. Field data, on the other hand, summarises 28 days of real visits and barely moves from one day to the next. To decide whether your WordPress site passes, look at the field data and its three metrics.

Do Elementor and other page builders slow a site down?

A page builder does not doom a site, but it adds HTML, CSS and JavaScript that a hand-built template would not need. The risk shows up in INP, because a very large DOM makes every screen update more expensive, and in LCP when the main image is set as a CSS background. Measure the template with field data before deciding whether to replace it.

Do I need to convert all my images to WebP or AVIF?

It is not mandatory. WordPress has accepted WebP uploads since 5.8 and AVIF since 6.5, but it does not convert the images you already have. Start with the images that are the LCP element on your main templates, because that is where a lighter file improves the metric that counts. The rest can wait for a plugin that generates them on upload.