Fix First Contentful Paint with image optimization

You've run your site through PageSpeed Insights. The number that stings the most isn't the overall score — it's that yellow or red bar next to First Contentful Paint. Visitors are staring at a blank screen for two, three, sometimes four seconds before anything shows up.

That's First Contentful Paint, or FCP. And while it sounds like a problem only developers should care about, FCP is one of the clearest signals Google uses to decide whether your page feels fast or slow. It directly influences bounce rates, search rankings, and the gut feeling a visitor gets in the first second of their visit.

The surprising part? In most cases, the biggest lever for fixing FCP isn't your code — it's your images.

What First Contentful Paint actually measures

FCP is the moment the browser paints the first piece of meaningful content on the screen. That could be a headline, a logo, an icon, or a background — whatever the user first perceives as "the page is loading."

Anything under 1.8 seconds is considered good. Between 1.8 and 3 seconds needs improvement. Anything above 3 seconds is poor, and that's where most unoptimized sites land.

It's easy to think of FCP as just a network problem — slow server, slow connection. But the truth is that even on a fast connection, your browser has a queue of work to do before it can paint anything. And images, even ones that aren't the first thing visible, often clog that queue.

Why images hurt FCP, even when they're "below the fold"

Here's where it gets counterintuitive. You might think your hero text would render long before your hero image — after all, it's just letters on a screen. But browsers don't work that linearly.

When a page loads, the browser fetches the HTML, then starts pulling in everything it references: stylesheets, scripts, fonts, and images. All of these compete for the same network bandwidth. If your homepage carries a 2 MB hero image and three more 1 MB product photos, the browser is choking on that download queue before it can lay out the page properly.

The result: critical CSS arrives late, the layout shifts, and that first paint gets delayed.

There's also the issue of render-blocking. Large images, especially when paired with bloated CSS or unoptimized fonts, can starve the browser of resources it needs to render the first frame. Trim the image weight, and everything else moves faster — including the text and styles that drive FCP.

The format problem: JPEG and PNG are quietly wasteful

Most websites still serve their images as JPEG or PNG. Both formats have been around for decades, and both are dramatically less efficient than modern alternatives.

WebP, developed by Google specifically for the web, typically delivers the same visual quality at 25 to 35 percent of the file size of a comparable JPEG, and even greater savings against PNG for graphics with transparency. That means a 1 MB JPEG can become a 300 KB WebP without any visible quality loss.

Multiply that across every image on your page and the savings add up to seconds — not milliseconds — shaved off your load time.

The catch is that converting and compressing images by hand is tedious. You'd need to open each one, export it through a converter, find the right quality setting, save it with a fallback for older browsers, and update your HTML or CMS to serve the right format. For a five-page site that's an afternoon. For a real site with hundreds of product photos or blog images, it's a project no one wants to do.

That's the gap Sukat fills.

How Sukat helps you fix FCP

Sukat is built around one specific job: take any image and compress it to an exact file size target — say, 150 KB — using a binary search to find the highest quality that fits under your ceiling. It converts to WebP at the same time, all in your browser. No uploads, no server, no account.

A few things make a real difference for FCP work:

You hit specific targets, not approximate ones. Most compression tools give you a quality slider and hope you land in the right range. If you want every hero image on your site under 200 KB, you can spend an hour fiddling with presets. Sukat lets you type "200 KB" and it finds the best quality that fits — every time, on every image.

It runs entirely in your browser. Your images never leave your device. If you're optimizing photos that have any sensitivity — product mockups, client work, anything pre-publication — there's no server-side processing to worry about. Just drop them on the page.

Batch ZIP for a whole site audit. If you're going through every image on your site to bring FCP down, dropping 50 images in, setting a target, and downloading a ZIP of optimized WebPs takes a few minutes instead of an afternoon.

The actual workflow is straightforward: use Lighthouse or PageSpeed Insights to find which images are bloating FCP, drop them into Sukat, set a target size based on your performance budget (our size guide has typical ranges), download the optimized versions, and re-upload them through your CMS. How It Works covers the encoder side in more detail.

What to expect after optimization

If your site is currently serving unoptimized JPEGs and PNGs — and most sites are — running your largest images through Sukat at a sensible target (typically 100-300 KB per image, depending on placement) usually pulls FCP down by between 30 and 60 percent. A site that was painting at 3.2 seconds might drop to 1.5 seconds. That's not a marginal improvement; that's the difference between Google flagging your site as slow and Google rewarding it as fast.

The harder truth about FCP is that no single fix gets you there. But image weight is almost always the first domino. Once your images are right-sized and right-formatted, every other optimization you do — code splitting, font loading, caching — has more room to actually show its value.

If your largest paint is also slow, see the LCP post for the deeper image-side fix.

Start with the images.