Cutting Our Homepage From 204 MB to 9.7 MB

Most case studies are about client work, told at a flattering angle. This one is about us, told at an unflattering one: the site you're reading right now once asked visitors to download roughly 204 MB to see the homepage. We're publishing the mistake alongside the fix because the fix is the kind of thing that applies to a huge number of business websites — and because "we found this on our own site" is a claim you can actually check.

The problem: a beautiful hero that cost 204 MB

Our homepage opens with a scroll-driven animation: as you scroll, the hero plays through a sequence like a flipbook. Under the hood, it's 145 individual image frames drawn onto a canvas, with your scroll position deciding which frame is showing. It's a technique used on some of the best-looking sites on the web, and when it's light, it feels great.

Ours was not light. As originally shipped, each of those 145 frames was a PNG of about 1.4 MB — roughly 204 MB for the full animation. On fast office broadband with caching, it looked fine, which is exactly how it survived long enough to ship. On a cellular connection it was unusable: no realistic mobile visitor waits out a download of that size, which means the most impressive thing on our homepage was, for a real chunk of visitors, the reason they never saw the homepage.

Why it happened

No exotic cause — just a default nobody questioned at the moment it mattered. Frame-by-frame scroll animation means every frame is a full image, so per-image weight gets multiplied by 145 before it reaches a visitor. The frames were exported as PNGs, a format built for perfect, lossless quality — the wrong trade for photographic animation frames drawn to a canvas during a scroll, where nobody can perceive lossless precision but everybody can perceive a stalled page.

We shipped it too heavy at first. That's the honest version. Each piece was reasonable in isolation — nice animation, standard technique, default export settings — and we didn't multiply 1.4 MB by 145 until after it was live. We build websites for a living, and this still got past us, which is exactly why "check the total page weight on a slow connection" is now a step, not an assumption. If it can slip past a shop that does this professionally, it can slip past anyone — and it does, constantly.

The options we considered

Three candidate fixes, and why we rejected two:

• Swap the frames for a video and scrub it with scroll. Video compression is superb, so the download would shrink dramatically. But scroll-scrubbing works by seeking, and video formats are built for playing forward, not for jumping precisely to arbitrary moments — seeking accurately across a long timeline is exactly what they're worst at. The result on real devices tends to be jerky, stuttering playback: a smaller download for a worse animation. Rejected.
• Remove the animation. The nuclear option, and the one performance advice often defaults to. It would have solved the weight instantly — by deleting the design. The animation is doing real work for the brand, and "make it fast by making it plain" is a false choice more often than people think. Rejected, happily.
• Keep everything, re-encode the frames. The frames were heavy because of their format, not their content. Modern formats store the same picture in a fraction of the space. If the frames could shrink enough, the animation, the code, and the design could all stay exactly as they were. This was the bet.

The fix

We re-encoded all 145 frames from PNG to WebP using ffmpeg, at quality 72. Two things worth translating out of jargon:

WebP is a modern image format that every current browser understands. For photographic content it stores a visually equivalent image at a small fraction of PNG's size, because PNG spends bytes guaranteeing pixel-perfect losslessness that no human can see in a moving animation frame.

Quality 72 is the dial that decides the trade. The scale runs to 100, where the encoder discards almost nothing; lower settings let it discard detail the eye is unlikely to notice. At 72, the frames in motion are indistinguishable from the originals to a human — the detail being discarded was, in a very real sense, detail we were forcing visitors to pay for without being able to perceive it.

The result: each frame went from about 1.4 MB to about 67 KB, and the animation code needed no rework at all — the only change to the loader was the file extension it requests. One re-encode pass, a one-line kind of change, and the whole thing is a single commit in our repository.

The results

Numbers first, then how we know they're true:

• About 204 MB of animation frames became about 9.7 MB — a 95% reduction.
• All 145 frames, the canvas rendering, and the scroll behavior are unchanged. The design paid nothing for the fix.
• After this and related accessibility work, the homepage scores 100/100/100 — Accessibility, Best Practices, SEO — in Lighthouse desktop testing.

We verified rather than assumed. We loaded the page against a local server and watched the network: all 145 WebP frames requested, 9.7 MB transferred, zero PNG requests — meaning nothing was still quietly fetching the old heavy files. We confirmed the canvas was actually rendering the new frames by sampling pixels from it, rather than trusting that a lack of errors meant a working animation. And because the change is one commit in our repository, the before and after aren't our recollection — they're diffable.

What this means for your site

The reason this case study is worth your time is that our mistake is the single most common thing wrong with business websites: image weight. Not code, not hosting, not some deep technical flaw — images exported at whatever size and format they happened to be in, multiplied across a page. A hero photo straight off a phone camera can weigh more than the rest of the site combined. We just did it 145 times at once, which made it dramatic enough to write about.

Two takeaways travel well:

• Formats matter more than people expect. The same picture, re-encoded, was one-twentieth the size with no visible difference in use. Nothing about our fix required rare expertise — it required noticing.
• You can usually keep the design. The common assumption is that a fast site must be a plain site, so businesses quietly accept slow ones. Our animation survived untouched. Before you sacrifice anything visual for speed, check whether the weight is really in the visuals' content — or just in their packaging.

How to check your own site

You can run the same check we should have run sooner, in about two minutes, using tools already in your browser:

1. Open your website in Chrome or Edge, then press F12 to open DevTools.
2. Click the Network tab, then reload the page.
3. Look at the bottom of the panel for the total — "transferred" is the number your visitors actually download.
4. Click the "Img" filter and sort by size. The biggest offenders will be sitting right at the top, with their formats visible in the list.
5. For the mobile truth, open the throttling dropdown (it usually says "No throttling"), pick a mobile preset, and reload again. That wait is your customer's wait.

A rough reading: if the total is in the low single-digit megabytes, you're in reasonable territory for a business site; if you see tens of megabytes, there's almost certainly an easy win hiding in the image list. If you'd rather not interpret the panel yourself, send us your web address and we'll take a free look and tell you plainly what we see — the same kind of look that's part of our web design work, and no, we won't turn it into a sales ambush. More guides like this one live in our resources hub.