Sukat blog banner showing a webpage with a hero image flagged as the Largest Contentful Paint element.

Largest contentful paint is (almost always) an image problem — here's how Sukat solves it

If you've spent any time staring at a PageSpeed Insights report, you've probably noticed that one metric tends to misbehave more than the others: Largest Contentful Paint. You can tune your code, defer your scripts, cache your assets — and LCP still sits in the red.

There's a reason for that. In nine out of ten cases, LCP isn't really a code problem. It's an image problem. And until you address what's actually slowing down that largest paint event, no amount of clever JavaScript will save your score.

What LCP measures, and why Google cares so much about it

LCP is the moment the browser finishes rendering the largest visible element on the screen — usually within the user's initial viewport, before they scroll. That element is whatever takes up the most real estate above the fold. On the vast majority of websites, that's a hero image, a featured photo, or a banner.

Google has been pretty blunt about the thresholds. Under 2.5 seconds is good. Between 2.5 and 4 seconds needs improvement. Above 4 seconds is poor, and it directly impacts your Core Web Vitals — which directly impacts your search ranking.

Unlike older speed metrics that measured how quickly anything appeared, LCP captures something more meaningful: how quickly the page feels like it's actually loaded. A blank screen at 1 second is bad, but a blank-hero-image-with-text-around-it at 4 seconds might be worse. Users perceive the page as broken until that main element finishes painting.

Why images dominate LCP

When you inspect what's flagged as the LCP element on most websites, the same pattern shows up over and over: it's an image. Sometimes it's a hero banner, sometimes a product photo, sometimes a background image, sometimes a logo on a sparse landing page. Text can be the LCP element on text-heavy sites, but image-driven pages almost always have an image as the bottleneck.

This is because of how the metric works. The "largest" element is measured by rendered size — the area it occupies on the screen. A 1600-pixel-wide hero photo will almost always beat any headline or paragraph for total area. And large images take longer to download, decode, and paint than text, which the browser can render the moment the CSS is ready.

So if your LCP is slow, the math is usually simple. Your LCP element is an image. That image is too big, in the wrong format, or both. Fixing it is the single biggest improvement you can make.

The two levers that matter: compression and format

There are two things you can do to an image that have an outsized effect on LCP.

The first is compression. Most images on the web are saved at quality levels far beyond what a human eye can distinguish from a smaller version. A JPEG saved at quality 100 looks identical to one saved at quality 80, but the file size can be cut in half. For PNGs, the savings are often even greater because PNGs were never designed for photographs in the first place.

The second is format. WebP, which is supported by every browser worth caring about in 2026, was designed specifically to deliver images more efficiently than JPEG and PNG. The same image, at the same perceived quality, will typically be 25 to 35 percent smaller as a WebP. For graphics and screenshots, the savings are even bigger.

Combine intelligent compression with WebP conversion, and a 2 MB hero image can routinely become a 350 KB hero image without a single visual change a user would notice. That's not optimization theater — that's a real, measurable difference in how fast your largest paint completes.

The problem is that doing this by hand is painful. You'd be opening each image, exporting it, picking a quality level, generating a WebP version, generating a fallback, updating your image tags or your CMS to serve the right format to the right browser. For a single landing page it's tedious. For a real site with dozens or hundreds of images, it's the kind of work that never gets done.

That's where Sukat comes in.

How Sukat targets LCP directly

Sukat is a single-purpose tool: take any image and compress it to a specific file size target while converting to WebP. It uses a binary search algorithm to find the highest quality that fits under your KB or MB ceiling — and the whole thing runs in your browser, so files never leave your device.

For LCP work specifically, this matters in a way that goes beyond raw file size:

Your hero image gets a precise size target. LCP optimization is really about putting a budget on your largest image. If your performance budget says "hero images under 200 KB," Sukat lets you actually hit that — every time, on every image — instead of guessing with a quality slider. Type the target, drop the image, get the file. Our size guide covers typical targets by placement.

It's a workflow, not a plugin. You audit your site's slow LCP pages with Lighthouse, find the offending hero images, drop them into Sukat with a target size, download the optimized WebPs, and re-upload through your CMS. It takes minutes, doesn't touch your codebase, and the results show up in your next Search Console crawl. How It Works walks through the encoder behavior.

Batch through everything at once. If LCP is bad across multiple pages, the batch mode handles it. Drop in 20 hero images, set a target, download a ZIP. Your full image audit goes from a multi-hour project to a coffee break.

The privacy angle is worth flagging too: nothing uploads to a server. Sukat runs locally using the Canvas API, so client mockups, unreleased designs, and pre-publication assets stay on your machine.

What optimization looks like in the real world

On a typical site with unoptimized hero images, LCP improvements after running them through Sukat tend to land in the 40 to 60 percent range. A site stuck at 4.2 seconds can drop to 1.8. That's the difference between failing Core Web Vitals and passing them — and the difference between Google ranking you below faster competitors or above them.

The honest summary is this: if your LCP is slow, your images are slow. Fix the images first, and the metric follows. Sukat is built to do exactly that, and to do it without forcing you to redesign your site, change your CMS, or learn a new workflow.

If your first paint is also dragging, see the FCP post for the upstream side of the same fix.

If LCP has been your white whale, this is where you start.