16 ms·

The modern web on a slow connection (2017)

222 points by x14km2d 5y ago

habibur 5y ago
The modern web loads the whole website on your first visit, aka SPA. 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.
- bgroat 5y ago
  It isn't
- capableweb 5y ago
  That's last years modern web. This years modern web splits up the JS bundle based on the pages so you only load what's required for each page. So we're basically back to square one. > 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.
- systemvoltage 5y ago
  I really like the idea of server side rendering. Flask/Django style backend and use Jinja2 templates, sprinkle some vanilla JS for interaction if needed. 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" :-)
  - the__alchemist 5y ago
    I do this. It's remarkable this is considered to be a novel pattern! (Note that some of the advances in modern CSS and JS made this more feasible than it used to be)
  - vbsteven 5y ago
    It’s not just an idea. It’s tech that has been around for decades now. Rails, Django, Spring, Laravel, Sinatra, Flask and hundreds of others. 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.
    - pjmlp 5y ago
      Same here, such approaches work and do the job just fine.
  - yurishimo 5y ago
    Since you say you're new, it might be worth looking at Laravel if you learned with the componentized JS approach. The Blade templating language they've been perfecting for years now has started to embrace composable components very similar to a JS framework, but all server-side. https://laravel.com/docs/8.x/blade#anonymous-components https://laravel.com/docs/8.x/blade#anonymous-components https://laracasts.com/series/blade-component-cookbook/episodes/1 https://laracasts.com/series/blade-component-cookbook/episod...
- osrec 5y ago
  That's only when done poorly, which unfortunately has become the norm. Properly done modern websites load things incrementally, as and when they're needed, while cleanly separating the front end logic from the back end.
  - bdcravens 5y ago
    The No True Scotsman argument could also be applied to the technologies that "modern websites" were supposed to replace.
- sneak 5y ago
  The downside of this "modern" approach is that you break the website for anyone with javascript off, or using a text browser.
  - hypertele-Xii 5y ago
    Doesn't it also break basic caching? That is, I can't download a "modern" website to view it offline because it's actually just a rendering shim that needs to phone home for the content?
  - goodpoint 5y ago
    ...also everybody without modern and/or expensive hardware AKA 2 billion people in the world.
- grishka 5y ago
  Most often though, your first visit is your only visit.
k__ 5y ago
Interesting that it mentions the book "High Performance Browser Networking". My feeling after reading it was that latency is all that matters, not page size.
- AlexanderDhoore 5y ago
  Page size becomes latency when your connection is slow.
  - k__ 5y ago
    Yes. Every round trip adds up.
ansgri 5y ago
From a capitalist devil’s advocate point of view: does it really matter that your website works poorly with 90% of the web when these 90% either don’t have any disposable income (there’s got to be a correlation) or are too distant geographically and culturally to ever bring you business? The “commercial quality” (i.e. to avoid looking worse than competition) web development has become unbelievably complicated and expensive, so in reality probably only individual enthusiasts and NCOs should care about the long tail. Local small businesses will just use some local site builder or social media, so even they don’t matter.
- hokumguru 5y ago
  From the other capitalist point of view, wouldn’t it be more ideal to squeeze every single percentage of the market if you could? I think most companies would gladly take a 10% boost in sales. 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
  - pjscott 5y ago
    That depends on how much money it takes to get a bit more of the market and how much money you expect to get from them. Ideally you'd reach the point where those two derivatives are equal, then stop.
- yjftsjthsd-h 5y ago
  That assumes that you can appropriately target the 10% that are profitable. If you can't reliably do that or the profitable 10% isn't 10% with the highest performance computers and connections, then you probably are better served by casting a wide net.
  - blowski 5y ago
    What if, to take advantage of the profitable 10%, you are better off providing a rich page, albeit with a large filesize? I have no evidence to support that claim, other than that large profitable companies generally seem to think this is the case.
