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

Core Web Vitals are three Google metrics that measure how fast your main content appears, how quickly the page reacts to clicks and taps, and how stable the layout is while it loads. On WordPress, most failing scores come from a short list of causes: a slow server response, a heavy hero image, too much JavaScript from plugins, and images or ads without reserved space. This guide explains each metric, the current thresholds, and the fixes we use on real WordPress sites.

What Core Web Vitals measure

Google defines three Core Web Vitals. Each one has a “good” threshold, and Google checks it at the 75th percentile of page loads. That means at least 75% of real visits need to hit the target, measured separately for mobile and desktop. You can read the full definitions on web.dev’s Core Web Vitals overview.

INP replaced First Input Delay (FID) as a Core Web Vital on March 12, 2024, as announced on web.dev. FID only measured the delay before the first interaction. INP looks at interactions across the whole visit and reports one of the slowest. Many WordPress sites that passed with FID started failing with INP, because heavy JavaScript now shows up in the score.

Field data versus lab data

There are two kinds of performance data, and mixing them up causes a lot of confusion.

• Field data comes from real Chrome users and is collected in the Chrome User Experience Report (CrUX). It is what Google uses for Core Web Vitals. You see it in Google Search Console and at the top of PageSpeed Insights. It covers a rolling 28-day window, so fixes take weeks to show up.
• Lab data comes from a single simulated test, such as Lighthouse. It is great for debugging because you get results right away, but it is not your Core Web Vitals score.

A high Lighthouse score does not guarantee you pass in the field, and a low one does not mean you fail. Check field data first, then use lab tools to find the cause.

How to find what is failing

First find out which metric fails, on which template, and on which device. Our usual order:

1. Open the Core Web Vitals report in Google Search Console. It groups URLs by issue, such as “LCP issue: longer than 2.5s (mobile).”
2. Pick a representative URL from each group. On WordPress, URLs in a group usually share a template: product pages, blog posts, or the home page.
3. Run that URL through PageSpeed Insights. Read the field data, then the lab diagnostics below it.
4. Open Chrome DevTools, go to the Performance panel, and record a page load or an interaction on a throttled mobile profile. This shows exactly which element is the LCP, which script blocks the main thread, and which element shifts.

If the whole site is slow, not just one metric, start with our guide on why your WordPress site is slow. It covers the diagnostic order from server to browser.

Fixing LCP on WordPress

Google breaks LCP into four parts, explained in web.dev’s guide to optimizing LCP:

1. Time to First Byte (TTFB): how long the server takes to start sending the HTML.
2. Resource load delay: the gap between the first byte and when the browser starts loading the LCP image.
3. Resource load duration: how long the LCP image takes to download.
4. Element render delay: the time between the image arriving and it appearing on screen.

Fix the biggest part first. Each one has typical WordPress causes.

Server response time

If TTFB is slow, nothing else can be fast. Google suggests a TTFB of 0.8 seconds or less as a rough guide. TTFB is not a Core Web Vital itself, but it eats into your LCP budget. On WordPress, slow TTFB usually means:

• No full-page caching, so every visit runs PHP and database queries.
• Pages that can’t be cached, such as WooCommerce carts or logged-in views, running slow queries.
• An overloaded or poorly tuned server: too few PHP workers, OPcache too small, no persistent object cache.
• A large wp_options table with too much autoloaded data. We cover this in cleaning up a bloated WordPress database.

Server-side fixes are covered in depth in WordPress server tuning: PHP-FPM, OPcache and Redis. A CDN that caches full HTML pages at the edge can also cut TTFB for visitors far from your server.

The LCP image

On most WordPress pages the LCP element is a hero image, a featured image or a slider. Common problems:

• The image is lazy-loaded. Lazy loading is good for images below the fold and bad for the LCP image. WordPress core skips lazy loading for the first images in the content, but many themes, page builders and plugins add loading="lazy" to everything.
• The image is hidden from the browser. If the hero is a CSS background or is injected by a JavaScript slider, the browser can’t find it until late. Use a normal <img> tag in the HTML when you can.
• The image is too big. Serve properly sized images with srcset (WordPress does this for images inserted through the media library) and use modern formats such as WebP or AVIF.
• The image isn’t prioritized. Since WordPress 6.3, core adds fetchpriority="high" to the image it thinks is most likely the LCP element, as described in the WordPress 6.3 image performance notes. Custom themes that build image markup by hand often miss it.

For a hero image in a custom theme, the markup should look roughly like this:

<img src="/wp-content/uploads/hero-1200.webp"
     srcset="/wp-content/uploads/hero-800.webp 800w, /wp-content/uploads/hero-1200.webp 1200w"
     sizes="100vw" width="1200" height="600"
     fetchpriority="high" alt="Team reviewing a project plan">

No loading="lazy", explicit width and height, and a high fetch priority.

Render-blocking CSS and JavaScript

If the image arrives early but appears late, something is blocking rendering. On WordPress that is usually large stylesheets from the theme and plugins, or scripts loaded in the <head> without defer. Practical fixes:

