How I Cut My Website's Page Weight in Half With Better Images

The Day I Finally Checked My Page Speed

I'd been ignoring the little voice in my head for months. The one that whispered your site feels slow every time I loaded it on my phone while waiting for coffee. I kept telling myself it was the café wifi. It wasn't the café wifi.

Last November, I finally ran my photography portfolio through Google PageSpeed Insights. The score came back: 31 on mobile. Thirty-one. Out of a hundred. I sat there for a good thirty seconds just staring at the number like it had personally insulted me.

The biggest culprit, taking up nearly 80% of my page weight? Images. Obviously. I'm a photographer — my site is basically one long gallery. But what I didn't realize was how badly I'd been handling those images. We're talking 4MB JPEGs exported straight from Lightroom, dropped into WordPress with zero optimization, living their best uncompressed lives on a server in Frankfurt while visitors in Manila waited six seconds for the fold to load.

Over the next two weekends, I went through a proper image audit. My total page weight dropped from 8.4MB to 3.9MB on my heaviest page. Load time on mobile (tested on a throttled 4G connection) went from 9.1 seconds to 4.2 seconds. Here's exactly what I did.

Step One: Actually Measuring What You Have

Before touching a single file, I needed to understand the problem. I used three tools in combination:

• WebPageTest.org — free, detailed waterfall charts showing which images loaded when and how large each one was.
• Chrome DevTools Network tab — filtered by "Img" type, sorted by size descending. This showed me instantly that I had one hero image at 3.8MB that I'd somehow never noticed.
• Screaming Frog — crawled my whole site and exported a list of every image URL with its file size. This was the most useful thing. Seeing a spreadsheet of 140 images, sorted by size, makes the problem very concrete very fast.

What I found surprised me. It wasn't just the obvious hero images causing problems. I had a "client logos" section with PNG files of company logos that were each 400-600KB. Logos. Tiny, mostly-white logos. One of them was a 512KB PNG that displayed at 80x40 pixels on screen. That's criminal.

The Format Switch That Made the Biggest Difference

I'd heard about WebP for years and kept putting it off because it sounded like more work than it was worth. It is not more work than it's worth. I converted my entire image library to WebP using Squoosh (Google's browser-based tool, completely free) and the results were genuinely shocking.

My typical travel photo — a 3000px wide JPEG at about 1.8MB straight from camera — came out as a WebP at roughly 280KB at quality 82. Same visual quality to my eye. Actually, I did a proper A/B pixel comparison on a few shots and couldn't find meaningful differences at normal viewing sizes.

For the logos and graphics with transparency, I switched from PNG to WebP as well. That 512KB logo PNG became a 24KB WebP. I'm not exaggerating — 24KB. For a logo.

The one exception: I kept JPEG for a handful of images that needed to be downloadable by clients who might be using older software. WebP support in image editors still isn't universal.

Resizing: The Problem Nobody Talks About

Here's something I didn't fully appreciate before this project: serving a 4000px wide image that displays at 800px wide is wasteful even if the file is compressed. The browser downloads all those pixels and then scales them down visually. You're paying bandwidth costs for resolution the user never sees.

I went through my site and documented the actual display sizes for every image at different breakpoints. My hero image, for example, maxes out at 1440px wide on large screens. On mobile it's 390px. I was serving one 3800px file for both.

I created three versions of each major image:

1. A full-width version capped at 1600px (for desktop)
2. A medium version at 800px (for tablets)
3. A small version at 400px (for phones)

Then I implemented srcset in my image tags so the browser picks the right one automatically. If you're on WordPress, the good news is it generates these automatically for new uploads — but it won't retroactively fix old images unless you use a plugin like Regenerate Thumbnails.

Lazy Loading: The Easy Win I Should Have Done First

This one took me about forty minutes to implement across my whole site and it had an immediate impact on that initial page load score.

Adding loading="lazy" to images below the fold means the browser doesn't bother downloading them until the user actually scrolls close to them. For a gallery page with 60 images, only the first few rows get loaded immediately. The rest load on demand.

One thing I got wrong the first time: I added lazy loading to my hero image and logo in the header. Don't do this. Anything visible without scrolling — "above the fold" — should load eagerly. Lazy loading those actually made my LCP (Largest Contentful Paint) score worse because the browser deprioritized the hero image. I had to go back and remove loading="lazy" from those specific elements.

The Thumbnail Problem

My portfolio homepage had a grid of 24 project thumbnails. Each thumbnail displayed at roughly 300x200px. I had been serving full-resolution gallery images — 2400x1600px — for those thumbnails and just letting CSS shrink them down.

I generated proper thumbnail versions (300x200, WebP, quality 75) for each project. The homepage went from pulling 11MB of images to pulling 980KB. That single change probably accounts for more improvement than anything else I did. Thumbnails should be small. They sound obvious in retrospect but I genuinely had not thought about it.

Compression Settings: Quality vs. Size

Most people set JPEG quality at 80-85% and call it a day. That's reasonable but not optimal. I spent some time doing visual comparisons at different quality levels and came up with settings that work specifically for my type of content:

• Hero/feature images: WebP at quality 85. These get scrutinized, so I keep quality slightly higher.
• Gallery thumbnails: WebP at quality 72. At small display sizes, you genuinely cannot tell.
• Background textures and decorative images: WebP at quality 60. Nobody is pixel-peeping a subtle background texture.
• Logos and icons: SVG where possible, WebP otherwise at quality 80.

The key insight is that quality settings aren't one-size-fits-all. A photograph of a person's face at quality 65 might show visible artifacts around eyes and skin. A blurry bokeh background at quality 65 looks identical to quality 90 because there are no sharp edges to artifact on.

What I Didn't Do (And Why)

I looked into AVIF format — the successor to WebP with even better compression. The numbers are impressive. But browser support, while improving, still isn't universal enough for a client-facing portfolio site where I have no idea what browser someone is using. I'll revisit this in a year.

I also considered a CDN with automatic image optimization (Cloudflare Polish, Imgix, Cloudinary). These are genuinely great solutions, especially for larger sites. For my 140-image portfolio, the manual approach was faster to implement and gave me more control. If I had a site with thousands of images being added regularly, I'd go the CDN route without question.

The Results, Three Months Later

My PageSpeed score on mobile went from 31 to 67. That's not perfect — I still have some JavaScript issues to sort out — but it's a real, meaningful improvement. My Google Search Console shows average page experience has improved, and bounce rate on my portfolio page dropped about 8 percentage points, though that could be coincidence.

The part that surprised me most: the process wasn't as tedious as I expected. Once I had a system (measure → convert → resize → implement srcset → lazy load below fold), each page took maybe an hour to fully optimize. The first page took three hours because I was figuring out the workflow. Pages five through ten took maybe 45 minutes each.

If your site has images and you've been avoiding the optimization rabbit hole, start with Screaming Frog or just the Chrome DevTools Network tab. Sort by size. Look at the top five images. Convert them to WebP. Serve correct sizes. Add lazy loading below the fold. That alone will probably get you 60-70% of the gains I got, in about two hours of actual work.

Your café wifi isn't the problem. It wasn't mine either.