WordPress Core Web Vitals: How to Pass LCP, INP and CLS

To pass Core Web Vitals, a WordPress page needs a Largest Contentful Paint (LCP) of 2.5 seconds or less, an Interaction to Next Paint (INP) of 200 milliseconds or less and a Cumulative Layout Shift (CLS) of 0.1 or less, measured on real visitors. On most business sites the fixes are the same handful of things: a lighter theme, properly sized images, fewer plugins and scripts, good caching and decent hosting. This guide shows how to measure your site correctly, what usually causes the problems on WordPress and a step-by-step plan to fix them.

The three Core Web Vitals and their targets

Metric	What it measures	Good	Poor
LCP (Largest Contentful Paint)	How quickly the main content, often the hero image or headline, appears	2.5 s or less	Over 4 s
INP (Interaction to Next Paint)	How quickly the page responds when someone taps, clicks or types	200 ms or less	Over 500 ms
CLS (Cumulative Layout Shift)	How much the layout jumps around while loading	0.1 or less	Over 0.25

web.dev recommends judging these at the 75th percentile of page loads, separately for mobile and desktop. A page passes only when all three metrics are good at that level. In practice that means most of your real visitors, including the ones on mid-range phones and patchy mobile data, need a good experience.

Does it affect rankings? Google Search Central says good Core Web Vitals, along with other page experience aspects, "aligns with what our core ranking systems seek to reward", and recommends site owners achieve them. In our view the bigger reason is customers: a slow, jumpy page loses enquiries no matter where it ranks.

How to measure: field data vs lab data

This is where most confusion comes from. There are two kinds of numbers:

Field data is collected from real Chrome users visiting your site. PageSpeed Insights shows it from the Chrome User Experience Report (CrUX), covering the previous 28 days. This is what counts for Core Web Vitals.
Lab data comes from Lighthouse loading your page once in a simulated environment. It's useful for debugging and for checking a fix before real data catches up. web.dev notes that Lighthouse can't measure INP because no user is interacting, so it shows Total Blocking Time (TBT) as a stand-in.

So a "Performance score" of 45 in the lab section doesn't automatically mean you fail Core Web Vitals, and a score of 95 doesn't mean you pass. Look at the field data section first.

Where to look

PageSpeed Insights: enter a URL and read the "Discover what your real users are experiencing" section. If a page doesn't have enough visitors, PageSpeed Insights falls back to data for your whole site (origin), and if the site has too little traffic it shows no field data at all. Smaller local business sites often see this; use lab data and TBT as a guide in that case.
Search Console Core Web Vitals report: groups similar URLs together and labels each group Good, Need improvement or Poor, separately for mobile and desktop. A group takes the status of its worst metric. After fixing an issue, use "Validate fix" to start a 28-day monitoring period.

Common WordPress causes, and how to fix them

1. Heavy themes and page builders

Multipurpose themes and page builders load CSS and JavaScript for features you may never use, and often wrap content in many nested elements. web.dev's INP guidance notes that large page structures (DOM size) slow rendering both at load and during interactions.

Fix: if you're redesigning, choose a lightweight theme or a custom theme built for your content. If you're keeping a page builder, disable modules you don't use, avoid sliders and animation on the first screen, and keep layouts simple.

2. Unoptimised images

A 3 MB photo of your showroom uploaded straight from a phone is a classic LCP problem. Missing image dimensions cause layout shift.

Fix:

Resize images to the size they're displayed at and compress them. WordPress's optimisation documentation suggests choosing the right format and considering WebP. WordPress 6.5 added AVIF support, as long as your server's image library supports it (check under Tools > Site Health > Info > Media Handling).
Make sure images have width and height attributes. web.dev says to "always include width and height size attributes on your images and video elements" so the browser can reserve space.
Don't lazy-load the main image at the top of the page. web.dev is blunt: "Never lazy-load your LCP image." If a plugin lazy-loads all images, exclude the hero image from it.
For the hero image, consider fetchpriority="high", but only on one or two images.

3. Too many plugins and third-party scripts

Every plugin that adds front-end code, plus chat widgets, tracking pixels, review badges and pop-ups, adds JavaScript the phone has to download and run. Heavy scripts create long tasks on the main thread, which is what drives poor INP.

Fix: list every plugin and script and ask what it does for the business. WordPress's documentation says plainly: "Deactivate and delete any unnecessary plugins." Remove duplicate tracking (for example, the same analytics tag added by a plugin and by hand), and load chat widgets after the page is usable rather than immediately.

4. Render-blocking CSS and JavaScript

Scripts in the page head that load synchronously stop the browser from showing anything until they finish. web.dev notes it's "almost never necessary" to add synchronous scripts there.

Fix: defer non-critical JavaScript, reduce unused CSS, and inline only very small critical CSS. Many caching and optimisation plugins can do this, but test carefully, because aggressive settings can break menus, forms and sliders.

5. Web fonts

Several font families in many weights slow down loading, and font swapping can make text jump. web.dev lists font loading as a cause of layout shift and suggests preloading critical fonts, using a close-matching fallback font and considering font-display: optional.

Fix: use one or two families and only the weights you need. Host fonts locally where your theme allows. If your site has Bengali text, check which Bengali font files are loading and how large they are.

6. Caching and hosting

Nothing appears until the server sends the first byte. web.dev warns that a slow server response "can make achieving a 2.5 second LCP challenging, or even impossible". WordPress builds each page with PHP and database queries, so the server matters.

Fix: use page caching (WordPress's documentation describes caching plugins that serve pages as static files), run a current PHP version (WordPress.org recommends PHP 8.3 or newer), and consider a CDN for images, scripts and styles. If the server is still slow after caching, the hosting plan is probably the bottleneck.

7. Third-party embeds

YouTube videos, Google Maps embeds, Instagram feeds and ad slots are heavy and often load without reserved space. web.dev calls ads "one of the largest contributors to layout shifts on the web".

Fix: reserve space with a fixed height or aspect ratio, and use a click-to-load preview (a thumbnail that loads the real video or map only when tapped). A contact page with a map, a video and a reviews widget all loading at once is a common example.

A step-by-step plan

Check field data in Search Console and PageSpeed Insights. Note which metric fails, on which device and which URL groups. Usually it's mobile.
Start with your most important templates: homepage, main service pages and contact page. Fixing a template fixes every page that uses it.
Take a full backup and, ideally, work on a staging copy.
Fix server response first: page caching, current PHP, and hosting if needed.
Fix images: resize, compress, convert to WebP or AVIF, add dimensions, stop lazy-loading the hero image.
Cut plugins and scripts: remove what isn't needed, delay what can wait.
Fix layout shift: reserve space for embeds, banners and cookie notices; tidy up fonts.
Test in the lab with PageSpeed Insights and on a real mid-range Android phone, and check forms, menus and checkout still work.
Validate in Search Console and wait for the 28-day field data to update.
Keep it fixed: check speed whenever you add a plugin, change the theme or add a new tracking tag.

Core Web Vitals are one part of technical health. For crawling, indexing, redirects and structured data, see our technical SEO checklist.

Want a faster WordPress site?

We audit and fix slow WordPress sites, and build new ones with performance planned in from the start. See our WordPress development service or send us your URL for a review.

Based on web.dev, Google Search Central, PageSpeed Insights and Search Console documentation, and WordPress.org developer documentation as read on 18 October 2026.

Sources

Written by Koushik Paikar

Founder of Pocket Web Dev, a digital marketing and web development agency in Kolkata. About us

How to Pass Core Web Vitals on a WordPress Business Website