Here is the situation that sends most WordPress owners in circles: PageSpeed Insights gives you a green 98, and Search Console still says your Core Web Vitals are failing. Both are correct. They measure different things, and until you know which one to act on, you will spend weeks optimizing the wrong number.

This guide skips the generic “install a caching plugin” advice. Instead it shows you how to find out which specific metric your site fails, then fix that one. Diagnose first, optimize second.

The three metrics that actually count

Google measures page experience with three Core Web Vitals. Each covers a different part of how your page feels to a real person, and each has a published threshold:

Metric	Measures	Good score
Largest Contentful Paint (LCP)	Loading: when the main content appears	2.5 seconds or less
Interaction to Next Paint (INP)	Interactivity: how fast the page responds to clicks and taps	200 milliseconds or less
Cumulative Layout Shift (CLS)	Visual stability: how much the page jumps around	0.1 or less

Two details matter more than the numbers themselves. You need to hit these targets at the 75th percentile of page loads, so it is not your average visitor that counts, it is your slower quarter. And INP replaced First Input Delay as an official Core Web Vital in March 2024, so any guide still telling you to optimize FID is out of date. Google publishes all of this in its Web Vitals documentation.

Why your PageSpeed score disagrees with Search Console

This is the part that confuses everyone, and it is worth understanding before you change a single setting.

There are two kinds of speed data. Lab data comes from a simulated page load on a simulated device, which is what the Lighthouse performance score at the top of PageSpeed Insights shows you. Field data comes from real Chrome users on real devices and networks, collected in the Chrome User Experience Report, and it is what Search Console reports and what Google actually uses.

Three consequences follow from that:

• Lighthouse cannot measure INP at all. It has no real user clicking things, so it reports Total Blocking Time as a stand-in. A perfect Lighthouse score tells you almost nothing about whether your INP passes.
• Field data covers a rolling 28 day window, so fixes take weeks to show up. Changing something today and rechecking tomorrow proves nothing.
• Your real visitors are on worse phones and worse connections than your desktop. That is why the field numbers are usually uglier than the lab score.

The practical rule: use the field data section of PageSpeed Insights (or the Core Web Vitals report in Search Console) to decide what to fix. Use the lab score only to test whether a change helped, before the field data catches up.

Step 1: find out which metric you fail

Run your homepage and one or two of your most-visited posts through PageSpeed Insights. Ignore the big score for a moment and look at the “Discover what your real users are experiencing” panel at the top. That is your field data. Check the mobile tab, since that is where most sites fail.

If that panel says it does not have enough data, your site has too little traffic for the Chrome report. In that case, fall back on the lab diagnostics and fix the obvious problems, since you will not get real-user numbers either way.

Write down which of the three metrics is red or orange. Then go to just that section below. Fixing a metric you already pass is wasted effort.

Step 2a: fixing LCP (slow loading)

LCP is usually your hero image, featured image, or the largest block of heading text. Failing LCP almost always traces back to one of four things, in the order worth checking:

• Slow server response. Cheap shared hosting is the single most common cause and no plugin fully compensates. If your time to first byte is over 600ms consistently, better hosting beats every other fix on this list.
• No page caching. A caching plugin (WP Rocket, LiteSpeed Cache, or W3 Total Cache) serves a prebuilt HTML file instead of rebuilding the page from the database on every visit. This is the highest-leverage plugin you will install.
• Oversized images. Serve WebP, size images to the dimensions they actually display at, and never lazy-load the image at the top of the page. Lazy-loading your LCP image delays the exact thing being measured.
• Render-blocking CSS, JavaScript, and web fonts. Fonts especially: preload the one font file used above the fold and set font-display to swap so text paints immediately.

One WordPress-specific note. Since version 6.3, core adds a fetchpriority attribute to the image it believes is your LCP element, which helps browsers prioritize it. Core guesses from markup order, so on custom or page-builder layouts it does not always pick the right image. Worth checking if your LCP is stubbornly slow.

Step 2b: fixing INP (sluggish interactions)

INP is the metric most WordPress sites now fail, and caching plugins do not help, because the problem is JavaScript running on the visitor’s device rather than how fast the page arrived.

