Core Web Vitals for WordPress: Realistically Under the Thresholds
“WordPress is slow” is a common claim – but as a blanket statement it’s wrong. WordPress sites can pass Core Web Vitals cleanly, even with lots of features. It doesn’t take miracle plugins, just a few disciplined decisions. This post explains the three metrics, shows what’s possible, and delivers concrete measures for each metric that we use in practice ourselves.
The Three Values and Their Thresholds
Core Web Vitals measure the actual user experience. “Good” means:
| Metric | What it measures | Green zone |
|---|---|---|
| LCP (Largest Contentful Paint) | How fast the largest content is visible | ≤ 2.5 s |
| INP (Interaction to Next Paint) | How quickly the page responds to input | ≤ 200 ms |
| CLS (Cumulative Layout Shift) | How stable the layout stays | ≤ 0.1 |
INP replaced the old FID metric in March 2024. For interactive WordPress sites – shops, search filters, flyout menus – it’s the most demanding of the three, because it measures every interaction point, not just the first click.
Lab Data ≠ Field Data
A common misconception: a 100/100 result in PageSpeed Insights doesn’t automatically mean “passing”. The lab test (Lighthouse) measures under ideal, simulated conditions with a defined device profile. What counts for Google’s ranking is the field data (CrUX) – real measurements from real visitors over the last 28 days, on their own devices and connections.
That explains why a page shines in the lab and still fails in the field: many visitors arrive on a mid-range Android phone and a 4G connection – no lab test in the world reproduces that exactly. Always optimise with an eye on the field data; the lab score is only an indicator.
Improving LCP: The Biggest Lever
Largest Contentful Paint measures when the largest visible element – usually the hero image or a large text block – is fully loaded. Over 2.5 seconds means red in Search Console.
Caching First
Caching is the simplest and most effective LCP lever in WordPress. When the server delivers a finished HTML page instead of rebuilding it on every request, the Time to First Byte (TTFB) drops drastically – and with it the LCP. Server-side caching (nginx fastcgi_cache, Varnish, or hosting with a built-in full-page cache) beats plugin caching alone. A well-configured caching setup delivers TTFB values below 200 ms, even on cheap managed hosting. Details are in → set up caching properly.
Preload the Hero Image
The image that triggers the LCP should be requested by the browser as early as possible. This works with a <link rel="preload" as="image"> in the <head>. Even more important: this element’s loading attribute must not be lazy – loading="lazy" belongs on images below the fold, not on the largest element in the viewport. The fetchpriority="high" attribute additionally signals to the browser that this image has priority.
On format: WebP or AVIF instead of JPEG or PNG. On a typical article image, WebP saves 30–50% file size over JPEG with no visible quality loss. The srcset attributes ensure mobile devices don’t have to download a desktop-sized image.
Serve Fonts Locally
External font sources – including Google Fonts – block loading, because the browser sets up an extra DNS lookup and connection. Fonts belong in your own server folder, served over your own domain. Add font-display: swap in the @font-face declaration: the browser first shows a fallback font and loads the web font afterwards, instead of blocking rendering entirely. A <link rel="preload" as="font" crossorigin> for the most important font weight speeds things up further.
Render-Blocking CSS and JavaScript
Stylesheets in the <head> block rendering. JavaScript without defer or async does the same. In the “Performance” tab of the Chrome DevTools or the diagnostics section of PageSpeed Insights, you can see which resources are marked as render-blocking. Unused CSS from a page builder? Either turn it off entirely or serve critical CSS inline. Plugin JavaScript that loads on every page even though it’s only needed on one subpage? Restrict visibility by page type – manually via wp_dequeue_script or with a tool like Asset CleanUp.
Optimising INP: JavaScript Under Control
Interaction to Next Paint measures the time between a user input – click, tap, keypress – and the moment the browser shows the next visual response. Threshold: 200 ms. Over 500 ms counts as poor.
What Really Slows INP
The most common reason for poor INP values in WordPress is too much JavaScript on the main thread. Every plugin that embeds a large JavaScript bundle on load – sliders, countdown timers, cookie banners, live chat – makes the main thread heavier. When the main thread is busy, the browser only processes user input once it has finished the running task. To the user, that feels like a delay.
WooCommerce is a special case: the cart fragments are fetched via Ajax on every page load, even for non-logged-in visitors. This creates latency and burdens the main thread unnecessarily. Anyone running WooCommerce should disable these fragments or switch to a static cart display – more on that in → speed up WooCommerce.
Concrete Measures
- Check every page type in the Chrome DevTools “Performance” tab for long tasks (tasks over 50 ms on the main thread).
- Disable plugins one by one to isolate the culprit; then replace or configure it specifically.
- Load JavaScript files that aren’t needed immediately with
defer, or move them to the footer. - Check whether jQuery is really necessary – many modern themes and plugins do without it, and jQuery is one of the most common sources of main-thread ballast.
Avoiding CLS: A Stable Layout from the Start
Cumulative Layout Shift measures how much the layout shifts during loading. A CLS over 0.1 is red – and it annoys real users, because the click target runs away or text jumps.
Images Without Placeholders
The most common CLS cause in WordPress: images without explicit width and height attributes. When these are missing, the browser reserves no space before loading, and as soon as the image appears, everything below it shifts. WordPress has set these attributes automatically since version 5.5 when the attachment data is complete – older themes or manual <img> tags have to be fixed manually. Alternatively, the aspect ratio can be secured via CSS with aspect-ratio.
Fonts and Layout Shift
FOUT (Flash of Unstyled Text) causes CLS when the fallback font has noticeably different line heights and spacing than the web font. font-display: swap is still the right choice – but the fallback fonts should be metrically similar to the web font. With the CSS property size-adjust in the @font-face rule, the fallback font can be tuned so the font swap causes barely visible layout shift.
Other CLS Traps in WordPress
- Ads and embeds without a fixed height: ad banners or external embeds (YouTube, maps) need a container with a minimum height or fixed aspect ratio.
- Lazy-loaded images in the initial viewport: the
loading="lazy"attribute belongs on images below the fold, not on the first visible image. - Cookie banners: banners that sit as an overlay above the content shift nothing. Banners inserted into the document flow that push content down, on the other hand, cause CLS – often the only problem that pushes an otherwise clean page over 0.1.
What’s Realistically Possible
“WordPress = slow” isn’t true when the foundation is right. We look after feature-rich WordPress sites that pass Core Web Vitals cleanly in the green zone – with proper caching, optimised images and locally served fonts, not with a miracle plugin.
Just as honest is the counterpoint from practice: often an otherwise fast site fails on a single value – typically CLS, just over the 0.1 threshold. It’s not that the whole site is “slow”, but a single element that loads in without reserved space pulls the value over the line. Exactly these individual problems can be fixed in a targeted way, once you see in the field data what to look for.
Measure Before You Optimise
PageSpeed Insights and Lighthouse
PageSpeed Insights shows both the lab test and – where field data is available – the CrUX values for the given URL. The lab test delivers instant diagnostics. The field data shows how real visitors experience the page. Together they give the complete picture.
Lighthouse directly in the Chrome DevTools (“Lighthouse” tab) is useful for quick diagnostics during development, because you can test without an internet connection and without CrUX noise.
Search Console
In the “Core Web Vitals” report of Google Search Console, you can see which URLs are rated poor or in need of improvement – grouped by metric and device type (mobile / desktop). This report is the most reliable source for prioritisation, because it’s based on real CrUX data and shows you immediately where the biggest problem sits.
Realistic Expectations
CrUX rolls over a 28-day window. An optimisation made today shows up in field data after a few days at the earliest – fully only after four weeks. That means: don’t build in five measures at once. Change too much at once and you won’t know afterwards what helped and what didn’t.
How to Proceed
- Check the field data in Search Console (the “Core Web Vitals” report) or in PageSpeed Insights – not just the lab score.
- Tackle the worst of the three values first; usually it’s LCP or CLS.
- Make one change, then measure – don’t install five plugins at once.
- After 28 days, recheck the field data and tackle the next value if needed.
Related Topics
- Fix WordPress errors – when performance problems end in error messages
- What WordPress maintenance really covers – regular upkeep keeps load times stable too
- WordPress security overview – secure and fast aren’t mutually exclusive
Want to get your Core Web Vitals reliably into the green – with measurement instead of gut feeling? Drop us a line – we’ll analyse the real field data of your site and tell you where the biggest lever is.
Frequently Asked Questions
How do I improve LCP in WordPress?
Set up server-side caching so the TTFB drops below 200 ms, preload the hero image with a preload link, and switch to WebP or AVIF. In practice, these three measures deliver the biggest jump in LCP.
What is a good Core Web Vitals score?
Good means: LCP ≤ 2.5 s, INP ≤ 200 ms and CLS ≤ 0.1 – each for at least 75 percent of real visitors. Below these thresholds, a page counts as passing at Google.
Why does my page pass the lab test but not the field data?
Lab tests like Lighthouse run under ideal conditions with a defined device profile. Field data captures real visitors – many of them on weak smartphones with mobile internet. A good lab score therefore doesn't automatically mean green field data.
How long does it take for an optimisation to show in the field data?
CrUX rolls over a 28-day window. An improvement made today shows up in field data after a few days at the earliest – fully only after four weeks. So: only ever make one change at a time and wait out the window before implementing the next.
Related Services
Founder & Full-Stack Developer
20+ years of web development experience. Specialised in Laravel, WordPress and custom software for mid-sized businesses.