How WebP Fixes Your Largest Contentful Paint Score

Largest Contentful Paint measures how long it takes for the biggest visible element to finish rendering. On the overwhelming majority of pages that element is an image — a hero photo, a product shot, a banner. Which means LCP is almost never a server problem, a database problem, or a JavaScript problem. It is an image problem wearing a performance metric's clothing.

This matters beyond the score itself: LCP is one of the Core Web Vitals Google uses as a ranking signal, and it correlates unusually well with what visitors actually experience. A page that shows its main image in 1.8 seconds feels fast. The same page at 4.2 seconds feels broken, whatever the rest of the metrics say.

Step 1: Find out what your LCP element actually is

Do not guess. Open Chrome DevTools, run a Lighthouse report on mobile, and expand the "Largest Contentful Paint element" entry in the diagnostics. Lighthouse names the exact node. People are wrong about this more often than not — a background image in a hero section, a logo, or a lazily-loaded carousel frame frequently turns out to be the culprit rather than the obvious photograph.

Note the element's rendered size too. That number is the single most important input to everything that follows.

Step 2: Stop serving pixels nobody sees

The most expensive mistake in web imagery is shipping a 3000-pixel-wide image into a slot that renders at 800 pixels. You are paying for roughly 14 times the pixel data the visitor's screen will ever use, and no amount of clever compression recovers that.

Resize first, compress second. File size scales with pixel count, so halving both edges quarters the data before the encoder even starts. Dropping quality from 90 to 80 might save you 30%; halving the dimensions saves around 75%. Do the resize, then the compression, in that order.

Step 3: Convert to WebP at quality 80-85

At matched visual quality, WebP lands roughly 25-35% below JPEG. On a 400 KB hero image that is 100-140 KB removed from the critical path, and on a mobile connection that is real time.

Quality 80-85 is the working range for photographs. Above 90 you are spending bytes on detail that is invisible at any realistic viewing size. Export presets in most tools default to 90 or higher because they are tuned to avoid complaints, not to be fast — which is why simply re-encoding an existing media library at 82 so often produces a dramatic saving with no perceptible change.

For logos, icons and anything containing text, use lossless WebP instead. Lossy compression puts a distinctive fuzz around hard edges, and on flat-colour graphics lossless is frequently smaller anyway.

Step 4: Do not lazy-load your hero image

This is the most common own goal in image performance. Somebody reads that loading="lazy" improves page speed, applies it to every image on the page including the hero, and watches LCP get worse. Lazy-loading defers the request — which is exactly wrong for the element LCP is measuring.

Lazy-load everything below the fold. For the LCP image specifically, do the opposite: leave it eager and add fetchpriority="high" so the browser knows to prioritise it over stylesheets, fonts and analytics scripts competing for the same connection.

Step 5: Set width and height on every image

Intrinsic dimensions on the <img> tag let the browser reserve the correct space before the file arrives. Without them the page reflows when each image loads, which wrecks Cumulative Layout Shift — a separate Core Web Vital that people often spend hours chasing without realising the fix is two attributes.

Step 6: Serve WebP with a fallback, not instead of everything

Use a <picture> element with an AVIF source first, a WebP source second, and a JPG in the <img> tag as the final fallback. Every browser takes the best format it understands, and nothing breaks for the ones that do not. This also means you never have to make a single format choice on behalf of your entire audience.

What to expect

A typical image-heavy page that has never been optimised will see its total image payload drop by 50-70% from resizing and WebP conversion together, with mobile LCP improving by one to two seconds. The gains are front-loaded: the hero image alone usually accounts for most of the improvement, which makes it worth fixing properly before touching anything else.