The modern web on a slow connection (2017)
danluu.com
danluu.com
This had some validity in the early days of AJAX when common practice was to respond with HTML fragments and it was mostly just a work-around for Frames not being very good at a bunch of things they should have been good at. These days, not so much.
JSON is just a terrible fit for GQL schemas. I regularly deal with metadata enum fields that are repeatedly serialized causing massive bloat. Sure it gets gzipped away, but you still have all those copies after decompression and parsing.
A reasonable POTS modem does ok on latency, but bad on bandwidth. So roundtrip is fine until you send too much data (which is real easy, modern initial segment limit of 10 combined with a 1500 mtu is more than a second of download buffer). If you kept the data small, many round trips would be okish.
On the other hand, traditional geosynchronous satellite always has terrible latency, so many round trips is bad regardless of the data size... One big load would be a lot better there.
Some early ISPs I worked with started with 56K leased lines. The latency there was like night-and-day compared to a 56k modem.
Web pages just appeared (modulo Netscape connection limitations). A fresh page load felt as fast as a cached page load on my analog modem. It was nuts.
It was most noticeable in a handful of games of Quake I played. I got to experience the joy of being a Low Ping Bastard and actually landing a few hits on people.
My experience growing up is that you don't notice the issues on sane pages written by hobbyists/professors/researchers and then you go to something built by google and everything falls apart.
It should work, but it's never so in practice.
On a web page, missing a bit of the page at the end is not an issue, you might have somewhat broken content but that's not a deal-breaker.
With an SPA, an incompletely loaded API call is just a complete waste of the transferred bytes.
And slow connections also tend to have much larger latencies. Care to guess what's an issue on an SPA which keeps firing API calls for every interaction?
> So your initial page load would be slow because of all the HTML and JS, but afterwards it should be faster compared to having server side rendered pages.
The actual effect is that the initial page load is so slow you just give up, and if you have not, afterwards it's completely unreliable.
Seriously, try browsing the "modern web" and SPAs with something like a 1024 DSL with 100ms latency and 5% packet loss, it's just hell. And it's the sort of connections you can absolutely find in rural places.
- the argument is that most of what you probably want is better than nothing.
Although I can imagine sites thus prioritising ads even more…
Facebook is an example of a website where there is such an absurd amount of content that's not the focus of the page: the sidebars, the recommendations, the friend list of the chat, the trends, the ads. It sorta makes sense for them to have an SPA (although let's be frank: most people in slow connections prefer "mobile" or "static" versions of those sites).
The impetus for SPAs was never really speed. The impetus for SPAs is control for developers, by allowing navigation between "pages" but with zero-reloads for certain widgets. It was like 90s HTML frames but with full control of how everything works.
TFA is arguing that a user on a bad connection won't even make it to a proper page load event in the first place.
It's probably also worth mentioning that the "gains" from sending only data on subsequent user actions are subject to devils in details, namely that response data isn't always fully optimized (e.g. more fields than needed), and HTML gzips exceptionally well due to markup repetitiveness compared to compression rate of just arbitrary data. Generally speaking you can rarely make up in small incremental gzip gains what you spent on downloading a framework upfront plus js parse/run time and DOM repaint times, especially on mobile, compared to the super fast native streaming rendering of pure HTML.
Unfortunately they are the exception as there are a lot of awful SPAs that focus on looking cool while they’re barely usable. Looking at you, Airbnb.
HTML pages are not that big, though, unless you put a lot of content around the data. Not to mention JSON can be wasteful, and contain more data than needed. And lots of SPAs require multiple roundtrips for fetching data.
And even if you do have lots of content around your data, there are alternatives, like PJAX/Turbolinks that allow you to only fetch only partial content, while still using minimal JS compared to a regular JS framework.
In other words, pretty often the initial load is the only one.
If you get rid of javascript frameworks used for SPA, the overhead of delivering a handful of HTML tables and forms instead of some JSON is negligible.
But that depends on the use case, doesn't it. Static sites may as well be huge, and now you need to send all of the surrounding html over, when only a small table or form would need updating. So I am not so sure about your point. The greater the complexity of the displayed page, the more sense it makes to use a SPA network-wise. (edit: mostly covered in sibling comments)
You have a point about compression though. I now wonder what the situation would look like if we had (had) native HTML imports, as that would greatly help with caching.
No, you don't. For something like the upvote button on HN you can do an ajax call with a line of javascript. In the context of the conversation this is very far from bloated SPAs.
HN is a good example: each thread page consists mostly of comments. Reusing the same DOM across different pages would do very little.
Gmail is another: the default UI is a heavy SPA. The "plain html" mode is not. And it's faster.
Naturally it has to be more clusmy than just using one of the boring SSR that exist since 2000.
I've lived in dozens of places. I've lived in urban areas, suburban areas, rural areas. I've even lived on a boat. With the exception of wealthy areas, reasonable internet is a constant struggle.
It's also never due to the speed though, in my experience. The biggest issues are always packet loss, intermittent outages, latency, and jitter. High speed internet doesn't count for much, aside checking off a box, if it goes out for a couple hours every few hours, or has 10% packet loss. You'd be surprised how common stuff like that is. Try visiting the domicile of someone who isn't rich and running mtr.
Another thing I've noticed ISPs doing is they seem to intentionally add things like jitter to latency-sensitive low-bandwidth connections like SSH, because they want people to buy business class. So, in many ways, 56k was better than modern high speed internet. Because yes, connections had slow throughput, but even with 300 baud the latency was fast and the reliability was good enough that you could count on it to be something you could actually use when connecting to a central computer and running vi. Bill Joy actually wrote vi on that kind of internet connection, which deeply influenced its design.
I recently got the chance to speed up a website that I often use myself as a part of my consulting work, and despite my best efforts a further 10x speed up was left on the table because of insurmountable apathy by the developers.
In the last two decades, I've met one (1) web developer that cared about performance at all. One! The rest are blithely unaware of the profligate waste of CPU time and network bandwidth their "features" are consuming.
Things like two different third-party APMs on top of Google Analytics, the CDN analytics, and in-house analytics taking up 90% of both the bandwidth and server load.
I regularly see web sites with all caching, compression, and HTTP settings left on defaults. As in: private, off, and HTTP/1.1 only.
It's mind boggling how slow these sites are, in an era where benchmarks show that modern servers can put out 100K responses per second!
Here's what you do. You start off by showing people papers like this https://static.googleusercontent.com/media/research.google.c... which say "users are 1.5 times more likely to choose the fast engine". That's how you get resources to do the 10x optimization. But doing the optimization isn't enough, if you can't tie the results into something people care about. To do that, you're already paying the price for Google Analytics telemetry. You can use its API to A/B test the slow vs. fast version of your website for conversions or whatever behavior you're trying to optimize.
People fall in love with stuff that goes fast in unpredictable ways. Be prepared for that. Sometimes it helps to just walk around the office and watch people using your website, to get a basic idea of how they feel about it and how they're engaging. For instance you might discover they're constantly alt-tabbing to some blog while they're waiting for pages to load. In that case you can quantify a productivity impact across everyone who's using the website that likely far exceeds your own salary. Then the people who didn't care might start paying attention. All you had to do was make a web page less sluggish.
I vividly remember trying to explain these concepts to a librarian. She wanted to implement a hugely complex "search form" where you could narrow down the search to something like: "Show me all young adult fiction about dragons written by authors who's name starts with the letter A and was published in the years 1997 to 1999".
But that's an absurd scenario, and no student in the history of the world will ever use it like that. Never. They'll type in "dragons" and read the first book that has a cover picture they like. I did this. My friends did this. All of the statistics I collected in the system shows that this is what everyone else does too.
The reason she wanted that search was because the old system would take tens of seconds to do any search. So you had to get the search "right" the first time, or you'd be there for tens of minutes.
My version did the search in under 15ms, and even did live tab complete. I copied the Google interface with quotes for exact search, negative sign prefix for exclude, etc...
Oh, and I made sure to get the highest quality book cover art for every title I possibly could. Kids love to see that, the artwork is engaging, and it motivates them to read more. Search forms? Not so much...
The kids loved it, but the librarian is still a little bit grumpy that I didn't build her the two page form that she wanted!
Librarians are really intelligent people. All the recent engineering marvels that Google does under the hood to provide meaningful results, such as PageRank and machine learning, librarians have always been able to do in their heads. They are not unsophisticated users who click on the first picture they like. If your search algorithms are simpler than what Google does, then you can count on librarians to fill in the gaps for you. But in order to do that, they need control. Because when someone can't find something in the library, because full-text search isn't taking into consideration popularity, then what do kids do? They go to the librarian, who enters the complicated search for them, based on what they know, and they know a lot.
So I think the librarian was being perfectly reasonable. You should have empowered her with the tools she needs to do her job. You could have just as easily put it behind a drop-down that's hidden by default, so both her and the kids are happy.
I also had typo-correction, similar to what Google does.
Also, these are tiny school libraries, where at most you have a couple of pages of results even for popular key words.
I'm not an idiot either! :)
This adds an interesting dimension to things. In a roundabout way, for this kind of case, have you ever been glad to be using a PWA (with client-side caching) instead of a regular website?
The way I see it, these PWA client-side caching technologies are mostly used by news websites to install permanent service workers on my PC that run in the background after the tab is closed to mitm http requests, phone home every day, and have a kill switch over my data associated with their origin. What's my data? I don't even know. For example, I noticed the Western Digital Forum (I don't even remember visiting it) had a service worker that managed to store 1gb of content to my hard disk. What's in it? I don't know. Chrome doesn't let me see it. Maybe it made the whole forum available offline for me to enjoy. Or maybe I'm an unknowing member of their new cloud storage service. Can't tell. The lack of visibility, lack of consent, and lack of options to disable these emerging standards are in themselves an issue. We should be focusing on making local apps better, rather than having browsers foray into territories that are not in sync at all with expectations.
Now with phones and always on connections it's not even comparable. I spent more time using my computer; programming, graphics, learning about it, yes the physical thing in front of me than on the Internet in the early 1990s even later 1990s.
Now they are 1200x750 high resolution JPGs, but that is a worth while tradeof when we have screens that can display them.
The real issue is Javascript.
Large images being “worth the trade off” is debatable depending on your connection speed, I think (though at least you can disable images in the browser?)
I was glued all the time to my computer on the internet as far back as 2002 - browsing forums and playing video games and self-learning programming from C++ tutorials here and there.
Yea, that's not 25 years ago, only 19 years ago.
I find the modern web quite quick with an adblocker on but a bit horrendous with it off.
It doesn't matter if your home broadband is awesome if you're currently at the store trying to look something up on a bloated page. It's little consolation that the store wrote an SPA to do fancy looking fades when navigating between links when it won't even load right in the store's brick and mortar location.
Far too many web devs are making terrible assumptions about not just bandwidth but latency. Making a hundred small connections might not require a lot of total bandwidth but when each connection takes a tenth to a quarter of a second just to get established there's a lot of time a user is blocked unable to do anything. Asynchronous loading just means "I won't explicitly block for this load", it doesn't mean that dozens of in-flight requests won't cause de facto blocking.
I'm using the web not because I love huge hero images or fade effects. I'm using the web to get something accomplished like buy something or look up information. Using my time, bandwidth, and battery poorly by forcing me to accommodate your bloated web page makes me not want to give you any money.
I specifically designed my website to work reasonably fast on the Berlin U-Bahn, where some of my readers are likely to be.
Home Depot web devs, make sure someone can load the Home Depot web page in side one of your stores filled with steel shelves and other cellular hating materials. I can't imagine trying to use Home Depot's website inside a store is some super edge case that's not worth the effort.
My home connection is smoking some of my dedicated servers: the cheap ones are still on 100 MBit/s in datacenter and they're totally the bottleneck. That's how fast home connections are, for some.
I used to browse on a 28.8 modem, then 33.6, then ISDN, then ADSL.
The problem is: people who get fiber are probably not going back. We're going towards faster and faster connections.
It's easy, when you're on fiber since years and years now, to forget what it was. To me it's at least part of the problem.
Joel is not loading his own site on a 28.8 modem. It's the unevenly distributed future.
I hope that no one are... and at least using 56k
I don't see the advantages
What happens is that it is basically two modems into one, so it can go double the speed at the expense of using two phone lines.
Sans multimedia consumption, the modern web is fine on a reasonable connection provided you're using noscript or something like that. If you're not, then well, you're already screwed either way.
What's crazy to me is not that regular users put up with a ton of bullshit - they have to. It's that lots of fellow developers do and they most certainly don't have to. They simply don't care.
The default for most of the tools/frameworks is to generate this bloat without a nice fallback for slow connections. Because the industry is focused on people with good connections, because that's where the money is.
Whenever I develop a webapp whose users won't be having a good Internet connection, there's a requirement to support that use case, and I spend time making sure the thing is usable on bad connections, and it's OK to sacrifice some UX to get there.
But on most cases, customers (both end-users and companies that pay me to code something for them) prefer shiny & cheap rather than "works OK for faceless people I don't know they still live like I did 15 years ago".
TL;DR: it's an economics issue, as usual.
----
PD: I've spent five hours yesterday to avoid a 70% packet loss to the router in the place I've recently moved to. There's a (top) 6Mbps connection on the other side of the router. I'm suffering not being on a top-class connection - but that's _my_ issue, not my customer's, nor my customer's customers.
Honestly, the number of people working in tech, not using an adblock (and not even knowing that things like this exist) is making me sad.
The cynic would view society is an optimization problem between bullshitters and those willing to tolerate bullshit. I say introduce a little anarchy into the equation, using the clean and pristine.
> Dillo is a multi-platform graphical web browser known for its speed and small footprint.
> Dillo is written in C and C++.
> Dillo is based on FLTK, the Fast Light Toolkit (statically-linked by default!).
Dillo doesn't have a JS engine. (This is a "pro" in my opinion.)
Using it the web is divided into three equivalence classes:
1) Works. (defined as, the site loads, the content is accessible and it looks more-or-less like the author intended.) As a rule such sites load lightning fast.
2) Broken but the content can still be read. Usually the site layout is messed up.
3) Broken completely. Typically a blank page, or garbage without visible content. (There is a new failure mode: sites that won't reply to browsers without server name indication (SNI https://www.cloudflare.com/learning/ssl/what-is-sni/ ) Dillo doesn't (yet) support SNI, so those sites are "broken" too. Typically these are Cloudflare-protected sites that give me a 403, but e.g. PyPI recently adopted SNI and went from category 1 to 3.)
(HN is in category 2 FWIW: you can read the content but the "bells and whistles" don't work, login, voting, etc.)
I don't really have much to add, just that A) enough of the web works that I find it useful to use dillo for my purposes, B) the web that does work with dillo is much less annoying than the "modern" web, C) it kinda sucks IMO that most of the web is junk from the POV of dillo user agent.
(Does PyPI need to host multiple HTTPS domains?)
You're missing the point. "It doesn't matter why they're dressed as a tiger. Have they got my leg?"
The real question: is the PyPI front page running on someone else's infrastructure or some dedicated hardware?
Login works on HN without JS, but comment collapsing and voting doesn't work. (Just posted this from Safari with JS disabled).
Do not forget to set the User Agent to something "usable" such as the ones for the PSP or the old Opera Mini 3 browser.
So we went from paying 9.95/month for average 56k service, to 80/month for a service that was worse than that.
To add insult to injury, a local broadband provider kept sticking their signs at our driveway next to our mailbox, and we would call to try and get service, but we were apparently 200 feet past the limit of their service area. People who lived at the mouth of our driveway had service, our neighbors had service, but we were too far out they said.
I repeat: as late as 2016 I WOULD HAVE KILLED TO BE ABLE TO JUST USE FREAKING DIALUP!
With high gain antennas you simultaneously increase mutual reception and decrease reception of other signals, giving a triple boost to your signal-to-noise ratio if you can use it on both sides (sender: +1 txpower; receiver: +1 signal reception, +1 interference rejection), so that is what you should aim for.
Transmit power does comparatively little (sender only: +1 txpower, -? amplifier noise), while blanketing the area with useless power (both in-band and out-of-band²) that can get you detected and affect other devices. Especially if you driver you transmitter near the limit (or use a shitty amplifier, broadband antenna) further increasing out-of-band transmissions, which is the part that is likely to get you a visit from regulators.
¹ gain ~ directionality; symmetric in both reception and transmission
² out-of-band - frequencies other than intended ones
This often started with off the shelf wireless APs (like the venerable D-Link DWL-900AP+ with often home made antennas connected. If the network had more knowledgeable Unix people, they might have used an old PC running Linux or BSD with hostapd and an PCI wireless card. The most advanced ones even had home-built optical links (Seriously, 10 Mbit/s full duplex on 2001 by light was super cool! https://en.wikipedia.org/wiki/RONJA) though our network was not that hardcore. :P We did lay some cable via agricultural pipe and build a makeshift com tower next to a Vineyard. :)
Over time the networks got high larger via bridging and wired or even fiber segments and a lot of the hardware was often replaced by high performance Microtik and Ubiquity devices.
Also the networks often merged into bigger ones, covering whole cities and their surrounding villages, with APs on top of grain silos and water towers.
Some of the networks are still independent and quite big, some were bought by big "traditional" telecom companies and some still operate as user coops to this day.
Family in Placerville CA went from unusable <1mbps viasat to 50-190mbps overnight.
I hope it puts all the geostationary satellite companies into bankruptcy.
It's a real 150-300 down, 16-25 Mbps up. In many cases it actually beats the DOCSIS3 cable operator's network at the same location for jitter, packet loss, downtime.
The unfortunate economics of building 4000-6000 kg sized geostationary telecom satellites with 15 year finite lifespans, and launching them into a proper orbit ($200 million would not be a bad figure for a cost to put one satellite in place) mean that the oversubscription/contention ratios on consumer grade VSAT are extreme.
Dedicated 1:1 geostationary satellite still has the 492-495ms but is remarkably not bad, but you're looking at a figure of anywhere from $1300 to $3000 per Mbps, per direction, per month for your own dedicated chunk of transponder kHz for SCPC. You're also looking at a minimum of $7000-9000 for terminal equipment. That's the unfortunate reality right now.
I feel sorry for both viasat/hughesnet consumer grade customers, who are suffering, and also the companies, who are on a path dependent lock in towards obsolescence. Even more so if various starlink competitors like Kuiper, Telesat's LEO network and OneWeb (not exactly a competitor since it won't be serving the end user, but same general concept) actually launch services.
Do you have any more specific data you could share there? For example, how much of that percentage is caused by downtime and how much is caused by random lost packets outside of downtime? Or how long does it go unavailable?
Not within the past 3-4 weeks, but there have been previous times of 30 to 120 minute downtime at 0200 in the morning local time while the starlink people do terminal firmware updates and other changes in the network.
We spent today taking a look at properties, and the internet situation goes downhill fast from where we presently rent from DSL to "unknown". HughesNet is an option, but it's an iffy option for latency reasons, and Starlink is crazy pricey. Cellular is a total non-starter: there is none.
Our realtor lives on a road with a bunch of people willing to pony up to get decent internet, but they can't get the ISP to actually run media down the road because it's too few houses, never mind that there's money on the table.
So if you're a web developer, please know that there are real folks in the USA who have legitimately lousy internet options in 2021. In our case, it's self inflicted, but I'm going to make some sweeping assumptions based on the houses we drove by and say it isn't a matter of choice for everybody.
128kbps isn't so bad, is it? More than 3x the speed she used to get with a dialup modem.
But no. We ran it into the fallback zone to try it out. And half the sites (e.g. the full Gmail UI or Facebook) wouldn't even load - the load would time out before the page was functional.
The 128kbs fallback is meant to be as a lifeline, for email and instant messaging communications. And that's really all it's food for any more.
No need to travel that far. During my time in my previous apartment I had two options for connecting:
-The landlord's mother's old router behind a thick wall (400kbps at best, 300-400ms latency with 10-30% packet loss).
-A "soapbar" modem we got along with my SO's mobile plan. 14GB a month, slowing down to a trickle of 16-32kbps when used up.
Things that worked on such a connection:
-Google Meet
-Facebook Messenger
-Hacker News
The rest of the web would often break or not load at all.
Plus React 150kb, Bootstrap 150kb and all their plugins make it multi megabyte.
I was thinking about converting my old server rendered web site into modern web. Still wondering if it's worth it.
> I was thinking about converting my old server rendered web site into modern web. Still wondering if it's worth it.
As usual guideline I tend to use: Are you building a website or a web application? If you're building a website, you're best off with just static pages or static pages generated dynamically. If you need lots of interactivity and similar, better to build a web application, and React fits well for that purpose.
I wonder if it is safe to say vast majority of websites are simple enough to use the aforementioned pattern? There are so many "Doctors appointment" type dynamic websites that I don't think need anything like React or Angular.
I think React is great if you're building the next Notion or a web-based application such as Google Sheets.
Edit: Yeah, I am new to webdev and I find server side rendering "refreshing" :-)
They work fine for a large chunk of modern websites. And server side templating is not the only concept from that era that is much simpler than what is popular now. Those frameworks were primarily synchronous instead of asynchronous. And they worked in pretty much every browser. Without breaking the back button. With shareable links. And no scrolljacking.
For me personally the sweet spot for many applications/websites is still just that: A synchronous MVC framework with serverside rendering. With a sprinkle of vanilla JS or Vue on select pages for dynamic stuff.
https://laravel.com/docs/8.x/blade#anonymous-components
https://laracasts.com/series/blade-component-cookbook/episod...
This is cute. Somehow it's like Compton limit where at a certain scale you just can't make measurements accurate enough because the very act of measurement interferes with the system.
Companies are grooming the developers so that they will never have difficulty hiring people that can diagnose a broken firewall, but they are not getting faster web pages out of the deal.
I would be surprised if this discussion has not taken place at Airbnb and they apparently decided it did not matter.
You might also want to know how many of your users are actually on slow connections,and how important they are to you.
Yet another reason to not get rid of HTTP in the HTTP+HTTPS world just because it's hip and what big companies are going.
A website that only works on recent kit in high-bandwidth locales with low ping latencies and little packet loss ... acts much the same as a posh high-street address does in dissuading those people one would prefer not to have to face with or address.
(There may be a similar logic to truly atrocious web deisgn, intended to dissuade (literal) tyre kickers, as with LINGsCars: https://ello.co/dredmorbius/post/7TOJTiDEF_L4r_sdBRINGw)
Though this explains the behaviour, it doesn't excuse it. And might well form the basis of discrimination or accessibility lawsuits.
I like that in a person.
Every round trip adds up.
I use Mint Mobile and last month I hit the 4G data cap of my "unlimited" plan (30 Gb). I tried to buy more data, but it can't be done on the "unlimited" plan. I could not buy more data for my "unlimited" data plan after my "unlimited" data plan ran out of data. Other plans let you purchase additional data at an expensive price, only the "unlimited" plan doesn't.
Before you think out loud how simple html is and you still remember doing that a million years ago ask yourself this: do you write now and would you pay to hire someone to do that?
It’s not a job or skill you can be hired for. Instead you have to use React if you want employment. So that’s an immediate 50x swell right there immediately out of the gate and we haven’t even gotten to poor coding practices.
This is all possible, it's just that collectively, web developers have tried so hard to make their discipline as 'complex' as other software engineering domains, that we have destroyed our sense of efficiency, speed, and catering to the worst off end users.
React is great for some tasks, but it's ridiculous for others. Its use can be overengineering, and it presumes that JavaScript execution is always allowed for all websites (which is not true).
Plain HTML, pre-generated as a static site or generated server-side at runtime, is a better solution in many cases. React is great for the things it was designed for.
Fad engineering is just that, a fad. All technologies have situations or cases where they should not be used. People should never use a technology until they understand at least some situations where it should not be used.
Furthermore, that’s only the bottom 10% of America, appealing to their audience appeals to maybe the top percentage of India and Asia as well which are giant markets
Assume that I earn a six figure income and live in a major city with reasonably fast (though not necessarily top tier) Internet. So, y'know, theoretically a fairly desirable customer and not a subsistence farmer or some other demographic that's easy to give the cold shoulder. But still --
Bad Internet day, maybe someone's getting DDoS attacked? If your website isn't lean, I'm more likely to get frustrated by the jank and leave.
It's Friday evening and the Internet is crammed full of Netflix? If your website isn't lean, I'm more likely to get frustrated by the jank and leave.
Neighbor's running some device that leaks a bunch of radio noise and degrades my wifi network? It's Friday evening and the Internet is crammed full of Netflix? If your website isn't lean, I'm more likely to get frustrated by the jank and leave.
I'm connecting from a coffee shop with spotty Internet? If your website isn't lean, I'm more likely to get frustrated by the jank and leave.
I've got 50,000 tabs open and they're all eating up a crapton of RAM? If your website isn't lean, I'm more likely to get frustrated by the jank and leave.
I'm browsing while I've got some background task like a big compile or whatever chewing up my CPU? If your website isn't lean, I'm more likely to get frustrated by the jank and leave.
I'm accessing from my mobile device and I'm in a dead zone (they're common in major cities doncha know)? If your website isn't lean, I'm more likely to get frustrated by the jank and leave.
etc. etc. etc.
Meanwhile, while it may not be the style of the times, it's absolutely possible to make very good looking websites with no or very little JavaScript. Frankly, a lot of them look and feel even better than over-engineered virtual DOM "applications" do. Without all that JavaScript in the way, the UX feels downright snappy. https://standardebooks.org/ is a nice example.
After you get frustrated by the jank and leave, is there anything else you can do except go back because the people and customers and services you need to deal with are using the janky systems, and all the systems are janky these days - and finding ones which aren't, and predicting they will stay that way, and moving to them, is non-trivial?
Most businesses fall into this category. Facebook, Amazon, and Netflix fall into this category. That’s why their reliability engineers are amongst the highest paid engineers in those businesses. They literally cannot afford to be down.
The ironic thing about your argument is that I’ve found recently that the more something costs, the more difficult it is to procure, ESPECIALLY online. Some of the most expensive items out there simply cannot be purchased online end-to-end.
looking to rent an apartment online? Easy. Looking to rent or buy a house? A billion moving parts, with half a million of those parts needing to be done face to face.
Some situations to give your "capitalist devil" pause:
- A train passenger on the way to their summer home enters a tunnel. Packet loss goes through the roof and nothing but HTML loads.
- A hotel room housing an attendee of a local shareholder meeting has awful shared wi-fi.
- Ping speeds plummet on a politician's private jet.
- Someone hoping to buy a new Rolex at the mall can barely connect in the underground parking garage.
Everyone hits the bottom of the bell curve.
- Approx 1 million crew are at sea at the same time on average
The web "development" world is just too messy and hype driven.
What's the solution? Don't write rock music. Focus on classical, jazz, opera, ballet, etc. which has a fewer number of fans with more money who have a better education in appreciating your music. That same concept can be applied to software.
If you're traveling, internet can be unreliable. AirBnb's customers are people who want to travel.
One of the things it does is to remove the need for hundreds of requests to fetch every single image/script in the page (from the client that is). Instead it is only one file to fetch over http. Only that makes a huge difference.
Well, 1MB is way too small, but 1GB is way too large. Conserving resources is important.