← Back to context

Comment by lelandfe

4 days ago

Just a quick heads up that the homepage video is ~24MB over the wire, even on a phone. That might actually be a challenge if someone's WiFi is down and they're trying to get support over cellular.

(Huge kudos for this project in general)

Thanks! It's actually much less for the bandwidth-constrained, I use adaptive coding. If you have the bandwidth though...

That said, I know our page isn't particularly lightweight anyway, I've been pretty focused on expansion efforts and haven't had much time to update & work on the site.

  • This page was 9 seconds of white screen before the entire thing loaded at once. I'm on Starlink. Hopefully you get a chance to correct this in the future, as I'm really supportive of projects like yours, but if the page was linked from a top-5 article or something I would have hit the back button already.

    • Totally - we're not advertising yet and usually only dealing with very local traffic at the moment, didn't expect to get tens of thousands of hits from linking to it from a hackernews comment!

      The backend is an azure appservice running on a single low-spec worker at the moment, wasn't planning on enabling scaling before doing a hard-launch but here we are.

      2 replies →

    • It's a great marketing strategy. People without broadband access will truly feel it when they visit.

  • Yes the white page with nothing else mad me think it was broken.

    • It's currently running on a single azure appworker, you might've hit it during a service autoheal/reset. There's a fair bit of overhead for every connection since it's designed for our subscribers to use and get realtime stats on their connection, was not expecting to get tens of thousands of hits by linking to it in a hacker news comment.

(not OP)

This nerdsniped me.

10 minutes later, and TIL: MPD is some sort of streamed-MP4 format; dash-mpd-cli is a xplatform Rust utility binary that can download this to an MP4, just given the MPD URL in dev tools.

However I keep getting 1.5 MB and 500 KB for the two videos, no matter window width. Chrome on macOS arm64, 16" MBP.

I'm curious what your environment is, if you don't mind sharing

(also, trivia for audience: last week I saw a tweet that palantir.com was doing over 100 MB worth of videos, and of course, A) they are B) they're poorly compressed, as much as 10x the bitrate they need to be.)

  • Frontend is full blazor w/hybrid WASM, almost zero JS, all C#. Browser DOM is controlled by the app service in realtime, I plan on using this as a basis for our subscribers to be able to do live traffic & link stats monitoring, among other things.

  • Similar specs here. Here's a full load in a Chrome guest window with resolution constrained to an iPhone SE: https://imgur.com/a/xRjKWNb

    In the left panel, at the end of the video you'll see two important numbers: 28.5MB transferred, 40.7MB resources. "Transferred" is the (compressed) size of everything downloaded over the wire, 40.7MB is the ultimate (uncompressed) size of those.

    I don't show it in that video but you can filter by "initiator" to see that the video files are the lion's share of this.

It's not really the size that matters in this case, because the video is loaded after the page is completed, and in theory, ought not be slowing down the page if at all (my cursory examining of the network tab gives me a sort of confirmation).

However, what is indeed slow is the initial load, and the lack of CDN for their static assets (css etc). When the HN effect started eating their resources, these static assets are what hurt their load time the most.

Xfinity's website is like that, it barely loads even using their service. I've had it time out several times, and had to start over, just trying to help my mom pay her bill.