Improving WordPress Core Web Vitals comes down to three metrics — LCP, INP, and CLS — and the good news is that most sites can move all three meaningfully without a rebuild. The work is mostly about controlling images, scripts, and how the page loads. Here is how I approach it as a senior developer, in priority order.
What WordPress Core Web Vitals actually measure
LCP (Largest Contentful Paint) is how quickly the largest visible element — usually the hero image or headline — finishes loading; aim for under 2.5 seconds. INP (Interaction to Next Paint) measures how fast the page responds when a visitor clicks or taps; aim for under 200 milliseconds. CLS (Cumulative Layout Shift) measures how much the layout jumps around as things load; aim for under 0.1.
Two things trip people up. First, Google scores these on real visitors (field data) at the 75th percentile, so a perfect lab score in Lighthouse does not guarantee a pass — you need real-world data from the Chrome User Experience Report. Second, INP replaced FID in 2024, so any advice still talking about First Input Delay is out of date.
Fixing LCP
On WordPress, slow LCP almost always traces back to images and render-blocking resources. Serve the hero image eagerly with a high fetch priority, and lazy-load everything below the fold so the browser is not fighting to download images the visitor cannot see yet. Use modern formats — WebP or AVIF — and serve images at the size they are actually displayed, not full resolution.
Then tackle the render path: inline the small amount of critical CSS needed to paint what is above the fold, defer the rest, and keep render-blocking JavaScript out of the way. A CDN that serves assets close to your audience matters too, especially for regional sites where the server might be continents away from the visitor.
Fixing INP
INP is where heavy WordPress sites struggle most, and the cause is almost always too much JavaScript competing for the browser’s main thread at the exact moment the visitor tries to interact. The biggest offenders are page builders that ship megabytes of script for simple layouts, and third-party tags — chat widgets, analytics, marketing pixels, A/B testing tools.
The fixes: remove scripts you do not genuinely need, load non-essential ones after the first interaction rather than on page load, and give your team a single, controlled place to add marketing tags instead of scattering them through the theme. If a plugin adds heavy JavaScript site-wide for a feature used on one page, load it only where it is needed.
Fixing CLS
Layout shift comes from a short list of causes: images and embeds without declared dimensions, web fonts that swap in late, and content (ads, banners, cookie bars) injected after the page has rendered. The fixes are small and high-leverage: set explicit width and height on every image and video, preload key fonts and use font-display: swap, and reserve space for anything that loads in dynamically so nothing below it jumps.
Measure before and after
Do not guess. I measure real metrics before and after every change, because the assumed problem is often not the real one — sometimes a single third-party script is responsible for most of the damage. Measuring keeps the work honest and proves the result to stakeholders.
Do you actually need a rebuild?
Usually not. Plenty of WordPress sites jump from the 30s–40s into the 90s with focused work on the points above. A rebuild only pays off when the theme itself is the bottleneck — a bloated page-builder stack that fights every optimisation you attempt. If you want this handled end to end, see my WordPress performance optimization service, speed optimization for Dubai teams specifically, or the WooCommerce work where checkout speed maps straight to revenue. Either way, get in touch and I will tell you honestly what your site needs.
