The embarrassing part
I make live streaming software. Bandwidth discipline is the core competency. It is, quite literally, the thing I am supposed to be good at.
My marketing website was shipping about 173 megabytes of video to every single visitor.
Not over a session. Not across many pages. Per visit, to load the page that explains why I understand bandwidth.
This is the audit that found it, what caused it, and, the part I think is actually interesting, why it survived so long without my noticing.
Two separate problems that looked like one
The complaint that started this was vague, which is how these usually arrive: things feel slow. Not one page. Not one action. A general impression.
Vague complaints are worth taking seriously, but they are dangerous to act on, because the instinct is to find one cause and declare victory. I went looking properly, and it turned out there were two entirely independent problems sharing no code whatsoever.
Problem one: the video payload. The site uses background video in several places... the kind that plays silently behind a headline. Visually it works well. The files behind it were the originals, straight from the editing process, served uncompressed and uncached to every visitor.
Problem two: sign-out was slow. Signing out of the platform took an oddly long time. The cause was unrelated to video: the operation was doing several round-trips to a server, one after another, each waiting for the last. For anyone geographically distant from that server, which describes most people using this, those round-trips stack into a visible delay.
Two causes, one symptom. If I had found either one alone and stopped, I would have fixed half a problem and been confused about why "slow" persisted.
Why 173 MB was invisible
Here is the mechanism, and it is worth understanding because it is extremely common.
Video files produced for editing are not video files intended for delivery. An editing master is optimised for quality retention and for being cut and re-cut without degrading. It is enormous by design, and that is correct... you want that file to be enormous while you are working on it.
A delivery file has a different job entirely. It needs to look good once, played straight through, over a network, on a device you do not control. Encoded for that job, the same content can be a fraction of the size with no perceptible difference.
The failure mode is simply forgetting to do the second step. The video looks right in the browser during development, so it passes review. Design review checks appearance. Code review checks the code. Neither has an obvious moment where someone asks "how large is that file," because the file is an asset, not code, and assets slip through the gaps between reviews.
The second amplifier: on a development machine, the files are local. There is no download. Everything is instant, always, no matter how large. The person best positioned to notice is structurally the last person who will.
The fix, and the numbers
I re-encoded the video masters for web delivery. The total went from about 179 MB to under 10 MB, a reduction of roughly 94%, with no visible quality difference on the page.
Then I fixed caching, which was the other half. A returning visitor was re-downloading everything, because nothing instructed the browser to keep it. With correct caching headers, the initial media payload for a page load dropped from roughly 173 MB to about 633 KB.
The deployment bundle came down as well, from 276 MB to 16.6 MB, which makes every future deploy faster too.
One discipline worth flagging, because it is the kind of thing that goes wrong quietly: every original file was preserved and verified byte-identical afterwards. Nothing was overwritten in place. When you are running a bulk transformation across a media library, the transformation is the easy part... not destroying your source material is the part that requires deliberate care. Re-encoding is lossy and irreversible. If the only copy of your master is the one you just compressed, you have not optimised your site, you have degraded your archive.
The sign-out fix
The second problem had a different shape and a different lesson.
Several operations were running one after another, each waiting for the previous one to complete, when they had no actual dependency on each other. That pattern is easy to write and easy to miss, because it reads perfectly naturally in code (do this, then this, then this) and on a fast local connection each step is nearly free.
The distance is what exposes it. Every round-trip costs real time when the server is far away, and sequential round-trips add up while independent ones would not. The fix is not clever; it is noticing that the steps were never actually sequential.
I would gently suggest that if you are close to your servers and your users are not, this bug exists somewhere in your product right now.
What I changed about how I work
The lasting outcome was not the megabytes. It was accepting that I am the worst-positioned person to notice my own performance problems.
My machine is fast. My files are local. My connection to my own infrastructure is short. Every structural advantage I have as the person building this is a blindfold for this particular class of bug, and no amount of caring about performance overcomes it, because you cannot perceive what your environment hides from you.
So performance became something I measure rather than something I feel. Media assets get checked for size before they ship. Page weight is a number I look at, not an impression I form.
The uncomfortable question I would leave with anyone building anything: when did you last load your own product on a normal connection, on an ordinary device, from where your users actually live? Not tested it... loaded it, and waited.
I had not, for a long time. It cost me 173 megabytes a visitor and a fair amount of pride.