• Stop plugins from loading their CSS and JavaScript on pages that don’t use them. A contact form plugin doesn’t need to load on every blog post.
• Defer non-critical scripts. WordPress 6.3 added a loading strategy option to wp_enqueue_script() for defer and async.

Fixing INP on WordPress

INP measures the time from a user’s interaction until the browser paints the next frame. web.dev’s INP guide splits it into three phases: input delay, processing time, and presentation delay. In plain terms, the page is slow to respond because the browser’s main thread is busy.

Common INP problems we see

• Too much third-party JavaScript. Chat widgets, tag managers loaded with many tags, ad scripts, heatmaps and session recorders all compete for the main thread.
• Heavy page builders. Some builders ship a lot of JavaScript to every page, even for simple layouts.
• Expensive event handlers. A “filter products” click that rebuilds a large part of the page, or a menu toggle that triggers a lot of layout work.
• Large DOM size. Pages with thousands of HTML elements, which is common with nested builder layouts, make every update slower.

How to improve INP

1. Audit your scripts. List every script that loads on the slow page and who owns it. Remove what nobody uses. This is often the biggest single win.
2. Delay third-party scripts until they are needed. For example, load a chat widget only after the user clicks the chat button.
3. Break up long tasks. If you write custom JavaScript, split heavy work into smaller chunks and yield to the main thread so the browser can paint in between.
4. Simplify the DOM. Reducing nested wrappers in templates and builder sections makes style and layout work cheaper.
5. Test with real interactions. Use the DevTools Performance panel and click the actual buttons, menus and filters your visitors use.

INP is often the hardest metric to fix on an older site, because the causes are spread across many plugins. That is one reason we track plugin count and script weight as part of measuring WordPress technical debt.

Fixing CLS on WordPress

CLS measures unexpected layout shifts: content that moves after it first appears. It is usually the easiest metric to fix.

Common CLS causes

• Images and embeds without dimensions. If an <img> has no width and height, the browser doesn’t know how much space to reserve. WordPress adds dimensions to images inserted through the editor, but custom theme code and some plugins leave them out.
• Ads, banners and cookie notices injected at the top of the page. Anything that pushes existing content down causes a shift.
• Web fonts. When a custom font loads and replaces the fallback font, text can reflow. Preloading key fonts and using font-display with matched fallback metrics reduces this.
• Late-loading content above the fold, such as a promotional bar or a “related posts” block that appears after a script runs.

How to fix CLS

• Always set width and height on images and video embeds, or use the CSS aspect-ratio property.
• Reserve space for ad slots and dynamic blocks with a fixed minimum height.
• Show cookie banners as overlays at the bottom of the screen instead of pushing content down.
• Self-host fonts, preload the one or two most important files, and pick fallback fonts with similar sizing.

WordPress plugins: help or harm?

Performance plugins can help, but stacking several of them often causes conflicts and hard-to-debug breakage.

We prefer to fix causes in this order:

1. Server and caching, so pages are generated and delivered quickly.
2. Remove what isn’t needed: unused plugins, scripts and styles.
3. Fix the theme: image markup, dimensions, script loading.
4. Only then add an optimization plugin for what is left, with settings tested on staging.

Test every change before it reaches production. We use automated browser tests, as described in our guide to automated testing for WordPress with Playwright and PHPUnit.

Your hosting sets the floor

You can’t optimize your way out of a slow server. If your host gives you shared resources, old PHP versions or no control over caching, there is a limit to how fast WordPress can be. Our comparison of managed WordPress hosting vs a VPS explains the tradeoffs.

Keep the gains

Core Web Vitals are not a one-time project. A new plugin or marketing tag can undo months of work. Check the Search Console report monthly, set a performance budget per template (such as a maximum page weight), and run a quick lab test on key templates after significant updates.

Get help with WordPress Core Web Vitals

If your Search Console report is full of red and you are not sure where to start, our WordPress performance review finds the specific causes on your site and ranks the fixes by impact. Server-side issues are handled through server tuning. Contact us and tell us which pages are failing.

Frequently asked questions

What are the Core Web Vitals thresholds?

A page is rated good when Largest Contentful Paint is 2.5 seconds or less, Interaction to Next Paint is 200 milliseconds or less, and Cumulative Layout Shift is 0.1 or less, measured at the 75th percentile of real visits.

Did INP replace FID?

Yes. Interaction to Next Paint replaced First Input Delay as a Core Web Vital on March 12, 2024. INP looks at the responsiveness of all interactions on a page, not just the first one.

Why does PageSpeed Insights show different scores than Search Console?

The Lighthouse score in PageSpeed Insights is a lab test on one simulated device. Search Console and the field data section use real visitor data from the Chrome User Experience Report over the last 28 days, which is what Google uses for Core Web Vitals.

Will a caching plugin fix my Core Web Vitals?

A caching plugin usually helps loading speed and LCP, but it does little for INP or CLS. Those depend on JavaScript, fonts, images and layout, so they need targeted fixes in the theme and plugins.