Hero Video Loading Strategy

Date: 21 March 2026 Status: Research notes for implementation

Current file sizes are too big

The keeper clips are 17-22MB each for 10-15 seconds. That’s because Kling outputs at a high bitrate. For web, we need to compress them significantly - a 10-second clip should be around 3-5MB with modern encoding, and it’ll still look great. We can do that with FFmpeg before we build the site.

The loading strategy

The pattern is called progressive buffering, and here’s how it plays out:

The page loads with a tiny blurred poster image (maybe 10KB) of the first frame - this appears essentially instantly. The first video starts buffering immediately behind that poster. Within a second or two on a decent connection, the video starts playing and replaces the poster. While that first clip plays its 10 seconds, the browser quietly downloads the next clip in the background. By the time clip one ends, clip two is already buffered and ready. And so on down the chain.

Key technical bits

The first video in the sequence should be the smallest, tightest clip - ideally under 3MB. That’s the “door opener.” The rest can be slightly larger because they’ve got a 10-15 second head start while the current clip plays. For the HTML, each video needs muted autoplay playsinline (the playsinline is essential for iOS, otherwise Safari tries to go fullscreen). A small bit of JavaScript listens for when each clip hits about 80% played, then starts loading the next one.

Mobile considerations

On slow connections or when someone has data-saver mode on, we serve a static image instead of video. On mobile generally, we’d serve 720p instead of 1080p - roughly half the file size. The browser can tell us the connection speed, so we can make this decision automatically.

Cloudflare Pages specifics

The free/pro tier doesn’t really cache video files the way it does images and HTML. For a handful of compressed clips totalling maybe 30MB, it’ll be fine - traffic isn’t going to be Netflix-level. But for a more robust solution down the line, Cloudflare R2 (their object storage) or a service like Mux (which has an official Astro integration) would handle it. For launch, self-hosted compressed MP4s will work perfectly.

Practical plan for the build

  1. Compress each keeper clip to around 3-5MB using H.265 (with H.264 fallback for older browsers)
  2. Extract a blurred poster image from the first frame of the lead clip (about 10KB)
  3. Put the shortest, smallest clip first in the sequence
  4. Use a simple JavaScript component that listens for each clip ending and crossfades to the next
  5. On mobile or slow connections, fall back to the poster image with a play button

Astro architecture fit

The hero section can be mostly static HTML (fast), with a small interactive island that handles the clip sequencing. No heavy framework needed. Astro’s island architecture means the video sequencing JS only loads for the hero component, keeping everything else lightweight.