thirdplace_ 5y ago
We are soon coming full circle when this generation's programmers realize they can render html templates server-side.
- RedShift1 5y ago
  But there is something to be said for SPAs and slow connections. All the HTML and JS code is loaded beforehand and afterwards only raw data is exchanged. If the API calls can be limited to one call per user action/page visit, the experience would be better because only some API data has to be transferred instead of an entire HTML page. 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.
  - handrous 5y ago
    I very rarely see a "Web App" that's faster due to this. Take Gmail: plain-HTML gmail transfers and renders a whole page faster than full-fat Gmail does most of the things it does, which involve merely "some API data". The activity/loading indicators on normal Gmail display longer than the full-page load on plain-HTML gmail. 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.
    - zozbot234 5y ago
      Makes sense. Roundtrips will kill you on slow connections, and the average SPA does lots of back-and-forth roundtrips. Then the JS code has to tweak hundreds or thousands of DOM nodes in a completely serial fashion to reflect the new data. Much faster in practice to either download or generate (preferably via WASM) a single chunk of raw HTML and let the browser rerender it natively.
      - handrous 5y ago
        It's part of the cause of all the damn memory-bloat , too. Receive some JSON (one copy of the data), parse that and turn it into JS objects (at least two copies allocated, now, depending on how the parsing works), modify that for whatever your in-browser data store is, and/or copy it in there, or copy it to "local state", or whatever (three copies), render the data to the shadow DOM (four copies), render the shadow DOM to the real DOM (five copies). Some of those stages very likely hide even more allocations of memory to hold the same data, as it's transformed and moved around. Lots of library or pattern choices can add more. It adds up.
dustractor 5y ago
Between 2010-2016, I lived in a rural area where we had one option: Satellite internet from HughesNet. Prior to that, the only option was dialup, and since it was such a remote area, the telephone had grandfathered a few numbers from out of the service area as free-to-call, to allow for residents to use the nearest isp without extra toll charges. 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!
- detaro 5y ago
  No neighbor that let you piggyback on their connection? (That of course doesn't change the fundamental shittyness of the overall lack of available access)
  - Causality1 5y ago
    Yes that was my first thought. Offer to pay half the bill and pick up a giant yagi antenna for twenty bucks. Only downside is it's technically illegal to combine that much power and that much gain but I've known people who did it for a decade with no FCC call.
    - afavour 5y ago
      Depending on how far we’re talking you could also just run network cable…
    - labawi 5y ago
      For a link, you mainly need signal-to-noise ratio (SNR). 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
strooper 5y ago
I wonder if the experience improves by using proxy browsers, such as- Opera (lite/mini).
- judge2020 5y ago
  I doubt it since most websites have moved to using geo-distributed CDNs and sometimes app servers anyways.
  - fifilura 5y ago
    I am pretty sure it would, and that is one of the reasons Opera Mini is still very popular in Africa. 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.
superkuh 5y ago
>You can see that for a very small site that doesn’t load many blocking resources, HTTPS is noticeably slower than HTTP, especially on slow connections. 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.
- ev1 5y ago
  This is an old article. 0RTT TLS 1.3 + QUIC is on par with HTTP usually, based on our RUM/telemetry.
  - superkuh 5y ago
    0RRT only applies to connections after the first load. And what cloudflare does is certainly not what most people on the internet (as opposed to most mega-corporations) should do.
- Grimm1 5y ago
  That's a really bad take on HTTPS. HTTP helps to enable a bunch of trivial but damaging attacks on an end user. If you run anything maybe more complicated than a static blog, and even then for your own security, HTTP is the wrong choice.
brundolf 5y ago
I was expecting an empty rant, but this was even-handed and made some good points
- bo1024 5y ago
  If you don't know Dan Luu's blog, I suggest reading the rest!
marcodiego 5y ago
Nevermind connection speed, the modern web is unbearable without ad blockers.
TacticalCoder 5y ago
One of the problem is that a lot of devs have very good connections at home. I've got 600 MBit/s symmetric (optic fiber). Spain, France, now Belgium... It's fiber nearly everywhere. Heck, Andorra has 100% fiber coverage. Japan: my brother has got 2 Gbit/s at home. 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.
- Black101 5y ago
  > Joel is not loading its own site on a 28.8 modem. It's the unevenly distributed future. I hope that no one are... and at least using 56k
  - pjmlp 5y ago
    Preferbly the dual mode versions then.
    - Black101 5y ago
      " Dualmode faxmodems provide high-quality voice mail when used with a soundcard. They also have both Class 1 14.4 Kbps send/receive fax for convenient printer-quality faxing to any faxmodem or fax machine. You can even "broadcast" your faxes to multiple recipients, schedule fax transmission, or forward them to another number. " I don't see the advantages
      - pjmlp 5y ago
        That isn't correct. 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. https://www.amazon.com/dp/B00000JBAI/?shop28-20 https://www.amazon.com/dp/B00000JBAI/?shop28-20
morpheos137 5y ago
what do people think is the best approach to incentivise lean web design? The bloat of the modern web is absolutely ridiculous but it seems to be the inevitable result of piling abstraction on top of abstraction so that you end up with a multimegabyte news article due to keeping up with the latest fad framework.
- tomaskafka 5y ago
  What every large company does - make an employee VPN (for laptops and phones) that simulated poor internet connection (slow, packet loss, lags), to let the developers feel the pain.
  - marcosdumay 5y ago
    The joke is on them (well, yeah, but figuratively too). The VPN is only slow for external sites that the developers can not fix, while internal ones load at the full speed the middlebox can handle. 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.
- MattGaiser 5y ago
  I think you would need to prove that it matters in terms of increasing revenue and is more valuable than other things you can spend your engineers on. I would be surprised if this discussion has not taken place at Airbnb and they apparently decided it did not matter.
- nicbou 5y ago
  Include slow machines in your QA process,just like you include certain operating systems and browsers. You might also want to know how many of your users are actually on slow connections,and how important they are to you.
istillwritecode 5y ago
For many advertising-based websites, the value of the user is often proportional to their bandwidth.
dghughes 5y ago
The problem with comparing the Internet now vs 25 years ago is back then you didn't live on the Internet all your waking hours. You jumped on, got what you needed and got off again otherwise you'd be paying a high hourly premium. And to top that off you'd power off your computer and cover it and the monitor with a dust cover. 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.
- gscott 5y ago
  Plus 25 years ago images were a few k in size. Now with the average webpage being a megabyte in size, it is outrageous.
  - tomjen3 5y ago
    The images were a few kilobytes in size because they were 120x80 pixels GIFs. 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.
    - afavour 5y ago
      Actually in terms of bandwidth JavaScript isn’t the problem, you can fit an entire SPA into the bandwidth required for one large image (it is a problem in terms of CPU usage on underpowered devices though) 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?)
      - edflsafoiewq 5y ago
        Some browsers used to have "click to show image" too. I know dillo did. Actually, come to think of it, its browsers that have really dropped the ball on helping out users with slow connections.
