Core Web Vitals in 2026 are still three field metrics: Largest Contentful Paint, Interaction to Next Paint, and Cumulative Layout Shift. Google Search uses the Chrome User Experience Report, at the 75th percentile of real visits over a roughly 28-day window. A lab Lighthouse run is a debugger. It is not the ranking dataset.
The good thresholds have not moved into a new secret band. LCP should occur within 2.5 seconds of navigation start. INP should be under 200 milliseconds. CLS should be under 0.1. One metric in the poor band fails the URL group. Google does not average the three into a consolation score.
WordPress fails these in predictable ways. The theme ships a hero image the size of a billboard. The page builder and the marketing plugins add main-thread work that INP then records on every tap. Ads, embeds, and fonts shift the layout because nobody reserved space. Caching plugins can hide a slow origin from a lab test and leave field LCP untouched. We start from field data, then use the lab to find the element.
Field Data Versus The Lab
Search Console's Core Web Vitals report is the one that matches how Google talks about page experience. It groups URLs, splits mobile and desktop, and shows whether the 75th percentile is good, needs improvement, or poor. PageSpeed Insights shows the same CrUX field data when the URL or origin has enough traffic, plus a Lighthouse lab run.
Treat them as different instruments. The lab is a single device profile, a single network throttle, no real ads personalisation, no real third-party consent waterfall. It is useful for "what is the LCP element" and "which script ate 400 ms". It is useless as a trophy. We do not publish lab scores as if they were the live site, and we do not invent before-and-after numbers we did not measure on your origin.
If Search Console has no field data, the URL does not have enough Chrome traffic in the window. Fix using lab diagnostics and origin-level field data, then wait out the window. There is no honest shortcut that writes a 28-day histogram overnight.
FID is gone. Interaction to Next Paint replaced First Input Delay in March 2024. Guides that still optimise FID are out of date. INP looks at clicks, taps, and key presses across the page's life, not only the first one, and it includes the time until the next paint. Scrolling is not an INP interaction. Heavy page builders that felt "fine" under FID often fail INP because the second and third clicks still hitch.
LCP On A WordPress Page
LCP is the moment the largest visible content element paints. On WordPress that is usually a hero image, a slider slide, a heading block, or a featured image. Sometimes it is a late-appearing web font that swaps the H1. Sometimes it is a video poster.
The common causes are boring and specific.
The hero is a multi-megabyte PNG or a Smart Slider stack that only becomes the LCP candidate after JavaScript runs. The image is served at desktop width on a phone. There is no fetchpriority="high" on the actual LCP image, but there is a preload for a different file. The theme loads a CSS framework that blocks render while the image sits in the queue. Host TTFB is slow because object cache is off, the page is uncacheable for logged-out users, or the origin is in the wrong region.
Sliders are frequent LCP poison. The largest paint becomes a slide that is not in the first HTML, so LCP waits on JS. If the slider is decorative, replace it with one static image in the initial markup. If it is not decorative, at least render the first slide as a real <img> with dimensions, compressed, in a modern format, and do not lazy-load it. Lazy-loading the LCP image is a still-common WordPress default.
Fonts delay LCP when the heading is the LCP element and the font is render-blocking or late-swapped. Self-host the subset you actually use. Preload only that file. font-display: optional or swap with a fallback that has similar metrics reduces both LCP delay and CLS from the swap.
We measure LCP by identifying the element in a trace, not by guessing "images are slow". PageSpeed's LCP element field, or a WebPageTest filmstrip, tells you whether you are compressing the wrong file.
INP On A WordPress Page
INP is where plugin culture shows. Each plugin adds listeners, analytics, a chat widget, a popup, an A/B tag manager, a page-builder runtime. The main thread is busy. A tap on a mobile menu or an add-to-cart button waits.
Typical WordPress INP offenders: Elementor, Divi, and similar builders on every view; several analytics tags via GTM plus a native plugin doing the same job; chat scripts that parse on load; mega-menus implemented in JS; variation pickers on WooCommerce product pages that re-render the whole form; input handlers that do layout work on every keypress.
The fix is removal and delay, not a new INP plugin. Count the scripts on a template. Delete duplicates. Load chat and marketing pixels after idle, and never in the critical path of the first view. Replace the builder on templates that do not need it. WooCommerce product JS should not ship on posts.
Long tasks over 50 ms are the lab clue. INP in the field is the proof. If lab TBT looks fine and field INP is poor, the hitch is after load: a widget that boots late, a third party that runs on first scroll, or a click handler that is worse than the load cost. Debug with real interaction, not only with a cold load.
Consent banners deserve a mention. A banner that is itself slow to become interactive is an INP event. A banner that then loads twenty tags in one burst creates the next INP events. Design the waterfall. Do not dump the tag manager on accept as one blocking slab.
CLS On A WordPress Page
CLS is unexpected movement of visible content. WordPress themes fail it in a short list of ways.
Images and iframes without width and height. Ads and embeds that inject after first paint. Cookie banners that push the whole page down. Web fonts that reflow headings. Carousels that change height when the next slide loads. WooCommerce notices that insert above the product title. Admin bars on logged-in previews that you then confuse with the public layout.
Reserve space. Intrinsic dimensions on images. Aspect-ratio boxes for ads and embeds. Do not inject a banner by shifting the document; overlay it or reserve a slot. Match fallback font metrics to the webfont. Stop loading a second stylesheet that restyles the header after first paint.
Lazy-loaded images below the fold still need dimensions. Without them, they cause CLS when the user scrolls, and those shifts still count.
What Usually Does Not Fix Field Vitals
Installing three cache plugins. Combining CSS until the page is uncacheable to debug. A "performance" plugin that concatenates everything and breaks HTTP/2. Minifying already-minified third-party scripts. Chasing a 100 lab score by removing the features the business actually uses, then wondering why the field report barely moved.
A CDN helps TTFB and image delivery when it is configured. It does not fix a 2 MB hero, a builder runtime, or a banner that shifts the H1. Object cache (Redis or equivalent) helps origin TTFB on dynamic WordPress. Full-page cache helps anonymous templates. Logged-in or carted WooCommerce pages will still be dynamic; measure those templates separately.
Hosting matters, and it is not the whole story. Moving hosts without changing the theme can improve TTFB and still leave LCP on a huge image. We look at TTFB, then the LCP resource, then main-thread time. In that order.
WordPress Habits That Hold In 2026
One image pipeline: upload reasonably sized sources, let a single plugin or the CDN emit WebP or AVIF with correct srcset, do not stack two image optimisers.
One analytics path. If GTM is required, do not also fire the same pixels from WooCommerce and from a Facebook plugin.
Themes without a page builder on the default post and product templates. Builders on landing pages you accept as heavier, measured as their own URL group.
No auto-lazy-load on the first image in the viewport. Most "lazy load everything" toggles still get this wrong.
Critical CSS generated per template, not one giant global sheet, and no runtime CSS CDN on top of a built stylesheet.
Preconnect only to origins you actually use on first load. A preconnect to a chat host you delay for six seconds is a wasted hint.
When developers break WordPress SEO they often do it in the same files that break vitals: functions.php that concatenates scripts, a theme update that drops image dimensions, a "defer all JS" snippet that defers the LCP discoverability or breaks INP by scheduling work at the wrong time. Performance and technical SEO share the HTML. Treat them as one change list.
How We Work A WordPress Vital Failure
Read Search Console by URL group and by mobile first. Confirm the failing metric. Open a representative URL in PSI and in a trace. Identify the LCP element, the longest INP interaction if you can reproduce it, and the CLS sources in the experience section.
Change one cause at a time on staging: the hero, then third-party scripts, then layout slots. Re-run the lab to confirm the element changed. Ship. Wait for field data. Do not declare victory from a lab screenshot.
If the origin has no CrUX data yet, we still fix the same causes, and we say plainly that Search Console cannot confirm the field result until traffic fills the window. That is slower to report and more honest than a fake score.
What We Will Not Do
We will not quote a Lighthouse number as if Google ranks on it. We will not invent a before-and-after LCP for a site we have not measured. We will not strip a site to a blank theme to win a lab run that the live pages cannot match.
Page experience is a quality signal among others. A fast page that is the wrong document still will not rank. A slow page that is the right document still should be fixed, because users bounce and INP-poor checkouts cost money even when the query is already won.
If mobile LCP, INP, or CLS is in the red in Search Console, send the URL. We will read the field report you already have, name the element or script that is in the way, and only then talk about theme, hosting, or plugins.
