Compressing Hero Videos
for the Web.

I shot a nice hero video the other day. 4K, drone, the whole thing. I wanted to use it as a looping background on a landing page and immediately ran into the question every developer eventually asks: how big can this file actually be before I'm wasting everyone's bandwidth?

The honest answer is 'it depends on what the video is doing,' but that isn't very useful. So here's the version with actual numbers.

Duration matters more than resolution

The first instinct is to drop the resolution, take a 4K master, export at 1080p, then 720p, then 480p, watching the file size shrink. That works, but it's the wrong dial to grab first.

A 60-second 4K hero video and a 15-second 4K hero video are wildly different problems. Cut the duration in half and you've roughly halved the bytes, and a hero loop that's 12 seconds long with a clean cut point looks just as polished as a 30-second one. Trim before you transcode.

Practical size targets

These are the rough budgets I aim for, depending on what the video is being asked to do:

• Background loop on a landing page: 5-15 MB. This auto-plays for everyone who hits the page. If they're on a phone in a parking lot, you're burning their data plan to decorate your hero. Keep it tight.

• Click-to-play hero: up to 50-70 MB is fine. The user opted in. A short, polished feature reel is allowed to actually look like a feature reel.

• Inline product demo or case-study clip: 10-25 MB. Short, focused, and ideally below the fold so it isn't blocking initial render.

If you're building a background loop and your export is sitting at 25-30 MB, that's a sign to either trim duration, drop to 720p, or both.

Codec choice: H.264 is still the default

H.264 in an MP4 container plays everywhere. Every browser, every phone, every smart TV. For 90% of web video work, this is what you ship and you stop thinking about it.

A 15-second 720p H.264 export should land somewhere around 5-10 MB at a reasonable bitrate. A 30-second 1080p H.264 export at moderate compression typically falls in the 20-30 MB range. If your numbers are way above that, your bitrate is too high or you have a long export.

H.265 / HEVC: better, but not free

H.265 (also called HEVC) compresses roughly 25-50% smaller than H.264 at the same visual quality. That's huge for a background loop, a 15 MB H.264 export can drop to 8-10 MB in HEVC.

The catch is browser support. Chrome on the desktop only plays H.265 if the user's GPU and OS provide hardware decode (Windows HEVC Video Extensions, modern macOS, recent Android). Firefox is similar. Safari has had it for years. So in practice, you can't ship H.265 as your only source. You need a fallback.

The pattern looks like this:

<video autoplay muted loop playsinline>
  <source src="hero.mp4" type='video/mp4; codecs="hvc1"'> <!-- H.265 -->
  <source src="hero.mp4" type='video/mp4; codecs="avc1"'> <!-- H.264 fallback -->
</video>

The browser walks the source list and picks the first one it can decode. Devices with HEVC support get the smaller file; everything else falls back to H.264. You do have to maintain two exports. That's the real cost, and for a one-off marketing site, that overhead is often not worth the bandwidth savings. I'd reach for it on a high-traffic site where the byte savings actually move the needle.

Animated WebP: the surprise option

WebP supports animation. Most people associate it with photos, but it can do everything a GIF does (short, looping, no audio) and produces files dramatically smaller than the equivalent GIF.

It's not a replacement for a real video file. Browsers won't progressively stream a WebP the way they do MP4. The codec isn't tuned for the kind of bitrate-quality tradeoffs you'd want on a 15-second hero, and you can't fade audio in. But for the specific case of 'I want this animated thing on the page and a GIF would be embarrassing,' animated WebP is a great fit. Think product micro-interactions, animated logos, short illustrative loops: anything that's currently a 4 MB GIF and could be a 400 KB WebP.

For a real cinematic hero, stick with MP4.

Streaming and the network tab

Browsers don't download a video file all at once. They issue HTTP range requests and grab chunks as needed. Open the Network tab on a video-heavy page and you'll see the same file fetched in pieces as playback continues. That's why a 30 MB video can start playing nearly instantly: the browser only needs the first chunk to begin.

This is also why total file size still matters even with chunked delivery. A user who scrolls past your hero after three seconds still pulled down those first chunks. Multiply by every page load on a slow connection and a bloated background video adds up to real money on someone's phone bill.

When to just embed YouTube

If the video is the content (a case-study walkthrough, a recorded talk, anything more than 30 seconds where the user is meant to actually watch it), embedding from YouTube or Vimeo is usually the right answer. They handle adaptive bitrate, multi-codec delivery, mobile optimization, and CDN distribution for free. You ship an iframe and stop thinking about codecs.

Self-hosted MP4 is for the cases where you specifically need autoplay, no player chrome, no related-videos popup, and no third-party tracking: a background loop or a tightly art-directed hero. Once you're past that, YouTube wins on engineering effort.

My actual workflow

For a typical client landing page with a background hero loop:

• Cut the source down to 10-15 seconds with a clean loop point. Most of the savings live here.

• Export 1080p H.264, target around 8 MB. If it comes in heavier, drop to 720p before going lower on bitrate, quality drops off a cliff faster with bitrate than resolution at this scale.

• Strip audio. A muted background loop with an audio track is just wasted bytes.

• Add a poster image so the hero has something to render before the first chunk arrives.

• Lazy-load below-the-fold videos and skip autoplay on mobile if the file is on the larger end.

And if I'm tempted to ship something heavier than 15 MB on autoplay, I take another look at the duration before anything else.