We're building short films alongside some of our articles. They're hand-drawn, narrated, and scored. They play right on the page, without a video file and without anybody's player.

That isn't a style choice. The usual way to put a video on a website stores it, copies it into five sizes, ships it from someone else's servers, and bills for every play. That's the exact pattern this publication exists to argue against. So before the first film goes up, here's the case for building it the other way, and where our own version still falls short.

Every play is a fresh shipment

Video already eats most of the internet. Sandvine's 2024 Global Internet Phenomena report puts on-demand streaming at 54% of downstream volume, 7.9 GB per subscriber per day.

And it isn't just bandwidth. Every upload gets re-encoded into a ladder of sizes and formats before anyone watches it. At YouTube's scale, more than 500 hours of video a minute, that work got so heavy Google designed its own video chips. YouTube says they're up to 20 to 33 times more compute-efficient than the system they replaced, and analysts estimate they took the place of somewhere between 4 and 33 million Intel CPUs. Meta built its own too, and notes that each new codec generation makes files about 50% smaller at 10 times the computing cost. Video isn't just filling the pipes. It's filling data centers.

That's the backdrop. The bill is the part that lands on you.

A video file doesn't get cheaper with use. Every play sends the whole thing across the network again, and the CDN charges by the gigabyte. On CloudFront, after the first free terabyte each month, North American delivery is $0.085 per GB. That rate doesn't care whether the viewer watched to the end or left after ten seconds of buffering.

Here's the arithmetic for our own first film. It runs just under four minutes. Exported as a native MP4, it comes to 83.3 MB. A thousand full plays is about 83 GB, or roughly $7 past the free tier. A viral week turns that into a line item. The bill grows with your success and never stops while the file is up.

Then there's storage. A hosted video is never one file. Players expect a ladder of renditions so phones on bad connections get something watchable. Five sizes of one film sit in a bucket, billed monthly, for as long as anyone might link to it.

Somebody else's player, somebody else's terms

Most sites skip the bill by handing the video to a platform. That swaps a cost you can see for a dependency you can't control.

In March 2022, Vimeo told creators who went over its bandwidth thresholds to move to custom plans or leave. Illustrator Lois van Baarle had been paying $200 a year. Her most-watched video had about 815 views, which still put her in Vimeo's top 1% for bandwidth. She was offered a $3,500-a-year plan and a week to decide. Vimeo's shareholder letter that year said it plainly: "We are a B2B solution, not the indie version of YouTube."

Then the platform itself changed hands. Bending Spoons bought Vimeo for $1.38 billion in November 2025 and has run two rounds of layoffs since. Nobody's videos have gone dark. But every site that embeds Vimeo now depends on a new owner's plans for a product it just cut back.

When a host does go away, the embeds go with it. Snap shut Gfycat down on September 1, 2023 and deleted everything on it. Every article that had embedded a Gfycat clip got a broken box in its place.

The free option has its own price, paid by your reader. A standard YouTube embed pulls 1.3 MB across 32 requests before anyone presses play, Chris Coyier measured in 2024. A second embed on the same page adds the same again. That's Google's code, running on your page, deciding what your reader sees next.

Not a carbon story

It would be easy to dress this up as a climate argument. It mostly isn't one. The IEA's corrected estimate puts an hour of streaming at about 0.077 kWh and 36 g of CO2, roughly a hundred metres in a petrol car. And 72% of that energy is the viewer's screen and device, not the network or the data centre.

That cuts both ways for us. Shipping fewer bytes saves very little carbon. And a film drawn live on the reader's device makes that device do more work, not less. Phones decode video in dedicated hardware that sips power. Our films draw every frame in the browser. Whether that costs more battery than playing an MP4 is something we haven't measured yet, and we won't claim otherwise until we have.

The arguments that do hold are the reader's data plan, their load time, and our bill.

A film that's mostly instructions

Our films aren't recordings. They're small programs that draw the picture as it plays. We build them with airbrx's story kit, the same one behind its own explainers. The only real media file is the narrator's voice.

Until someone presses play, the article carries only a card: a title, a length and a button. Here's what a reader downloads for one full play of the film:

WhatSize over the wireWhen it loads
Drawing code, music engine, script and timingabout 150 KB compressedwhen someone presses play
Voiceover (M4A)1.1 MBas it plays
Totalabout 1.3 MB 

Set that against 83.3 MB for an MP4 of the same film. The whole film weighs about what an empty YouTube player does before anyone presses play. A thousand full plays is about 1.3 GB, comfortably inside CloudFront's free terabyte. At list price it would be about 11 cents.

The score costs nothing to ship because it's never recorded. Each film describes its music as data: a key, a mode, a tempo, a chord progression, a level for each instrument. The reader's browser plays it. The music follows the script's clock, so it changes section when the narrator does.

The script is the single source of truth. The same file sets the timing, the captions and the transcript. Fixing a typo or a figure means editing one line and redeploying a text file. Nothing gets re-rendered, re-uploaded or re-encoded. The picture is drawn live too, so it's sharp at any size and follows the reader's light or dark setting. A video file can't do either.

None of it needs a server. It's static files on the same CDN as the article. When nobody's watching, it costs nothing.

What our own scorecard says about it

We ran the film's player against our flat-stack scorecard, the same checks we point at everyone else. The first build didn't pass clean. Here's what it flagged, and what we changed.

  • Code from other people's servers. The music engine loaded from jsDelivr and the typefaces from Google Fonts, neither with an integrity hash, so whoever ran those CDNs controlled part of our page. Now every file comes from the same place as the article.
  • Page weight. About 250 KB of uncompressed JavaScript sat between the scorecard's pass line (100 KB) and its fail line (500 KB). Now the player loads only when someone presses play. Until then the article carries a card: a title, a length and a button.
  • A loop that never rested. The player redrew the picture 60 times a second, even when the film was paused or scrolled out of view. Now press pause, or walk away, and the drawing stops. Nothing runs while nobody's watching.
  • Work done on the reader's phone that we should do once. To balance the voice against the music, the player decoded the whole voice track into raw audio in memory. Now how loud the voice is, and where it speaks, is worked out once, when we make the film. The voice plays as it arrives.

When you should still ship the MP4

This only works because our films are drawings. Lines, shapes, type and a voice can be described as instructions. Camera footage can't. Neither can screen recordings or anything with a face in it. For that, a video file is the right tool, and a plain <video> tag on your own storage beats a platform embed on weight, privacy and permanence.

It doesn't travel either. LinkedIn, X and YouTube want a file, so the kit still exports MP4. That's one render, made on our machine, uploaded where the audience already is. It's never served from our site.

And it costs effort up front. A drawn film takes more work to make than a screen recording, and the toolkit is code someone has to maintain. That's a dependency too, just one we chose and can read. Every dependency is a decision. This one we made on purpose.

The first one runs with this article.

Sources