Page Weight Matters (2012)
blog.chriszacharias.com
blog.chriszacharias.com
Even in industries where customers are on extremely bad connections [0], I couldn't convince people to give up their bloated component libraries or cache things in indexedDB. Fact is not many web developers know how to write for these environments and not many businesses will incentivize for it, even when their customers complain.
Though the optimist in me will say this - if anyone actually does web dev where people do actually care about this, I'd love to hear about it.
[0] My experience here https://lewiscampbell.tech/blog/220205.html
1. It's just text on a page. There are no excuses.
2. People use my website on the train, where the reception is so-so.
Some don't seem to realise that tethering to the mobile network is a thing when something is amiss with the local network's connection to the outside world (more common now than it used to be, with more people working remotely) or trying to get stuff done while travelling - so users might have a decent sized screen & chunky processor but still be talking to us over a low-bandwidth & high-latencey link.
A lot of devs should spend more time with Chrom{ium|e}'s network throttling options turned on. It is far from perfect, but gives at least some insight into the troubles experienced by those with less than ideal connectivity. Perhaps I'll see if, next time I have my infrastructure hat on, there is a way to enforce that as a policy that can't be overridden!
People cobble together npm packages because it saves time vs having to reinvent their whole color conversion solution, or page routing system, or unit converter or whatever.
And sometimes management is the one unwilling to budge. I couldn't get us to spend ANY time on performance until I showed them a video like, "Hey, I know this works fine on our latest Macs, but check out what happens when I try to run this on a 2-year-old budget Windows laptop, like our users would have. It barely even runs." Only then did we start testing with not just network throttling but CPU throttling too. There are still some really slow computers out there.
I've also never met a React user who could explain why React is supposedly better than Angular, other than because everybody else is.
This thread paints people who don’t share your preferences as simpletons without preferences at all. That should be a red flag.
Fast forward half a decade, of course I'm using React now because every employer demands it, but god, what a duct-taped ecosystem! You have to reinvent SO MANY wheels and hack them together, when Angular had it all so tightly integrated. I am really pretty sad that React won out in the end. It's honestly kinda useless on its own (there's not even basic page routing).
Thankfully, Next.js solves a lot of that and makes React useful and easy with a brunch of preconfigured libraries and features they wrote well-integrated together. React by itself is nowhere near Angular, but Next.js is amazing.
Reactivity Data Initial Page View
SS Delayed Delayed Quick
CS Instant Delayed Super Slow
It's not impossible to have CS with lighter components too, but generally apps that have had a longer lifetime and revisions will get heavyweight components.
I thought that was pretty cool, don't know if that's something they still do though (this would have been back in 2013 or so).
Once a year I take them into the actual places where our users will use the web sites To see how the web sites perform. The visitors are 70% mobile users, and I shadow a few of them in the locations where the sites are used, like parking garages and basements and industrial buildings with lots of opportunities for interference.
Very illuminating. And I suspect more accurate than many of the bad connection simulators I've seen.
https://mbasic.facebook.com/ perhaps? It is still available and is designed for the lowest of low-end dumbphones.
It's a decent workaround if you need access to facebook's chat services on your phone but don't want to install that accursed messenger app.
The second lesson I guess, is that inside an evolving product, this is a constant battle against entropy. The YouTube homepage is once again 15mb/90 requests, and that's with an ad-blocker.
You look to be measuring the wrong thing there: 15MB is the uncompressed size; the actual amount transferred is only 3MB. (The two biggest JavaScript files are about 10.5MB, but 2MB on the wire.) And it’s the transfer size that the article is talking about.
(Now the uncompressed size does matter too, especially for JavaScript where that code has to all be parsed and executed, and 10MB will block for multiple seconds on particularly slow mobile devices, but that’s about CPUs, whereas the article is focusing on networks.)
I also wonder how much of that 3MB affects time-to-video-play vs being loaded after the video starts.
On a slow or bitty connection that could still impact the video playback, perhaps even causing a stutter or few, due to competing with it for a share of the throughput possible, if only for a short time, so I think it is still valid to consider as potentially blocking content.
So a website that is supposed to be for playing videos has optimized the page loading pretty well, gotten the video player showing as quickly as possible, then after all that the experience of playing the video is depressing. Without knowing details, it feels like a case where the devs have optimized for the wrong things.
The article is about the Feather frontend, which was never the same as the normal YouTube frontend. So, it’s not really a fair comparison. Also, Feather was introduced in 2009 and they axed it after some years.
I remember the YouTube feather opt-in being spread by word of mouth at the time by folk in the tech community on fast connections. People really care about this stuff and the only reliable way to know is by engaging them directly.
By the sounds of it, though, it was a net loss for Google, which is why the page is still so big. Much of the code might have been irrelevant (even harmful) for the end user, but was necessary for Google's business model.
So a side-learning ignored by the article is that there are more types of stakeholder than just the end users, especially in applications that are free (as in beer) at the point of use. And more stakeholders means more complex solutions. And more complex solutions typically mean more code and bigger pages.
It depends a lot on the content. The example I’m about to show comes to about 114kbps (14.25KB/s).
You can inspect this sort of thing with tools like yt-dlp (the superior fork of the probably-better-known youtube-dl). Here’s one example from a well-known music video:
$ yt-dlp -F 'https://www.youtube.com/watch?v=dQw4w9WgXcQ'
[youtube] dQw4w9WgXcQ: Downloading webpage
[youtube] dQw4w9WgXcQ: Downloading android player API JSON
[info] Available formats for dQw4w9WgXcQ:
ID EXT RESOLUTION FPS │ FILESIZE TBR PROTO │ VCODEC VBR ACODEC ABR ASR MORE INFO
────────────────────────────────────────────────────────────────────────────────────────────────────────────
sb2 mhtml 48x27 0 │ mhtml │ images storyboard
sb1 mhtml 80x45 1 │ mhtml │ images storyboard
sb0 mhtml 160x90 1 │ mhtml │ images storyboard
139 m4a audio only │ 1.23MiB 49k https │ audio only mp4a.40.5 49k 22k low, m4a_dash
249 webm audio only │ 1.18MiB 46k https │ audio only opus 46k 48k low, webm_dash
250 webm audio only │ 1.55MiB 61k https │ audio only opus 61k 48k low, webm_dash
140 m4a audio only │ 3.27MiB 130k https │ audio only mp4a.40.2 130k 44k medium, m4a_dash
251 webm audio only │ 3.28MiB 130k https │ audio only opus 130k 48k medium, webm_dash
17 3gp 176x144 6 │ 1.97MiB 78k https │ mp4v.20.3 78k mp4a.40.2 0k 22k 144p
394 mp4 256x144 25 │ 1.71MiB 68k https │ av01.0.00M.08 68k video only 144p, mp4_dash
160 mp4 256x144 25 │ 1.82MiB 72k https │ avc1.4d400c 72k video only 144p, mp4_dash
278 webm 256x144 25 │ 2.27MiB 90k https │ vp9 90k video only 144p, webm_dash
395 mp4 426x240 25 │ 3.37MiB 134k https │ av01.0.00M.08 134k video only 240p, mp4_dash
133 mp4 426x240 25 │ 2.96MiB 117k https │ avc1.4d4015 117k video only 240p, mp4_dash
242 webm 426x240 25 │ 4.02MiB 159k https │ vp9 159k video only 240p, webm_dash
396 mp4 640x360 25 │ 6.57MiB 260k https │ av01.0.01M.08 260k video only 360p, mp4_dash
134 mp4 640x360 25 │ 5.55MiB 220k https │ avc1.4d401e 220k video only 360p, mp4_dash
18 mp4 640x360 25 │ 15.04MiB 595k https │ avc1.42001E 595k mp4a.40.2 0k 48k 360p
243 webm 640x360 25 │ 6.93MiB 274k https │ vp9 274k video only 360p, webm_dash
397 mp4 854x480 25 │ 11.45MiB 453k https │ av01.0.04M.08 453k video only 480p, mp4_dash
135 mp4 854x480 25 │ 8.52MiB 337k https │ avc1.4d401e 337k video only 480p, mp4_dash
244 webm 854x480 25 │ 10.04MiB 397k https │ vp9 397k video only 480p, webm_dash
22 mp4 1280x720 25 │ ~66.22MiB 2559k https │ avc1.64001F 2559k mp4a.40.2 0k 44k 720p
398 mp4 1280x720 25 │ 23.71MiB 938k https │ av01.0.05M.08 938k video only 720p, mp4_dash
136 mp4 1280x720 25 │ 16.56MiB 655k https │ avc1.4d401f 655k video only 720p, mp4_dash
247 webm 1280x720 25 │ 16.97MiB 671k https │ vp9 671k video only 720p, webm_dash
399 mp4 1920x1080 25 │ 45.16MiB 1786k https │ av01.0.08M.08 1786k video only 1080p, mp4_dash
137 mp4 1920x1080 25 │ 89.66MiB 3547k https │ avc1.640028 3547k video only 1080p, mp4_dash
(The source article speaks of 100KB taking 2 minutes, which corresponds to 6.7kbps, which is extraordinarily slow. Well, at that rate it would take you an hour to load the 3MB of the video in this example, though experience suggests that at those speeds other stuff is extremely likely to clog things up further. But then, maybe that clogging is already taken into account.)
Even on high latency and crappy connections this can provide a better UX. TCP is still applicable on that websocket, so it's not like things will arbitrarily derail because of some packet loss.
If your web application is doing anything useful, it probably has to periodically check in with the server anyways. Why not just keep all of the state on the server and stream the UI to the client in a more granular fashion?
That said it's worth aiming to keeps things as small as possible from the start. Just not investing in a rewrite.
I used to be on the Performance team at Box. Our charter was to get the files page to load in under 1s for the median domestic (US) user.
Box is largely sold to CTOs, not the people using it. The folks demoing/testing/evaluating are almost always on fast computers with fast internet. That didn't negate our goal, though, for a few reasons:
1. It turns out that lots of business users fly on airplanes. If you have to store/send a file and the app loads too slowly, you'll just use Dropbox or GDrive, or the OneDrive that Microsoft threw into your Office365 contract for free instead. And when _that_ loads instead, you'll remember it come contract negotiation time.
2. If all of the people who are supposed to use the app hate it, they'll actively avoid using it. If they have no choice, they'll complain and make sure decision makers are well-aware of how bad it sucks. That does eventually trickle up. With Box, folks would switch to email or flash drives, which makes security/compliance orgs salty, which introduces new, stricter limitations on your USB ports and email, which pisses off the execs paying for Box. Bad business software—contrary to popular belief—does eventually get phased out, just not on a short timescale.
3. Geography does matter. One project to bring the files page on Box from ~3s to ~2.3s ended up improving EU load times by multiple seconds in some cases. Companies who would have previously ruled Box after testing it once suddenly became meaningful prospects.
4. Sites that load slowly usually load slowly because of underlying complexity. That complexity makes the code harder to change. The slowness and the ability to make meaningful improvements to the site in other areas are directly linked. In 2014, I realized we'd picked almost all of our low-hanging (performance) fruit and pushed a full rewrite/redesign. It turned out to be one of the biggest software ships Box has had in the last decade (see "All New Box" [0]), and was a huge boon for sales and marketing. Something something life gives you lemons. Nobody plans on making their site slow, "not investing in a rewrite" makes no sense in the real world.
It's also worth calling out that this is woefully inaccurate:
> make very little difference to most users as they visit the site every day and have most of it in cache
If you're a serious company that releases software changes regularly (Box had ~nightly releases when I worked there), no, your users will not have the assets cached. One small JavaScript change (bug fix, feature, whatever) invalidates the cache.
We spent many man months getting our third party libraries into a "vendor" bundle that didn't change with meaningful frequency, but that accounted for less than 30% of total JS payload. With the exception of weekends and Mondays, you could be guaranteed to load a few hundred kilobytes of fresh JavaScript every morning. Organizations with CD would be in a worse situation.
But in the real world, the experience feels worse than it is: the times your cache is the least fresh are the times when you're most likely to notice the slowness. You just paid for Gogo in-flight wifi, you just came back from vacation or sick leave, you just opened your laptop at a customer site.
[0] https://blog.box.com/introducing-all-new-box-where-all-your-...
That was kind of their point: No one is, so why bother with a lot of effort?
> The apps with bundle sizes that people complain about are almost exclusively from third parties.
Right, like Box. Not the internal apps they were referring to.
> I've worked on some big internal apps, and almost none of them have payloads big enough to notice.
That echoes my own experience.
> If it ain't broken don't fix it.
I think you’re agreeing with the person you responded to. It was just that Box wasn’t the kind of app they were talking about. All I was saying was that your response, while interesting, was not 100% relevant. It was still interesting, though!
So true! But, man, that not-so-short timescale often is painful! :-)
I'm talking about the kind of app that exists in one organization, has 1 - 10 users, and is not a huge part of one persons job.
Something like an EDI tool that sends invoices to that one creditor that requires some strange EDI format and only just makes up enough of your business for it to be worth while. Where the EDI was written 15 years ago and no one knows much about it. Then you get a new dev asked to make a small a change and comes back saying they need a week to improve its performance or shrink it's binary.
1) lightweight pages, that link out to lots of stuff (javascript libraries, images, ...). AJAX request to load page content.
2) more heavyweight page, but everything into one. Only inline javascript, <img src="data:image/gif;base64,R0lGODlhEgA... Everything into one.
Because page weight doesn't really matter. Time to display matters.
However: the user may be throttled, in which case any connection is likely to have an interruption about 3MB of data transfer.
So you get bit coming and going.
This all adds up to relying on cached resources for page load performance is fragile at best and completely broken at worst. Relying on caches ends up with a worse experience on average because whenever a user loads the app they may get wildly different load performance based on the state of the cache.
Also if your uncached page is slow loading, then any of the multitude of reasons a returning user has an empty/invalid cache, they get a nice unexpected slow load experience. Even two page loads a day apart might have had the cache invalidated by an update on the server. Use patterns don't neatly align with deployment patterns.