4 ms·

Your math sounds wrong, so I did it on paper and proved that it's wrong. The average bandwidth for a mobile device in the USA is about 3.25 mb/s (26mbps). So t

Your math sounds wrong, so I did it on paper and proved that it's wrong. The average bandwidth for a mobile device in the USA is about 3.25 mb/s (26mbps). So to load your "2-4mb" Javascript library you're looking at 400ms to connect + 1000ms to download resources. That's 1400ms. Now for the rest of the math I benchmarked my own website. My homepage is ~300kb and loaded in 461ms. The fastest you're going to get ANYTHING back from my server is about ~170ms. Lets start with your App. 1,400ms and the app is loaded. Load another page and it takes 200ms to load another 5kb of content. Load one more page and it's another 200ms for 5kb of content. I've been waiting on your website for a total 1,800ms and viewed three "pages" of content. Lets move on to my website. ~450ms and the site is loaded. Load another page and it takes another ~450ms to load another 300kb. Load another page and that's another ~450ms to load another 300kb. I've been waiting on my website for a total of 1,350ms and viewed three actual pages of content, but the user only had to download 900kb instead of 4mb. So I think you proved the OP's point.

fovc 8y ago
User expectations are very different for when they are starting work vs when they are in the middle of something. If it's really a SPA you can also disguise the load times with optimistic updates and such
- chooseaname 8y ago
  Don't people still have data caps?
- extrapickles 8y ago
  You can also stream in most of the assets while the user is trying to remember their username/password.
Izkata 8y ago
Shouldn't your static assets be cached in the browser for pages 2 and 3, making your subsequent pages load a bit faster than the first?
mercer 8y ago
Also don't forget that frameworks like Phoenix, or alternatively aggressive optimization in other ways, can be significantly faster at that 'first load' than you describe.
deleted 8y ago
[deleted]
chipotle_coyote 8y ago
But the person you're replying to specifically cited SPAs, single page applications, as the use case for "download a big JS library first and then minimize future loads." If the SPA presents more than five 5kb chunks of what you define as "actual pages of content" to the user in a single session -- which doesn't sound at all unreasonable -- then using your own numbers, the SPA is now slightly beating your web site (2600ms to 2700ms). By ten "pages," the SPA has substantially pulled ahead (3400ms to 4500ms), and has still only sent 50kb of data past the initial huge hit. If the JS library is closer to the 2mb side than the 4mb side, it may well have already sent less data. At any rate, the NYT page that Drew DeVault is complaining about isn't an SPA, and its problems don't stem from loading a JS library whose point is to make future requests faster. Its excessive JavaScript use is driven almost entirely by including advertising/marketing-driven code, and I would argue that JS is being a bit scapegoated here: it's a symptom, not the problem. I bet we could deliver a lean, mean, highly-optimized version of that web site that duplicated the exact same ads, down to the same obtrusive banner behavior. Would we like the site more then? Would any of us really respond, "Wow, it's so much better now that I can be frustrated by this terrible design in a tenth the load time!"?
- zelon88 8y ago
  I agree that there is a point where SPA's make sense. Like Gmail. If a user logs in, they're probably going to stay a while and use quite a few features. But I'd be willing to bet that the vast majority of NYT visitors will load just one page and then navigate away. If someone is browsing their search results and EVERY website developer assumes that their visitor is in-it for the long haul, that one user is going to consume 12mb of data to load 3 pages off of 3 different domains. I believe the point of the post wasn't to demonize Javascript, but to point out that there are a lot of low-hanging fruit in the world of web design and that it takes very little effort for developers to simply look at their design in terms of respecting users bandwidth and only using what you need to get your message across. NYT sent this guy 2.8mb of data from 5 different domains to communicate 9037 bytes of requested content. That should resonate with anyone using multiple Javascript libraries, especially the ones who are offended.
watersb 8y ago
Where do you see 26 megabit/s speeds? I live in US/Mountain time zone, have only ever seen such speed via my wired, local ISP land-line.

fovc 8y ago

User expectations are very different for when they are starting work vs when they are in the middle of something. If it's really a SPA you can also disguise the load times with optimistic updates and such

chooseaname 8y ago
Don't people still have data caps?
extrapickles 8y ago
You can also stream in most of the assets while the user is trying to remember their username/password.

Izkata 8y ago

Shouldn't your static assets be cached in the browser for pages 2 and 3, making your subsequent pages load a bit faster than the first?

mercer 8y ago

Also don't forget that frameworks like Phoenix, or alternatively aggressive optimization in other ways, can be significantly faster at that 'first load' than you describe.

deleted 8y ago

[deleted]

chipotle_coyote 8y ago

But the person you're replying to specifically cited SPAs, single page applications, as the use case for "download a big JS library first and then minimize future loads." If the SPA presents more than five 5kb chunks of what you define as "actual pages of content" to the user in a single session -- which doesn't sound at all unreasonable -- then using your own numbers, the SPA is now slightly beating your web site (2600ms to 2700ms). By ten "pages," the SPA has substantially pulled ahead (3400ms to 4500ms), and has still only sent 50kb of data past the initial huge hit. If the JS library is closer to the 2mb side than the 4mb side, it may well have already sent less data. At any rate, the NYT page that Drew DeVault is complaining about isn't an SPA, and its problems don't stem from loading a JS library whose point is to make future requests faster. Its excessive JavaScript use is driven almost entirely by including advertising/marketing-driven code, and I would argue that JS is being a bit scapegoated here: it's a symptom, not the problem. I bet we could deliver a lean, mean, highly-optimized version of that web site that duplicated the exact same ads, down to the same obtrusive banner behavior. Would we like the site more then? Would any of us really respond, "Wow, it's so much better now that I can be frustrated by this terrible design in a tenth the load time!"?

zelon88 8y ago
I agree that there is a point where SPA's make sense. Like Gmail. If a user logs in, they're probably going to stay a while and use quite a few features. But I'd be willing to bet that the vast majority of NYT visitors will load just one page and then navigate away. If someone is browsing their search results and EVERY website developer assumes that their visitor is in-it for the long haul, that one user is going to consume 12mb of data to load 3 pages off of 3 different domains. I believe the point of the post wasn't to demonize Javascript, but to point out that there are a lot of low-hanging fruit in the world of web design and that it takes very little effort for developers to simply look at their design in terms of respecting users bandwidth and only using what you need to get your message across. NYT sent this guy 2.8mb of data from 5 different domains to communicate 9037 bytes of requested content. That should resonate with anyone using multiple Javascript libraries, especially the ones who are offended.

watersb 8y ago

Where do you see 26 megabit/s speeds? I live in US/Mountain time zone, have only ever seen such speed via my wired, local ISP land-line.