- 5y ago
Tade0 5y ago
> If you think browsing on a 56k connection is bad, try a 16k connection from Ethiopia! 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 -Google Meet -Facebook Messenger -Hacker News The rest of the web would often break or not load at all.
johnmorrison 5y ago
This article gave me a random push to nuke the size of my site - just brought it down from ~50 kB on text pages all the way to ~1.5 kB now, and from 14 files to 1 HTML file.
0xbadcafebee 5y ago
> I probably sound like that dude who complains that his word processor, which used to take 1MB of RAM, takes 1GB of RAM Well, 1MB is way too small, but 1GB is way too large. Conserving resources is important.
giantrobot 5y ago
The performance numbers are a really helpful illustration of the problem with a lot of sites. A detail it misses and I see people constantly forget, is any individual user might have one of those crappy connections at multiple points during the day or even move through all of them. 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.
- ajsnigrutin 5y ago
  Yep... in large stores like ikea, i've had huge problems with my connection falling down to 2g speeds, and finding anything online was a huge pain in the ass. First thing to load should be the page layout with text already inside, then images, then everything else... some pages ignore this, load nothing + a huge JS library, then start with random crap, and i get bored and close my browser, before i get the actual text.
- nicbou 5y ago
  Yes! A subset of your users will access your website from public transportation, where reception can be significantly worse. I specifically designed my website to work reasonably fast on the Berlin U-Bahn, where some of my readers are likely to be.
  - giantrobot 5y ago
    I experienced this problem just yesterday which I found ironic since I had recently posted about it. I was in Home Depot and couldn't find what I was looking for. So I pulled up the website to see if it says they're in stock to ask an employee. It took me wandering the store for a few minutes to get a good enough signal to load the damn web page. 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.
