Running a Core Web Vitals report is easy. Actually improving the numbers — without breaking the rest of the site — takes a different kind of work. I have run this process on dozens of sites, and the pattern is almost always the same: the audit tells you what failed, but it does not tell you why, or in what order to attack the problems. This post covers the remediation side, not the reporting side.

Understand the Three Signals Before You Touch Anything

Core Web Vitals measure three distinct user experiences: loading (LCP), visual stability (CLS), and responsiveness (INP). They fail for different reasons and require different fixes. Treating them as one bucket is how teams waste sprint cycles. Prioritize by impact — pull your field data from Google Search Console, not just lab data from PageSpeed Insights. Field data is what Google actually scores you on, and it segments by page group and device type. A desktop lab score of 1.8s LCP means very little if 30% of your real users are on mobile with a 4G connection and seeing 5s in the field.

Fix LCP First — It Moves the Needle Most

Largest Contentful Paint is almost always the failing metric on content-heavy sites. The fastest wins: preload the LCP image with a <link rel='preload' as='image'> tag, eliminate render-blocking scripts above the fold, and make sure your server response time (TTFB) is under 600ms. If your LCP element is text, check whether a custom font is delaying it — font-display: swap buys you time while the font loads without blocking rendering entirely.

On WordPress specifically, the LCP image is usually the hero. Confirm it is not being lazy-loaded. WordPress 5.5 and later adds loading='lazy' to images automatically — you need to exclude the above-the-fold hero from this behavior. I use the wp_lazy_loading_enabled filter to carve out the first image in the content area. That one change alone has moved several client sites from Poor to Good LCP without touching anything else.

CLS Fixes Are Architectural, Not Cosmetic

Cumulative Layout Shift punishes you for elements that shift after load. The top culprits: images without explicit width and height attributes, ads that inject at the top of a column, and web fonts that swap late. Set explicit dimensions on every image and embed so the browser reserves space before the asset loads. Reserve space for ad slots with a CSS min-height matching the expected unit size. For fonts, self-hosting and preloading both reduce the swap window significantly.

One pattern I see often: a sticky header or cookie banner that pushes content down after the page paints. If the banner is injected by a third-party script, it fires after the main thread is free — right in the CLS window. The fix is either to reserve that vertical space in CSS before the script fires, or to move the banner to the bottom of the viewport where it does not affect document flow above it.

INP Is the Newest and Most Misunderstood

Interaction to Next Paint replaced FID in March 2024. It measures the full cycle from user input to the next paint, not just the delay before the handler fires. Heavy JavaScript on the main thread is the root cause in almost every case. Audit your third-party tag stack — ad networks, chat widgets, and analytics scripts all compete for main-thread time. Deferring non-critical scripts and breaking up long tasks with scheduler.yield() or setTimeout chunking are the primary levers. For WordPress sites, the culprit is usually a bloated plugin stack loading JavaScript that is only needed on specific pages but fires sitewide.

Use the Right Tools at Each Stage

  • PageSpeed Insights — lab plus field data linked to CrUX. Start here for a quick read on where you stand.
  • Chrome DevTools Performance panel — shows long tasks, main-thread blocking, and paint timing. Essential for INP debugging at the interaction level.
  • WebPageTest — filmstrip view to pinpoint exactly when the LCP element paints and what was blocking it.
  • Search Console Core Web Vitals report — URL-level field data grouped by Good, Needs Improvement, and Poor. This is your ground truth for what Google actually sees.

Prioritize by Page Group, Not Individual URLs

Google groups URLs by template type in Search Console. A failing score on one product page template likely means every product page fails. Fix the template, and you improve hundreds of URLs at once. This is where the ROI is — not on chasing individual page scores one by one. Related: orphan pages. Identify your highest-traffic failing template, fix it, and validate the improvement in field data before moving to the next group.

The Hosting Layer Cannot Be Ignored

If your TTFB is consistently over 1 second, no amount of frontend optimization gets you to Good LCP. Shared hosting on an oversold server will drag down your scores regardless of what you do in the theme and plugins. A proper managed WordPress stack with full-page caching, object caching, and a CDN in front is the foundation. At Salterra, when we take over a site that has been sitting on cheap shared hosting, the hosting migration alone often moves LCP from Poor to Needs Improvement before we touch a single image or script.

Validate in the Field, Not Just the Lab

Lab scores from Lighthouse and PageSpeed Insights are synthetic. They do not account for real user devices, real network conditions, or real third-party script behavior under production load. After deploying fixes, wait 28 days for field data to update in Search Console before declaring victory. I have seen lab scores jump 30 points while field data barely moved — usually because a slow CDN edge or inconsistent server response is dragging down real-user TTFB in a way the synthetic environment never sees.

What to Tackle in What Order

My standard sequence: (1) reduce TTFB at the server and hosting layer, (2) fix LCP by preloading, removing lazy-load from the hero, and compressing the image, (3) address CLS by adding image dimensions, reserving ad space, and fixing font swap, (4) reduce INP by deferring third-party scripts and breaking up long tasks. Do them in this order because TTFB is a sub-component of LCP, and LCP remediation work is partially wasted if the server is the real bottleneck.

If you want a systematic look at the full technical picture before diving into fixes, a website audit is a good starting point — it surfaces Core Web Vitals alongside crawl issues, indexation gaps, and structured data problems so you can prioritize everything in one pass. Page speed is also a factor in AI citation readiness; for the broader context see answer engine optimization. For a closer look at how vitals fit into the broader performance picture, see Core Web Vitals auditing and page speed optimization.