Optimizing LCP in 2026: beyond WebP (fetchpriority, lazy-loading, render-blocking CSS)

"We compressed every image to WebP, and the LCP won't budge." That's probably the sentence I hear most often when a site shows up with a speed problem. Converting images has become the default reflex (a good one, by the way), but it only fixes part of the problem. The Largest Contentful Paint, that moment when the biggest visible element of the page finally appears, depends on a whole chain that image format only touches at the surface.

This article is the field report on what actually moves the LCP needle once WebP is already in place. Four concrete levers that often weigh more than compression: not lazy-loading the LCP element, prioritizing it with fetchpriority and preload, neutralizing the CSS and fonts that block rendering, and caring about server response time. With, at the end, the settings specific to WordPress.

WebP makes the image lighter. But if the browser discovers it too late, downloads it last, or waits for a 300 KB CSS file before displaying anything, your LCP stays at 4 seconds. Perceived speed is a matter of priorities, not just weight.

First of all: identify the real LCP element

You can't optimize what you haven't identified. The first mistake is to assume which element is the LCP rather than measure it. On a homepage, it's often the hero image; on an article, it can be the header visual, a large block of text, or even the H1 title. The Chrome DevTools Performance panel and the Web Vitals extension show precisely which node is treated as LCP, and at what moment it appears.

This step changes everything, because it redirects the effort. No point optimizing ten images if the measured element is a CSS background banner, or a title waiting for a web font to load. Before touching anything, I measure on field data, not just in the lab, because Google's official LCP is read at the 75th percentile of real visits. That's the whole point of seriously monitoring Core Web Vitals and their SEO impact: act on the right page, on the right element.

Never lazy-load the LCP image

Here is the most expensive misconception I fix in the field. To gain performance, many sites, and most "all-in-one" WordPress plugins, enable lazy-loading on all images, indiscriminately. Deferred loading is an excellent technique… for images below the fold, the ones you only see by scrolling. But applied to the LCP image, it produces the opposite effect: you're explicitly asking the browser to delay loading the very element Google is timing.

The rule is binary. The main image visible on the first screen must be loaded with priority (attribute loading="eager", never loading="lazy"), and everything below it can be deferred. On the sites I take over, removing lazy-loading from the hero image alone often gains a full second of LCP, with nothing else changed. It's the most profitable setting of the lot: zero development, one attribute to fix.

fetchpriority and preload: tell the browser what matters

By default, the browser assigns download priorities according to its own heuristics, and it often gets the LCP image wrong, treating it as an ordinary resource to load as it goes. Two tools let you force its hand.

The first, fetchpriority="high", goes directly on the LCP image tag: it tells the browser to download it ahead of competing resources. The second, preload, declared in the <head>, asks the browser to start fetching the image very early, even before it's finished parsing the HTML, particularly useful when the LCP image is called late, in a CSS background or via a slider. Combined, these two levers move the LCP image to the front of the queue. Conversely, I deliberately de-prioritize what doesn't need it (secondary banners, third-party scripts, widgets) to free up bandwidth at the right moment.

Render-blocking CSS, the silent LCP brake

We talk a lot about images, rarely about CSS, and yet that's often where it all plays out. A stylesheet is, by nature, a render-blocking resource: until it's downloaded and parsed, the browser displays nothing. A WordPress theme loaded with plugins can pile up several hundred kilobytes of CSS, 90% of which is useless to the current page. The result: the browser waits for that big file before painting a single pixel, and the LCP collapses.

The fix takes two moves. First, extract the critical CSS, the strict minimum needed to display the first screen, and inline it in the <head>, so the browser paints immediately, without waiting for an external file. That's exactly the "critical CSS" logic you see at work in this site's source code. Then, defer the rest of the CSS so it loads without blocking rendering. The same reasoning applies to JavaScript: any script not essential to the first paint must be loaded with defer or async.

Web fonts, false innocents

When the LCP element is a title or a block of text, the web font becomes decisive. Without precaution, the browser waits for the font file to download before displaying the text (the infamous "invisible text"), which delays LCP. Two settings are enough: font-display: swap, to first show a system font then switch, and preload of the main font used above the fold. You also limit the number of weights loaded to the strict minimum.

LCP starts on the server: TTFB

All these front-end levers assume the HTML arrives fast. If the server takes 800 milliseconds to respond (the TTFB, Time To First Byte), you've already burned a third of your LCP budget before any image loads. On WordPress, the TTFB degrades quickly: uncached database queries, heavy plugins, saturated shared hosting. Page caching (serving static HTML rather than regenerating the page on every visit), a good CDN and hosting that's up to the job solve most of it.

WordPress: where to act, concretely

On WordPress, these levers translate into precise settings. A serious cache plugin handles page caching, CSS/JS deferral and preload, but you still have to exclude it from the wrong target: you must never let global lazy-loading apply to the hero image, nor defer the critical CSS of the first screen. Most good tools let you manually exclude the LCP image from deferred loading and add its preload: it's this fine tuning, not the default install, that makes the difference.

Page builders (Elementor, Divi and the like) add their own layer of CSS and DOM, and complicate identifying the LCP element, a topic I detailed in my report on Core Web Vitals with WordPress page builders. The approach stays the same: measure the real LCP element, prioritize it, lighten what blocks around it. And because speed isn't only a Google matter, it's also a direct lever for conversion: every second gained on LCP shows up in bounce rate and conversion rate, well beyond ranking alone.

In the crucible: distilling the millisecond

Optimizing LCP isn't about stacking plugins or converting one more image. It's about following a chain, from server to pixel, and removing one by one the obstacles that delay the display of the element that matters. You measure the real LCP, load it with priority instead of deferring it, clear its path by neutralizing the CSS and fonts that block, and make sure the server responds fast. WebP is just one link; perceived speed is forged in the order of priorities.

Done in this order, an LCP under 2.5 seconds stops being a stroke of luck and becomes a reproducible result. If you want to concretely audit what's slowing your pages, and sort the optimizations that pay off from those that cancel out, it's all detailed on my WordPress expertise page, where I connect technical performance, organic search and conversion in a single logic.