My sign-in button said "not configured". The cause was a 3 MB video

The thing I was building
I build small single-purpose AI tools, and this one is a photo-to-video generator: https://burningbridgesai.info . It takes one photo and renders a ~20-second video with the person in it, in a scene the model is handed as a reference clip. That is why there are two multi-megabyte videos in the markup at all, and why I would ship the reference at half the bitrate if I were starting today.
Have you run into the "script starved by media" one? I am curious what you did with it.
Disclosure: this post was written with AI assistance. The incident, the code and every number in it came from my own project's logs and measurements; the AI helped with the prose, not with the findings.
Last week my own site told me that sign-in was not configured.
It was configured. The endpoint the button reads was answering correctly, with the right URL and a valid public key, and a terminal showed me all of it in nine seconds. Which is why I spent the next hour looking in the wrong place: the message wasn't reporting a configuration problem, it was reporting that a fetch had never arrived, and my own code had decided to describe that as a setup mistake.
The actual cause was two videos.
The bit I had wrong in my head for years

controls when a script runs, not how urgently it is fetched.
That's the whole bug. defer means "execute after the document is parsed, before DOMContentLoaded". It does not put the file at the front of any queue. A deferred script competes for bandwidth with every image and video the markup asks for, and on a slow connection it can lose.
So my page's only script sat behind:
·two <video> elements marked preload="metadata", which I had always read as "just grab the header";
·five gallery posters marked loading="lazy", which I had always read as "don't touch this until it's nearby".
Both readings were wrong. preload="metadata" is still a request for a multi-megabyte file. And "lazy" is a hint, not a promise: on a slow connection Chrome widens its loading threshold on purpose, so images a screen and a half below the fold start fetching during page load anyway.
What it looked like
I throttled the browser to 50 KB/s with 300 ms of latency and recorded the requests:

Same page, same commit. The purple bar is the script the whole page depends on.
The script was requested at 2.3 s and finished at 9.3 s. The session request it makes never came back inside a 24-second test window. Anyone on that connection who pressed Sign in got told their configuration was broken.
From a terminal the same two files look almost funny: the 39 KB script comes back from the CDN cache in 240 ms, while one 3 MB clip took 192 seconds.
Three changes

1. Stop the videos from starting while the document is parsing. <video id="heroVideo" src="…-9x16.mp4" poster="…-9x16.jpg" preload="none" loop playsinline muted></video> preload="none" means no fetch until something calls play(). The script now calls it only after the session request has settled, so the two never race.
2. Fetch the critical script as early as the parser can. <script src="assets/app.js" defer fetchpriority="high">

It is still defer, so it still runs after parsing and sees the whole DOM. What changed is the fetch: from the last line of the body to the first kilobyte of the head. Script fetch went from 2.3 s to 9.3 s down to 0.45 s to 3.2 s, and the session was ready at 6.7 s instead of 9.7 s. Still slow, because the link in the test was 50 KB/s.

1. Stop the message from lying. My handler treated "no session yet" the same as "no configuration". It now retries once and says so, and the configuration complaint is reserved for the case where it is true. That is the change I would keep if I could keep only one. What I'd tell myself before this week ·defer buys you DOM readiness, not bandwidth. If the page cannot work without a script, give that script the network and keep the heavy files out of its way — a