Core Web Vitals are Google’s three user experience metrics: Largest Contentful Paint (LCP), Cumulative Layout Shift (CLS), and Interaction to Next Paint (INP, which replaced First Input Delay in 2024). Poor scores on these metrics affect search rankings and user experience. This guide addresses each metric with specific, actionable fixes for WordPress sites.
Understanding Your Current Scores
Check your current Core Web Vitals in two places. First, Google Search Console -> Core Web Vitals report shows your real user data (field data) across all pages that Google has enough data for. This is the most important data set because it reflects actual visitor experience. Second, PageSpeed Insights (pagespeed.web.dev) shows both lab data (simulated test) and field data for specific URLs. Always fix issues based on field data first – lab data shows potential problems, field data shows actual problems affecting rankings.
Fixing LCP (Largest Contentful Paint)
LCP measures how long it takes for the largest visible element to load – typically a hero image or the largest block of text. Target: under 2.5 seconds. Common causes of slow LCP and their fixes:
Hero image is too large or unoptimised. The LCP element on most sites is the above-fold hero image. Optimise it: compress to WebP, size it at the exact display dimensions (do not upload a 4000px image for a 1200px display area), and – critically – do NOT lazy load the LCP image. Lazy loading defers image loading until scroll, which delays LCP. Remove loading=”lazy” from your hero image specifically. Add fetchpriority=”high” to tell the browser to load this image first:
<img src="hero.webp" width="1200" height="600"
fetchpriority="high" alt="Hero image">Need help optimising your WordPress site? Describe your project and get a free estimate.
Slow server response time. If your TTFB exceeds 600ms, the LCP image cannot start loading until after the server responds. Fix: add caching, upgrade hosting, or use a CDN with edge caching. No amount of image optimisation compensates for a slow server.
Render-blocking resources. CSS and JavaScript in the page head that block rendering delay when the browser can start painting content. In WP Rocket, enable defer JavaScript loading and eliminate render-blocking CSS by loading non-critical CSS asynchronously.
Fixing CLS (Cumulative Layout Shift)
CLS measures how much the page layout shifts during loading – elements jumping around as images, ads, or embeds load late. Target: under 0.1. The most common causes:
Images without dimensions. When a browser does not know an image’s dimensions before it loads, it reserves no space. When the image loads, it pushes content down. Fix: add explicit width and height attributes to every image. WordPress automatically does this for images from the media library since version 5.5. Check that your theme and page builder are not stripping these attributes.
Ads and embeds that load late. Google AdSense, YouTube embeds, and similar third-party content load after the page and push content. Fix: reserve space for ads by setting explicit dimensions on the ad container. For YouTube embeds, use a facade (a thumbnail image that loads the iframe only on click) to prevent the iframe from causing layout shift on load.
Web fonts causing text swap. When a custom font loads after the page renders, text reflows if the font metrics differ from the fallback. Fix: use font-display: optional in your @font-face declaration to prevent font swapping, or preload your primary font in the document head:
<link rel="preload" href="/fonts/myfont.woff2"
as="font" type="font/woff2" crossorigin>Fixing INP (Interaction to Next Paint)
INP measures how quickly the page responds to user interactions – clicks, taps, keyboard input. Target: under 200ms. Poor INP is almost always caused by too much JavaScript executing on the main thread, blocking the browser from responding to interactions quickly.
Common causes: large JavaScript bundles that take long to parse and execute, third-party scripts (chat widgets, analytics, marketing pixels) that run expensive tasks on the main thread, and jQuery plugins that attach expensive event handlers.
Fixes: defer third-party scripts to load after the page is interactive. Use WP Rocket‘s delay JavaScript feature to load non-essential scripts only after user interaction. Remove unused JavaScript – Query Monitor shows which plugins load scripts on each page.
Monitoring After Fixes
After implementing fixes, Core Web Vitals field data in Search Console takes 28 days to update (it shows a rolling 28-day window). Check lab data in PageSpeed Insights immediately after changes to confirm the fix is working in tests, then monitor field data over the following month to see real-world improvement.
Tools for Measuring Core Web Vitals
Use these tools in combination – no single tool gives the complete picture:
- PageSpeed Insights (pagespeed.web.dev) – shows both lab data (simulated test) and field data (real user data from the Chrome User Experience Report). Check the field data section first – it reflects actual visitor experience.
- Google Search Console -> Core Web Vitals – shows your field data aggregated across all pages over 28 days, categorised as Good, Needs Improvement, or Poor. This is the authoritative source for what Google sees.
- Web Vitals Chrome Extension – shows real-time Core Web Vitals as you browse your site. Useful for testing specific user interactions for INP.
- GTmetrix – good for waterfall analysis showing which specific resources are slow and in what order they load. Set the test location to match your primary audience’s geography.
A common mistake: fixing issues identified only in lab data without checking field data. Lab data is useful for debugging but field data is what Google uses for ranking signals. A site that scores 95 in PageSpeed Insights lab but has poor field data (because real users on slow connections or phones experience problems) will still have Core Web Vitals issues in Search Console.