Skip to content

9 November 2026 · Sirajia Sol

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

Cover image with the title Core Web Vitals for WordPress: How to Fix LCP, INP and CLS on a dark Sirajia Sol background

Core Web Vitals for WordPress sites usually come down to a short list of repeat offenders: a heavy theme or page builder, too many plugins loading scripts on every page, an unoptimised hero image, web fonts that shift the layout, and slow hosting. The good news is that WordPress problems are well understood, and you can fix most of them in a sensible order without rebuilding the site.

This guide explains what the three metrics measure, how to find out which pages really fail, and which fixes tend to matter most for each metric. It makes no promise of a score or a ranking: results depend on your theme, plugins, hosting and audience devices.

What the Core Web Vitals measure

Google's web.dev guidance on Core Web Vitals defines three metrics and the thresholds for a "good" result, measured at the 75th percentile of real page loads:

Metric What it measures Good Poor
Largest Contentful Paint (LCP) How quickly the main content element, often a hero image or headline, is rendered 2.5 seconds or less More than 4 seconds
Interaction to Next Paint (INP) How quickly the page responds visually after clicks, taps and key presses 200 milliseconds or less More than 500 milliseconds
Cumulative Layout Shift (CLS) How much visible content moves unexpectedly while loading 0.1 or less More than 0.25

INP replaced First Input Delay as a Core Web Vital in March 2024, so older advice that talks about FID is out of date.

Core Web Vitals and SEO: what to expect

Google includes Core Web Vitals in the page experience signals used by its ranking systems, and its page experience documentation is clear that good page experience does not replace relevant, helpful content. Treat the metrics as a baseline. They help visitors stay on the page and complete actions, and they remove a technical weakness when you are competing against pages of similar quality. They will not carry a thin page to the top.

Step 1: Start with field data, not a lab score

The most common mistake is chasing a green number in a single test. Work from real-user data first:

  1. Open the Core Web Vitals report in Google Search Console. It groups URLs by status (poor, needs improvement, good) for mobile and desktop and shows which metric fails.
  2. Check PageSpeed Insights for the specific URLs you care about. The field data section shows what real Chrome users experienced; the lab section helps you find the cause.
  3. Group by template. WordPress pages share templates: the home page, blog posts, category pages, product pages. A fix to a template improves every URL that uses it, so prioritise templates with the most traffic or revenue.
  4. Note the mobile result separately. Mobile devices and connections are slower, and most sites fail there first.

If your site is new or low traffic, Search Console may show no field data. In that case use lab tests from PageSpeed Insights or Lighthouse as a guide, and treat them as estimates.

Step 2: Fix slow LCP on WordPress

LCP is usually the first metric to fail. Start by identifying the LCP element in PageSpeed Insights; it is most often the hero image, a large heading or a background image set by the page builder.

  • Serve a correctly sized, compressed hero image. Upload images at the size they display, use WebP or AVIF where your setup supports it, and let WordPress generate responsive srcset sizes.
  • Do not lazy-load the LCP image. WordPress adds lazy loading to images by default, but the main image above the fold should load immediately. Recent WordPress versions try to avoid lazy loading the first large image, but themes and builders can override it, so check the HTML.
  • Preload the key image or font when it is discovered late, for example when it is a CSS background image.
  • Cut render-blocking CSS and JavaScript. Remove unused plugins, and use your optimisation plugin's options to delay non-critical scripts. Test the page after each change, because aggressive settings can break menus and forms.
  • Check server response time. If the time to first byte is slow, page caching, a lighter database and better hosting matter more than image tweaks. Shared hosting with many sites on one server is a frequent cause.
  • Use a CDN for static files if your audience is spread across regions, such as the USA and other countries.

Step 3: Fix poor INP

INP measures responsiveness across the whole visit, not just the first load. On WordPress, poor INP is normally a JavaScript problem.

  • Audit plugins that add scripts. Chat widgets, popups, sliders, tracking tools, social feeds and review widgets can each add main-thread work. Remove what you do not need and load the rest only where it is used.
  • Be careful with page builders. Heavy builders and animation libraries can add large amounts of script. Simplify sections that include many animated elements.
  • Defer or delay third-party scripts such as analytics add-ons and ad tags, and review them with the Chrome DevTools Performance panel to see which tasks block interaction.
  • Keep the DOM small. Pages with thousands of nested elements make every interaction slower. Replace deeply nested layouts with simpler structures.
  • Test real interactions. Open menus, accordions, filters and forms on a mid-range phone, not only on a fast laptop.

