Core Web Vitals for WordPress: the complete guide

Core Web Vitals are three Google metrics measured on real Chrome users: Largest Contentful Paint (LCP) for loading, Interaction to Next Paint (INP) for responsiveness and Cumulative Layout Shift (CLS) for visual stability. A WordPress page passes when the 75th percentile of its field data is at or under 2.5 seconds for LCP, 200 milliseconds for INP and 0.1 for CLS. To improve them, fix the server first (page cache, object cache, PHP), then the LCP image, then plugin and third-party JavaScript, then layout shifts from fonts, banners and ads. Confirm every change in field data, not only in Lighthouse.

I audit WordPress sites for a living, and the same story keeps coming back. Most WordPress sites are slow for structural reasons: hosting, database, render-blocking assets and third-party scripts. Installing one more optimization plugin on top of that structure rarely moves the field data for long. This guide is the order I work in, with a deeper guide for each metric linked from its section.

What are Core Web Vitals and what are the thresholds?

Google evaluates each metric at the 75th percentile (p75) of page loads, separately for mobile and desktop. So a page is “good” for LCP when at least 75% of real visits saw the largest element render in 2.5 seconds or less. Averages hide the slow visits. The p75 forces you to care about the visitor on a mid-range Android phone over a weak connection, which is often most of your traffic.

INP replaced First Input Delay (FID) as a Core Web Vital in March 2024. FID only measured the wait before the browser started handling the first interaction. INP looks at every interaction during the visit and includes the time to run the handlers and paint the result, which makes it much harder to pass on JavaScript-heavy WordPress sites.

Time to First Byte (TTFB) is not on the list. It is a diagnostic metric, and web.dev treats 0.8 seconds or less as good. It still matters a lot, because the browser cannot render anything until the HTML arrives, so a slow TTFB eats into your LCP budget before a single image loads. I cover it in what TTFB measures in WordPress and how to lower it.

How do you measure Core Web Vitals: field data or lab data?

Field data comes from real visits. Google’s source is the Chrome User Experience Report (CrUX), which collects metrics from Chrome users and publishes them as a rolling 28-day window. This is the data behind the Core Web Vitals assessment in PageSpeed Insights and the Core Web Vitals report in Search Console. When Google talks about your Core Web Vitals, it means this data.

Lab data comes from a single simulated load, usually Lighthouse running on a throttled device profile. It is repeatable and great for debugging, but it is one visit on one device with an empty cache. Lighthouse also cannot measure INP, because nobody clicks anything during a lab run. It reports Total Blocking Time (TBT) instead, which correlates with INP without being the same thing. I explain the gap in detail in Core Web Vitals field data vs lab data.

These are the tools I use, in the order I open them:

• The Core Web Vitals report in Search Console shows which URL groups fail, by metric and device. Google groups similar pages, so one bad template can flag hundreds of URLs at once.
• In PageSpeed Insights, the top section is CrUX field data for the URL (or the whole origin when the URL lacks traffic). The bottom section is a Lighthouse lab run. Read the top first.
• The CrUX API and the CrUX BigQuery dataset are for history and for comparing origins, templates or competitors.
• The web-vitals JavaScript library gives you real user monitoring on your own site. Its attribution build tells you which element was the LCP, which interaction was slow and which element shifted.
• The Performance panel in Chrome DevTools is for reproducing a specific problem locally, with CPU throttling turned on.

Keep the 28-day window in mind. A fix you deploy today only fully replaces the old data in CrUX about four weeks later. If you need faster feedback, collect your own field data with the web-vitals library instead of refreshing PageSpeed Insights every morning.

Where do WordPress sites fail Core Web Vitals?

In audits I see the same failures again and again, on very different sites. The theme, the builder and the host change. The causes don’t change much.

• Slow or uncached HTML: no page cache, or a page cache that is bypassed by cookies and query strings. No persistent object cache, a bloated wp_options autoload, slow plugin queries, an old PHP version. All of this shows up as TTFB, and TTFB is part of LCP.
• An LCP image treated like every other image: lazy-loaded by a plugin, injected by a slider script, set as a CSS background the browser discovers late, or served at 2,000 pixels wide to a phone.
• Plugin assets on every page: the contact form plugin loads its scripts and styles on the blog, the slider loads on pages with no slider, WooCommerce assets load on landing pages.
• Third-party scripts: tag managers full of old tags, chat widgets, consent platforms, heatmaps, ad scripts. They compete with your own code for the main thread, which is where INP is lost.
• Page builder DOM size: nested wrapper elements from Elementor, Divi and similar builders make every style recalculation and layout more expensive. That hurts INP and adds CSS weight that delays LCP.
• Content that arrives late: web fonts that swap with different metrics, cookie and promo bars pushed into the top of the page, ads and embeds without reserved space. That is CLS.