hackernewslol 5y ago
YES! I've started using Tailwind and Alpine (with no other frontend framework). A basic page with a couple of images, a nice UI, animations, etc only takes up ~250kb gzipped. It loads quickly on practically any connection, is well-optomized, and generally just works really well. The users love it too. Coupled with a fast templating system and webserver (server-side in Go is my personal favorite but there are plenty of others), it isn't hard to get a modern featureset and UI with under 300kb. I hope the push for a faster internet continues. Load-all-the-things is great until you're on a bad connection. Sourcehut comes to mind as a great model/example, using a simple JS-less UI and Go server-side rendering.
MarkusWandel 5y ago
My mom's cellular data plan (used for rural internet access through a cellular/wifi router) has a 128kbps fallback if you use up your main data allotment. 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.
jart 5y ago
Finally, an influential developer who cares about the other 99%. 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.
- icedchai 5y ago
  I had an ISDN connection at home in the mid 90's. In many ways, it felt faster than today's broadband because the web was still built for dial up. I later upgraded to an early cable modem sometime around 1998 (3 megabits, I think.) The web was still, very much, built for dialup and things felt incredibly fast. Despite having a connection orders of magnitude faster today, things feel far more bloated and sluggish. Bloated web sites are everywhere.
  - jart 5y ago
    Just get a Ryzen CPU with business class gigabit internet and block display ads and third party cookies. The wild-eyed web frameworks and advertisements of our age were designed to consume the glut created by the cheapest silver status symbol, on which they now press the limits of not only bandwidth, but also CPUs and RAM too. For me I think it was around 2015 when I started feeling the heat of my Macbook scorching my legs each time I loaded a news website. I thought, oh my, am I being swept away by the performance tide already? So if your box is twice as fast as those things, then the modern web will feel fast. What's sad is most people aren't even granted that choice.
austincheney 5y ago
Part of the problem is that writing html is lost knowledge. Extinct. 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.
- phist_mcgee 5y ago
  We've invented abstractions that exceed our common ability to reason about their base building blocks. I think most websites should be just pure html, minimal inline styling so you don't get page flicker, and a small sprinkling of <script asyc/defer> to give you some async server functionality. That's it. 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.
- dwheeler 5y ago
  It may be extinct in some places, but in many others HTML knowledge is quite alive. 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.
- robertoandred 5y ago
  What? You need HTML to write a React site.
carapace 5y ago
Kind of a tangent but (for reasons) I have a workstation on which I didn't want to install a full-fledged browser so I'm using Dillo, https://www.dillo.org/ https://www.dillo.org/ > 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/ 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.
- majjgepolja 5y ago
  What's difference compared to using Chrome / Firefox with Noscript / UBO to block JS by default?
  - carapace 5y ago
    Try Dillo and find out. :)
- maple3142 5y ago
  Not supporting SNI is the browser's problem IMO, because SNI are required to enable a single IP to host multiple HTTPS websites. SNI is not just for CloudFlare.
aimor 5y ago
Is there any cellular phone service that throttles to a usable speed (say at least 1.5 Mbps)? I was looking forward to the spread of 4G because I naively thought throttled speeds would also increase to "3G equivalent" instead of "2G equivalent". 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.
- BenjiWiebe 5y ago
  Some don't throttle at all. But they aren't as cheap as Mint Mobile. However, Mint says that videos will stream at 480p after you've used 35GB/mo. If that's true, isn't that a lot faster than 2G?
  - aimor 5y ago
    Those are two separate sentences. All video streaming is capped at 480p, even if 4G data speeds are enabled.
dredmorbius 5y ago
A realisation I had a few years ago was that differential accessibility to websites is quite likely market segmentation technique, whether used intentionally or otherwise. 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 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.
- jeegsy 5y ago
  I'm sorry but I absolutely love the ling's car website!
  - dredmorbius 5y ago
    You are a sick and twisted individual. I like that in a person.
ilammy 5y ago
> For another level of ironic, consider that while I think of a 50kB table as bloat, this page is 12kB when gzipped, even with all of the bloat. Google's AMP currently has > 100kB of blocking javascript that has to load before the page loads! There's no reason for me to use AMP pages because AMP is slower than my current setup of pure HTML with a few lines of embedded CSS and the occasional image, but, as a result, I'm penalized by Google (relative to AMP pages) for not "accelerating" (deccelerating) my page with AMP. 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.

