Slow connection is okay, it's just slow. Now spotty connection, or high latency, that's the killer.
Webapps that make 50 requests to download all the JavaScript and CSS and talk to the API and get 3 images really really really don't behave well when 12 of those 50 requests fail or take 30 seconds to complete. Honestly, I'd rather have slow internet than packet lossy internet.
Still don't know why, but my Xfinity router routinely gets into a state where it drops the first 10 or so packets of any request. The first `ping 8.8.8.8` takes 3 seconds, the rest are the usual 0.1 second. Terrible.
Sad thing is that most of the web sucks on rather fast connections too. Pages being almost 5mb of data, making multiple dozens of requests for librairies and ads. Ads updating in the background, consuming evermore data.
I don't notice it much on my PC, since I've got a FTTH connection, but on LTE and 3G, it's very noticeable. Enough that I avoid certain websites. And that's nowhere near slow by his standards.
I do agree that everyone would benefit from slimmer websites.
I also use an add-on called Decentraleyes. It caches various common scripts from popular CDNs within the add-on itself so your device doesn't need to make any network requests for them. It was originally meant as a privacy to but the caching seems to be at least as valuable.
I have Javascript off-by-default, and about 80% of the time it simply makes everything better.
Oh, sure, a few sites need JS (and get whitelisted) and some just have minor layout quirks... But I can actually scroll down and read the text of a news article rather than suffering through waiting times and input-latency as Javascript churns.
Figure out a few interesting/useful websites that work fine without Javascript. Try browsing those for half an hour, then switch Javascript back on and browse your usual websites. You'll probably notice it's so much slower, even with FTTH, because of network load but also CPU (and marginally RAM, though modern browsers are mostly to blame for that).
Wow, really? Who knew overuse of JS and fancy graphical effects where they're not needed could negatively impact user experience? Could it be that all the web devs using 20 CDNs, cramming 900 frameworks, 100 externally provided analytics, advertisement providers and fancy layout eye-candy were wrong all along? What a surprise!
I'm already sick when I have to visit a webpage and it won't even load ANYTHING if I don't enable scripts on it. At least load the god damn text, I don't care if it'll look like trash, just don't show me a blank page...
The irony is that everyone calls for people to not use Flash, and then they go out of their way to recreate the abysmal experience without it, so really nothing changed as far as UX goes. Remember when pages didn't load at all unless you had flash installed? Well here's some nostalgia for you, won't load unless you run all the JS on the page and then you have to "enjoy" a bloated joke of a website, but Jesus does it have eye-candy!!!
>Wow, really? Who knew overuse of JS and fancy graphical effects where they're not needed could negatively impact user experience?
Clearly not enough people, because it keeps happening. I think it would also help if people kept in mind that the internet is global, it isn't just for developed nations.
It's not a matter of whether the internet is global, its who your audience is... if you audience is primarily in developed nations, then the rest of the world isn't much of an issue.
If you're running a purely domestic web store, maybe, but people in developing nations are not that different from people in developed nations, they can be just as interested in a a wide variety of topics, that's what makes the internet so appealing and wonderful.
Sure, we're humans and all, but jmcdiesel isn't saying that people in the developing world aren't interested in similar things, just that many businesses do have audiences which are limited to certain countries.
Much of the internet is a business, not a passion project. There are plenty of businesses that are completely OK with being inaccessible to users on 2g/3g in the developing world.
Even if you're running an international web store, shipping to developing countries plus the increased rate of fraud and different payment technologies generally mean that you're not keen to expand to those places anytime soon.
Even if your audience members are global, the west is going to be where most of your revenue streams are going to be. If you are facebook it may be worth optimizing for rural India, because they have few places left to grow, but for most companies it is just not worth it - and companies exist to make money.
Honestly, they don't even look that great. Lots of sites could be using lots of modern browser features to be fairly innovative from a visual design and user experience standpoint, but it's mostly just really inefficient (and inaccessible, with no compat fallbacks) implementations of the same old shit.
Everyone thought it was silly when I did that for my site (minimal css, no js, static pages with hugo). But yea I agree, that's the right future for the web and design.
> bring back the 1999 frame side bar. what was wrong with that?
That's funny. Back in the day, every Real web developer learned that frames are Evil and must be abolished, because they are breaking the back button and now the poor user can't provide a link to the view he sees, because the state of all the frames isn't encoded in the URL.
Then web2.0 happened and all the Cool web devs knew it's the time to start abusing ajax, use modal dialogs, break the back button, and turn simple websites serving text and images into complex stateful web apps and in doing so, ensure that people don't have nice URLs that encode the view they see, for linking.
Every time I get angry about this I'll open https://purecss.io/ or http://skytorrents.in and look at the source. It's a form of meditation to browse fast websites.
JavaScript is not the enemy here, it's very possible and easy to make full SPAs with judicious use of micro libs, lazy loading of images/assets, non-blocking styles/fonts/code, and ad-free. The problem is just not caring or knowing - misuse of the technology, rather than the technology itself.
Agreed. I really enjoy building static websites. With no databases, no server-side logic or caching, everything becomes extremely fast and simple. It does mean moving any logic to the client-side with Javascript though.
I completely agree. I think the problem is that bad designers are misusing a good tool. It's like salt: If I add a little to my meal, it makes it better. If I add a LOT of it to my meal, it doesn't keep getting better.
Unfortunately this causes a knee-jerk reaction to anything JS. Although I don't think JS is to blame, I think the hatred of JS comes from a good reason.
Lazy loading really sucks when you're left with a blurry image because it timed out while serving the full image (can happen even with an acceptable connection).
Unless it's really clever I'd prefer if they just let the browser do it's thing with an img tag, because that worked fine in the 56K times.
Many younger devs may have never lived outside of large, very-well connected cities (NY, Chicago, West Coast, etc.). They may assume that everyone has the connectivity and speeds that they do, or in the least they may not fully understand with 1.5 Mbps down really feels like.
I'm torn here, in a way. On the one hand light page weights and other such optimizations make the internet better for everyone, on the other, there's a certain point where designing your product to target 3 decades ago (we forget 1990 was 27 years ago) gets a little absurd.
I think the greater tragedy is not that the web is bloated (an issue for sure), but that so much of America has internet worse than 3rd world mobile 2G.
The bloat affects us today. A page that's impossible to load on dialup is also going to make broadband viewing extremely sluggish and unresponsive. Each click feels like a risk, especially when even the "back" button comes with 200 ad scripts that have to spin up again.
56k modem spec (V.90) appeared in 1998, so that's just two decades ago. And of course 3G networks appeared mostly in 2004 (in Europe) with (very theoretical) data rates up to 384kbps. About that same era, I recall 256-512 kbps DSL subscriptions being very common. And I can promise that browsing modern web with <512k connection (possibly with quite a bit of latency) will not be very comfortable.
No need to "target 3 decades ago", just be reasonable.
> Popular themes for many different kinds of blogging software and CMSs contain anti-optimizations so blatant that any programmer, even someone with no front-end experience, can find large gains by just pointing webpagetest at their site and looking at the output.
That's a compromise. Too many sites don't deal well with thin browsers, but I need space for my terminals. This width usually works, although I sometimes have to do a bit of horizontal scrolling to get the article fully visible. (As opposed to the sadly inevitable sidebars.)
You're free to narrow your browser window — that's what I used to do, before all web sites decided that they know better than I do what width their text should be.
you don't need to travel from Wisconsin to Washington to experience a slow internet connection.
Try any mainstream commute on the South West Trains Wimbledon to Waterloo (London) and you'll a) still get blackouts for about 1/4 of the 25 minute trip (this is one of the most densely populated areas in Europe - no excuses) and b) at 3 of the 4 stations you'll stop at, your vaunted 4g connection will drop to 1998 speeds due to contention. I generally curse the complex sites in these situations because you'll easily be waiting 30-90 seconds (firmly in your heatmap's red zone) for full load at least once per commute.
Incidentally, kudos on perfectly communicative yet lightweight web page (50Kb).
Agreed. It's not just "third world countries" that have slow connections. Low powered devices have slow connections. Places where there are lots of people with portable devices have slow connections. This is now not a long time ago, nor far far away. The more wearables and IoT becomes a "thing" you're going to find that attempting to get more interactions by saving on transmission and client CPU load is worth the investment.
Joey Hess (joeyh) has been writing about this for a long time (because he uses dial-up at his home). Here is a recent thread about a 2016 blog post on this:
1. There is extra connection information, or information can be sampled. E.g. query to see if anything is responding.
2. Our user just wants to get action ASAP. Not necessary to be a good citizen, our user just wants it to work.
3. Heuristics depend on what works in practice. HTTP/S is a comp layered protocol so it is hard to know what is right.
4. Connection conditions are extremely varied, mobile connection type, overseas location, ISP, IPv6, proxies, VPNs, etc all affect the connection parameters so finding a reasonable heuristic is hard.
5. Sampling connection information is difficult, because when it fails you also fall to log it.
I'd say that blanket advice to retry is not terrible but not great either. First ask, is the ajax call important enough to warrent a retry at all, if it is, did the response give any useful information about why there was a failure? If yes, did it tell you that something was wrong with the request? Then don't retry as it's not going to work the second time, or third time either. Did the request timeout? Again, think about whether the request is important enough to hit a potentially already overloaded server.
Also, as a side note, any page that becomes unusable because an ajax request failed to return has some really broken design. Ajax retries are not a solution for that, go fix the design instead.
My team has just started work on a new SaaS product. We are taking articles like this to heart and aiming to keep pages light and fast. We are using very little JavaScript.
Let's see if the market rewards us or punishes us for this approach...
There are more than enough other ways for the market to punish you. :-/
Your approach helps with reliability (fewer 3rd-party and browser needs) and accessibility (workable with lynx and screen readers) too. Latency makes people want to scream.
It's also important to remember that, to the customer, you are just another browser tab. The customer's computer is not dedicated to you. They could have 100 or more other tabs open. The customer may even have reason to open more than one copy of your site simultaneously, with same or different login, and same or different browser. Bogging down their computer makes them unhappy and resentful.
I'm not gonna lie, if my fat high-res site images make life a lil harder in Vanuatu but convert a bunch of black-turtleneck d-bags in San Francisco to customers, I know which side of the bread the butter is on.
I think thats probably part of the point of the article. I would read it less of a statement like "make you webpages smaller", and read it more as "be aware of the bloat of modern webpages".
If your target audience has great internet, then ignore optimising for size. But be aware that people travel, and your market may change, so what is ok in SF may become unusable if they go on holidays, move offices or need to work of roaming data due to an outage.
Ah, I'm just joking around. Mostly. ;) I agree with and mostly implement the vast majority of google's recommendations vis a vis site weight and speed (when I have time/budget to do so), because I regard making sites fast as a signifier of competent professionalism. Any hack can make a sucky, slow, heavy website. Making a website that really cooks is one of several things I use to justify my rate. ;)
> Why shouldn’t the web work with dialup or a dialup-like connection?
Because we have the capability to work beyond that capacity now in most cases. That's like asking "why shouldn't we allow horses on our highways?"
> Pretty much everything I consume online is plain text, even if it happens to be styled with images and fancy javascript.
No doubt, pretty much everyone who works on web apps for long enough understands that it's total madness. The cost however, in supporting people so far behind as to only be able to serve them text is quite frankly unmanageable. The web has grown dramatically over the past 20 years both in terms of physical scale and supported media types.
The web is becoming a platform delivery service for complex applications. Some people like to think of the web as just hyper text, and everything on it should be human parse-able. For me, as someone who has come late to the game, it has never seemed that way. The web is where I go to do things: work, learn, consume, watch, play. It's a tool that allows me to access the interfaces I use in my daily life. I think there's a ton of value in this, perhaps more than as a platform for simple reading news and blogs.
I look forward to WebAssembly and other advancements that allow us to treat the web as we once treated desktop environments, at the expense of human readability. It doesn't mean we need to abandon older + simpler protocols, because they too serve a purpose. But to stop technological advancement in order to appease the lowest common denominator seems silly to me.
> Because we have the capability to work beyond that capacity now in most cases. That's like asking "why shouldn't we allow horses on our highways?"
Adding to your analogy, the JS bloat mentioned in the article is like driving a semi-truck carrying only one carton of oranges. It's a lot of extra waste for a very slight benefit.
I don't think the point is that everything should be human parse-able. But most things on the web are not complex applications. Dan Luu isn't trying to use Google Maps over HSCSD, he's trying to read hypertext blogs and Twitter. Do you seriously think Twitter qualifies as a "complex application"?
The concept behind Twitter? No. Twitter? Maybe..? They have a user experience they want to deliver to 9X% of their users, so they optimize for that. For most of Twitter's users, their connection speeds aren't the limiting factor in their experience. If you optimize for the lowest common denominator, that 9X% almost certainly gets a worse experience.
It's not always a tradeoff. Several sites stopped serving CSS during the Superbowl (https://twitter.com/jensimmons/status/828415747625992192). At a smaller scale, the same thing happens to some sites that reach the HN front-page.
It depends on exactly the costs are. But in that example, those sites are spending millions on Superbowl ads, and it's probably their highest day of traffic, so it's not "almost no benefit".
* There is no proof in your statement that currrently 9X% of their users have fast internet connection.
* Even so, it would simply be an artefact of them never bothering to optimize for people with slower internet connections. If they did optimize, a lot of their traffic would come from the so called "lowest common denominator" just as the blog post says it did for Google.
* Finally I find the term "lowest common denominator" misrepresentative because it implies that optimization needs to cater to the slowest connection on earth, which is clearly not the case. If the average speed is above 90% of internet connections (as per Akamai report cited in the blog post) then the distribution of internet speeds is clearly skewed and there's value trying to even cater for median if not the minimum speed.
For a long time, you had to load 2+ mb of data to see a 140 character tweet. Twitter actually recently fixed this; the tweet text is available in the title now, so will be available very early in page load.
Not only does this make twitter usable on dialup again (it was effectively unusable ever since they switched from a simple html page to a massive "application" that you have to re-download every time they deploy), but it lets you search through tweets you've read in the browser history.
The 140-character limit was INITIALLY because of SMS, but now it's just the standard format for the medium. The whole point of Twitter is the 140-char limit.
> Because we have the capability to work beyond that capacity now in most cases
Except if you are in a rural area of a developed country, or in practically any undeveloped country. Most of Africa, Asia and South America have abysmal internet connections, and rural parts of Australia (even a few hours drive from a major city) are only able to get satellite internet.
Tech people often fail to realise how divided and limited access to internet actually is once you leave 'tech hubs'.
Absolutely, but those are secondary markets for most American businesses because there are an abundance of issues with delivering any application to those areas. Whether its political, cultural, financial, etc. Priority for most businesses and website owners is to serve the people you know you can serve first, then work on supporting those other areas.
Twitter, like most companies, exists to make money. If you're busy shaving off every bit you can from your requests, you're spending a lot of money. You're also losing money because I'd expect you wouldn't be serving ads, etc. as well.
Most blogs that exist to make money aren't targeting those without good internet either, so I don't really see the problem.
Rural areas secondary markets for most American businesses?
This isn't just about Twitter, its about making sure if you are helping build a local Mom & Pop Shop's online presence - which is where all business is now days - then you build it in a way that their customers might care about.
There is a world outside of cities, and a lot of people live there. The tech world needs to wake up to that, because those people where Ubers don't go, GrubHub doesn't deliver, they exist (and vote) too.
They vote, yes, but do they buy? Do they significantly contribute to a company's economy (even potentially)?
If they do, companies will be happy to spend time and resources in serving lighter versions of their content. But if they don't, there's no reason, from the POV of a company, to employ resources in something that doesn't generate revenue.
The web is becoming a platform delivery service for complex applications.
No, it's not. Yes, there are MMORPGs that run in the browser using WebGL.[1] But very, very few pages use all that capability. Most web pages today would work just fine in HTML 3.1.
And what is this thing with running over ten trackers on one page?
As soon as WebAssembly is stable and available I'm predicting we'll see a dramatic shift away HTML + JS as the target for most web apps. I don't mean blogs, I mean people who are trying to build websites that work like apps.
Most webpages today that would work fine in HTML 3.1 aren't built as massive JS web apps. If they are, it may serve a purpose (better UI/UX for most of their users being a major one.)
We see gazillion of the web apps (and pages that are web apps but shouldn't be) because of those who are not willing to learn anything but JS. Good luck dragging them to C/C++.
>That's like asking "why shouldn't we allow horses on our highways?" //
We do allow horses on our "highways" in the UK, not motorways but other highways. It's a terrible analogy though as you can't have progressive enhancement of a road for the vehicle capabilities as you can a website.
>But to stop technological advancement in order to appease the lowest common denominator seems silly to me. //
Not serving simple text, for websites where that's appropriate, and then offering enhanced capabilities when the web client can make use of them seems perverse to me.
You don't have to not advance the technology, having radio broadcasts doesn't hold back VR/AR, but if all you have to convey is able to be passed on in an audio stream then purposefully designing a site to be hostile to clients that can only consume an audio stream to me is wrong. Sure add on an immersive environment where one can play on a VR beach whilst listening to your "24/7 wave noises" but don't make it so that simple audio access is impossible if the primary content only requires that.
In other words don't require webgl so I can see your store opening times.
> The cost however, in supporting people so far behind as to only be able to serve them text is quite frankly unmanageable.
No, no it's not, it's really not. You're already writing your SPAs with a REST backend, right? Well, guess what: static HTML & REST go together like burgers & beer! All you need to do is add an HTML content renderer to your REST backend, and you have _something_ someone can use to interact with.
> The web is becoming a platform delivery service for complex applications. Some people like to think of the web as just hyper text, and everything on it should be human parse-able. For me, as someone who has come late to the game, it has never seemed that way. The web is where I go to do things: work, learn, consume, watch, play. It's a tool that allows me to access the interfaces I use in my daily life.
True fact: learning, consuming & watching are all well-supported by static HTML.
> But to stop technological advancement in order to appease the lowest common denominator seems silly to me.
Part of the problem is that we're not advancing technologically: we're getting bogged down in the La Brean morass which is modern web development. HTML is a terrible but acceptable markup language; CSS is an ugly but somewhat acceptable styling language; the DOM is as hideous as a Gorgon; JavaScript is approximately the worst language ever; the combination of all the above is grotesque, and an ongoing indictment of our entire industry.
A cross-platform application-distribution standard sounds pretty awesome, but that's not what web pages are supposed to be, and it's not what web browsers should deliver. The web is a web of hyperlinked documents. It's right there in its name. And anyone who demands that his readers enable a somewhat cross-platform, highly insecure, privacy-devouring application-distribution tool in order to read his text is welcome to take a long walk off of a short pier.
The web used to be a web of hyperlinked documents. This has not been the case for a long time now. Webapps have evolved to enable widespread communication, collaboration, gaming, social media, and so much more.
It's the single-largest open platform that's available from nearly any device in the world. It's a little more than a document viewer.
'Web apps' are still irrelevant to the mainstream web user. Unless you think that Facebook counts as a 'web app'. Facebook is a great example of a website that very much feels like a website: it's full of hyperlinks.
HTML is certainly not a 'terrible but acceptable markup language'. Used properly, it's a _fine_ markup language. CSS is brilliant, at least in its original incarnations: it's bloated beyond repair now.
> Because we have the capability to work beyond that capacity now in most cases. That's like asking "why shouldn't we allow horses on our highways?"
Horses on highways would cause accidents. I have yet to see a fast-moving web page crash in to a slow-moving one and shut down the router. Analogies work better when there is connective tissue between the concepts in play.
More generally, the vast bulk of the problem is not human readability or interactivity over http, but more a matter of insane amounts of unnecessary gunk being included in web pages because of faulty assumptions about the width of pipes.
More generally, I find myself moving in the opposite direction. I find that many SaaS services' interests don't align with mine, so I'm going back to local applications. I don't trust others with most of my data, so the only service that sees much of it only sees encrypted blobs (for offsite backup). I've always run my own mail, and have slowly been expanding the services I host as I bring more of this stuff in-house. And so on. But I realize I'm in a minority.
But the nice thing is that it gives me an intranet and "other" grouping that is very straightforward, so that the browser instances that touch untrusted (not-mine) services can run in "bastion" VM, locked down nicely and reset to a pristine state at will, not to mention allowing some stupid networking tricks that are sometimes useful.
> More generally, the vast bulk of the problem is not human readability or interactivity over http, but more a matter of insane amounts of unnecessary gunk being included in web pages because of faulty assumptions about the width of pipes.
Doesn't affect the vast majority of users.
> But I realize I'm in a minority.
Yes, your statements are pretty anecdotal and don't really relate to the vast majority of internet users.
I'm sure your setup works great for you, but it sounds like a ton of overhead, none of which is required if you have fast internet and don't give a shit about what's going on (like nearly everyone who uses the internet.)
I don't think your claim that it doesn't affect the vast majority of users is correct. There's well over a billion people in India alone. You might argue that you were only making claims about US users, but a lot of sites have no reason not to be global.
> don't really relate to the vast majority of internet users.
It's not that they don't. It's that you don't care.
Because why should you care about something that doesn't meaningfully increase ad revenue or sales? Why should you care that the 2 extra seconds of pageload on a fat pipe, and a fraction of a cent of extra electricity burned, when multiplied by a million of your US users add to over 500 man-hours and few kilograms of coal wasted. Not to mention the site being unreliable or unusable in trains, rural areas and larger buildings in which an user doesn't have Wi-Fi access.
And the problem wouldn't be as big if it was just you. The problem is, everyone else thinks the same way, so all the waste mentioned above adds up. All because people are too lazy to not put useless gunk - which often requires more work to add to your site than to refrain from using it in the first place.
And the funny thing is that it's even been shown that increasing speed increases usage and revenue/sales, so there's not even that excuse. Slow pages break flow, which cause people to realize that they've already wasted too much time on your site, and were supposed to have done xyz 15 minutes ago.
If you've ever traveled internationally, you'll know that a lot of English-language sites become unbearably slow to use over mediocre hotel wifi, let alone cellular. Lightweight sites like HN become relatively MUCH more pleasant to use.
Text articles are probably the most widespread type of content on the web. Most web sites are not web apps. But many developers want to re-construct web sites into web app architectures even when there's no benefit to the end user.
I posted the links below on a previous discussion about AMP. They are two examples of basic, javascript-free web pages with text content. There's about 2500+ words on these test pages, but the page weight is still much smaller than, for example, a medium article with one tenth the number of words (250).
Try loading them on your mobile on a 3G (or slower) connection. Do they load fast or slow?
Version B could probably be optimized here by not loading two very similar fonts.
You can also try loading the font locally first, to avoid the download if it's installed on the user's system.
Finally, unicode-range lets you avoid the download completely if that character isn't included on the page. Not a likely outcome on an English page, but a good practice regardless.
Webfonts are tough to optimize, but not impossible. Right now there's solutions of using Javascript to background the font so it's non-blocking (eg. loadCSS[1]), but it's not ideal when trying to keep overhead down. The situation should improve once font-display[2] becomes standardized.
For what it's worth though, I find Version B looks much nicer.
Version B has two different font weights from the same family: Regular and Medium/Semi-bold. Version A relies on the fonts already installed on the user's computer.
Dropping the semi-bold font weight would save approx 23k, but having a regular and bold font weight felt like the minimal styles needed to support the page.
Dropping the header image would save 40k. (Note: the header image hasn't been optimised using something like the HTML srcset attribute which can load different picture sizes for different devices).
> Why shouldn’t the web work with dialup or a dialup-like connection?
Because we have the capability to work beyond that capacity now in most cases. That's like asking "why shouldn't we allow horses on our highways?"
As a counterpoint, I have a 1G FTTH connection, 8GB of ram, but only a dual-core 1.4 GHz Haswell (Celeron 2955U) and an iffy SSD, so I get a terrible web experience if I have more than one tab open.
I work at a company whose revenue primarily comes from advertisements; it feels unethical to run an adblocker while ads are paying my salary. (And also would blind me to the experience that most users have; even ignoring the nice connectivity and ram that I have)
I have to applaud you for the second point. With many pages I see nowadays just googling for things like Vim-keybindings (I am sadly not allowed to install an ad blocker on some systems), I started to heavily doubt that anyone maintaining those sites has seen them through a user's eyes.
While I agree with others here that dial-up-friendly sites don't "collide" with complex web-apps (thus rendering this argument somewhat void), I sadly think the underlying problem is much more mundane:
Why are word processors not orders of magnitudes faster than two decades ago? Same reason. No one wants to pay the additional costs of achieving that.
Practically speaking, this means that either Random Local Newspaper Inc. knows their potential online reader base exactly and deemed the additional effort not to pay off, or they have no idea of their potential customers that would flock to their site if they did put in the effort, and thus don't miss them. Add on top of that the fact that much of the internet is based on (perhaps only assumed) prestige (or loss of it if your page doesn't have the most modern features A through Z or looks like its from the 90ies) or extremely short-lived (a newspaper doesn't care about yesterday's news) and this theory pretty much explains it all.
Cynical, I know, but hey... :-/
Edit: Also: We can have nice things. No one with a 56k connection will honestly try to watch Netflix. A much more interesting question would be: How could we create incentives for big corporations to optimize their pages for connections with a small bandwith? After all, much of the web is also built on ad deals - which also almost certainly don't target those people.
> Why are word processors not orders of magnitudes faster than two decades ago?
Because even in the 1990s, word processors weren't orders of magnitude slower than the person sitting at the keyboard, which is the ultimate limiting factor on word processing speed.
Which is, essentially, the same explanation. I would very much like a fast, Vim-style modern word processor (the new cursor behavior in Word drives me insane btw). But I'm not the main target. I alone wouldn't pay the bills.
The same goes for almost any website: People with 56k don't consume much digital goods and returns from ads are most likely almost non-existent (especially if the ads are huge themselves). That easily explains a huge part of the web.
Thus, either the connectivity around the globe has to be improved (thats the route Facebook seems to choose, albeit with debatable conditions for their new "customers") or create other incentives for anyone hosting something on the web to attract people with low bandwith connections.
>Because we have the capability to work beyond that capacity now in most cases. That's like asking "why shouldn't we allow horses on our highways?"
More like 'why shouldn't we allow people on our streets?' Which is a good question. It's a question we answered. With a yes.
>I look forward to WebAssembly and other advancements that allow us to treat the web as we once treated desktop environments, at the expense of human readability.
If you want to make a desktop programme, make a desktop programme. Don't ruin the web.
At my job, I work on a web app. It runs only on Android devices through a web view in a native app. It could have been a native app, and would have felt more natural on an Android device, been faster, and probably more secure too.
Its not just about plain text vs. content. Its about doing things at least reasonably efficiently. I commented about gmail taking 500MB on Chrome in another comment. I just checked Mail.app it started with 200MB. I wonder whats the energy budget of all the bloated website and their parsing is on millions of computers. The server side computation allows economy of scale and might have saved cpu cycles for the actual work but I'm sure many times more than that has been wasted by a bloated web.
I don't disagree that web and web applications provide a lot of convenience and I don't want to loose that. But I don't think for a moment that things can't be significantly more efficient.
T-Mobile used to offer 2G internet speeds internationally in 100+ countries included in Simple Choice subscriptions. 2G is limited to 50 kbit/s, that's slower than a 56K modem.
While this absolutely fine for background processes (e.g. notifications) and even checking your email, most websites never loaded at these speeds. Resources would time out, and the adverts alone could easily exceed a few megabytes. I even had a few website block me because of my "ad blocker" because the adverts didn't load timely enough.
Makes me feel for people in like rural India or other places still only at 2G or similar speeds. It is great for some things, not really useable for general purpose web browsing any longer.
PS - T-Mobile now offers 3G speeds internationally; this was just the freebie at the time.
Yeah when I used to run over my T-Mobile data allotment (in the US) and they dropped me to whatever speed they throttle you to when your "high speed" data is gone, Google Maps wouldn't load, Facebook wouldn't load, YouTube wouldn't load. I remember using all of those things back in the days when a 3G connection was a luxury, back when Windows was the best smartphone platform. What happened between then and now that suddenly nothing works?
Well, it would have to be downloaded once. It'd stay cached after that though so it's not really a concern. They use version numbers for cache busting.
On mobile cache sizes are very limited, and with the size of modern web pages it has to get reclaimed regularly. You can't rely on caching to solve poor performance.
Loading that in a simulated 2G connection takes about 80 seconds and at least 30 seconds of that is waiting to display anything you care about. Looking at the content breakdown shows why: ~200KB of webfonts, 1.2MB of JavaScript, 275KB of HTML, etc.
I live in a major city, have an iPhone 6S with good LTE coverage according to benchmarks, etc. and still routinely have AMP take 15+ seconds to render after the HTML has been received. I don't know if that's Mobile Safari applying strict cache limits or an issue in Google's side but the sales pitch isn't delivering.
Note that I did not say it always happens — when everything is cached, it performs as well as any other mobile-optimized site — or that it's specific to my device/carrier – it also happens on WiFi, Android, etc.
The problem is simply a brittle design which depends on a ton of render-blocking resources. The assumption is that those will be cached but my experience is simply that fairly regularly I'll click on a link, see the page title load (indicating the HTML response has started), and then have to wait a long time for the content to display. Many news sites also load a ton of stuff but since fewer of them block content display waiting for JavaScript, the experience under real-world wireless conditions is better in the worst case and no worse in average conditions.
> What happened between then and now that suddenly nothing works?
The average expection changed. Back in the day, everyone was on $SLOW_SPEED, so pages were designed for it. Now-a-days they can, and do design, pages for higher speeds
Yes and the average page size has sky-rocketed, despite there being no more actual content (i.e. text). Instead we have animations of images or text fading in as we scroll down a page and lots of Javascript to do things I do not know.
Kind of makes me miss the old plain HTML days - much less CPU intensive too.
It's really not about a privileged youngster, it's about business priorities. Most of the time the cost benefit ratio doesn't justify the effort to optimise for high latency high packet-loss connections. Let's say 1% of your potential users use such connections. It only makes sense to support them if your total userbase is a large enough number. For Google, it's a no-brainer. For other sites, it's something to consider.
At work we did something similar a few years ago with our Android app. We dropped support for Android 2.3 users because we only had a couple hundred of them and it didn't justify the developer cost to maintain it. WhatsApp only dropped support a month ago. I don't think that was because they were somehow less privileged than us.
The casual ageism in your comment is unbecoming. You could reconsider it.
I could, but I've worked with too many examples that only care about writing new code in whatever is the latest hotness and moving on. They[0] don't want to fix their bugs. They don't care about anything but "works on my machine." They certainly don't care about using bandwidth.
Bring it up! They're newer to development then you are, they're newer to life. They're far more likely to have always have had high speed internet growing up, and not have had that visceral experience. The initial reaction will probably be negative, but initial negative reactions to perceived increases in scope/work is basically a universal human trait, it's surmountable.
> Let's say 1% of your potential users use such connections. It only makes sense to support them if your total userbase is a large enough number. For Google, it's a no-brainer. For other sites, it's something to consider.
Your making it usable for that 1%, but you're making it better for the other 99%.
But your optimizing things people are using frequently, not adding things they probably aren't. Adding features is usually diminishing returns as well.
I've heard about ageism (like racism, but for people of different ages) since around 2000-2001. Really around the time baby boomers started getting close to retirement age and some companies decided it was a better deal to fire them or lay them off than pay the pensions they had earned, and also with the DotCom boom where startups would only hire 20-somethings. It's not really a new term.
High paying customers are going to have high speed connections. No one will talk about it, but it's discrimination. If you are on a slow connection, they don't want your kind on their site. If you try, they will mock you for not knowing your place.
No one will talk about it, but it's discrimination.
This will make a few segments of people cringe because much like the topic of racism, there's a school of thought that it only counts when things are exhibited in severe forms like water cannons, attack dogs or restrictive housing covenants or otherwise people being directly being told 'no' because of superficial topics like race, gender or sexual orientation.
But as a tech guy who's slowly pivoting towards law, I've long held the belief that technology will become the next battle ground for civil rights-and has the potential to even change (in the sense of expanding the definition of) how we talk about civil rights. Think along the lines of people being left behind when it comes to accessing information they need to request public resources as more and more cities move towards online only forms, or even utilization of "entitlement programs" to pay for internet access (http://www.usnews.com/news/articles/2016-03-31/fcc-expands-o...).
Now it may not be active discrimination in the sense that one will be outright told 'no', but disparate impact deserves to be at the table of discussing this sort of thing.
It seems more plausible to me that they just don't want to take the trouble to support low-bandwidth connections than that they're actively pumping up the space to keep out poor people.
> You’ll be surprised at how most of the web still works and is much faster.
And you'll be more secure, and you'll retain more of your privacy.
I find 'this site requires JavaScript' to be another way of saying, 'the authors of this site don't care about you, your security or your privacy, and will gladly sell all three to the highest bidder.'
It takes more work to have a bloated JS mess of a site, than it is to have a small, simple, clean site. If they were lazy, they wouldn't have gotten to that spot in the first place.
Not really. It's very easy to get bloat if you integrate ad-networks, analytics tools, social media tools etc. willy-nilly without looking at all the resources they fetch.
The lazy approach WILL lead to bloat.
No news agency is running a plain jane HTML website.
Your kind of proving my point. If you add these things in, it's more work. If you make a plain html site, which is what these sites should be doing, then you aren't going to add that stuff in, which means less work.
I think you're forgetting content creators that aren't developers - although to be fair I don't see why you can't create an interface for the user that spits out / retroactively updates old pages/links/images.
There is definitely a trade-off between ease-of-use and cost-of-use and I feel this gap is bridged by the content created by those who could not publish bare bones.
> I think you're forgetting content creators that aren't developers
I don't understand what you mean by that. Content creators don't need to be developers for us to use simple, reliable systems.
> There is definitely a trade-off between ease-of-use and cost-of-use and I feel this gap is bridged by the content created by those who could not publish bare bones.
Yes, but I personally find the "ease of use" to be worse on heavy, slow, bulky sites. If content is "easier to use", then why are people constantly angry at slow, non-responsive interfaces? I see and feel this all the time, yet it's somehow "easier to use"? I don't see people complain when sites are fast, responsive and simple. Everyone's top complaint is that their computer/phone is "soooo slooow". Why is this, when we have extremely fast computers?
If you're hand coding it either way, maybe but, at least in my personal experience, it's much faster/less effort to drop bootstrap and jquery on the page and get to something acceptable looking then to hand code just the 50 lines of js/CSS I actually need. Obviously there are many benefits to the latter approach, especially in the long run, but it's definitely not the lazier approach.
Quite the opposite actually, people don't know how to set up a website, let aside making a simple, static one. Many websites are created on services like Squarespace, wordpress (used by many as a CMS), CMSes, Blogger, etc. And then for who knows to edit text files, it's easy to start with a tutorial and end up with a +1Mb hello-world website.
Or, they assumed everyone nowadays has a browser with javascript and don't care about people who won't accept to using js or even know about these people existing
Cannot help but chuckle at the irony when I forget to allow goog/gstatic when using gmaps and get the non-blank-page stating "without js all that's left is a blank page".
Well, that's quite unfair. JavaScript is also used for creating interactive web applications - not just tracking users. Really your attitude comes off unnecessarily aggressive.
I think it depends on what the JavaScript is used for. I agree that blogs and news site should be static, but forums - and in general, sites with a high degree of user interactivity - can see significant UX improvements with some JavaScript, for things like asynchronous loading, changing the UI without reloading the page, and even nice animations (although many of those can be done in CSS these days). However, graceful degradation is very important - disabliing JavaScript on these sites shouldn't break them, merely impact the UX.
[Edit] "blogs and news sites should be static" -> this should read "blogs and news sites don't need JavaScript"
There are exceptions where JS is needed. They are exceptions though. A vast majority of the sites I see now are web-pages that think they need to be SPAs. Sorry, sucks to be them, but if they didn't mis-design, I wouldn't mis-interpret their intentions.
How can one know that first time viewing a webpage? I just enable some particular websites to run JS because I know that they are indeed interactive web applications that I want to (read: have been constrained to) use. Also, most interactive web applications can stay just as interactive even though they were to reduce the amount of JS and CSS libs, fonts, images, icons, videos and other stuff that they thoughtlessly pull in. I disabled fonts loading on webpages and all the search boxes are now an "fl" ligature for me, though many times I see that it's not more cryptic then before I disabled fonts, because weird icons some people invented are just as meaningless to me as random letters. I've gotten used to the fact that an identity sign is for a meny, but every other day someone invents another one that now I can't click anything without fear and uncertainty, as most of the time no-one bothers to put a tooltip or a litte label.
I started using "Image On/Off" and "Quick Javascript Switcher" plugins to easily toggle images and js while traveling South America in 2014 to increase speed and save costly bandwidth.
Still using them for the side effects. Its nice to be able to start reading an article immediately without waiting for the jumping around of content to stop. And actually read until the end without having modal dialogs shoven down my the throat.
I use NoScript. The web is much less annoying by default, and I can still enable scripts for those sites where I think it might be useful.
There are a good number of sites now which have entirely given up on progressive enhancement and simply don't show you anything without JS... but I generally find I just don't care, and just close the tab and look at the next thing instead.
I found that, usually, the ones that don't show anything when javascript is disabled are the ones loading scripts from ajax.google.com.... it might appear to be so because google is so much larger (or maybe Google did that on purpose)
This is the main reason why Brave is my default browser: you can set the default to disable JavaScript and enable it only on sites which actually do something useful with it. My data usage dropped something like 1GB the first month I switched.
You could have used an iframe for each button instead of a normal form to prevent the reload of the page. Using an iframe with data: should take no longer to load than a normal form.
Note though that disabling JavaScript can also slow down many sites. One good use of JavaScript is to detect the speed of the user's connection and then load in smaller and lower-quality assets. Disabling JavaScript can result in the default assets being loaded, which rapidly offsets the benefit of not loading that JS. Other sites will load in portions of the content first and use JS to load in extra chunks as requested, but load in the entirety of available content if JS is disabled, slowing down initial pageload enormously.
I can't think of a single website I know that uses JS to intelligently load thing via connection-speed sniffing. It's a nice thought, but it doesn't happen. There used to be JS fills for responsive imagery -- it was never connection-speed based, but viewport based -- but this is all browser-native these days. Some things might provide simpler assets via CDN-based UA sniffing.
FWIW, I just tried this in Firefox (set javascript.enabled=false) and went to my bank's website to see how it would fare. Firefox crashed. Tried again with no other tabs open, still crashed. Crash report sent.
OTOH, in Chrome the website actually works fine and feels more snappy with JS disabled. So, thanks for the tip!
Can you share the crash report IDs from your Firefox's about:crashes page? Can you share a link to your bank's crashing web page? I'd like to try to reproduce the crash. Thanks!
It's what makes me wish designers and developers would work with artificial constraints. Sure, it's easy to design and develop without really thinking of bandwidth constraints, but reality is you are and will always be a better developer and designer by setting artificial bandwidth constraints in your mind and choices.
Seeking out or thinking as though you have bandwidth constraints can push you to find better solutions and thereby make your services better. The west and the tech centers in particular is really rather blinded by the glutinous bandwidth that keeps eating up greater and greater amounts of data with only marginal improvements in outcome or user experience.
I say this so much that I should probably just copy/paste it in the future but...
I used to work at a place that had a <1mbps modem, and a ~7 year old destkop. If their software didn't work on that, it needed to be optimized. I wish more places would test this way. Your sight may work fine in downtown SF, but that doesn't mean it's going to work well anywhere else.
I just looked up EDGE. It's crazy to think that the first iPhone topped out at double the speed of a 56k modem. And that I actually used my iPhone on that network sometimes, when 3G wasn't available.
I had a blackberry a bit before the first iPhone. I remember getting an update wirelessly that was something like 3MB and just thought "Good, it should only be about 10 minutes this time."
> PS - T-Mobile now offers 3G speeds internationally; this was just the freebie at the time.
I don't think this has changed, at least not in general. The included roaming package is still free international 2G roaming everywhere except Mexico and Canada (which get free 4G), with "high-speed data pass" upgrades available for a daily or weekly fee if you want faster. They did have a promotion for the 2nd half of 2016 (initially for the summer, then extended through the end of the year), where international 3G, and in a few areas 4G/LTE, was free without buying the upgrade passes for most of Europe and South America [1]. But that's now over, and I believe it's back to free 2G internationally now.
I was in rural China with an EDGE connection on Google Fi last month.
Hacker News was pretty much the only site I visit that could reliably load quickly. m.facebook.com had a slight wait but was still bearable. I had to leave my phone for 10 or 15 minutes to get Google News.
WeChat and email worked well.
Everything else was horrible, especially ad networks that would ping pong several requests or load large images.
Opera has a compression proxy mode that helped a bit when it worked but it was still painful.
For search results, Stack Overflow, and YouTube, it was easier to easier to ssh into an AWS node and use elinks/youtube-dl.
Using SSH as a socks proxy/compression was insanely slow due to something with with the great firewall.
My 35Mbit cable got shaped down to 0.25 Mbit/s yesterday because we went over our download limit. It was like having no connection. I just gave up using it.
I hate the all-or-nothing approach to shaping. At least give me 5Mbit or something!
5mbps is a perfectly fine connection, they might as well not throttle you at all then. If they want to give you barely-usable internet, about 500kbps might be reasonable. 250kbps is quite slow indeed.
I wouldn't call 5mbps "perfectly fine", but I could do basic web browsing and email etc. And that's my point. I don't want to be shaped down to a barely-usable connection. Why do they need to shape at all? The only argument is congestion. And if there's congestion, they should shape us down to a reasonable level like 5mbps. No reason it should be all or nothing, 35Mbit or zero.
I use T-Mobile as my ISP because the only landline choice in my apartment building is AT&T and I absolutely refuse to do business with them. I regularly hit the monthly bandwidth cap on my plan and get booted down to 2G.
I live in California -- this is not just something people internationally are dealing with.
Annoyingly, T-Mobile's own website doesn't work properly when you're throttled to 2G speed. Found that out the hard way when I ran out of minutes on Thanksgiving and couldn't talk to my family, and couldn't load their website to add more minutes.
FYI, I had the same connection and I'm pretty sure T-Mobile simulates 2G by switching 3G on and off to get the correct speed on average. Breaks a lot of stuff. Almost unusable!
Most of the web really sucks on fast internet connections too. Thanks to so many web developers thinking every dang thing needs to be a single page app using a heavy JavaScript framework. Add animation, badly optimized images and of course ads and it becomes really unbearable.
We keep repeating our same mistakes but just in a different way.
I saw a sarcastic comment a while back saying that webdevs should be forced to work on a Pentium II machine and they would cut their bullshit, I laughed, and moved on.
But after seeing many examples where sites were built on huge iMacs with no care for users running off a battery, slower network connection or with an average 1366x768 display I somewhat agree with the sentiment.
I tend to run web frontends in lynx (or links) to see if they can degrade well enough. If the core user flows don't/can't work then there's a big problem with the UI.
The other issue I have with web page bloat: memory-constrained mobile devices are able to cache far fewer pages than a desktop computer, and navigating among multiple tabs, etc. gets slowed down to internet connection speed.
As someone who had fiber internet then had to spend a year and a half on 1.5MBPS DSL ... (hell) ... I can say I agree that it sucks...
I can also say that at no point did I feel entitled for it to work better for me. I don't understand this level of entitlement (i dont like your ads, i dont like your layout, i dont like your visual effect ...) ... just leave the site.
The modern web isn't simple static pages... its not going to revert to that, either. We're developing actual applications in the browser now... those aren't easily translated to static, simple pages...
And converted to using single-character class names and reducing the CSS needed, it can be down to about 3KB, sans-compression.
(I manually minified the whole source; the original is 53313 bytes, 12438 gzipped, while my minified source is 25628, 10124 gzipped. Most of the bloat in the tables compresses really well, as is common with such things.)
Out of curiosity, how did you do it? I did as well, and I used Sublimes multi-cursor functionality + some manual work to replace classes where it should be. Mainly because i saw an interesting problem and I like (love) using the psuedo automation tool that is Sublime 2.
Just curious how you went about it, if it was /all/ manual or some interesting technique.
My result was not too shabby, 7kb I think it was when I stopped due to the time cropping up.
Mostly fairly manual, with a bunch of regular expressions and things like sorting the CSS block by background-color (Vim: `:sort /{/`). It was tempting to slurp it in Python, gargle it about a bit and spit it out neatly refactored, but I didn’t do it that way. A small quantity of Vimscript would also have been fairly straightforward. But no, I did it the hard way out of the wrong type of laziness. (Why did I do it at all? Who knows.)
> if we just look at the three top 35 sites tested in this post, two send uncompressed javascript over the wire, two redirect the bare domain to the www subdomain, and two send a lot of extraneous information by not compressing images
So uncompressed javascript and images are bad, but I thought apex domain to www subdomain redirection was an optimisation as the apex domain can often only point to a single server but the subdomain can point to a range of geographically well distributed CDNs. So rather than going to North America for every request, the browser only needs to do it once than the rest can come from a regional CDN. Am i misunderstanding something, does this also break down on a slow connection?
The apex domain can only use A records, i.e. point directly to an IP address. It can have multiple A records, ebay.com does so:
host ebay.com
ebay.com has address 66.135.216.190
ebay.com has address 66.211.162.12
ebay.com has address 66.211.181.123
ebay.com has address 66.211.185.25
ebay.com has address 66.211.160.86
ebay.com has address 66.135.209.52
Without a CNAME (alias) record, eBay need to control the DNS resolution. Most people using a CDN don't, so they must use a subdomain.
Ah, I was unaware that there could be multiple IPs on an A record, thanks for that. If I'm understanding this right though, the extra IPs would just be for redundancy and resilience and cannot be relied for geographic routing? In this case ebay.com redirects to www.ebay.com.
It's not that there are multiple IP's in the A record, it's that there are multiple A records, each with an IP address.
For geographic routing, there is a clever trick that can be utilized using a technology called Anycast. Anycast is basically a way of assigning the same IP address to multiple machines so requests to that IP address results in connecting with the one that's the closest to you, route wise.
Providers sometimes use Anycast DNS Name Servers and configure them to provide the different IP addresses depending on which name server people connect to.
So, if someone wants to determine the IP address of ebay, their DNS client connects to ns1.ebay.com and asks "hey, what's the IP addresses for the A records for ebay.com" and ns1.ebay.com replies with the list.
But ns1.ebay.com might be an Anycast DNS Name Server that's close to them and it provides the list of IP addresses closest to that name server. Someone on another continent might reach a name server with the same name and ip address, but it's a different machine in a different data center. It would provide a list of IP addresses on that continent.
I do something similar with one of my sites. I rent three VPS's from buyvm.net (who has Anycast setup) that have the same IP address and are located in Las Vegas, New Jersey, and Luxembourg. I pay less than $10 a month in total and run my DNS name servers there.
Clients that connect to the name server in Las Vegas get an IP pointing to a Digital Ocean load balancer in San Francisco proxying data from a few front-end VPS's.
Clients that connect to the name server in New Jersey get an IP pointing to an OVH Canada load balancer near Montreal.
Clients that connect to the name server in Luxembourg get an IP pointing to an OVH load balancer in the North of France.
The result is a responsive service that has amazingly low latency for the US and the EU. Gonna try to set up some infrastructure in Singapore soon to make things faster for Australia and Asia.
Did most of the web suck when we were on 28k or 56k modems? I'd argue that it didn't, and yet even with the light weight of pages back then, it was incredibly slower than today's pages (even heavy ones) load over our much-faster connections.
So really, I think what the author is observing is that having experienced high-speed reliable connections, it is very disappointing to move to a much slower connection. For the emerging tech markets, I can imagine the experience would not be great if the load was long enough to cause timeouts and connection failures, but at the same time, the 99% experience, as it probably was when the web was born, is "holy crap look at everything I have access to now!"
Yes, there are some really terribly optimized and redirect-happy sites out there and yes, you should do everything you can to make your page speedy. Everybody benefits when you do. I think, though, that this is more of a case of "let's be thankful for and aware of what we have," and "if you suddenly have a slower connection you might find yourself annoyed" more than "most sites suck on slow connections."
While waiting for some JS-laden crapfest to load earlier, it occurred to me that I haven't heard the term "World Wide Wait" in many years. But here I am experiencing it all over again.
I think average number of requests per site, and average page size in megabytes went up over time. It is much higher now and content we browse is actually very similar - people read news like they did 20 years ago, but now their news site requires 2mb of data when it required 100kb 20 years ago.
> Did most of the web suck when we were on 28k or 56k modems?
I'd argue that it did, just like having 32MB of RAM and Windows 95 did. But almost everyone was in the same place, including the people making content for websites we went to, so page load times were as good for their minimal experience as the technology would let them be. Even in 2002, my family was still on dial-up, and it sucked because I knew how much was out there that just wasn't feasible for me to access.
I think you've missed my point. Yes, that was slow, but if it was literally the best, then it was awesome. The same thing goes today for everybody out there with access to gigabit. There's no reason to complain about it even if downloading takes some time still, because it's not like there's anything better.
Something that sticks out looking at the table. How can some sites simply FAIL loading? I mean, there is something inherently wrong with our web today, where if my internet is very slow and _could_ load a page in 80 seconds if I just leave it like that, the server itself could have configured the timeout to be 60 seconds. So I can never load the page?!
The assumption is here that both points of the connection is based on earth. When we have these hard timeout limits, how will stuff even remotely work when we are a interplanetary species or even from orbit around earth?
10% packet loss though typically is the threshold of "completely unusable" TCP connections. Depends of course, but 5% I generally think of "severely degraded" (e.g. ssh being almost unusable but still able to get some basic stuff done during a sev0) and 10% being "drive on-location because you aren't getting anything done" territory.
How is it not a modern website problem, if that modern website is being viewed over wireless connections, and follows Google's lead in disabling slow start TCP?
I chatted about just this timeout issue with an engineer from a major CDN while he was at my house enjoying the dialup. Seems like simply a matter of resource management; slow connections do use more resources. Most CDN customers don't care or don't know that a few percent of the US population is getting their web browsing broken by timeouts, so there's no push back.
(NASA has their wacky ways around the issue for ISS residents, something like VNC to a ground-based browser IIRC.)
That's pretty smart of NASA; things like a caching HTTP proxy still wouldn't work in some cases, given that sites can expect your browser to make a given AJAX request within X ms of requesting the page.
I wonder if there's still a more "API level" way to handle things, though, rather than making your computer into a dumb frame buffer client with extremely low responsiveness to typing/scrolling.
Maybe they could run a headless browser on Earth, and use a protocol like the Chromecast does to synchronize its DOM state to a "browser proxy" in space—like a higher-level, domain-specific version of the X11 protocol. That'd still have latency for JavaScript-based webapp UI, though... maybe the JS could be split and its state synchronized so that the "server" handles timer triggers, while the "client" handles input events.
I'm surprised they need anything. I get my home internet from a satellite in geosynchronous orbit and it works fine other than the latency. No human has got that far from Earth since Apollo in the 1970s, so my home internet has to be worse than anyone NASA cares give internet. (though I have no idea what bandwidth NASA has)
If they wanted to use a geosynchronous satellite from the ISS, it would be occluded by the earth half of the time and the other half of the time they'd have to track it with a satellite dish over the course of the 45 minutes (out of every 1.5 hours) they have access to it.
of course the same is true of ground stations... I'm not actually sure how they do it but they probably don't need as high-gain of an antenna to reach them.
The ISS gets connectivity via a small number of ground stations and mostly satellites. Their connectivity is not uninterrupted; there are small regular time intervals at which none of their uplinks is in line of sight.
I remember astronaut Alex Gertz somewhere saying the VNC was also for security reasons. Keep in mind that most infrastructure on the ISS was installed in the middle 00s and that the Thinkpads were possible running Windows XP and IE 6 then.
> how will stuff even remotely work when we are a interplanetary species
IPFS or similar. Basically, make all public content content-addressed (give me the article with SHA 0xabcdef) rather than connection oriented (give me the bytestream that comes from http://news.ycombinator.com/foo/bar)
I love this visual, but elevators have way more safety mechanisms than poorly-designed web sites. Check out the source HTML of instagram.com for a great example. /-:
Open connections take system resources. One way to DOS a website is to open a ton of connections and just sit on them. If the server allows extra long timeouts as long as some bits come in occasionally, then the attacker can send bits occasionally. It's a tricky problem. It might work to allow long turnouts as long as you don't have an ongoing DOS attack, but that sort of thing is hard to configure and test.
After Slowloris and other attacks, this is pretty much a solved problem. Minimise per connection memory, limit connections per IP, drop connections which don't finish the request in X seconds, and separate your app server from your front proxy. And for the front proxy, don't block on reads - do minimal event loop until you can dispatch the full request.
how will stuff even remotely work when we are a interplanetary species
I would not expect interactive anything when latency is 20min+. Usenet and listservs should work fine tho, maybe worth some tweaks to the underlying protocols if they're too chatty.
On the TV series Stargate SG-1, they envisioned using conventional EMR (like radio and TV signals) through wormhole connections.
Later plots faced invasion attempts through the stargates (permanent, direct-dial wormhole portals), so matter shielding was employed, and signals were used to authenticate who was on the other side of the connection before lowering the shield.
I travel fulltime and my primary internet is 4G LTE. But, even though I spend $250 per month on data, I still run out, and end up throttled to 128kbps for the last couple days of the data cycle. The internet is pretty much unusable at that rate. I can leave my email downloading in Thunderbird for a couple of hours and that's usable (gmail, however is not very usable), and I can read Hacker News (but not the articles linked, in most cases). Reddit kinda works at those speeds. But nearly everything else on the web is too slow to even bother with. When I hit that rate cap, I usually consider it a forced break and take a walk, cook something elaborate, and watch a movie (on DVD) or play a game.
So, yeah, the internet has gotten really fat. A lot of it seems gratuitous...but, I'm guilty of it, too. If I need graphs or something, I reach for whatever library does everything I need and drop it in. Likewise, I start with a framework like Bootstrap, and some JavaScript stuff, and by the time all is said and done, I'm pulling a couple MB down just to draw the page. Even as browsers bring more stuff into core (making things we used to need libs for unnecessary) folks keep pushing forward and we keep throwing more libraries at the problem. And, well, that's probably necessary growing pains.
Maybe someday the bandwidth will catch up with the apps. I do wish more people building the web tested at slower speeds, though. Could probably save users on mobile networks a lot of time, even if we accept that dial-up just can't meaningfully participate in the modern web.
And as for reddit, their old mobile view is still available at the "i." subdomain - it's so much lighter-weight than the dreadful JS-laden one they introduced a while back, it's the only way to use reddit on mobile IMO:
I use gmail's Basic HTML interface all the time. AJAXy gmail and Inbox balloon to incredible levels of memory use pretty quickly, and are slower for most interactions than the full-page loads on Basic HTML, which means that someone somewhere lost track of WTF they were supposed to be doing all of this for.
This is commonly stated but not true under all conditions. The full-blown GMail UI has extensive latency-hiding capabilities. The basic HTML UI has no latency-hiding features of any kind. If you are on a high-latency connection but you have some bandwidth available, you will have a much better experience with the full UI. Otherwise you face the full latency for every action.
The Inbox UI is for some reason irredeemable. It is slow under all conditions.
It's a shame that their oldest mobile version, the original m.reddit.com is no longer available. It was truly the most compact way to experience the site. Barely more than a list of links.
Add .compact to the end of add reddit link (before the query) and you can still access it. A few minor things are broken but it still works well enough that I prefer it over the modern mobile site.
Reddit appears to be actively trying to hurt the mobile experience. They bought the best iPhone reddit app, and removed it from the store entirely. They are also currently trialling a version of the mobile site that does not work at all if you aren't logged in.
Personally I'd prefer they just show ads on mobile than make the experience suck on purpose.
I use to get the desktop version on my tablet (nexus 7, 2013). It worked fine, though swapping to .compact was a little easier to use.
For the last month, it's given me the new mobile version. It never remembers that I don't want to try their app (and the opt out link is both tiny and right under the giant yes please button)
But the worse part? I'm on a fast home connection, and the mobile site gives the same loading/network experience as being in the Welsh countryside.
They can still throttle you after a certain level of consumption. With a recent T-Mobile promo, you could have 4 lines for the price of 2, each with its own 4G allotment... so if I ever experience throttling, I can switch to an alternate device.
I have accounts with both. T-Mobile has "unlimited" for the phone, but for hotspots, there are no unlimited plans (this may not be true anymore; I think if you get the new One plan, and add the $25 international option, it includes unlimited 4G LTE data, even for hotspots). The unlimited plan for phones also de-prioritizes customers that use over a certain amount of data in a month; but it's never the device usage that is a problem for me.
Sprint is similar, only even more restrictive in their "unlimited" plans. After 28GB, they throttle the device. Hotspot usage is severely restricted (2GB in the default "unlimited" plan) unless it is specifically a plan for a hotspot (not a phone acting as a hotspot).
There was no unlimited hotspot plan on any carrier at the time I signed up for all of my plans.
Sprint was the best deal per-GB when I hit the road this time around, so I have a 40GB plan on a hotspot from Sprint, and 16GB from T-Mobile spread across two devices (a hotspot and a phone that can act as a hotspot). I end up using all 56GB most months. Each provider gets about $125/month from me.
T-Mobile further complicates things by offering Binge On, which allows me to watch Netflix without burning as much data (the video itself doesn't use data, but all of the meta data, and browsing Netflix does, so once I'm out of data, it's impossible to actually watch anything, even with Binge On).
Data over 3G/4G is complicated as hell, is what I'm trying to say, and it's going to cost a fortune if it's your primary method of getting on the internet. I need to actually confirm with the T-Mobile folks that the One plan plus the International add-on provides actual unlimited data. If it does, it'll allow me to shrink my Sprint plan by a bunch, and stop running out of data.
Also worth noting: T-Mobile used to have a smaller network than Sprint (so much so that when I was traveling in the past, even though I had a grandfathered in unlimited plan on T-Mobile, that they finally made me switch off of a few years ago, I had a Clear hotspot, as well, to fill in the coverage gaps). But, the reverse is true now. T-Mobile's network is also faster in most locations. With the new bands they've put online, T-Mobile reaches further into out-of-the-way places.
In short, "unlimited" is a lie (or was; T-Mobile may actually have an unlimited data plan, now, though I wouldn't be surprised if it still de-prioritizes heavy users...and if "heavy" means some ridiculously small number like 28GB in a month).
Edit: It used to be possible to use a tethering app on a rooted phone to work around such limits. Both networks detect hotspot usage (somehow), even with a rooted phone.
It seems totally reasonable if you're not operating a company to be altruistic.
* Pushing all the rendering to the client makes development easier, eases the transition to native apps, and uses fewer resources on the back end.
* The fancy site drives more conversions and makes the stakeholders happy.
* Not having fast internet is a crude filter for disposable income and losing those users probably goes unnoticed and might even increase the value of ad placements.
After spending a month in Mexico, including regions with spotty/inconsistent service from one minute to the next, I think the problem goes deeper.
Browsers are IMO terrible at mitigating intermittent and very slow connections. Nothing I browse seems to be effectively cached other than Hacker News. Browsers just give up when a connection disappears, rather than holding what they have and trying again in a little bit.
The only thing I used which kept working was DropBox. DropBox never gives up, it just keeps trying to sync and eventually it will succeed if there is any possibility of doing so.
I understand the assumptions of the web are different than an app like Dropbox, but I think it might be a good idea to reexamine those assumptions.
Agreed, Dropbox is great in slow connections. Except when they auto update the client and you can't stop it. It tries to download 60 MB and you have to quit the client and restart it every time you need to upload or download a file until you can get the latest update.
Back in my dialup days (90's), I used to use Opera since it had great tools for dealing with poor connections. E.g. IIRC you could have it only show images that were already cached, with a handy button to async load in new images that weren't already displayed.
621 comments
[ 2.3 ms ] story [ 292 ms ] threadWebapps that make 50 requests to download all the JavaScript and CSS and talk to the API and get 3 images really really really don't behave well when 12 of those 50 requests fail or take 30 seconds to complete. Honestly, I'd rather have slow internet than packet lossy internet.
Still don't know why, but my Xfinity router routinely gets into a state where it drops the first 10 or so packets of any request. The first `ping 8.8.8.8` takes 3 seconds, the rest are the usual 0.1 second. Terrible.
I don't notice it much on my PC, since I've got a FTTH connection, but on LTE and 3G, it's very noticeable. Enough that I avoid certain websites. And that's nowhere near slow by his standards.
I do agree that everyone would benefit from slimmer websites.
Oh, sure, a few sites need JS (and get whitelisted) and some just have minor layout quirks... But I can actually scroll down and read the text of a news article rather than suffering through waiting times and input-latency as Javascript churns.
I'm already sick when I have to visit a webpage and it won't even load ANYTHING if I don't enable scripts on it. At least load the god damn text, I don't care if it'll look like trash, just don't show me a blank page...
The irony is that everyone calls for people to not use Flash, and then they go out of their way to recreate the abysmal experience without it, so really nothing changed as far as UX goes. Remember when pages didn't load at all unless you had flash installed? Well here's some nostalgia for you, won't load unless you run all the JS on the page and then you have to "enjoy" a bloated joke of a website, but Jesus does it have eye-candy!!!
Clearly not enough people, because it keeps happening. I think it would also help if people kept in mind that the internet is global, it isn't just for developed nations.
Much of the internet is a business, not a passion project. There are plenty of businesses that are completely OK with being inaccessible to users on 2g/3g in the developing world.
"Bill, phone calls are so 1992, they hired a web dev to create online polls"
we decided static html webpages are sooo 1999. Yet it remains the most secure and user friendly medium to deliver value.
bring back the 1999 frame side bar. what was wrong with that?
God I miss the late 90s and the internet. Even looking through neocities gives me a pang of nostalgia.
Now everything has to be "Material Design" or "Flat".
¯\_(ツ)_/¯
That's funny. Back in the day, every Real web developer learned that frames are Evil and must be abolished, because they are breaking the back button and now the poor user can't provide a link to the view he sees, because the state of all the frames isn't encoded in the URL.
Then web2.0 happened and all the Cool web devs knew it's the time to start abusing ajax, use modal dialogs, break the back button, and turn simple websites serving text and images into complex stateful web apps and in doing so, ensure that people don't have nice URLs that encode the view they see, for linking.
Hello??
I completely agree. I think the problem is that bad designers are misusing a good tool. It's like salt: If I add a little to my meal, it makes it better. If I add a LOT of it to my meal, it doesn't keep getting better.
Unfortunately this causes a knee-jerk reaction to anything JS. Although I don't think JS is to blame, I think the hatred of JS comes from a good reason.
Unless it's really clever I'd prefer if they just let the browser do it's thing with an img tag, because that worked fine in the 56K times.
I think the greater tragedy is not that the web is bloated (an issue for sure), but that so much of America has internet worse than 3rd world mobile 2G.
> Popular themes for many different kinds of blogging software and CMSs contain anti-optimizations so blatant that any programmer, even someone with no front-end experience, can find large gains by just pointing webpagetest at their site and looking at the output.
That's a compromise. Too many sites don't deal well with thin browsers, but I need space for my terminals. This width usually works, although I sometimes have to do a bit of horizontal scrolling to get the article fully visible. (As opposed to the sadly inevitable sidebars.)
Margins are good, though.
body{max-width:640px;margin:auto} The extra 33 bytes won't slow things down (unless you somehow hit the next ~1kb packet boundary)
line-height 1.5; would also make it more readable.
Well, that's how it seems to be implemented anyway. Ems usually do better.
Try any mainstream commute on the South West Trains Wimbledon to Waterloo (London) and you'll a) still get blackouts for about 1/4 of the 25 minute trip (this is one of the most densely populated areas in Europe - no excuses) and b) at 3 of the 4 stations you'll stop at, your vaunted 4g connection will drop to 1998 speeds due to contention. I generally curse the complex sites in these situations because you'll easily be waiting 30-90 seconds (firmly in your heatmap's red zone) for full load at least once per commute.
Incidentally, kudos on perfectly communicative yet lightweight web page (50Kb).
https://news.ycombinator.com/item?id=13397282
Anyone here have information on the most reliable heuristics to do retries?
Or information on the implementations used by say Gmail or Facebook?
1. There is extra connection information, or information can be sampled. E.g. query to see if anything is responding.
2. Our user just wants to get action ASAP. Not necessary to be a good citizen, our user just wants it to work.
3. Heuristics depend on what works in practice. HTTP/S is a comp layered protocol so it is hard to know what is right.
4. Connection conditions are extremely varied, mobile connection type, overseas location, ISP, IPv6, proxies, VPNs, etc all affect the connection parameters so finding a reasonable heuristic is hard.
5. Sampling connection information is difficult, because when it fails you also fall to log it.
Also, as a side note, any page that becomes unusable because an ajax request failed to return has some really broken design. Ajax retries are not a solution for that, go fix the design instead.
Let's see if the market rewards us or punishes us for this approach...
Your approach helps with reliability (fewer 3rd-party and browser needs) and accessibility (workable with lynx and screen readers) too. Latency makes people want to scream.
It's also important to remember that, to the customer, you are just another browser tab. The customer's computer is not dedicated to you. They could have 100 or more other tabs open. The customer may even have reason to open more than one copy of your site simultaneously, with same or different login, and same or different browser. Bogging down their computer makes them unhappy and resentful.
If your target audience has great internet, then ignore optimising for size. But be aware that people travel, and your market may change, so what is ok in SF may become unusable if they go on holidays, move offices or need to work of roaming data due to an outage.
Because we have the capability to work beyond that capacity now in most cases. That's like asking "why shouldn't we allow horses on our highways?"
> Pretty much everything I consume online is plain text, even if it happens to be styled with images and fancy javascript.
No doubt, pretty much everyone who works on web apps for long enough understands that it's total madness. The cost however, in supporting people so far behind as to only be able to serve them text is quite frankly unmanageable. The web has grown dramatically over the past 20 years both in terms of physical scale and supported media types.
The web is becoming a platform delivery service for complex applications. Some people like to think of the web as just hyper text, and everything on it should be human parse-able. For me, as someone who has come late to the game, it has never seemed that way. The web is where I go to do things: work, learn, consume, watch, play. It's a tool that allows me to access the interfaces I use in my daily life. I think there's a ton of value in this, perhaps more than as a platform for simple reading news and blogs.
I look forward to WebAssembly and other advancements that allow us to treat the web as we once treated desktop environments, at the expense of human readability. It doesn't mean we need to abandon older + simpler protocols, because they too serve a purpose. But to stop technological advancement in order to appease the lowest common denominator seems silly to me.
Adding to your analogy, the JS bloat mentioned in the article is like driving a semi-truck carrying only one carton of oranges. It's a lot of extra waste for a very slight benefit.
Seems like costly optimization with almost no benefit to me.
* Even so, it would simply be an artefact of them never bothering to optimize for people with slower internet connections. If they did optimize, a lot of their traffic would come from the so called "lowest common denominator" just as the blog post says it did for Google.
* Finally I find the term "lowest common denominator" misrepresentative because it implies that optimization needs to cater to the slowest connection on earth, which is clearly not the case. If the average speed is above 90% of internet connections (as per Akamai report cited in the blog post) then the distribution of internet speeds is clearly skewed and there's value trying to even cater for median if not the minimum speed.
Not only does this make twitter usable on dialup again (it was effectively unusable ever since they switched from a simple html page to a massive "application" that you have to re-download every time they deploy), but it lets you search through tweets you've read in the browser history.
Getting this stuff right is not rocket surgery.
2. 140-char limit isn't about SMS.
VHS is archaic.
Except if you are in a rural area of a developed country, or in practically any undeveloped country. Most of Africa, Asia and South America have abysmal internet connections, and rural parts of Australia (even a few hours drive from a major city) are only able to get satellite internet.
Tech people often fail to realise how divided and limited access to internet actually is once you leave 'tech hubs'.
Twitter, like most companies, exists to make money. If you're busy shaving off every bit you can from your requests, you're spending a lot of money. You're also losing money because I'd expect you wouldn't be serving ads, etc. as well.
Most blogs that exist to make money aren't targeting those without good internet either, so I don't really see the problem.
This isn't just about Twitter, its about making sure if you are helping build a local Mom & Pop Shop's online presence - which is where all business is now days - then you build it in a way that their customers might care about.
There is a world outside of cities, and a lot of people live there. The tech world needs to wake up to that, because those people where Ubers don't go, GrubHub doesn't deliver, they exist (and vote) too.
If they do, companies will be happy to spend time and resources in serving lighter versions of their content. But if they don't, there's no reason, from the POV of a company, to employ resources in something that doesn't generate revenue.
If there's money, there's will.
No, it's not. Yes, there are MMORPGs that run in the browser using WebGL.[1] But very, very few pages use all that capability. Most web pages today would work just fine in HTML 3.1.
And what is this thing with running over ten trackers on one page?
[1] http://www.webglgames.com/
Most webpages today that would work fine in HTML 3.1 aren't built as massive JS web apps. If they are, it may serve a purpose (better UI/UX for most of their users being a major one.)
We do allow horses on our "highways" in the UK, not motorways but other highways. It's a terrible analogy though as you can't have progressive enhancement of a road for the vehicle capabilities as you can a website.
>But to stop technological advancement in order to appease the lowest common denominator seems silly to me. //
Not serving simple text, for websites where that's appropriate, and then offering enhanced capabilities when the web client can make use of them seems perverse to me.
You don't have to not advance the technology, having radio broadcasts doesn't hold back VR/AR, but if all you have to convey is able to be passed on in an audio stream then purposefully designing a site to be hostile to clients that can only consume an audio stream to me is wrong. Sure add on an immersive environment where one can play on a VR beach whilst listening to your "24/7 wave noises" but don't make it so that simple audio access is impossible if the primary content only requires that.
In other words don't require webgl so I can see your store opening times.
No, no it's not, it's really not. You're already writing your SPAs with a REST backend, right? Well, guess what: static HTML & REST go together like burgers & beer! All you need to do is add an HTML content renderer to your REST backend, and you have _something_ someone can use to interact with.
> The web is becoming a platform delivery service for complex applications. Some people like to think of the web as just hyper text, and everything on it should be human parse-able. For me, as someone who has come late to the game, it has never seemed that way. The web is where I go to do things: work, learn, consume, watch, play. It's a tool that allows me to access the interfaces I use in my daily life.
True fact: learning, consuming & watching are all well-supported by static HTML.
> But to stop technological advancement in order to appease the lowest common denominator seems silly to me.
Part of the problem is that we're not advancing technologically: we're getting bogged down in the La Brean morass which is modern web development. HTML is a terrible but acceptable markup language; CSS is an ugly but somewhat acceptable styling language; the DOM is as hideous as a Gorgon; JavaScript is approximately the worst language ever; the combination of all the above is grotesque, and an ongoing indictment of our entire industry.
A cross-platform application-distribution standard sounds pretty awesome, but that's not what web pages are supposed to be, and it's not what web browsers should deliver. The web is a web of hyperlinked documents. It's right there in its name. And anyone who demands that his readers enable a somewhat cross-platform, highly insecure, privacy-devouring application-distribution tool in order to read his text is welcome to take a long walk off of a short pier.
The web used to be a web of hyperlinked documents. This has not been the case for a long time now. Webapps have evolved to enable widespread communication, collaboration, gaming, social media, and so much more.
It's the single-largest open platform that's available from nearly any device in the world. It's a little more than a document viewer.
Javascript, the DOM, yeah agreed.
Horses on highways would cause accidents. I have yet to see a fast-moving web page crash in to a slow-moving one and shut down the router. Analogies work better when there is connective tissue between the concepts in play.
More generally, the vast bulk of the problem is not human readability or interactivity over http, but more a matter of insane amounts of unnecessary gunk being included in web pages because of faulty assumptions about the width of pipes.
More generally, I find myself moving in the opposite direction. I find that many SaaS services' interests don't align with mine, so I'm going back to local applications. I don't trust others with most of my data, so the only service that sees much of it only sees encrypted blobs (for offsite backup). I've always run my own mail, and have slowly been expanding the services I host as I bring more of this stuff in-house. And so on. But I realize I'm in a minority.
But the nice thing is that it gives me an intranet and "other" grouping that is very straightforward, so that the browser instances that touch untrusted (not-mine) services can run in "bastion" VM, locked down nicely and reset to a pristine state at will, not to mention allowing some stupid networking tricks that are sometimes useful.
To be pedantic, if you have a threaded server (thread per connection) slow clients can cause problems.
https://en.wikipedia.org/wiki/Slowloris_(computer_security)
Doesn't affect the vast majority of users.
> But I realize I'm in a minority.
Yes, your statements are pretty anecdotal and don't really relate to the vast majority of internet users.
I'm sure your setup works great for you, but it sounds like a ton of overhead, none of which is required if you have fast internet and don't give a shit about what's going on (like nearly everyone who uses the internet.)
It's not that they don't. It's that you don't care.
Because why should you care about something that doesn't meaningfully increase ad revenue or sales? Why should you care that the 2 extra seconds of pageload on a fat pipe, and a fraction of a cent of extra electricity burned, when multiplied by a million of your US users add to over 500 man-hours and few kilograms of coal wasted. Not to mention the site being unreliable or unusable in trains, rural areas and larger buildings in which an user doesn't have Wi-Fi access.
And the problem wouldn't be as big if it was just you. The problem is, everyone else thinks the same way, so all the waste mentioned above adds up. All because people are too lazy to not put useless gunk - which often requires more work to add to your site than to refrain from using it in the first place.
You are right, they are not the best, but people make do: http://www.mapministry.org/news-and-stories/amish-buggy-acci...
The Amish frequently do so in my area.
I posted the links below on a previous discussion about AMP. They are two examples of basic, javascript-free web pages with text content. There's about 2500+ words on these test pages, but the page weight is still much smaller than, for example, a medium article with one tenth the number of words (250).
Try loading them on your mobile on a 3G (or slower) connection. Do they load fast or slow?
Version A: http://interfacesketch.com/test/energy-book-synopsis-a.html
Here is an identical version to the above but one that loads custom fonts (approx 40kb extra).
Version B: http://interfacesketch.com/test/energy-book-synopsis-b.html
You can also try loading the font locally first, to avoid the download if it's installed on the user's system.
Finally, unicode-range lets you avoid the download completely if that character isn't included on the page. Not a likely outcome on an English page, but a good practice regardless.
Webfonts are tough to optimize, but not impossible. Right now there's solutions of using Javascript to background the font so it's non-blocking (eg. loadCSS[1]), but it's not ideal when trying to keep overhead down. The situation should improve once font-display[2] becomes standardized.
For what it's worth though, I find Version B looks much nicer.
[1] https://github.com/filamentgroup/loadCSS
[2] https://css-tricks.com/font-display-masses/
Version B has two different font weights from the same family: Regular and Medium/Semi-bold. Version A relies on the fonts already installed on the user's computer.
Dropping the semi-bold font weight would save approx 23k, but having a regular and bold font weight felt like the minimal styles needed to support the page.
Dropping the header image would save 40k. (Note: the header image hasn't been optimised using something like the HTML srcset attribute which can load different picture sizes for different devices).
I don't load fonts. I either don't notice a difference, or the fancy pants fonts are hard to read.
As a counterpoint, I have a 1G FTTH connection, 8GB of ram, but only a dual-core 1.4 GHz Haswell (Celeron 2955U) and an iffy SSD, so I get a terrible web experience if I have more than one tab open.
Sounds like you need an adblocker, Firefox ESR + ublock Origin should be enough to make a 10yo single-core machine usable for common web browsing
Why are word processors not orders of magnitudes faster than two decades ago? Same reason. No one wants to pay the additional costs of achieving that.
Practically speaking, this means that either Random Local Newspaper Inc. knows their potential online reader base exactly and deemed the additional effort not to pay off, or they have no idea of their potential customers that would flock to their site if they did put in the effort, and thus don't miss them. Add on top of that the fact that much of the internet is based on (perhaps only assumed) prestige (or loss of it if your page doesn't have the most modern features A through Z or looks like its from the 90ies) or extremely short-lived (a newspaper doesn't care about yesterday's news) and this theory pretty much explains it all.
Cynical, I know, but hey... :-/
Edit: Also: We can have nice things. No one with a 56k connection will honestly try to watch Netflix. A much more interesting question would be: How could we create incentives for big corporations to optimize their pages for connections with a small bandwith? After all, much of the web is also built on ad deals - which also almost certainly don't target those people.
Because even in the 1990s, word processors weren't orders of magnitude slower than the person sitting at the keyboard, which is the ultimate limiting factor on word processing speed.
The same goes for almost any website: People with 56k don't consume much digital goods and returns from ads are most likely almost non-existent (especially if the ads are huge themselves). That easily explains a huge part of the web.
Thus, either the connectivity around the globe has to be improved (thats the route Facebook seems to choose, albeit with debatable conditions for their new "customers") or create other incentives for anyone hosting something on the web to attract people with low bandwith connections.
More like 'why shouldn't we allow people on our streets?' Which is a good question. It's a question we answered. With a yes.
>I look forward to WebAssembly and other advancements that allow us to treat the web as we once treated desktop environments, at the expense of human readability.
If you want to make a desktop programme, make a desktop programme. Don't ruin the web.
At my job, I work on a web app. It runs only on Android devices through a web view in a native app. It could have been a native app, and would have felt more natural on an Android device, been faster, and probably more secure too.
I don't disagree that web and web applications provide a lot of convenience and I don't want to loose that. But I don't think for a moment that things can't be significantly more efficient.
T-Mobile used to offer 2G internet speeds internationally in 100+ countries included in Simple Choice subscriptions. 2G is limited to 50 kbit/s, that's slower than a 56K modem.
While this absolutely fine for background processes (e.g. notifications) and even checking your email, most websites never loaded at these speeds. Resources would time out, and the adverts alone could easily exceed a few megabytes. I even had a few website block me because of my "ad blocker" because the adverts didn't load timely enough.
Makes me feel for people in like rural India or other places still only at 2G or similar speeds. It is great for some things, not really useable for general purpose web browsing any longer.
PS - T-Mobile now offers 3G speeds internationally; this was just the freebie at the time.
Single Page Applications with dozens of MB of Javascript, Google AMP (which has a JS runtime taking several minutes to load on 2G), and so on.
source? the entire goal of AMP is to load pages quickly
Here's the current top story when I hit news.google.com in a mobile browser:
https://news.google.com/news/amp?caurl=https%3A%2F%2Fwww.was...
Loading that in a simulated 2G connection takes about 80 seconds and at least 30 seconds of that is waiting to display anything you care about. Looking at the content breakdown shows why: ~200KB of webfonts, 1.2MB of JavaScript, 275KB of HTML, etc.
https://www.webpagetest.org/result/170208_DV_R2R1/2/details/...
https://www.webpagetest.org/result/170208_5Y_R404/1/details
Loading the same page without JavaScript pulls the content render time down into a couple seconds, still over 2G:
https://www.webpagetest.org/result/170208_5Y_R404/1/details/...
Sounds like either a configuration issue on your end or maybe your wireless carrier.
The problem is simply a brittle design which depends on a ton of render-blocking resources. The assumption is that those will be cached but my experience is simply that fairly regularly I'll click on a link, see the page title load (indicating the HTML response has started), and then have to wait a long time for the content to display. Many news sites also load a ton of stuff but since fewer of them block content display waiting for JavaScript, the experience under real-world wireless conditions is better in the worst case and no worse in average conditions.
The average expection changed. Back in the day, everyone was on $SLOW_SPEED, so pages were designed for it. Now-a-days they can, and do design, pages for higher speeds
Kind of makes me miss the old plain HTML days - much less CPU intensive too.
At work we did something similar a few years ago with our Android app. We dropped support for Android 2.3 users because we only had a couple hundred of them and it didn't justify the developer cost to maintain it. WhatsApp only dropped support a month ago. I don't think that was because they were somehow less privileged than us.
The casual ageism in your comment is unbecoming. You could reconsider it.
[0] The ones I've worked with
Your making it usable for that 1%, but you're making it better for the other 99%.
This will make a few segments of people cringe because much like the topic of racism, there's a school of thought that it only counts when things are exhibited in severe forms like water cannons, attack dogs or restrictive housing covenants or otherwise people being directly being told 'no' because of superficial topics like race, gender or sexual orientation.
But as a tech guy who's slowly pivoting towards law, I've long held the belief that technology will become the next battle ground for civil rights-and has the potential to even change (in the sense of expanding the definition of) how we talk about civil rights. Think along the lines of people being left behind when it comes to accessing information they need to request public resources as more and more cities move towards online only forms, or even utilization of "entitlement programs" to pay for internet access (http://www.usnews.com/news/articles/2016-03-31/fcc-expands-o...).
Now it may not be active discrimination in the sense that one will be outright told 'no', but disparate impact deserves to be at the table of discussing this sort of thing.
And you'll be more secure, and you'll retain more of your privacy.
I find 'this site requires JavaScript' to be another way of saying, 'the authors of this site don't care about you, your security or your privacy, and will gladly sell all three to the highest bidder.'
It takes more work to have a bloated JS mess of a site, than it is to have a small, simple, clean site. If they were lazy, they wouldn't have gotten to that spot in the first place.
Antoine de Saint-Exupery
The lazy approach WILL lead to bloat.
No news agency is running a plain jane HTML website.
There is definitely a trade-off between ease-of-use and cost-of-use and I feel this gap is bridged by the content created by those who could not publish bare bones.
I don't understand what you mean by that. Content creators don't need to be developers for us to use simple, reliable systems.
> There is definitely a trade-off between ease-of-use and cost-of-use and I feel this gap is bridged by the content created by those who could not publish bare bones.
Yes, but I personally find the "ease of use" to be worse on heavy, slow, bulky sites. If content is "easier to use", then why are people constantly angry at slow, non-responsive interfaces? I see and feel this all the time, yet it's somehow "easier to use"? I don't see people complain when sites are fast, responsive and simple. Everyone's top complaint is that their computer/phone is "soooo slooow". Why is this, when we have extremely fast computers?
That's the problem. If you do legitimately need it, then yeah, it might be, but my experience says you probably don't need that.
[Edit] "blogs and news sites should be static" -> this should read "blogs and news sites don't need JavaScript"
Still using them for the side effects. Its nice to be able to start reading an article immediately without waiting for the jumping around of content to stop. And actually read until the end without having modal dialogs shoven down my the throat.
There are a good number of sites now which have entirely given up on progressive enhancement and simply don't show you anything without JS... but I generally find I just don't care, and just close the tab and look at the next thing instead.
I guess we're almost all on evergreen browsers now anyway...
OTOH, in Chrome the website actually works fine and feels more snappy with JS disabled. So, thanks for the tip!
Seeking out or thinking as though you have bandwidth constraints can push you to find better solutions and thereby make your services better. The west and the tech centers in particular is really rather blinded by the glutinous bandwidth that keeps eating up greater and greater amounts of data with only marginal improvements in outcome or user experience.
I used to work at a place that had a <1mbps modem, and a ~7 year old destkop. If their software didn't work on that, it needed to be optimized. I wish more places would test this way. Your sight may work fine in downtown SF, but that doesn't mean it's going to work well anywhere else.
I've gotten a lot of blank stares.
That's why more designers don't bother: decision makers usually respond only to look/flashiness/branding.
I don't think this has changed, at least not in general. The included roaming package is still free international 2G roaming everywhere except Mexico and Canada (which get free 4G), with "high-speed data pass" upgrades available for a daily or weekly fee if you want faster. They did have a promotion for the 2nd half of 2016 (initially for the summer, then extended through the end of the year), where international 3G, and in a few areas 4G/LTE, was free without buying the upgrade passes for most of Europe and South America [1]. But that's now over, and I believe it's back to free 2G internationally now.
[1] https://newsroom.t-mobile.com/news-and-blogs/t-mobiles-endle...
Hacker News was pretty much the only site I visit that could reliably load quickly. m.facebook.com had a slight wait but was still bearable. I had to leave my phone for 10 or 15 minutes to get Google News.
WeChat and email worked well.
Everything else was horrible, especially ad networks that would ping pong several requests or load large images.
Opera has a compression proxy mode that helped a bit when it worked but it was still painful.
For search results, Stack Overflow, and YouTube, it was easier to easier to ssh into an AWS node and use elinks/youtube-dl.
Using SSH as a socks proxy/compression was insanely slow due to something with with the great firewall.
With iOS9+ content blockers and things like Google AMP, I think the web is a lot more usable.
Apps tend to be less bloated in terms of bandwidth as well, since they usually don't load as many assets on request.
I hate the all-or-nothing approach to shaping. At least give me 5Mbit or something!
I live in California -- this is not just something people internationally are dealing with.
Annoyingly, T-Mobile's own website doesn't work properly when you're throttled to 2G speed. Found that out the hard way when I ran out of minutes on Thanksgiving and couldn't talk to my family, and couldn't load their website to add more minutes.
We keep repeating our same mistakes but just in a different way.
But after seeing many examples where sites were built on huge iMacs with no care for users running off a battery, slower network connection or with an average 1366x768 display I somewhat agree with the sentiment.
I can also say that at no point did I feel entitled for it to work better for me. I don't understand this level of entitlement (i dont like your ads, i dont like your layout, i dont like your visual effect ...) ... just leave the site.
The modern web isn't simple static pages... its not going to revert to that, either. We're developing actual applications in the browser now... those aren't easily translated to static, simple pages...
This is today's "grumpy old engineer" argument...
Just for fun, I just took a screenshot of that table and made a PNG with indexed colors: 21243 bytes.
(I manually minified the whole source; the original is 53313 bytes, 12438 gzipped, while my minified source is 25628, 10124 gzipped. Most of the bloat in the tables compresses really well, as is common with such things.)
Just curious how you went about it, if it was /all/ manual or some interesting technique.
My result was not too shabby, 7kb I think it was when I stopped due to the time cropping up.
So uncompressed javascript and images are bad, but I thought apex domain to www subdomain redirection was an optimisation as the apex domain can often only point to a single server but the subdomain can point to a range of geographically well distributed CDNs. So rather than going to North America for every request, the browser only needs to do it once than the rest can come from a regional CDN. Am i misunderstanding something, does this also break down on a slow connection?
For geographic routing, there is a clever trick that can be utilized using a technology called Anycast. Anycast is basically a way of assigning the same IP address to multiple machines so requests to that IP address results in connecting with the one that's the closest to you, route wise.
Providers sometimes use Anycast DNS Name Servers and configure them to provide the different IP addresses depending on which name server people connect to.
So, if someone wants to determine the IP address of ebay, their DNS client connects to ns1.ebay.com and asks "hey, what's the IP addresses for the A records for ebay.com" and ns1.ebay.com replies with the list.
But ns1.ebay.com might be an Anycast DNS Name Server that's close to them and it provides the list of IP addresses closest to that name server. Someone on another continent might reach a name server with the same name and ip address, but it's a different machine in a different data center. It would provide a list of IP addresses on that continent.
I do something similar with one of my sites. I rent three VPS's from buyvm.net (who has Anycast setup) that have the same IP address and are located in Las Vegas, New Jersey, and Luxembourg. I pay less than $10 a month in total and run my DNS name servers there.
Clients that connect to the name server in Las Vegas get an IP pointing to a Digital Ocean load balancer in San Francisco proxying data from a few front-end VPS's.
Clients that connect to the name server in New Jersey get an IP pointing to an OVH Canada load balancer near Montreal.
Clients that connect to the name server in Luxembourg get an IP pointing to an OVH load balancer in the North of France.
The result is a responsive service that has amazingly low latency for the US and the EU. Gonna try to set up some infrastructure in Singapore soon to make things faster for Australia and Asia.
So really, I think what the author is observing is that having experienced high-speed reliable connections, it is very disappointing to move to a much slower connection. For the emerging tech markets, I can imagine the experience would not be great if the load was long enough to cause timeouts and connection failures, but at the same time, the 99% experience, as it probably was when the web was born, is "holy crap look at everything I have access to now!"
Yes, there are some really terribly optimized and redirect-happy sites out there and yes, you should do everything you can to make your page speedy. Everybody benefits when you do. I think, though, that this is more of a case of "let's be thankful for and aware of what we have," and "if you suddenly have a slower connection you might find yourself annoyed" more than "most sites suck on slow connections."
Yes, lots of the early web sucked over dialup.
I'd argue that it did, just like having 32MB of RAM and Windows 95 did. But almost everyone was in the same place, including the people making content for websites we went to, so page load times were as good for their minimal experience as the technology would let them be. Even in 2002, my family was still on dial-up, and it sucked because I knew how much was out there that just wasn't feasible for me to access.
Yes! Pages loaded in 10 to 20 seconds.
I remember people complaining that the web was too slow compared to gopher, even on pages without images.
The assumption is here that both points of the connection is based on earth. When we have these hard timeout limits, how will stuff even remotely work when we are a interplanetary species or even from orbit around earth?
This effect is exacerbated if the web site you're connecting to changes congestion control and TCP ramp up settings.
We won't be and aliens have better internet anyway :)
(NASA has their wacky ways around the issue for ISS residents, something like VNC to a ground-based browser IIRC.)
I wonder if there's still a more "API level" way to handle things, though, rather than making your computer into a dumb frame buffer client with extremely low responsiveness to typing/scrolling.
Maybe they could run a headless browser on Earth, and use a protocol like the Chromecast does to synchronize its DOM state to a "browser proxy" in space—like a higher-level, domain-specific version of the X11 protocol. That'd still have latency for JavaScript-based webapp UI, though... maybe the JS could be split and its state synchronized so that the "server" handles timer triggers, while the "client" handles input events.
of course the same is true of ground stations... I'm not actually sure how they do it but they probably don't need as high-gain of an antenna to reach them.
Wait, VNC? Won't that use oodles more bandwidth than proxying HTTP?
This is one of my favorite NT4 tidbits :)
IPFS or similar. Basically, make all public content content-addressed (give me the article with SHA 0xabcdef) rather than connection oriented (give me the bytestream that comes from http://news.ycombinator.com/foo/bar)
I would not expect interactive anything when latency is 20min+. Usenet and listservs should work fine tho, maybe worth some tweaks to the underlying protocols if they're too chatty.
Later plots faced invasion attempts through the stargates (permanent, direct-dial wormhole portals), so matter shielding was employed, and signals were used to authenticate who was on the other side of the connection before lowering the shield.
So, yeah, the internet has gotten really fat. A lot of it seems gratuitous...but, I'm guilty of it, too. If I need graphs or something, I reach for whatever library does everything I need and drop it in. Likewise, I start with a framework like Bootstrap, and some JavaScript stuff, and by the time all is said and done, I'm pulling a couple MB down just to draw the page. Even as browsers bring more stuff into core (making things we used to need libs for unnecessary) folks keep pushing forward and we keep throwing more libraries at the problem. And, well, that's probably necessary growing pains.
Maybe someday the bandwidth will catch up with the apps. I do wish more people building the web tested at slower speeds, though. Could probably save users on mobile networks a lot of time, even if we accept that dial-up just can't meaningfully participate in the modern web.
https://support.google.com/mail/answer/15049
And as for reddit, their old mobile view is still available at the "i." subdomain - it's so much lighter-weight than the dreadful JS-laden one they introduced a while back, it's the only way to use reddit on mobile IMO:
https://i.reddit.com
It's easily worth the loss of a couple features.
The Inbox UI is for some reason irredeemable. It is slow under all conditions.
Personally I'd prefer they just show ads on mobile than make the experience suck on purpose.
For the last month, it's given me the new mobile version. It never remembers that I don't want to try their app (and the opt out link is both tiny and right under the giant yes please button)
But the worse part? I'm on a fast home connection, and the mobile site gives the same loading/network experience as being in the Welsh countryside.
Sometimes I can't even get to the HTML view because of the login process!
I have accounts with both. T-Mobile has "unlimited" for the phone, but for hotspots, there are no unlimited plans (this may not be true anymore; I think if you get the new One plan, and add the $25 international option, it includes unlimited 4G LTE data, even for hotspots). The unlimited plan for phones also de-prioritizes customers that use over a certain amount of data in a month; but it's never the device usage that is a problem for me.
Sprint is similar, only even more restrictive in their "unlimited" plans. After 28GB, they throttle the device. Hotspot usage is severely restricted (2GB in the default "unlimited" plan) unless it is specifically a plan for a hotspot (not a phone acting as a hotspot).
There was no unlimited hotspot plan on any carrier at the time I signed up for all of my plans.
Sprint was the best deal per-GB when I hit the road this time around, so I have a 40GB plan on a hotspot from Sprint, and 16GB from T-Mobile spread across two devices (a hotspot and a phone that can act as a hotspot). I end up using all 56GB most months. Each provider gets about $125/month from me.
T-Mobile further complicates things by offering Binge On, which allows me to watch Netflix without burning as much data (the video itself doesn't use data, but all of the meta data, and browsing Netflix does, so once I'm out of data, it's impossible to actually watch anything, even with Binge On).
Data over 3G/4G is complicated as hell, is what I'm trying to say, and it's going to cost a fortune if it's your primary method of getting on the internet. I need to actually confirm with the T-Mobile folks that the One plan plus the International add-on provides actual unlimited data. If it does, it'll allow me to shrink my Sprint plan by a bunch, and stop running out of data.
Also worth noting: T-Mobile used to have a smaller network than Sprint (so much so that when I was traveling in the past, even though I had a grandfathered in unlimited plan on T-Mobile, that they finally made me switch off of a few years ago, I had a Clear hotspot, as well, to fill in the coverage gaps). But, the reverse is true now. T-Mobile's network is also faster in most locations. With the new bands they've put online, T-Mobile reaches further into out-of-the-way places.
In short, "unlimited" is a lie (or was; T-Mobile may actually have an unlimited data plan, now, though I wouldn't be surprised if it still de-prioritizes heavy users...and if "heavy" means some ridiculously small number like 28GB in a month).
Edit: It used to be possible to use a tethering app on a rooted phone to work around such limits. Both networks detect hotspot usage (somehow), even with a rooted phone.
https://twitter.com/xbs/status/626781529054834688
(I'm not putting /s because there's actually people that think this is a reasonable opinion in the general case).
* Pushing all the rendering to the client makes development easier, eases the transition to native apps, and uses fewer resources on the back end.
* The fancy site drives more conversions and makes the stakeholders happy.
* Not having fast internet is a crude filter for disposable income and losing those users probably goes unnoticed and might even increase the value of ad placements.
Browsers are IMO terrible at mitigating intermittent and very slow connections. Nothing I browse seems to be effectively cached other than Hacker News. Browsers just give up when a connection disappears, rather than holding what they have and trying again in a little bit.
The only thing I used which kept working was DropBox. DropBox never gives up, it just keeps trying to sync and eventually it will succeed if there is any possibility of doing so.
I understand the assumptions of the web are different than an app like Dropbox, but I think it might be a good idea to reexamine those assumptions.