Most site owners chase page speed by upgrading hosting, installing caching plugins, or arguing with a developer about JavaScript bundles. Meanwhile the heaviest thing sitting on the page rarely gets touched: the images. A single unoptimized photo can outweigh every script and stylesheet on the page combined, and it's usually the first thing a visitor's browser has to wait for. Slow images delay Largest Contentful Paint, frustrate mobile visitors on patchy connections, and quietly cost rankings and conversions. Fixing this rarely needs a developer or a paid plugin — it needs the right format, the right dimensions, and the right compression, applied before the file ever reaches your server.
The Real Reason Your Site Feels Slow
Open any page speed report and the single largest resource is almost always an image. Images still make up roughly 40% of a typical page's total weight, even after years of WebP adoption and lazy loading becoming standard browser behavior. The median desktop page now weighs around 2.6MB, and mobile isn't far behind at roughly 2.3MB. A large share of that weight is one or two photos that were never resized or compressed before upload.
This matters specifically because of how Google measures speed. Largest Contentful Paint (LCP) — one of the three Core Web Vitals, alongside Interaction to Next Paint and Cumulative Layout Shift — tracks how long it takes the biggest visible element on the page to render. On most pages, that element is an image: a hero photo, a product shot, a banner. Ship that file at 2MB instead of 200KB and you've built a slow LCP into the page before a single stylesheet loads.
The useful part is that image weight is the easiest of the three Core Web Vitals to fix. Restructuring JavaScript to pass Interaction to Next Paint can take a developer weeks. Compressing and converting images takes an afternoon, and the size reduction is often steep enough to move LCP from "poor" to "good" without touching anything else on the page.
How to Check If Images Are Your Bottleneck
Before compressing anything, confirm images are actually the problem. Run the page through PageSpeed Insights or Lighthouse and look at the flagged opportunities — oversized images and inefficiently encoded images are usually near the top of the list when they're an issue. These lab results are useful for diagnosis, but Google grades your actual ranking using field data from the Chrome User Experience Report, measured at the 75th percentile of real visitors over a rolling 28-day window. A perfect Lighthouse score means little if a quarter of your real mobile visitors are still stuck on a slow connection.
For a faster, more direct check, open Chrome DevTools, go to the Network tab, reload the page, and sort by size. Anything over 300-500KB is worth a look, especially if it's displaying at a fraction of its native resolution. The same panel will usually show you which image is acting as the LCP element — that's the one to prioritize first, since it directly affects your Core Web Vitals score.
WebPageTest is a useful second opinion, particularly for testing on simulated slow connections and older devices — the kind of real-world conditions a fast office connection won't show you.
JPG vs PNG vs WebP: Which Format Actually Loads Faster
Format choice alone can cut image weight in half before you touch a single compression slider. Here's how the three formats actually compare for web use:
| Format | Best for | File size vs. JPG | Transparency | Browser support |
|---|---|---|---|---|
| JPG | Photos, no transparency needed | Baseline | No | Universal |
| PNG | Logos, icons, screenshots | 2-5x larger for photos | Yes | Universal |
| WebP | Nearly everything | 25-35% smaller | Yes | All modern browsers |
JPG has been the default for photographs for decades because it compresses well and is universally supported, but it's a lossy format with no transparency support. PNG is lossless and supports transparency, which makes it the right call for logos, icons, and screenshots — but that same losslessness makes it a poor choice for photographs, where file sizes balloon compared to JPG or WebP for no visible benefit. WebP does both jobs at once: it typically produces files 25-35% smaller than an equivalent-quality JPG, while also supporting transparency like PNG. Browser support has been effectively universal since Safari added WebP support in 2020, which means there's rarely a technical reason left to avoid it.
You'll increasingly see AVIF mentioned as an even smaller format — in some benchmarks it beats WebP by a wide margin on high-resolution images. Encoder tooling and consistent support are still less mature than WebP's, though, which keeps WebP the safer default for most sites today. For the full breakdown of when each format wins, see our complete JPG vs WebP vs PNG comparison.
The Dimension Mismatch Nobody Notices
Compression settings get most of the attention, but dimension mismatches waste just as much bandwidth. A phone camera shoots at 3000-4000 pixels wide by default. If that file gets uploaded straight into a content block that displays images at 600px wide, the browser still downloads the full 4000px file — CSS only changes how large the image appears, not how much data was transferred to display it.
The fix is straightforward: resize the image to roughly twice its maximum display width before uploading, to account for high-density (retina) screens, and no larger. A photo that will never display wider than 800px on any device doesn't need to be 4000px across — resizing it down to around 1600px removes the vast majority of the wasted weight with zero visible quality loss, since no screen will render it any larger than that.
Responsive images, using the srcset attribute to serve different file sizes to different screen widths, solve this more precisely and are worth implementing if you have developer access. But resizing before upload gets you most of the benefit with none of the added complexity, and it works on any platform — WordPress, Shopify, Squarespace, or a static site with no CMS at all.
How Much Compression You Can Get Away With
Quality settings follow a curve, not a straight line. Dropping from 100% quality to around 80% typically cuts file size by half or more, with a difference in the final image that's imperceptible to almost anyone scrolling past it at normal speed. Below roughly 60% quality, that curve flattens out — you stop saving much file size, and start introducing visible artifacts: blocky edges, color banding, and mushy detail in areas with fine texture like hair, foliage, or text.
The practical sweet spot for most photographic content sits between 75% and 85% quality, whether you're exporting as JPG or WebP. That range removes the vast majority of unnecessary file weight while staying visually indistinguishable from the original at normal viewing sizes. The only way to know your specific sweet spot is comparing a compressed version against the original at full zoom — not by eye at a glance, but side by side, looking specifically at edges and fine detail.
Graphics like logos, icons, and screenshots with sharp edges and flat color don't follow this curve the same way — they belong in a lossless format like PNG regardless of file size, since even mild lossy compression introduces visible fuzziness around hard edges that a quality slider can't fix.
The Free Fix: Compress and Convert Before You Upload
None of this requires new software, an account, or a monthly subscription. Running an image through a browser-based compressor before it ever reaches your CMS or file host takes seconds, and because the processing happens entirely client-side, in the browser itself, the file never leaves your device to hit someone else's server first.
Compress JPG, PNG, and WebP files right in your browser — free, no login, nothing ever uploaded to a server.
The practical workflow: resize to the actual display dimensions, run it through Image Compressor at roughly 75-85% quality, and — if the platform supports it — convert to WebP using JPG to WebP or PNG to WebP for the extra 25-35% saving on top of compression. For a typical blog post or product page with a handful of images, this whole process takes a few minutes and can cut total page weight by more than half.
Make this the last step before every upload, not an occasional cleanup project. The images already live on your site got the "fix it later" treatment once; the ones you haven't uploaded yet don't have to.
Common Mistakes That Undo Your Compression Work
A few habits quietly cancel out the effort of compressing images in the first place.
Indirectly, yes. Core Web Vitals — including Largest Contentful Paint, which is often decided by your biggest image — are a confirmed part of Google's page experience signals. They won't outrank a page with better content and stronger authority, but between two similar pages, the faster one has a real, measurable edge. Google evaluates this using real visitor data from the Chrome User Experience Report, not a lab test, so the improvement has to hold up for actual people on actual devices, not just a developer's fast office connection.
There's no single number that fits every use case, but rough targets that work well in practice: keep hero or banner images under 200-300KB, in-content photos under 100-150KB, and thumbnails under 50KB. Reaching those targets usually just means resizing to actual display dimensions and running the file through Image Compressor at 75-85% quality. If an image still won't fit that range without visible quality loss, the problem is often the source photo's dimensions rather than the compression setting.
Yes. Every major browser — Chrome, Firefox, Edge, and Safari — has supported WebP since 2020, when Safari added support as the last major holdout. There's essentially no technical reason left to avoid it for a general audience site, though it's still worth keeping a JPG or PNG fallback if you're serving a very old browser base or exporting images for use outside the browser, like print materials or PDFs.
Resize first. Compression reduces file size at a given resolution, but it can't undo the waste of shipping a 4000-pixel-wide photo to a spot on the page that only displays it at 600 pixels. Resize to the actual display size first, then compress. The two steps solve different problems: resizing fixes wasted resolution, compression fixes wasted detail within that resolution. Skipping either one leaves real savings on the table.
At the 75-85% quality range recommended for most photos, no — the difference is imperceptible at normal viewing sizes and zoom levels. Visible quality loss, like blocky edges or muddy detail, tends to show up only once you drop below roughly 60% quality, which is well past the point where most of the file-size savings have already been captured. The safest approach is comparing the compressed version against the original side by side before publishing.
A little, and it helps privacy a lot more. EXIF metadata — GPS coordinates, camera model, timestamp — typically adds anywhere from a few kilobytes to a few dozen kilobytes per photo, so it's a minor contributor to page weight next to resizing and compression. The bigger reason to strip it is that GPS metadata embedded in a photo can reveal exactly where it was taken. It's a five-second step worth taking regardless of the size savings.