What actually moves LCP and INP on a WordPress site

The two metrics, briefly

Core Web Vitals are three measurements Google uses to describe real visitors’ experience. Two of them depend heavily on how a theme is built:

• Largest Contentful Paint (LCP): how long until the largest image or text block in the viewport is displayed. Good is 2.5 seconds or less, measured at the 75th percentile of real visits, separately for mobile and desktop.
• Interaction to Next Paint (INP): how quickly the page visibly responds to taps, clicks and key presses, across the whole visit. Good is 200 milliseconds or less, on the same basis. INP replaced First Input Delay as a Core Web Vital in March 2024.

The third, Cumulative Layout Shift, measures visual stability and is mostly fixed by reserving space for images and embeds.

We will use one real build as the example: RefrigeratorRepair.center, where the team edits in WordPress and visitors receive a static build. In Lighthouse on November 3, 2026, its homepage scored 100 for Performance on desktop and 96 on mobile. Those are lab numbers, but the decisions behind them apply to any WordPress theme.

What moves LCP

LCP is a chain: the server responds, the browser discovers the main resource, downloads it and renders it. Each link can be shortened.

1. Server response. If the HTML takes a second to arrive, nothing else can start. Page caching, a better host or a static build all reduce this. On RefrigeratorRepair.center, visitors receive pre-built HTML, so there is no PHP or database work per request.
2. Early discovery of the hero. The LCP element is usually the hero image. The browser should find it in the initial HTML: usually as an <img> element, or, if it is a CSS background, with a preload. It should never be lazy-loaded or injected by JavaScript. That build preloads the hero image and marks it fetchpriority="high", asking the browser to fetch it early and ahead of less important files.
3. The right size. An image much larger than its displayed size and the screen’s pixel density need wastes bandwidth. Responsive images with srcset and sizes, in a modern format such as WebP, let the browser pick a file that fits.
4. Fonts that do not block text. Preload only the critical font file and declare it with font-display: swap, so fallback text appears after a very short block period and the brand font swaps in when it arrives. Matching the fallback’s metrics limits layout shift. Self-hosting removes a connection to a third-party font server.
5. Less in the way. Every render-blocking stylesheet and synchronous script in the head delays the first paint. Compiling CSS at build time so only used styles ship, and deferring scripts, keeps the critical path short.

What moves INP

INP is about the main thread. When a visitor taps a button, the browser must run any JavaScript attached to that tap and then paint the result. If the main thread is busy with something else, such as a tag manager parsing, a chat widget booting or a slider recalculating, the tap waits.

• Ship less JavaScript. Most service sites need very little: a menu, a form, perhaps a filter. Avoid loading a large library for a small effect.
• Delay third parties. Analytics, ad pixels and widgets do not need to run before the visitor can read and tap. On RefrigeratorRepair.center, analytics and marketing tags are added by one small loader after the page has loaded, in idle time. The trade-off is that very short visits may not be recorded, and delayed scripts can still cause slow interactions later.
• Keep handlers short. If a click triggers heavy work, update the interface, then yield to the browser so it can paint before the rest of the work continues.

A related technique helps the next page rather than the current one. WordPress 6.8 introduced conservative speculation rules that prefetch likely next pages for logged-out visitors on sites with pretty permalinks, in supporting browsers. Prefetch downloads HTML only; prerender also runs the next page’s scripts, which can fire analytics for pages nobody opened. It shortens navigation, but it does not fix INP on the page a visitor is already using.

Lab scores and real visitors

Lighthouse runs one page load in controlled conditions. It is excellent for catching regressions, but Core Web Vitals in Search Console come from real Chrome users over 28 days, on their own devices and connections. A page can score well in the lab and still have poor field INP because of a script that only runs after interaction. Check both, and give field data time to update after a change.

If your site feels slow and you are not sure where the time goes, our website fixes work starts with exactly this kind of measurement. For the architecture behind the example, read WordPress to edit, static to serve.