222 points by x14km2d 5y ago

The modern web loads the whole website on your first visit, aka SPA. 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.

bgroat 5y ago
It isn't
capableweb 5y ago
That's last years modern web. This years modern web splits up the JS bundle based on the pages so you only load what's required for each page. So we're basically back to square one. > 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.
systemvoltage 5y ago
I really like the idea of server side rendering. Flask/Django style backend and use Jinja2 templates, sprinkle some vanilla JS for interaction if needed. 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" :-)
- the__alchemist 5y ago
  I do this. It's remarkable this is considered to be a novel pattern! (Note that some of the advances in modern CSS and JS made this more feasible than it used to be)
- vbsteven 5y ago
  It’s not just an idea. It’s tech that has been around for decades now. Rails, Django, Spring, Laravel, Sinatra, Flask and hundreds of others. 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.
  - pjmlp 5y ago
    Same here, such approaches work and do the job just fine.
- yurishimo 5y ago
  Since you say you're new, it might be worth looking at Laravel if you learned with the componentized JS approach. The Blade templating language they've been perfecting for years now has started to embrace composable components very similar to a JS framework, but all server-side. https://laravel.com/docs/8.x/blade#anonymous-components https://laravel.com/docs/8.x/blade#anonymous-components https://laracasts.com/series/blade-component-cookbook/episodes/1 https://laracasts.com/series/blade-component-cookbook/episod...
osrec 5y ago
That's only when done poorly, which unfortunately has become the norm. Properly done modern websites load things incrementally, as and when they're needed, while cleanly separating the front end logic from the back end.
- bdcravens 5y ago
  The No True Scotsman argument could also be applied to the technologies that "modern websites" were supposed to replace.
sneak 5y ago
The downside of this "modern" approach is that you break the website for anyone with javascript off, or using a text browser.
- hypertele-Xii 5y ago
  Doesn't it also break basic caching? That is, I can't download a "modern" website to view it offline because it's actually just a rendering shim that needs to phone home for the content?
- goodpoint 5y ago
  ...also everybody without modern and/or expensive hardware AKA 2 billion people in the world.
grishka 5y ago
Most often though, your first visit is your only visit.

k__ 5y ago

Interesting that it mentions the book "High Performance Browser Networking". My feeling after reading it was that latency is all that matters, not page size.

AlexanderDhoore 5y ago
Page size becomes latency when your connection is slow.
- k__ 5y ago
  Yes. Every round trip adds up.

ansgri 5y ago

From a capitalist devil’s advocate point of view: does it really matter that your website works poorly with 90% of the web when these 90% either don’t have any disposable income (there’s got to be a correlation) or are too distant geographically and culturally to ever bring you business? The “commercial quality” (i.e. to avoid looking worse than competition) web development has become unbelievably complicated and expensive, so in reality probably only individual enthusiasts and NCOs should care about the long tail. Local small businesses will just use some local site builder or social media, so even they don’t matter.

hokumguru 5y ago
From the other capitalist point of view, wouldn’t it be more ideal to squeeze every single percentage of the market if you could? I think most companies would gladly take a 10% boost in sales. 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
- pjscott 5y ago
  That depends on how much money it takes to get a bit more of the market and how much money you expect to get from them. Ideally you'd reach the point where those two derivatives are equal, then stop.
yjftsjthsd-h 5y ago
That assumes that you can appropriately target the 10% that are profitable. If you can't reliably do that or the profitable 10% isn't 10% with the highest performance computers and connections, then you probably are better served by casting a wide net.
- blowski 5y ago
  What if, to take advantage of the profitable 10%, you are better off providing a rich page, albeit with a large filesize? I have no evidence to support that claim, other than that large profitable companies generally seem to think this is the case.

thirdplace_ 5y ago

We are soon coming full circle when this generation's programmers realize they can render html templates server-side.

