Largest Contentful Paint, First Contentful Paint, Cumulative Layout Shift, and Interaction to Next Paint — what each one measures, why Google uses them as a ranking signal, and the specific, concrete fixes that move each number, with WordPress-specific detail throughout.
Core Web Vitals are a set of specific, measurable signals Google uses to judge how a real visitor experiences loading a page — not a subjective "feels fast" rating, but exact numbers captured either in a lab (Lighthouse, PageSpeed Insights) or from real Chrome users in the field (the Chrome User Experience Report, or CrUX). They're part of Google's broader Page Experience signals, and Google has confirmed they're used as a ranking factor.
There are three current Core Web Vitals:
Two related metrics — First Contentful Paint (FCP) and Time to First Byte (TTFB) — aren't official Core Web Vitals themselves, but they're closely tied to LCP and show up on every PageSpeed Insights report, so this guide covers them too.
What it measures: the time from when the page starts loading to when the largest visible element in the viewport — almost always a hero image, a large heading, or a background image — finishes rendering.
≤ 2.5s
2.5s – 4s
> 4s
fetchpriority="high" to the LCP image so the browser fetches it before lower-priority resources.<link rel="preload" as="image"> in <head>, so the browser starts the download immediately rather than discovering it mid-render.RD Performance Toolkit's free tier automates the first four of these directly: it detects the actual first-rendered image on any page (homepage, post, archive — regardless of theme structure), removes lazy-loading from it specifically, adds fetchpriority="high", adds a preload hint, and converts uploads to WebP automatically.
What it measures: the time until the browser renders the very first piece of content — text, an image, a background color, anything. FCP happens before LCP; a page can't have a fast LCP without at least an equally fast FCP.
This maps directly to the free tier's Scripts & Styles toggles: defer non-essential JavaScript, load stylesheets without blocking render, minify local CSS, and remove the render-blocking scripts WordPress enqueues by default.
CLS measures visual stability — how much visible content unexpectedly shifts position while a page loads (the classic case: you go to tap a button, and an ad loads above it a split second earlier, so you tap the wrong thing). It's driven mainly by images/embeds without explicit width and height, web fonts causing a layout reflow, and content injected above existing content.
INP measures responsiveness — how long the page takes to visually respond after a click, tap, or keypress, measured across the entire visit rather than just the first interaction. INP officially replaced First Input Delay (FID) as a Core Web Vital in March 2024. Heavy, long-running JavaScript is the main cause of poor INP — which is exactly what delaying non-essential script execution until user interaction (a Pro feature) is designed to address.
What it measures: the time between the browser requesting a page and receiving the first byte of the server's response — before any rendering can even begin.
TTFB isn't an official Core Web Vital, but it's foundational to all of them: LCP, FCP, and INP all effectively start their clock after TTFB completes. A slow TTFB puts a floor under every other metric that no amount of frontend optimization can fix.
What determines TTFB: your hosting plan's server hardware and configuration, database query performance, how many plugins run on every request, and whether pages are cached. This is genuinely the one area where a plugin has the least direct control — no plugin can rewrite your host's server hardware. What a plugin can do is reduce the PHP/database work needed to build a page in the first place, largely by serving a cached, pre-built copy instead of rebuilding the page from scratch on every visit. That's exactly what a page cache does, and why TTFB and page caching are so closely linked.
PageSpeed Insights (PSI) is Google's own free tool for measuring Core Web Vitals, built on the open-source Lighthouse auditing engine. It reports both lab data (a simulated test run at that exact moment) and, where enough real-world data exists, field data from the Chrome User Experience Report — actual visitors on actual devices and connections.
PSI scores mobile and desktop separately, and mobile is usually meaningfully worse, since Google's mobile test simulates a mid-range phone on a throttled connection — much closer to a large share of real visitors than a developer's desktop on fiber.
RD Performance Toolkit's Core Web Vitals Monitor calls the real PageSpeed Insights API directly from your WordPress dashboard — the same Lighthouse engine, the same scores you'd get testing manually, on demand or on a daily schedule, with history tracked over time so you can see whether a change actually helped.
2.5 seconds or faster is "Good" by Google's own thresholds. 2.5–4 seconds is "Needs Improvement," and anything above 4 seconds is "Poor."
Stop lazy-loading the LCP image, add fetchpriority="high" and a preload hint for it, convert it to WebP, and reduce your server response time (TTFB) — LCP can't improve until TTFB does.
FCP is when the browser paints anything at all for the first time. LCP is when the single largest visible element finishes rendering — it happens at the same time as FCP or later, never before it.
Interaction to Next Paint (INP) replaced FID as an official Core Web Vital in March 2024. INP measures responsiveness across an entire visit rather than just the very first interaction.
Yes, as part of Google's Page Experience signals — though in practice they matter most as a tiebreaker between pages that are already similarly relevant to the search query, not as a way to outrank fundamentally more relevant content.
TTFB is how long the browser waits for the server's first response byte, before any rendering starts. It's not an official Core Web Vital, but every other metric is bottlenecked by it — nothing can paint faster than the server responds.
No, and be skeptical of any plugin that claims otherwise. Your hosting's raw response time, the images and video you choose to publish, and any third-party scripts you add all affect the result. A plugin can implement every optimization that's genuinely within its control — it can't rewrite your server or your content for you.
RD Performance Toolkit's free tier automates the LCP, FCP, and caching fixes above — plus a real PageSpeed Insights monitor to track the actual numbers.
Download Free