Images are still the biggest reason your site is slow

We've run performance audits on dozens of sites at this point, across every industry a small business can be in, and one finding shows up almost every single time: images, not scripts, not fonts, not third-party trackers, are the largest single contributor to a slow page. It's the most common finding by a wide margin, and it's also the easiest one to fix.

This isn't a new problem, and the tools to solve it have existed for years. It persists anyway, because image handling tends to be invisible in normal workflow: a photo gets uploaded once, looks fine on the screen it was checked on, and nobody revisits it until a performance audit specifically flags it as a problem.

Modern cameras and phones produce enormous, high-resolution files by default, and it's genuinely easy to drag one straight into a content management system without thinking about whether a browser needs anywhere near that resolution for the space it'll actually be displayed in. The upload works, the image looks fine, and the hidden cost only shows up later, in load time nobody connects back to that specific decision.

Content editors are usually not the people who'll see the performance report later, so the incentive to compress an image before uploading it is weak in the moment and strong only in hindsight, once a slow page has already cost the business some amount of traffic or conversions nobody can precisely trace back to the cause.

Resized to the actual maximum display dimensions the layout will ever need, not the original camera resolution. Compressed to the point just before visible quality loss, which for most photographic images is a substantial reduction with no perceptible difference to a typical viewer. Served in a modern format that achieves smaller file sizes than older formats at equivalent visual quality.

Done correctly, this routinely cuts an image's file size by seventy to ninety percent with no visible quality loss to a typical visitor. That's not a marginal improvement; on an image-heavy page, it's often the single biggest lever available for improving load time, larger than any other single change we typically make.

Lazy loading, where images below the visible screen only load once a user scrolls near them, is a genuinely useful technique, and we use it by default. It's often misunderstood as a fix for unoptimized images rather than a complement to optimizing them properly. An enormous unoptimized image that loads lazily is still an enormous unoptimized image once it finally does load.

We treat lazy loading and proper compression as two separate, both-necessary steps, not alternatives to choose between. Skipping compression because lazy loading is already in place just delays when the cost gets paid, and it still gets paid, by whichever visitor ends up scrolling far enough to trigger the load.

Individual optimization passes help once, but the real fix is a workflow that optimizes automatically, so nobody has to remember to do it manually every single time. We set up automated image processing on every new build we deliver, so any image uploaded through the content system gets resized and compressed on the way in, without requiring the person uploading it to know anything about file formats.

This removes the dependency on training every future content editor, which never holds up reliably over time as staff changes and institutional memory fades. A system that enforces good defaults automatically outperforms a policy that relies on everyone remembering to follow it correctly, every time, indefinitely.

We ran this same audit across every site we'd delivered in the previous year, expecting our own work to be clean given how much we talk about this exact problem. It mostly was, with two notable exceptions where a client's own content team had uploaded large images directly after launch, bypassing the automated pipeline through a workflow we hadn't fully accounted for.

We fixed both, and more importantly, we fixed the gap in our own process that let it happen, adding a monitoring check that flags any image over a certain size threshold automatically, regardless of how it made its way onto the site. Auditing our own work with the same rigor we apply to client audits turned out to be genuinely humbling.

On a recent client site, unoptimized images were adding roughly three seconds to load time on a typical mobile connection, a range where a meaningful share of visitors abandon a page before it even finishes loading. Fixing image handling alone, without touching anything else on the site, cut that load time by more than half.

That's not a hypothetical improvement. It showed up directly in the client's own analytics as a measurable drop in bounce rate within the following month, tied specifically to the timing of that one change, which is about as clean a before-and-after as performance work ever produces.

Newer image formats offer meaningfully better compression than older standards at equivalent visual quality, and we use them by default now on every project. We still generate a fallback in an older, universally supported format for the small remaining share of browsers that don't handle the newer ones correctly, because a broken image is a far worse outcome than a slightly larger file size.

This dual-format approach adds a small amount of build complexity, handled automatically by the same pipeline that resizes and compresses on upload, so it costs nothing in ongoing effort once it's set up correctly. It's exactly the kind of one-time investment that keeps paying off quietly on every image uploaded afterward.

Image optimization is not a glamorous fix, and it doesn't require sophisticated engineering to get right. It requires attention, and a workflow that doesn't depend on everyone remembering to apply that attention manually every time.

It's also, consistently, the first thing we check on any new site, because the odds of finding a meaningful improvement here are higher than almost anywhere else we could look first.

If your site feels slow and you haven't checked your images specifically, that's very likely where we'd start looking too, before touching anything more complicated on the page.