As long as web designers and developers continue to target imaginary users or themselves, they'll also leave real users wanting more.

Great, you've shaved off 150-350ms of refresh load time. So why does your website take 10-15 seconds to load on my phone when I'm walking about the supermarket?

Get out of the lab. Start testing with real users in real contexts. You'll quickly learn that many of your assumptions about what users want disappear.

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.

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!"?

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.

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

Don't people still have data caps?

You can also stream in most of the assets while the user is trying to remember their username/password.

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?

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.

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.

Unless your user is sitting in the same datacenter as the app, there is almost no chance that you're getting a 50ms latency on any action that requires a round-trip.

Pinging google.com from my current connection (NYC) results in an average 26ms latency. Facebook is 25ms. That's just baseline connection latency for a user in a place with a solid connection, and you're unlikely to do better.

Realistically, most apps that aren't Google scale are lucky to get 300ms average latency. The way you improve responsiveness is by eliminating round-trips, not assuming that client-side frameworks will save you.

> Realistically, most apps that aren't Google scale are lucky to get 300ms average latency.

I am hosting a quite popular site built with perl and php over 20+ years and with at least 2 round-trips to the DB per request. 150ms latency triggers a warning in monitoring, 200 is considered "critical". The site sits on the west coast, the monitor in Chicago. The site serves at least 10 concurrent clients at any time (read: 5am) up to a few thousand.

And I am painfully aware that the bottleneck is the code, not the network.

Honestly, it sounds like you're set up better than 95% of the webapps I've encountered (and I'm including some big, famous names in that list). Big, well-resourced dev teams make the mistake of assuming that "works on my box" is the definitive measurement of site speed.

But also, let's be real for a moment: define "latency". Is 150ms your (client-measured) connection time? Your render time? Your usable-page time? Again, most webapps are lucky to get HTML back to the user in under 300ms, and if your 150ms metric is "time to server-side render", then you very likely aren't.

150ms are client-side read. But without any js-triggered modifications to the DOM tree, this is pretty much the render time (rendering is 2ms on my not-too-beefy laptop).

Yes, that's quite good. It's pretty common to find server-side actions that take longer than 150ms to just return the page, and 2ms render times absolutely smoke most JS-framework pages.

I stand by my original comment (it's better to avoid loads than to assume you're fast), but good on you for getting those latencies down.

I get a <50ms ping to AWS datacenters in my country.

"...there is almost no chance that you're getting a 50ms latency on any action that requires a round-trip."

Which is why the comment is advocating for locally-cached resources.

"The way you improve responsiveness is by eliminating round-trips..."

Hence "preload" above.

Frameworks don't make your code smart. Writing a webapp that aggressively preloads without causing problems is hard, and while frameworks give you some tools to make that easier, they don't do the hard work for you.

The issue of course is that about 80% of websites don't need to be 'apps' or SPAs or what not. If you're building a news site for instance, it's basically a blog at the end of the day, not something akin to Gmail or Discord or what not.

Same goes with a lot of sites that seem to be built as web apps despite not needing to be apps in any shape or form.

It reminds me of when I was in 8th grade and I discovered Visual Studio and made tons of "apps" that were glorified iframes with a menu and an about box for no reason other than I could. It's a clear case of a solution in search of a problem syndrome (not that there aren't proper use cases for complex web/desktop apps, obviously).

And the third type -- apps where the user is expected to be a developer ;)

These definitions are a bit too narrow for me.

I think there's a place for sites where the user is expected to stay a while, and where functionality doesn't warrant several megabytes of resources.

Thinking that there's anything but can lead to a wasteful landscape for the web.

In those situations I'd generally recommend a conservative server-side approach...

Map and chat apps are the ones I can think of right now that is better as a single-pager. I have been writing web apps for over 10 years. They aren't single-pagers, yet everything is a "3-8 KB request" and happens in "about 50 ms." There is never a time at any point where "2-4 MB" is needed. Now perhaps you are thinking these are ugly, and it means little to you if I claim that they aren't. All I can say is before I was a programmer I was a graphic designer, and I still like studying and thinking about user interface design. Oh, and my customers have complimented the look and feel of my apps, without solicitation, many times through the years.