How I Cut My Website's Image Weight by 70% in an Afternoon

Updated on February 24, 2026

Last month, a friend texted me a link to my own portfolio site with a single message: "bro your site takes forever to load on my phone." I laughed it off, then pulled out my phone to check. He was right. A spinning loader for four full seconds before the hero image even showed up. I'd been building in Chrome on a fiber connection and had gone completely blind to the problem.

That evening I sat down with a coffee and a determination to fix it. By the time I finished, my total image payload had dropped from 11.2MB to just under 3MB. No lazy loading tricks, no CDN, no code changes — just a proper audit and a few hours of resize, crop, and format conversion work I'd been putting off for months.

Step One: Actually Seeing the Damage

I opened Chrome DevTools, went to the Network tab, filtered by "Img," and refreshed the page. The numbers were embarrassing. My hero image alone was a 4.1MB JPEG I'd exported from Figma at 3840×2160 pixels — full 4K, being displayed in a 1200px wide container. Three project thumbnails were PNGs exported at print resolution. One of them, a screenshot of a dashboard I'd built, was sitting at 2.3MB for a 400×300px slot on the page.

I made a quick spreadsheet. Filename, actual pixel dimensions being rendered, file size, file format. Six images total. Combined weight: 11.2MB. The largest single file was nearly the size of a paperback novel in digital bytes. The whole exercise of writing it down made the problem feel concrete in a way that vague "my site is slow" feelings never had.

The Format Problem Nobody Talked To Me About

I'd exported everything as either JPEG or PNG because those were the options I understood. JPEGs for photos, PNGs for anything with transparency. This is fine advice from about 2015. In 2024, WebP exists and browser support is effectively universal — I checked caniuse.com and it's above 97% globally.

WebP gives you the best of both worlds: lossy compression comparable to JPEG (but usually 25–35% smaller at the same perceptual quality), and lossless with transparency support to replace PNG. For my use case — a portfolio with no IE11 users — there was genuinely no reason to ship JPEGs at all.

I used Squoosh (squoosh.app, Google's free browser-based tool) for the conversion. You drag an image in, pick WebP as the output format, adjust the quality slider while watching a before/after comparison split-screen, and download. No software to install. The quality slider is genuinely useful because you can see exactly where compression artifacts start appearing — for most of my images, I could take quality down to 75-80 and the result was visually indistinguishable from the original at normal viewing distances.

My 4.1MB hero JPEG became a 380KB WebP at quality 78. Same visual impression. Different universe in terms of file size.

The Resize Problem Is Separate From the Format Problem

Here's something that took me an embarrassingly long time to understand: format conversion and resizing are independent problems, and you need to solve both.

Converting that 3840×2160 image to WebP without resizing it would have brought me to maybe 2.1MB — better, but still wasteful. The browser was displaying it at 1200px wide on desktop and maybe 390px wide on mobile. Sending a 3840-pixel-wide image to a 390px container means the browser downloads all that pixel data and then throws most of it away. You've paid the bandwidth cost for nothing.

My process: I used ImageMagick on the command line for batch resizing (if you're not comfortable with terminal, GIMP or even Photoshop's "Export for Web" dialog work fine). For the hero image, I decided on a max display width of 1400px — enough for wide monitors without absurd overkill — and ran:

magick hero.jpg -resize 1400x\> hero-resized.jpg

The \> flag means "only shrink, never enlarge," which is a nice safety net. Then I took that resized file into Squoosh for the WebP conversion. Two-step process, but each step has a clear job.

For the project thumbnails, I cropped too. The dashboard screenshot was showing fine detail that nobody could see at thumbnail size anyway — it was just visual noise. I cropped to the most visually interesting part of the UI (a chart and a couple of metric cards), resized to 600×400, converted to WebP. That 2.3MB file became 67KB. I had to double-check my math. Sixty-seven kilobytes.

Where Cropping Matters More Than You'd Think

Resizing scales the entire image down uniformly. Cropping lets you make an intentional decision about what part of the image actually matters for its context on the page.

I had a team photo on my About page — a wide shot with eight people, me on the far left. On mobile, where the image rendered at maybe 320px wide, you basically couldn't distinguish any faces. The photo was communicating almost nothing except "group of people, blurry." I cropped it tighter to the three people centered in the frame (including me), which made the faces actually readable at mobile widths. The image was now doing its job better and it was smaller because I'd removed pixels I didn't need.

This is the piece that took more thought than the technical conversion steps — asking "what does this image actually need to show at the size it will be displayed?" The answer is often "less than you think."

The Final Numbers

After an afternoon of work — and I want to be honest, this was maybe three hours total, not a heroic multi-day effort — here's where things landed:

  • Hero image: 4.1MB JPEG → 380KB WebP (cropped to 1400px wide)
  • Project thumbnail 1: 2.3MB PNG → 67KB WebP
  • Project thumbnail 2: 1.8MB PNG → 52KB WebP
  • Project thumbnail 3: 1.4MB PNG → 48KB WebP
  • About page team photo: 890KB JPEG → 103KB WebP
  • Blog header image: 760KB JPEG → 89KB WebP

Total before: 11.25MB. Total after: 739KB. That's a 93% reduction in image weight, though I'd called it 70% in the title because that accounts for the slight overhead of me adding a couple of `<picture>` elements with fallbacks for ancient browsers (which pushed my effective page weight up slightly).

PageSpeed Insights score on mobile went from 41 to 79. Largest Contentful Paint — which is the metric Google uses to measure when your main content is visible — dropped from 6.2 seconds on a simulated 4G connection to 1.8 seconds.

What I'd Do Differently If I Were Starting Fresh

The obvious answer is "not let this accumulate in the first place." But more practically: I'd set up a simple script or use a tool like Sharp (Node.js library) in my build pipeline to automatically convert images to WebP and resize them to predefined max dimensions on deploy. Then this problem can never creep back in.

I'd also be more deliberate about art direction from the start — thinking about how an image looks at mobile widths before I decide what to include in the frame, not after. The best crop for a 1400px hero image and the best crop for a 390px mobile image are often different, and the HTML `<picture>` element lets you serve different source images at different breakpoints. I used it for the hero image and it added maybe ten minutes of work.

Tools I Actually Used (Short List)

Squoosh (squoosh.app) — browser-based, free, no install, great quality preview. Best for one-off conversions where you want visual control.

ImageMagick — command-line, handles batch operations, scriptable. Essential if you have more than a handful of images. The learning curve is real but the docs are thorough.

Chrome DevTools Network tab — for the initial audit. Filter by Img, check the Size column. The numbers will probably make you wince.

PageSpeed Insights (pagespeed.web.dev) — free, gives you a before/after benchmark so you can see what actually changed. More trustworthy than a gut feeling.

That's genuinely it. No paid tools, no subscriptions, no plugins. The whole fix was technique and time, not money.

The Part That Still Stings

What gets me is that I was proud of that site. I'd spent weeks on the typography, the animation details, the color palette. And then I was shipping it with 11MB of images that buried all of that work under four seconds of blank screen. First impressions happen before any of the design choices register. If the site is slow, the design doesn't matter yet — and for a surprising number of visitors on mobile connections, the site was just slow.

The image audit felt unglamorous compared to the design work. It was basically digital housekeeping. But the impact on actual user experience was larger than anything else I'd done to that site. That's the kind of thing that recalibrates how you think about where effort is worth spending.

If you haven't done this audit on your own site, open DevTools right now. The Network tab doesn't lie.