RedShift1 5y ago
But there is something to be said for SPAs and slow connections. All the HTML and JS code is loaded beforehand and afterwards only raw data is exchanged. If the API calls can be limited to one call per user action/page visit, the experience would be better because only some API data has to be transferred instead of an entire HTML page. 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.
- handrous 5y ago
  I very rarely see a "Web App" that's faster due to this. Take Gmail: plain-HTML gmail transfers and renders a whole page faster than full-fat Gmail does most of the things it does, which involve merely "some API data". The activity/loading indicators on normal Gmail display longer than the full-page load on plain-HTML gmail. 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.
  - zozbot234 5y ago
    Makes sense. Roundtrips will kill you on slow connections, and the average SPA does lots of back-and-forth roundtrips. Then the JS code has to tweak hundreds or thousands of DOM nodes in a completely serial fashion to reflect the new data. Much faster in practice to either download or generate (preferably via WASM) a single chunk of raw HTML and let the browser rerender it natively.
    - handrous 5y ago
      It's part of the cause of all the damn memory-bloat , too. Receive some JSON (one copy of the data), parse that and turn it into JS objects (at least two copies allocated, now, depending on how the parsing works), modify that for whatever your in-browser data store is, and/or copy it in there, or copy it to "local state", or whatever (three copies), render the data to the shadow DOM (four copies), render the shadow DOM to the real DOM (five copies). Some of those stages very likely hide even more allocations of memory to hold the same data, as it's transformed and moved around. Lots of library or pattern choices can add more. It adds up.

dustractor 5y ago

Between 2010-2016, I lived in a rural area where we had one option: Satellite internet from HughesNet. Prior to that, the only option was dialup, and since it was such a remote area, the telephone had grandfathered a few numbers from out of the service area as free-to-call, to allow for residents to use the nearest isp without extra toll charges. 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!

detaro 5y ago
No neighbor that let you piggyback on their connection? (That of course doesn't change the fundamental shittyness of the overall lack of available access)
- Causality1 5y ago
  Yes that was my first thought. Offer to pay half the bill and pick up a giant yagi antenna for twenty bucks. Only downside is it's technically illegal to combine that much power and that much gain but I've known people who did it for a decade with no FCC call.
  - afavour 5y ago
    Depending on how far we’re talking you could also just run network cable…
  - labawi 5y ago
    For a link, you mainly need signal-to-noise ratio (SNR). 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

strooper 5y ago

I wonder if the experience improves by using proxy browsers, such as- Opera (lite/mini).

judge2020 5y ago
I doubt it since most websites have moved to using geo-distributed CDNs and sometimes app servers anyways.
- fifilura 5y ago
  I am pretty sure it would, and that is one of the reasons Opera Mini is still very popular in Africa. 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.

superkuh 5y ago

>You can see that for a very small site that doesn’t load many blocking resources, HTTPS is noticeably slower than HTTP, especially on slow connections. 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.

ev1 5y ago
This is an old article. 0RTT TLS 1.3 + QUIC is on par with HTTP usually, based on our RUM/telemetry.
- superkuh 5y ago
  0RRT only applies to connections after the first load. And what cloudflare does is certainly not what most people on the internet (as opposed to most mega-corporations) should do.
Grimm1 5y ago
That's a really bad take on HTTPS. HTTP helps to enable a bunch of trivial but damaging attacks on an end user. If you run anything maybe more complicated than a static blog, and even then for your own security, HTTP is the wrong choice.

brundolf 5y ago

I was expecting an empty rant, but this was even-handed and made some good points

bo1024 5y ago
If you don't know Dan Luu's blog, I suggest reading the rest!

marcodiego 5y ago

Nevermind connection speed, the modern web is unbearable without ad blockers.

TacticalCoder 5y ago

One of the problem is that a lot of devs have very good connections at home. I've got 600 MBit/s symmetric (optic fiber). Spain, France, now Belgium... It's fiber nearly everywhere. Heck, Andorra has 100% fiber coverage. Japan: my brother has got 2 Gbit/s at home. 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.

Black101 5y ago
> Joel is not loading its own site on a 28.8 modem. It's the unevenly distributed future. I hope that no one are... and at least using 56k
- pjmlp 5y ago
  Preferbly the dual mode versions then.
  - Black101 5y ago
    " Dualmode faxmodems provide high-quality voice mail when used with a soundcard. They also have both Class 1 14.4 Kbps send/receive fax for convenient printer-quality faxing to any faxmodem or fax machine. You can even "broadcast" your faxes to multiple recipients, schedule fax transmission, or forward them to another number. " I don't see the advantages
    - pjmlp 5y ago
      That isn't correct. 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. https://www.amazon.com/dp/B00000JBAI/?shop28-20 https://www.amazon.com/dp/B00000JBAI/?shop28-20

morpheos137 5y ago

what do people think is the best approach to incentivise lean web design? The bloat of the modern web is absolutely ridiculous but it seems to be the inevitable result of piling abstraction on top of abstraction so that you end up with a multimegabyte news article due to keeping up with the latest fad framework.

tomaskafka 5y ago
What every large company does - make an employee VPN (for laptops and phones) that simulated poor internet connection (slow, packet loss, lags), to let the developers feel the pain.
- marcosdumay 5y ago
  The joke is on them (well, yeah, but figuratively too). The VPN is only slow for external sites that the developers can not fix, while internal ones load at the full speed the middlebox can handle. 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.
MattGaiser 5y ago
I think you would need to prove that it matters in terms of increasing revenue and is more valuable than other things you can spend your engineers on. I would be surprised if this discussion has not taken place at Airbnb and they apparently decided it did not matter.
nicbou 5y ago
Include slow machines in your QA process,just like you include certain operating systems and browsers. You might also want to know how many of your users are actually on slow connections,and how important they are to you.

istillwritecode 5y ago

For many advertising-based websites, the value of the user is often proportional to their bandwidth.

dghughes 5y ago

The problem with comparing the Internet now vs 25 years ago is back then you didn't live on the Internet all your waking hours. You jumped on, got what you needed and got off again otherwise you'd be paying a high hourly premium. And to top that off you'd power off your computer and cover it and the monitor with a dust cover. 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.

gscott 5y ago
Plus 25 years ago images were a few k in size. Now with the average webpage being a megabyte in size, it is outrageous.
- tomjen3 5y ago
  The images were a few kilobytes in size because they were 120x80 pixels GIFs. 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.
  - afavour 5y ago
    Actually in terms of bandwidth JavaScript isn’t the problem, you can fit an entire SPA into the bandwidth required for one large image (it is a problem in terms of CPU usage on underpowered devices though) 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?)
    - edflsafoiewq 5y ago
      Some browsers used to have "click to show image" too. I know dillo did. Actually, come to think of it, its browsers that have really dropped the ball on helping out users with slow connections.