LCP in WordPress: what delays the largest paint?

LCP time splits into four parts. Time to First Byte is the wait for the HTML. Resource load delay is the gap between the first byte and the moment the browser starts downloading the LCP resource. Resource load duration is the download itself. Element render delay is the time between the download finishing and the element appearing on screen. Each part has its own WordPress causes, and fixing the wrong part is how teams lose weeks.

On a typical WordPress post the LCP element is the featured image. On a home page it is usually a hero image or a large heading, and on a product page it is the main product image. WordPress core helps here: since WordPress 6.3 it adds fetchpriority="high" to the image it judges most likely to be the LCP, and it skips loading="lazy" on images near the top of the page. In audits, I often find a lazy-loading plugin, a builder setting or custom theme code undoing exactly that.

The other usual suspects are hero images set as CSS backgrounds, sliders that build their first slide with JavaScript, missing or wrong sizes attributes that make the browser download a desktop image on mobile, and render-blocking CSS from the theme plus every active plugin. The full process, including how to read the LCP breakdown, is in how to improve LCP in WordPress.

INP in WordPress: why do clicks feel slow?

INP measures three phases of an interaction. Input delay is the time the browser waits before it can run your event handler, usually because another task is busy on the main thread. Processing duration is the time your handlers take. Presentation delay is the time to recalculate styles, lay out and paint the next frame. A page’s INP is close to the slowest interaction a visitor had, so one heavy mega menu can fail a whole template.

WordPress sites lose INP in a few predictable places: third-party tags firing while the user is trying to tap, jQuery plugins that do a lot of work on every click, WooCommerce variation and cart handlers, faceted filters that re-render big chunks of the page, and large builder DOMs that make each frame expensive to paint. “Delay JavaScript until user interaction” features in caching plugins deserve a special mention. They can make lab scores look great while pushing the cost of loading every script onto the visitor’s first tap.

WordPress gives you tools here too. Since WordPress 6.3 you can register scripts with a defer or async loading strategy, and since 6.5 the Interactivity API powers interactive core blocks with a small, shared runtime instead of one library per plugin. How to find the slow interaction and fix it is in how to fix INP in WordPress.

CLS in WordPress: what moves the layout?

CLS scores how much visible content moves without the user asking for it. Layout shifts that happen within 500 milliseconds of a user input don’t count, and the score reports the worst burst of shifts during the visit, not only during load. That is why CLS in the field is often worse than in Lighthouse: lab tools only watch the load, while real visitors scroll, and lazy content, ads and sticky elements keep moving things.

The WordPress causes are concrete. Images in theme templates or builder widgets output without width and height (WordPress adds these to images in post content, but custom template code often doesn’t). Web fonts that swap in with different metrics and reflow every paragraph. Cookie banners and promo bars inserted above the header. Ads, YouTube embeds and social embeds without a reserved slot. Optimization plugins that delay or strip CSS, so the page renders unstyled and then jumps. Fixes for each are in how to reduce CLS in WordPress.

Is TTFB a Core Web Vital?

No. TTFB is a diagnostic metric that Google does not use in the Core Web Vitals assessment. It measures the time from the start of navigation until the first byte of the HTML response, including redirects, DNS, connection setup and server processing. Google left it out because a fast TTFB with a slow render is still a slow page, and different site architectures can reach good LCP with different TTFB.

In WordPress, TTFB is mostly about whether PHP has to run at all. A page cache serves stored HTML and WordPress never boots. A persistent object cache (Redis or Memcached through an object-cache.php drop-in) speeds up the requests that can’t be cached, such as logged-in users, carts and checkout. An edge cache serves HTML from a location close to the visitor. If you aren’t sure which layer you are missing, read page cache, object cache or edge cache: which one you actually need.

In what order should you fix Core Web Vitals on WordPress?

This is the fix order I follow on audits. It starts with changes that help every template at once and leaves the expensive work for when you know exactly where it is needed.