Every script has to finish before the browser can respond to a tap. Too much JavaScript means the page looks ready but ignores your visitor for a few hundred milliseconds. The usual culprits:

• Plugin sprawl. Every active plugin that loads front-end JavaScript adds to the pile, including on pages that do not use it. Audit what is actually running and deactivate what you no longer need.
• Third-party scripts. Live chat widgets, heat maps, ad networks, and multiple analytics tags are frequently the largest single contributor, and they are the easiest to cut because they are not your code.
• Heavy page builders and sliders. Feature-rich builders ship a lot of JavaScript to render layouts a lighter theme handles in CSS.
• Loading everything everywhere. Most performance plugins can delay or defer non-critical JavaScript until a visitor interacts, which is usually the fastest INP win available.

Because Lighthouse cannot measure INP, test this one by actually using your site on a mid-range phone. If tapping the menu feels laggy to you, it is failing for your visitors too. Google’s guide to optimizing INP covers the deeper technical fixes.

Step 2c: fixing CLS (content jumping around)

CLS is the easiest of the three to fix, because the causes are mechanical. Content shifts when the browser does not know how much space something needs until it loads. The fixes all amount to reserving that space in advance:

• Give every image explicit width and height attributes. WordPress adds these automatically for media library images, but hand-coded or page-builder images often lose them.
• Reserve space for ads, embeds, and iframes with a fixed container height, so the content below does not get shoved down when they load.
• Preload your web fonts. A late-loading custom font reflows the text it replaces, which registers as a shift.
• Stop injecting banners, cookie notices, or announcement bars above existing content after the page renders. Push them into the layout from the start, or overlay them instead.

What is not worth your time

A few popular optimizations produce very little for the effort they cost, or actively backfire:

• Chasing a perfect 100 Lighthouse score. It is a lab number. Passing Core Web Vitals in the field is the goal, and the last few points usually cost more than they return.
• Stacking multiple optimization plugins. Two caching or minification plugins running at once conflict and commonly break layouts. Pick one.
• Aggressive minification and JS combining without testing. These settings break things quietly. Change one at a time and check the front end after each.
• Switching themes to solve a plugin or hosting problem. Diagnose first, or you will rebuild your site and land in the same place.

That said, your theme is a real variable. If you suspect it, we compared real load times across popular options in fast loading WordPress themes, and our guide on testing WordPress theme speed shows how to benchmark one properly before you commit.

Does site speed actually affect rankings?

Yes, but less dramatically than most posts imply. Core Web Vitals are a genuine ranking signal, and they are a tiebreaker rather than a trump card. A fast page with weak content will not outrank a slow page that answers the question better.

The stronger argument for speed is what happens after the click. Slow, janky pages lose people before they read anything, which costs you conversions and the engagement signals that follow. Fix speed for your visitors, and take the ranking benefit as a bonus. If your theme is the bottleneck, how your WordPress theme impacts SEO rankings covers that relationship in more detail.

Frequently asked questions

Why is my PageSpeed score high but Core Web Vitals still failing?

The score is lab data from a simulated load, while Core Web Vitals are field data from real visitors on real devices. Lighthouse also cannot measure INP, so a high score can hide a failing interactivity metric. Trust the field data.

How long until my speed fixes show up in Search Console?

Field data uses a rolling 28 day window, so expect several weeks before improvements are fully reflected. Use lab tests to confirm a fix worked in the meantime.

Do I need a caching plugin if my host has server caching?

Usually not for page caching, and running both can cause conflicts. Managed WordPress hosts often handle caching at the server level and ask you to skip caching plugins. Check your host’s documentation before installing one.

The short version

Start with the field data in PageSpeed Insights, not the score, and find out which single metric you fail. Slow LCP points at hosting, caching, and oversized images. Failing INP points at JavaScript, meaning plugins, third-party scripts, and page builders, and caching will not save you. CLS points at unreserved space for images, ads, and fonts. Fix the one metric that is failing, wait for the 28 day window to catch up, then measure again. That beats installing five optimization plugins and hoping.