5y ago

Tade0 5y ago

> If you think browsing on a 56k connection is bad, try a 16k connection from Ethiopia! 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 -Google Meet -Facebook Messenger -Hacker News The rest of the web would often break or not load at all.

johnmorrison 5y ago

This article gave me a random push to nuke the size of my site - just brought it down from ~50 kB on text pages all the way to ~1.5 kB now, and from 14 files to 1 HTML file.

0xbadcafebee 5y ago

> I probably sound like that dude who complains that his word processor, which used to take 1MB of RAM, takes 1GB of RAM Well, 1MB is way too small, but 1GB is way too large. Conserving resources is important.

giantrobot 5y ago

The performance numbers are a really helpful illustration of the problem with a lot of sites. A detail it misses and I see people constantly forget, is any individual user might have one of those crappy connections at multiple points during the day or even move through all of them. 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.

ajsnigrutin 5y ago
Yep... in large stores like ikea, i've had huge problems with my connection falling down to 2g speeds, and finding anything online was a huge pain in the ass. First thing to load should be the page layout with text already inside, then images, then everything else... some pages ignore this, load nothing + a huge JS library, then start with random crap, and i get bored and close my browser, before i get the actual text.
nicbou 5y ago
Yes! A subset of your users will access your website from public transportation, where reception can be significantly worse. I specifically designed my website to work reasonably fast on the Berlin U-Bahn, where some of my readers are likely to be.
- giantrobot 5y ago
  I experienced this problem just yesterday which I found ironic since I had recently posted about it. I was in Home Depot and couldn't find what I was looking for. So I pulled up the website to see if it says they're in stock to ask an employee. It took me wandering the store for a few minutes to get a good enough signal to load the damn web page. 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.

hackernewslol 5y ago

