Core Web Vitals for WordPress: A Practical Speed Checklist
What Google actually measures, and the WordPress changes that move LCP, INP and CLS — hosting, caching, images, fonts and plugins, in the right order.
Most "my WordPress site is slow" conversations start with a Lighthouse score. That score is useful, but it isn't what Google measures for ranking. Core Web Vitals come from real visits, on real devices and real connections.
This is the checklist I work through on a WordPress site, roughly in order of how much difference each step makes for the effort it takes.
What Google actually measures
Three metrics make up Core Web Vitals, and each has a published threshold for "good":
- Largest Contentful Paint (LCP) — how long until the biggest thing in the viewport is drawn. Good is 2.5 seconds or less.
- Interaction to Next Paint (INP) — how quickly the page responds when someone taps or clicks. Good is 200 milliseconds or less.
- Cumulative Layout Shift (CLS) — how much the layout jumps around while loading. Good is 0.1 or less.
Field data vs lab data
PageSpeed Insights shows you two things. The top section is field data: what actual Chrome users experienced on your site over the last 28 days, taken from the Chrome User Experience Report. The bottom section is a Lighthouse lab test — one simulated load, on a throttled connection, from one location.
Google uses the field data, and it scores you at the 75th percentile: three quarters of visits have to be good, not the average one. That's why a site can score 98 in Lighthouse and still fail Core Web Vitals in Search Console. Fix things that help real visitors on mid-range phones, not things that only help the lab run.
Search Console's Core Web Vitals report is the one to watch, because it groups your URLs and tells you which templates are failing.
Start with hosting and caching
Every WordPress page is assembled by PHP on each request unless something stops it. Slow server response delays everything after it, so no amount of frontend tuning rescues a slow host.
- Use PHP 8.x with OPcache enabled, and check your host actually has it on.
- Add full-page caching so repeat visitors get HTML straight from cache instead of PHP. Most managed WordPress hosts do this at the server level; otherwise a caching plugin will.
- Put a CDN in front of the site so static files are served near the visitor. This matters a lot for an India-based site with visitors abroad, and the other way round.
- Turn on object caching (Redis or Memcached) if the site runs heavy queries — a WooCommerce store or a site with large taxonomies will feel it.
Fix LCP: the biggest element above the fold
On most WordPress sites the LCP element is the hero image or the headline in the first screen. Find it in PageSpeed Insights — it names the element — and then make just that element arrive sooner.
- Never lazy-load the hero image. WordPress adds loading="lazy" automatically, and on the LCP image that delays the very thing being measured.
- Serve it as WebP or AVIF at the size it's actually displayed, not a 3000px original scaled down in CSS.
- Preload the hero image and the font it sits next to, so the browser doesn't discover them late.
- Self-host fonts, subset them, and use font-display: swap so text is readable while the font loads.
- Get render-blocking CSS and JavaScript out of the <head>. Inline the small amount of CSS the first screen needs and defer the rest.
Fix INP: less JavaScript on the main thread
INP replaced First Input Delay in 2024 and it is much harder to fool, because it measures the whole interaction — the click, the work your scripts do, and the frame that finally gets painted.
On WordPress, poor INP is almost always too much JavaScript: sliders, popups, chat widgets, analytics, heat-mapping tools and page builders all competing for the main thread.
- Audit what each plugin loads on the frontend, and dequeue its assets on pages that don't use it.
- Defer or async every script that isn't needed for the first interaction.
- Load third-party embeds — chat, maps, video, tracking — only after the page is interactive, or on user action.
- Replace a heavy slider or page builder section with plain markup where you can. This is usually the single biggest INP win on a builder-based site.
Fix CLS: reserve the space
Layout shift is the easiest of the three to fix and the easiest to reintroduce. It happens when something loads later and pushes content that was already drawn.
- Set width and height (or an aspect-ratio) on every image, iframe and video so the browser reserves the box before the file arrives.
- Give ad slots, banners and cookie notices a fixed height instead of letting them appear and shove the page down.
- Avoid injecting content above existing content after load — a notification bar added by JavaScript is a classic CLS source.
- Preload web fonts and match the fallback font's metrics so the swap doesn't reflow the text.
Then trim WordPress itself
- Deactivate and delete plugins you don't use. Deactivated plugins are still a maintenance and security cost, and many active ones load assets sitewide.
- Clean the database: expired transients, post revisions and orphaned metadata all slow admin and frontend queries.
- Check for plugins doing remote HTTP calls on every page load — they block PHP until the remote server answers.
- Look at wp-cron on busy sites. Moving it to a real server cron stops scheduled tasks from running inside a visitor's page load.
How to measure honestly
- Test on a real mid-range Android phone on mobile data, not only on your desktop.
- Compare before and after on the same URL, same device, several runs — a single run is noise.
- Watch Search Console's Core Web Vitals report over the following weeks; field data moves slowly because it's a 28-day window.
- Test the templates that matter: home, a service or product page, a blog post and the cart or contact page. They rarely score the same.
Realistic expectations
Core Web Vitals are a ranking signal, not the ranking. A fast page with thin content won't outrank a slower page that answers the question better. Speed work pays off most where it changes behaviour — fewer people leaving before the page draws, more people finishing a checkout.
If a site is built on a heavy page builder with thirty plugins, there's a ceiling to what tuning can do. At that point rebuilding the templates is cheaper than fighting the stack every quarter.
Frequently asked questions
What are good Core Web Vitals scores?
Largest Contentful Paint of 2.5 seconds or less, Interaction to Next Paint of 200 milliseconds or less, and Cumulative Layout Shift of 0.1 or less. Google measures these at the 75th percentile of real visits, so three quarters of your visitors have to be inside those thresholds — not just the average one.
Why does PageSpeed Insights show a good score but Search Console says my site is failing?
Because they measure different things. The Lighthouse score is one simulated load from one location; Search Console reports field data from real Chrome users over the last 28 days. Real visitors on mid-range phones and slower connections have a harder time than the lab does. Always trust the field data.
Will a caching plugin fix Core Web Vitals on its own?
It will usually help LCP, because it removes PHP work from the request. It does very little for INP, which is about how much JavaScript runs when someone taps, and nothing for CLS, which is about reserving space in your layout. Those need actual changes to what the site loads and how it's built.
How long before Core Web Vitals improvements show up in Search Console?
The report is based on a rolling 28-day window, so a fix made today takes weeks to be fully reflected. Don't judge a change by what Search Console says the next morning — check that the underlying metric improved in a lab test first, then watch the field data catch up.
Do Core Web Vitals actually affect rankings?
They're a real but modest ranking signal, and they can't rescue a page that answers the question worse than its competitors. Where speed work reliably pays off is in behaviour: fewer people abandoning the page before it draws, and more of them finishing a checkout or a form.
Topics
- WordPress Core Web Vitals
- WordPress speed optimization
- LCP WordPress
- WordPress performance