On a typical page today, images make up close to half of everything the browser has to download before it can show you something. On most pages, the single heaviest image is also the exact element Google's own speed test is timing when it calculates your Largest Contentful Paint score. Those two facts together explain a pattern we see constantly when people bring us a "slow site" complaint: they've minified their CSS, deferred every script they can find, and their PageSpeed score still won't move, because nobody touched the one file actually holding the page hostage.
We're going to walk through this the way we'd actually fix it on a real site, in order, rather than front-loading a wall of theory about Core Web Vitals before getting to anything useful. Each step folds in the "why" as we go, because the reasoning only makes sense once you can see what it's fixing.
Step 1: Find out which image is actually the problem
Before changing a single file, run the page through PageSpeed Insights and look past the big number at the top. That overall score is a lab simulation, and it's not what Google uses to evaluate your rankings. What matters is the Core Web Vitals section further down, the one pulling from real Chrome user data collected over a rolling 28-day window. That's your field data, and it's the version of "slow" Google actually sees.
Inside that report, find the element labeled as your Largest Contentful Paint target. On roughly eight out of ten pages, it's an image, usually a hero banner, a product photo, or a header graphic sitting above the fold. Write down its current format and file size before you touch anything. You need a baseline, or you won't be able to tell later whether your fix actually worked or just felt like it should have.
Step 2: Understand why the format matters more than the compression slider
Here's the part most speed guides gloss over. You can crank a JPEG's compression down to a lower quality setting and shave off some kilobytes, but you're fighting the format's own math. JPEG and PNG are decades-old encoding schemes, and neither was built with the kind of prediction and transform efficiency that newer formats use to represent the same visual information in a smaller container.
WebP, sitting in the middle, typically renders the same image at something like a quarter to a third smaller than an equivalent-quality JPEG, and it does that without the visible blockiness you'd get from just pushing a JPEG's quality slider too far down. AVIF goes further still, often landing 40 to 60 percent smaller than JPEG at a comparable visual quality, though it costs more processing time to encode and isn't universally supported by every older browser still floating around in your analytics.
That's the actual tradeoff, and it's why we don't tell people to blindly convert everything to AVIF and call it done. If your traffic skews toward an audience running current browsers, AVIF earns its place as your primary format with WebP as a fallback. If you're supporting a wider spread of devices, or you just want one format that covers the overwhelming majority of visitors without a fallback chain, WebP is usually the more practical default. JPEG and PNG still have a job: PNG for anything needing hard transparency or crisp flat-color graphics like logos, JPEG as your final safety net for the handful of visitors on genuinely old software.
Step 3: Convert without shipping your files to someone else's server first
This is where we'll be direct about our own tool, because it's built specifically for this step and we want to describe what it does, not what we wish it did.
Our Local Image Converter takes JPG, PNG, WEBP, AVIF, GIF, BMP, and SVG as input, and lets you output PNG, JPEG, WEBP, or BMP with an adjustable compression quality setting. The conversion itself runs on HTML5 canvas operations inside your own browser tab. Nothing gets uploaded anywhere, which you can confirm yourself by opening your browser's Network tab while you drop a file in and convert it. You'll see the tool load once, and then no outbound request fires for the file itself. That's not a marketing claim, it's something you can watch happen.
Practically, that means you can drag your identified LCP image straight into the converter, pick WebP as the target, adjust the quality slider (85% is a reasonable starting point for photographic content, and you can push it lower and compare the visual difference yourself before committing), and download the result in a few seconds without ever leaving your browser tab or waiting on an upload queue. For a batch of product photos or a full blog's worth of header images, that local processing speed is the difference between an afternoon task and a five-minute one.
One honest limitation worth naming: this step handles format and compression, not responsive resizing. If your hero image is being served at 2400 pixels wide to a phone screen that's rendering it at 390 pixels, converting the format alone won't fix that particular waste. That's a separate fix, covered next.
Step 4: Make sure the browser isn't downloading more pixels than it needs
A correctly formatted image that's still oversized for its display container is still a slow image. If you're on WordPress, most modern themes and image plugins generate responsive variants automatically once you enable them. If you're hand-coding HTML, this means setting up a srcset attribute with a few width variants so the browser picks the smallest one that still fills the space it's rendering into.
While you're in the markup, do two more things that cost nothing and matter disproportionately. Add explicit width and height attributes to every image tag, which lets the browser reserve the correct layout space before the image finishes loading and prevents the page from jumping around as it renders, the exact behavior Cumulative Layout Shift is measuring. And apply fetchpriority="high" to your LCP image specifically, and only that one. Marking every image on the page as high priority tells the browser nothing is actually a priority, which defeats the entire point.
Step 5: Recheck the field data, not the lab score
Convert your image, push the change live, and resist the urge to immediately re-run PageSpeed Insights expecting your score to jump. The lab score will likely improve right away, but the Core Web Vitals field data section pulls from that rolling 28-day CrUX window, so it takes time to reflect what real visitors are now experiencing. Check back in Google Search Console under the Core Web Vitals report over the following weeks rather than refreshing a single lab test repeatedly and wondering why the number hasn't caught up yet.
Does any of this actually move your rankings
Worth being straight about this rather than implying page speed alone will fix a ranking problem. Core Web Vitals are a confirmed ranking signal, but Google has described them as functioning closer to a tiebreaker than a dominant factor, something that matters most when your page is already competing closely with others on relevance and content quality. If your content itself is thin or off-target for the query, a perfect LCP score won't rescue it. But when two pages are otherwise closely matched, and one of them is failing LCP because of a three-megabyte unoptimized hero image, that's a gap worth closing, and it's usually the cheapest technical fix available compared to a content rebuild or a link campaign.
There's a second reason this matters beyond the ranking algorithm itself. Slow-loading pages simply lose visitors before those visitors ever get far enough to judge your content, and that shows up in bounce rate and session duration regardless of what any algorithm decides. Fixing the image is worth doing even in a hypothetical world where Google didn't measure it at all.
The sequence, one more time
Find your actual LCP element in the field data section of PageSpeed Insights before touching anything. Understand which format tradeoff fits your audience, WebP as the practical default, AVIF where your traffic supports it, PNG and JPEG kept for their specific jobs. Convert locally rather than routing your files through a server you don't control. Fix the dimensions and priority hints in your markup so the format change isn't undermined by an oversized asset. Then wait for the field data to confirm it, instead of chasing a lab number that was never the thing being measured for rankings in the first place.