1. Segment the field data. Find which metric fails, on mobile or desktop, and on which templates (home, post, page, product, category, checkout). Search Console groups make this fast. Don’t optimize a page nobody visits.
2. Fix server response: page cache with correct bypass rules, a persistent object cache, a supported PHP version with OPcache, a clean autoload. Check that marketing query strings like utm_source don’t create cache misses.
3. Fix the LCP element on each failing template: right image size, srcset and sizes that match the layout, no lazy loading, fetchpriority="high", and an img tag in the HTML instead of a CSS background or a slider script.
4. Remove plugin assets where they aren’t used. Dequeue scripts and styles per template with wp_dequeue_script() and wp_dequeue_style(), or replace the plugin. Load scripts with the defer strategy where the plugin allows it.
5. Audit third-party scripts. Every tag needs an owner and a reason. Remove what nobody uses, load the rest after the page is interactive where the business accepts it, and check consent and chat tools on mobile hardware.
6. Reduce main-thread work for INP. Break up long tasks, give visual feedback before heavy work, and reduce DOM size on builder templates.
7. Fix layout shifts: dimensions on every image and embed, reserved space for ads and banners, font loading that doesn’t reflow text, and no unstyled flashes from CSS optimization.
8. Monitor. Keep real user monitoring running, watch CrUX across the 28-day window, and add a performance check to deployments so a new plugin doesn’t undo the work.

The order matters because the metrics share causes. Server response is part of LCP. Plugin JavaScript affects both LCP (render-blocking) and INP (main-thread work). CSS optimization can help LCP and break CLS. If you start with step 6 on a site that has no page cache, you are polishing the wrong layer.

Do performance plugins fix Core Web Vitals?

They help with part of the work. A good caching plugin gives you a page cache, file optimization, delayed scripts and sometimes critical CSS. None of that fixes a slow host, a database with megabytes of autoloaded options, a builder layout with thousands of elements or a tag manager with forty tags. I treat these plugins as tools I configure per site, and I test each feature against field data.

Two features cause most of the regressions I find. “Remove unused CSS” can strip styles that a page needs after an interaction or at a different screen size, which creates layout shifts and broken components. “Delay JavaScript” can improve LCP and lab scores while moving script execution to the first interaction, which shows up later as poor INP in CrUX. Neither is bad on its own. Both need testing on real templates, on a phone.

Do Core Web Vitals affect Google rankings?

Yes, but less than many tools imply. Core Web Vitals are part of the page experience signals that Google’s ranking systems use. Google also says it will still show the most relevant content even when its page experience is worse than a competitor’s. In practice that means a fast page with weak content won’t beat a slow page that answers the question better.

I fix Core Web Vitals because slow pages lose visitors, and on WordPress the work usually fixes real structural problems along the way: overloaded servers, plugins nobody needs, scripts nobody owns. The ranking benefit is real but it is not the main reason.

Frequently asked questions

Why does Lighthouse show a high score while the Core Web Vitals assessment fails?

They measure different things. Lighthouse is one simulated load in a lab. The assessment uses 28 days of real visits from CrUX at the 75th percentile. Real visitors use slower phones and networks, come in with different cache states, interact with the page and scroll. Lighthouse can’t measure INP at all. When the two disagree, trust the field data and use the lab only to debug.

How long does it take for Core Web Vitals fixes to show up?

CrUX uses a rolling 28-day window, so a fix takes about four weeks to fully replace the old data in PageSpeed Insights and Search Console. You will see the p75 move gradually during that time. After that, Search Console validation can take more time on top. Run your own real user monitoring if you need to confirm a fix within days.

Why is there no field data for my page in PageSpeed Insights?

CrUX only publishes data for URLs and origins with enough eligible traffic. If a page doesn’t qualify, PageSpeed Insights falls back to origin data or shows nothing. Low-traffic pages are still judged in Search Console through the URL group they belong to, which is why fixing a template usually beats fixing single URLs.

Does a CDN fix Core Web Vitals on WordPress?

A CDN serves images, CSS and JavaScript from closer locations, which helps the download part of LCP. If it also caches HTML at the edge, it can cut TTFB sharply for anonymous visitors. It does not fix main-thread work, so it won’t solve INP, and it does nothing for layout shifts caused by fonts, banners or missing dimensions.

Is Elementor bad for Core Web Vitals?

Elementor sites can pass Core Web Vitals, but they start with more work to do. The usual problems are a large DOM, many widget assets and heavy global CSS. Elementor’s container-based layouts produce fewer wrapper elements than the older section and column structure, so moving old layouts to containers is worth planning on any Elementor site that fails INP or LCP.

Do I still need to care about First Input Delay?

No. INP replaced FID as a Core Web Vital in March 2024, and Google no longer reports FID in its Core Web Vitals tools. If an old report or plugin still shows FID, ignore that number and look at INP in your field data.

Get a Core Web Vitals audit for your WordPress site

If your field data fails and you can’t tell why, start with a diagnosis instead of another plugin. I audit WordPress sites metric by metric and template by template, then hand over a fix order backed by field data. You can read more about how I work as a Core Web Vitals consultant. When you also need hands on the code, the implementation is done by the WebOption performance team.