Google's Core Web Vitals are a set of performance metrics that measure how users actually experience your page: how fast the main content loads, how quickly it responds to interaction, and how much the layout shifts unexpectedly as it loads. They're a confirmed Google ranking signal, and they're also a reliable proxy for whether your site is genuinely good to use. Here's what each metric means and how to fix the most common WordPress problems that cause failures.
Largest Contentful Paint (LCP) measures how long it takes for the largest visible content element to fully render in the viewport. This is usually a hero image, a large heading, or a featured video thumbnail. Target: under 2.5 seconds for a "Good" rating; 2.5–4.0 is "Needs Improvement"; above 4.0 is "Poor". The primary causes of poor LCP are slow server response time (TTFB), unoptimized LCP images, and render-blocking resources that delay the browser from rendering content.
Interaction to Next Paint (INP) replaced First Input Delay (FID) as a Core Web Vital in March 2024. INP measures the delay between any user interaction (click, tap, keypress) and the next visual response from the page. Target: under 200ms for "Good"; 200–500ms is "Needs Improvement"; above 500ms is "Poor". Poor INP is almost always caused by heavy JavaScript executing on the main thread, blocking the browser from responding to user input promptly.
Cumulative Layout Shift (CLS) measures the total amount of unexpected layout shifting that occurs during the page's lifespan. When images without defined dimensions load and push content down, or when fonts swap and text reflows, or when ads inject above the fold, each of these contributes to CLS. Target: under 0.1 for "Good"; 0.1–0.25 is "Needs Improvement"; above 0.25 is "Poor".
There are two types of CWV data: lab data (simulated tests run in a controlled environment) and field data (real measurements from actual users collected via the Chrome UX Report). Google uses field data for ranking. PageSpeed Insights (pagespeed.web.dev) shows both. If your field data is "Good" but your lab data is "Poor", your ranking is fine even though the PageSpeed score looks alarming.
For field data to appear in PageSpeed Insights, your URL needs sufficient traffic from Chrome users (typically several thousand visits over the past 28 days). New sites or low-traffic pages will only show lab data. Google Search Console shows aggregate field data for your entire site under Experience > Core Web Vitals, which is the most actionable view for identifying which page groups have problems.
LCP is primarily a server and asset loading problem. Address these in order:
1. Reduce TTFB. Server response time is the foundation of LCP. If your server takes 1 second to respond, LCP cannot be under 2.5 seconds regardless of other optimisations. Enable server-side page caching (LiteSpeed Cache if your host supports it). This single change is often enough to move LCP from "Poor" to "Good" on well-optimised sites.
2. Preload the LCP image. Add a preload hint in your <head> so the browser fetches the LCP image before it encounters it in the HTML body:
<link rel="preload" as="image" href="/wp-content/uploads/hero.webp">3. Never lazy-load the LCP image. WordPress 5.5+ applies loading="lazy" to images by default. Your LCP image should have loading="eager" (or no loading attribute at all). Check that your theme or page builder isn't applying lazy loading to the hero image.
4. Serve the LCP image in WebP. A 200KB WebP hero loads faster than a 700KB JPEG even on the same connection. Format and compression matter for LCP just as they do for general page weight.
Most CLS problems on WordPress have straightforward fixes. The most common causes:
Images without defined dimensions. When the browser encounters an <img> tag without width and height attributes, it doesn't reserve space for the image before it loads. When the image arrives, the browser has to reflow the layout. WordPress generates proper width and height attributes for images inserted via the media library. If you're seeing CLS from images, check that you're not hardcoding <img> tags and that your theme's template functions include dimensions.
Web font loading. Fonts that take time to load cause a Flash of Invisible Text (FOIT) or Flash of Unstyled Text (FOUT), both of which contribute to CLS as text reflows when the web font arrives. Add font-display: swap to your @font-face declarations, and preload critical fonts in the <head>: <link rel="preload" as="font" type="font/woff2" href="/fonts/myfont.woff2" crossorigin>.
Embeds and ads. YouTube embeds, Google Maps, and ad slots that inject content above the fold after the initial render are a common source of CLS. Reserve space for embeds using a wrapper with a fixed aspect ratio. For YouTube, the standard 16:9 aspect ratio container:
.video-wrapper {
aspect-ratio: 16 / 9;
width: 100%;
}INP problems are almost always JavaScript problems. The browser's main thread is blocked by long-running JavaScript tasks, which prevents it from responding to user clicks and taps promptly. A page that takes 600ms to respond to a button click has poor INP regardless of how fast it initially loaded.
Audit your plugin list using Chrome DevTools' Performance panel. Record a profile while clicking an interactive element, then look for Long Tasks (shown in red in the main thread timeline). The call stack will identify which scripts are responsible. Common culprits: page builders loading full JavaScript frameworks on every page, slider plugins with animation loops, contact form plugins loading jQuery UI, and analytics scripts with synchronous execution.
For each JavaScript-heavy plugin, ask: does it need to load on every page, or only on pages where it's used? Conditional loading, only loading a plugin's scripts on pages where the plugin outputs something, is one of the highest-ROI INP optimisations for WordPress sites with many plugins.
CSS loaded in the <head> is render-blocking by default, the browser won't render anything until all head CSS is downloaded and parsed. JavaScript loaded in the <head> without async or defer is also render-blocking. For LCP, the goal is to minimize the time between when the browser starts parsing HTML and when it can render the LCP element.
For CSS: inline the critical CSS required to render above-the-fold content directly in the <head>, and load the full stylesheet asynchronously. For JavaScript: add defer to non-critical scripts. WordPress enqueues scripts via wp_enqueue_script() with an optional $in_footer parameter, passing true moves the script to the footer, which is the simplest way to defer it.
LiteSpeed page caching drops TTFB to under 50ms. That's the single most impactful change you can make for LCP, and it's included on every HostBible plan.
View Hosting Plans