YES! I've started using Tailwind and Alpine (with no other frontend framework). A basic page with a couple of images, a nice UI, animations, etc only takes up ~250kb gzipped. It loads quickly on practically any connection, is well-optomized, and generally just works really well. The users love it too. Coupled with a fast templating system and webserver (server-side in Go is my personal favorite but there are plenty of others), it isn't hard to get a modern featureset and UI with under 300kb. I hope the push for a faster internet continues. Load-all-the-things is great until you're on a bad connection. Sourcehut comes to mind as a great model/example, using a simple JS-less UI and Go server-side rendering.

MarkusWandel 5y ago

My mom's cellular data plan (used for rural internet access through a cellular/wifi router) has a 128kbps fallback if you use up your main data allotment. 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.

jart 5y ago

Finally, an influential developer who cares about the other 99%. 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.

icedchai 5y ago
I had an ISDN connection at home in the mid 90's. In many ways, it felt faster than today's broadband because the web was still built for dial up. I later upgraded to an early cable modem sometime around 1998 (3 megabits, I think.) The web was still, very much, built for dialup and things felt incredibly fast. Despite having a connection orders of magnitude faster today, things feel far more bloated and sluggish. Bloated web sites are everywhere.
- jart 5y ago
  Just get a Ryzen CPU with business class gigabit internet and block display ads and third party cookies. The wild-eyed web frameworks and advertisements of our age were designed to consume the glut created by the cheapest silver status symbol, on which they now press the limits of not only bandwidth, but also CPUs and RAM too. For me I think it was around 2015 when I started feeling the heat of my Macbook scorching my legs each time I loaded a news website. I thought, oh my, am I being swept away by the performance tide already? So if your box is twice as fast as those things, then the modern web will feel fast. What's sad is most people aren't even granted that choice.

austincheney 5y ago

Part of the problem is that writing html is lost knowledge. Extinct. 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.

phist_mcgee 5y ago
We've invented abstractions that exceed our common ability to reason about their base building blocks. I think most websites should be just pure html, minimal inline styling so you don't get page flicker, and a small sprinkling of <script asyc/defer> to give you some async server functionality. That's it. 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.
dwheeler 5y ago
It may be extinct in some places, but in many others HTML knowledge is quite alive. 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.
robertoandred 5y ago
What? You need HTML to write a React site.

carapace 5y ago

Kind of a tangent but (for reasons) I have a workstation on which I didn't want to install a full-fledged browser so I'm using Dillo, https://www.dillo.org/ https://www.dillo.org/ > 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/ 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.

majjgepolja 5y ago
What's difference compared to using Chrome / Firefox with Noscript / UBO to block JS by default?
- carapace 5y ago
  Try Dillo and find out. :)
maple3142 5y ago
Not supporting SNI is the browser's problem IMO, because SNI are required to enable a single IP to host multiple HTTPS websites. SNI is not just for CloudFlare.

aimor 5y ago

Is there any cellular phone service that throttles to a usable speed (say at least 1.5 Mbps)? I was looking forward to the spread of 4G because I naively thought throttled speeds would also increase to "3G equivalent" instead of "2G equivalent". 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.

BenjiWiebe 5y ago
Some don't throttle at all. But they aren't as cheap as Mint Mobile. However, Mint says that videos will stream at 480p after you've used 35GB/mo. If that's true, isn't that a lot faster than 2G?
- aimor 5y ago
  Those are two separate sentences. All video streaming is capped at 480p, even if 4G data speeds are enabled.

dredmorbius 5y ago

A realisation I had a few years ago was that differential accessibility to websites is quite likely market segmentation technique, whether used intentionally or otherwise. 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 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.

jeegsy 5y ago
I'm sorry but I absolutely love the ling's car website!
- dredmorbius 5y ago
  You are a sick and twisted individual. I like that in a person.

ilammy 5y ago

> For another level of ironic, consider that while I think of a 50kB table as bloat, this page is 12kB when gzipped, even with all of the bloat. Google's AMP currently has > 100kB of blocking javascript that has to load before the page loads! There's no reason for me to use AMP pages because AMP is slower than my current setup of pure HTML with a few lines of embedded CSS and the occasional image, but, as a result, I'm penalized by Google (relative to AMP pages) for not "accelerating" (deccelerating) my page with AMP. 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.