Google's INP guide on web.dev explains how to find slow interactions with field and lab tools.

Step 4: Fix layout shift (CLS)

Layout shift happens when elements appear or resize after the page starts to render. On WordPress, the usual causes are easy to find:

  • Images and embeds without dimensions. Set width and height attributes (WordPress does this for most images it generates) and reserve space for videos, maps and iframes.
  • Web fonts that swap late. Use font-display: swap or optional, preload the main font, and limit the number of font families and weights.
  • Ads, banners and cookie notices that push content down. Reserve space for them or position them so they do not move content that is already visible.
  • Dynamically injected content from plugins, such as announcement bars, popups and "related posts" widgets that load after the first paint.
  • Sticky headers that change height after scrolling or after a font loads.

Step 5: Pick a sensible plugin and theme setup

Plugins can help, but each one is another piece of code to maintain, and stacking several optimisation plugins often causes conflicts.

Area Safe approach
Caching Use one page-caching solution, usually the one your host recommends
Images One image optimisation tool for compression and modern formats, not several
Scripts Remove unused plugins first; only then defer or delay scripts selectively
Theme Prefer a lightweight theme and avoid loading every builder module on every page
Hosting Choose hosting with current PHP, server-side caching and enough resources for your traffic

Always test on a staging copy first. Changes to script loading can break checkout, forms or menus without any visible error in the dashboard.

A practical fix order

  1. Identify failing templates in Search Console.
  2. Fix the LCP element on those templates: image size, preload, and server response.
  3. Remove unused plugins and heavy third-party scripts.
  4. Add dimensions and reserved space to stop layout shifts.
  5. Re-test with PageSpeed Insights, then wait for field data to update.
  6. Re-check after theme, plugin or WordPress core updates, since new releases can reintroduce problems.

Performance work also supports the rest of your technical foundation. Our technical SEO audit checklist covers crawling, indexing and site architecture, and the on-page SEO checklist covers the content side. For ecommerce sites on another platform, see our Shopify SEO checklist, which includes platform-specific speed advice.

How Sirajia Sol can help

At Sirajia Sol, we work with businesses in the USA and worldwide whose WordPress sites are held back by speed and page experience problems. Our SEO team uses Search Console field data to find the templates that matter, and our web development team makes the theme, image and script changes that move the numbers, with testing on staging before anything goes live.

If you want a Core Web Vitals review of your WordPress site, contact us with your URL and the pages that bring in the most leads or sales.

Frequently asked questions

What are the Core Web Vitals thresholds?

Google's web.dev documentation defines a good Largest Contentful Paint (LCP) as 2.5 seconds or less, a good Interaction to Next Paint (INP) as 200 milliseconds or less, and a good Cumulative Layout Shift (CLS) as 0.1 or less. Each is judged at the 75th percentile of real page loads, split by mobile and desktop.

Do Core Web Vitals affect rankings?

Google lists Core Web Vitals among the page experience signals its ranking systems use, but also says great page experience does not override relevance. A fast page with weak content will not outrank a more useful result, so treat these metrics as a quality baseline and a conversion benefit rather than a ranking shortcut.

Why is my PageSpeed Insights score different from Search Console?

PageSpeed Insights shows a lab test run on one simulated device and, where available, field data from real Chrome users. Search Console's Core Web Vitals report uses only field data grouped by similar URLs. Field data is what counts for the assessment, so use lab scores to diagnose causes, not to judge pass or fail.

Can a caching plugin fix Core Web Vitals on its own?

Caching mainly improves server response time, which helps LCP when the server is slow. It does not fix oversized images, render-blocking scripts, heavy page builders or layout shifts. Use it as one step, then test what is still slow.

How long until Search Console shows improvement after a fix?

The Core Web Vitals report is built from a rolling window of real-user data, so improvements appear gradually rather than the next day. Google's Search Console documentation describes a 28-day collection period for the data, so allow several weeks before judging a change.

Need help putting this into practice?

Talk to the Sirajia Sol team about your goals.

Work with us

Related articles