Clients often send me a screenshot of a red PageSpeed score and ask me to “make it green”. I understand why. The score is visible, simple and a little embarrassing when it’s low. But the score itself isn’t what matters. What matters is how your site feels to real visitors, and that’s what Core Web Vitals try to measure.
Core Web Vitals are three metrics Google uses to describe the loading speed, responsiveness and visual stability of a page. They’re part of Google’s page experience signals, and more importantly, they correlate with whether visitors stay or leave.
This guide explains each metric, how to read the data properly and the fixes I use most often on WordPress sites.
The three metrics
Largest Contentful Paint (LCP)
LCP measures how long it takes for the largest visible element in the viewport to appear. That’s usually a hero image, a large heading or a featured image. It represents the moment the visitor feels the page has mostly loaded.
A good LCP is 2.5 seconds or less.
Interaction to Next Paint (INP)
INP measures responsiveness. When a visitor taps a button, opens a menu or types in a field, how long does it take before the page visibly responds? INP looks at interactions throughout the visit and reports one of the slowest.
INP replaced First Input Delay as a Core Web Vital in March 2024. It’s a stricter, more complete measure, and many sites that passed the old metric struggle with this one.
A good INP is 200 milliseconds or less.
Cumulative Layout Shift (CLS)
CLS measures how much content moves around unexpectedly while the page loads. You’ve experienced bad CLS: you go to tap a link, an ad loads above it, and you tap something else entirely.
A good CLS is 0.1 or less.
To pass, a page needs at least 75 percent of visits to meet the “good” threshold for each metric.
Field data versus lab data
This distinction causes more confusion than anything else.
Field data comes from real Chrome users visiting your site, collected in the Chrome User Experience Report. It’s what Google uses for ranking signals. You see it in Search Console’s Core Web Vitals report and at the top of PageSpeed Insights, if your site has enough traffic.
Lab data comes from a single simulated test, like the Lighthouse score in PageSpeed Insights. It runs on a throttled connection and device, under controlled conditions.
Lab tests are useful for diagnosing problems and testing fixes, but they’re not what your visitors experience. A site can have a mediocre lab score but pass Core Web Vitals in the field, or the reverse. Always start with field data to see whether there’s a real problem, then use lab tools to find the cause.
Note that INP can’t really be measured in a lab test, because it depends on real interactions. Lighthouse uses Total Blocking Time as a rough proxy.
Fixing LCP
LCP problems usually come from one of four areas.
1. Slow server response
If the server takes a second to send the first byte of HTML, LCP can’t be fast. Check Time to First Byte. If it’s high, the fix is server-side: page caching, a persistent object cache, better hosting or removing slow plugins. Caching alone often transforms LCP for anonymous visitors.
2. The LCP image loads late
Find your LCP element. PageSpeed Insights shows it in the diagnostics. If it’s an image:
- Don’t lazy load it. Lazy loading delays the most important image on the page. WordPress tries to skip lazy loading for the first images, but themes and page builders sometimes override this.
- Give it high priority. fetchpriority=”high” tells the browser to fetch it early. WordPress adds this automatically to the image it believes is the LCP element, since version 6.3.
- Avoid CSS background images for the hero. The browser can’t discover them until the CSS is downloaded and parsed. Use a regular img element, or preload the image if you must use a background.
- Serve it at the right size and format. A properly sized WebP or AVIF image loads far faster than a huge JPEG.
3. Render-blocking resources
Stylesheets and scripts in the page head can block rendering. Large CSS files from page builders, multiple font files and scripts loaded without defer all delay LCP.
Reduce render-blocking CSS by removing unused styles and loading only what each page needs. Defer non-essential JavaScript.
4. Client-side rendering
If your hero content is built by JavaScript, such as a slider that initialises after scripts load, LCP waits for that script. Sliders on the homepage are a common LCP killer. A static hero image or heading usually performs much better, and often converts better too.
Fixing INP
INP problems come from JavaScript keeping the browser’s main thread busy, so it can’t respond to interactions quickly.
Reduce JavaScript
The most effective fix is simply loading less JavaScript. On WordPress sites, the biggest sources are usually:
- Page builder scripts and animation libraries.
- Sliders, carousels and pop-up plugins.
- Chat widgets.
- Tag managers loading many marketing tags.
- Social media embeds.
Audit what loads on each page. Remove plugins you don’t need, and stop plugins from loading scripts on pages where their features aren’t used.
Break up long tasks
Any JavaScript task that runs longer than 50 milliseconds blocks the main thread and can delay interactions. In custom code, break heavy work into smaller chunks and yield to the browser between them. For third-party scripts, the only real options are loading them later, loading them only where needed or removing them.
Delay non-essential third-party scripts
Chat widgets, heatmaps and some tracking scripts don’t need to load immediately. Loading them after the page becomes interactive, or after the first user interaction, can improve INP significantly. Some optimisation plugins offer this, but test carefully. Delaying the wrong script can break functionality or analytics.
Watch out for heavy event handlers
Menus that run complex animations, filters that rebuild large parts of the page and forms that validate on every keystroke can all produce slow interactions. Simplify the work done in response to each interaction.
Fixing CLS
CLS is usually the easiest metric to fix once you know the causes.
Images and videos without dimensions
Always include width and height attributes, so the browser reserves space before the image loads. WordPress does this automatically for images inserted through the editor. Problems come from custom code, page builders and embedded media. CSS aspect-ratio can help for responsive embeds.
Ads, embeds and dynamic content
Reserve space for ads and embeds with a minimum height. Don’t insert banners or notices above existing content after the page loads. Cookie consent banners should overlay content or appear in a fixed position, not push the page down.
Web fonts
When a web font loads and replaces the fallback font, text can change size and shift layout. Using font-display: swap with a well-matched fallback font, preloading your main font files and limiting the number of fonts all reduce font-related shifts. Newer CSS features for adjusting fallback font metrics can make the swap almost invisible.
Late-loading CSS
If styles for above-the-fold content arrive late, elements jump as styles apply. Make sure critical styles load early.
A practical workflow
Here’s the process I follow on client sites:
- Check Search Console’s Core Web Vitals report to see which metrics fail and which groups of pages are affected.
- Pick a representative URL from each failing group.
- Run PageSpeed Insights to see field data and lab diagnostics for that URL.
- Identify the cause using the diagnostics: the LCP element, long tasks, layout shift sources.
- Reproduce in browser developer tools. The Performance panel shows exactly what happens during loading and interactions.
- Fix on staging, test, then deploy.
- Wait for field data to update. Field data is based on a rolling 28-day window, so improvements take time to appear in Search Console.
WordPress-specific quick wins
- Use a lightweight theme, or a block theme that loads minimal CSS and JavaScript.
- Remove sliders from above the fold.
- Use page caching and a persistent object cache.
- Serve images in modern formats at the right sizes.
- Limit fonts to one or two families and a few weights, preferably self-hosted.
- Audit plugins and remove anything that loads assets sitewide without good reason.
- Load third-party scripts carefully, and question whether each one is needed.
Frequently asked questions
Do Core Web Vitals affect rankings?
They’re part of Google’s page experience signals, but relevance and content quality matter far more. Think of them as a tiebreaker between otherwise similar pages, and as a strong influence on visitor behaviour and conversions.
Why is my PageSpeed score different every time I test?
Lab tests vary with network conditions, server response times and test location. Use field data for decisions, and run lab tests several times when comparing changes.
My mobile scores are much worse than desktop. Why?
Mobile tests simulate slower devices and connections. JavaScript-heavy pages suffer most, because mobile processors take longer to run scripts. Reducing JavaScript usually helps mobile scores most.
Can a plugin fix Core Web Vitals for me?
Optimisation plugins help with caching, image formats, lazy loading and script deferral. But they can’t fix a heavy theme, slow hosting or too many third-party scripts. The biggest gains come from removing work, not compressing it.
Final thoughts
Core Web Vitals reward sites that load their main content quickly, respond to taps without delay and stay steady while loading. On WordPress, that usually means a lean theme, good caching, a well-handled hero image, fewer scripts and careful handling of fonts and embeds. Focus on real-user field data, fix the specific causes it reveals and give improvements a few weeks to show. Your visitors will notice the difference long before Google does.
