The web sucks if you have a slow connection
danluu.com
danluu.com
A nice chart showing how many users are in each bucket of load time would be far more useful. One that you could easily change the bucketsize from 0.1ms to 1 second and these types of 'digging' wouldn't even be a second thought.
The average human has, on average, one testicle and one ovary, but there aren't many humans who can actually fit this description.
Even by the most optimistic estimations, a video that is a few minutes long at 480p will weigh in at 10 megabytes, meaning it'll take them OVER 3 HOURS to download the entire thing.
You would probably be able to browse (slowly), read comments, but not actually do much else.
I used Internet in the 90s and dial-up specifically as recently as 2004 - and have quite a good memory of the experience. Internet at dial-up speed was an extremely valuable commodity, to the point of disabling images in the browser and only downloading the most essential things (which is about as far from a youtube video you can get) - like documents and zipped installers (after researching that it was what you actually needed) and checking email.
Internet "videos" didn't really even exist as content before ~2005 and Youtube. The biggest player before them was Break.com, which posted a whopping 10-15 videos a day.
While someone may have spent several hours waiting for a key software installer to download, almost no one would do the same for a video of dubious quality and content, certainly not in the 90s.
________________________________________________________________________________________________________________________
To illustrate my point even further, the speed we're talking about isn't even dial-up speed. It's 6.5kbit/second, which makes it almost an order of magnitude slower than a 56k modem! 10 times slower!
And people are actually suggesting that someone would spend that valuable bandwidth to spend days to load a video...
Umm. Porn?
I vividly remember waiting hours to download a video in the '90s. The Spirit of Christmas short that spawned South Park, and that news story about the exploding whale, were viral videos that predated modern video sites by many years. You'd download it off of an FTP server somewhere. At one point, the majority of my hard drive was devoted to half a dozen videos that I'd show to everyone who came over.
Basically, watching a video on your computer felt new and exciting and worth waiting for. I'd never do that today even if I were stuck on a slow pipe, but at the time it was oddly compelling.
That always reminds me: Earlier that decade, a major plot arc of Beverly Hills 90210 featured a nightclub called Peach Pit After Dark. The door of the club had a flying toaster, from the PC screensaver After Dark.
Someone doesn't agree with your comment, but rather than come back with a refutation they voted you down instead :)
And someone else don't agree with my comment .. modded down -4
If people chose to download porn over 28.8k modems, that's their choice. Just seems like a waste of time, that's all. Probably quicker just to take your dad's nudie mags rather than wait 6 hours for a 400x300 jpeg.
I remember using "download accelerators" to try and grab files faster back in the day. Who knew they were just doing 4 simultaneous downloads of ranges of the same file eh?
Ah I feel old
Incredibly useful for enormous files like visual basic 6, which I spent like...a month or so downloading in the late 90s.
And before there was YouTube there was flash videos/animations on Newgrounds. The people I hung with back then were into animutations.
Internet video has been a thing a while before youtube got released hoping to capture enough of this thing through offering to host it for free in the hope to be bought later by one of the big players.
The bigger point was simply that people will wait for things they want. Not being able to load instantly changed the style of interaction but not the desire to listen to or watch things and there's far more content available than there used to be. Tell teenagers that the cool music video is available and you'll find a lot of slow downloads over their entire day at school, work, etc.
By the time I got stuck with slow internet again (boycotting Comcast), they had removed that feature and it really sucked. Now I have fiber and the only drama is around Netflix only allowing you to stream a couple movies at once.
I'd rather let it buffer for 10 min, then watch it in 360p because you guys can't figure out your buffering. The same goes for netflix!
I remember frequently spending three hours downloading 5MB files over dial-up in the late 90s. Mostly software, not videos+, but it really just felt like a regular thing back then.
+ Computers nearly didn't have the power to decode video—or even audio—in realtime back then, unless it was the entirely uncompressed kind. I recall ripping a CD to WAV and finding out half-way that my 2GB hard drive was now 100% full.
Ah Napster.
I, too, remember quite vividly waiting 30-40 minutes to download a 5MB installer for WinAmp and ICQ.
I honestly wouldn't even know where to look for videos in the 90s internet. Most people probably didn't have the upload speed to even consider sharing them online.
I remember the first realtime mp3 player on Windows, Fraunhofer IIS' WinPlay3, which launched in '95. Then Winamp came out in '97 and blew our minds.
Even tried it on mpg123 and mpg321 on RedHat on a 486 DX66 - I was poor. Didn't fare any better.
My Pentium 166 on the other hand was much more capable I could multitask while playing Mp3's (I used to play mp3's and Quake at the same time).
AFAIK all sound drivers in Windows accepted standard PCM data.
I'm very young, only 27, and know that I missed a full decade of early internet culture and can't speak to it. Even given that, I had a 14.4 and fondly remember downloading a music video for hours. (No porn on the modems personally, I think I was barely adolescent when we upgraded to cable)
We take file sizes for granted these days.
Right there in the same link, it says that the video page was a megabyte. It's the sentence directly after the 'two minutes' but. The sentence even has some 'all caps' words in it - even skimming, your eye is drawn to it. Why on earth did you stop reading halfway through the penultimate paragraph?
The modern codecs make these super compressed video and sound relatively watchable.
When they were initially planning the system in 1930s, 40s, they were planning to have the system in use for next 100 years. So they built over sized roads (like 10 lane freeway, without having to stop for traffic lights, that go THROUGH center of a major city).
When the system proved so car friendly, more and more people moved in and bought cars. Within in a short period of time (much shorter than 100), the system is completely jammed.
Always look for unintended consequences...
Also lost in the conversation is opportunity cost: sure people drove more and that drove growth to those areas. However what if the roads had not been built - what would have happened instead? We don't know, but it is fun to speculate. (maybe railroads would still be the most common mode of transport?)
But there was a coalition of mayors and municipal associations that pressured Congress to have the roads pass through their towns (jobs! progress!). President Eisenhower was not amused, but he found out too late to change the design.
A consequence of this was the bulldozing of historically black-owned property to make way for the new roads.
They RIPPED it out thanks to lobbying by car companies and tire companies. Yay to lobbyists.
Now, it takes a billion to build a few miles of a subway/lightrail system that practically goes no where...
https://en.wikipedia.org/wiki/Los_Angeles_Railway
GM, Firestone, and several other companies were indicted in 1949 for attempting to form a monopoly over local transit. The semi-urban legend part (it was never definitively proved there was a plot behind it all) was the ripping out of the streetcars, replacing them with GM-made bus networks.
https://en.wikipedia.org/wiki/General_Motors_streetcar_consp...
Indeed. A couple years ago, the city of St Paul actually formally apologized for exactly this, destroying the primarily black Rondo neighborhood with freeway I-94.
http://www.usatoday.com/story/news/local/2015/07/17/rondo-ap...
The current North American coal proven reserve is less than 300 years of current utilisation rates: http://www.bp.com/en/global/corporate/energy-economics/stati...
It's amazing what a constant increase in growth rate can accomplish. Also the overwhelming tendency for lowered costs to induce an increased demand -- the Jevons paradox.
If you want people to use less of something, increase the cost, not the efficiency.
________________________________
Notes:
1. Henri Erni, Coal Oil and Petroleum: Their origin, history, geology, and chemistry, 1865. p. 15.
https://archive.org/stream/coaloilpetroleum00erni#page/14/mo...
If there's ever a need to widen the road, it can be done without demolishing any tall buildings. I see this in new road layouts in China all the time. Of course, under the road will be a new subway system -- another disincentive for people to buy cars.
[1] When an increase in the efficiency with which a resource is used causes total usage to increase. https://en.wikipedia.org/wiki/Jevons_paradox
See: the entire popular support for efficiency mandates.
(Edit: Also, this very example -- I certainly didn't expect that a faster site would allow that many more users: my model was more "either they want to see your site, or they don't", i.e. inelastic demand.)
The (common) error is to neglect the additional uses people will put a resource to when its cost of use goes down. ("Great news! We get free water now! Wha ... hey, why are you putting in an ultra-thirsty lawn??! You don't need that!")
Also, I wouldn't call it basic supply and demand; depending on the specifics (inelasticiy of demand, mainly), total usage may not actually go up with efficiency.
Which, really, can be summed up by my favorite Yogi Berra-ism "No one goes there nowadays, it’s too crowded."
It usually does actually.
What is happening there is that you have different demand levels at different congestion levels. If you alleviate some congestion by widening the road then demand goes up.
That is only a problem if the demand without congestion is higher than what even the wider road can handle. As long as the new road can handle the higher but still finite demand you get when there is no congestion, there is no problem.
In other words, as long as you make the road wide enough for the congestion-free demand level to begin with, that doesn't happen.
- It may not be physically possible to add enough lanes to e.g. handle everyone who would ever want to commute into L.A.
- Even if that road was correctly sized, it still has to dump the traffic into the next road, through the next intersection point. If you've increased the capacity of the freeway but none of smaller road networks that the traffic transitions to, you've just moved the bottleneck, not eliminated it. And that too may be physically impossible.
In any practical situation car transportation efficiency does not scale well enough that you can avoid addressing the demand side.
That is a separate question from how stupid that is in comparison to the alternative of building higher density residential housing closer to where people work and with better mass transit.
But if people don't want to do that either, you have to pick your poison.
And there really are many cases (Los Angeles notwithstanding) where adding one lane isn't enough but adding two is and where that genuinely is the most reasonable option.
14 percent of LA county (not just city!!) is parking. http://www.citylab.com/commute/2015/12/parking-los-angeles-m...
I'm trying to find a better source, but at one point supposedly 59 percent of the central business district was car infrastructure (parking, roads, etc.) http://www.autolife.umd.umich.edu/Environment/E_Casestudy/E_...
I mean, at what point do you just build a 400 square mile skid pad with nothing else there just to "alleviate traffic"? Hell, that's practically what Orange County is already.
The rest of the day they don't actually park anywhere, they just stay on the road operating by carry one or two passengers at a time instead of eight or nine. Or half them stay on the road operating and the other half go off and park in some huge lot out where land is cheaper until demand picks up again.
Then instead of 3.3 spaces per car you can have <1, and most of them can be in low land cost areas.
It's actually kind of like dynamically allocated mass transit.
Final point, you can certainly build out less parking spaces, but pre-existing spaces won't go away without redevelopment.
This might be an extreme example that won't work for other reasons, but generally adding more lanes will increase demand, so you still won't have enough lanes.
http://www.scottaaronson.com/blog/?p=418
For example:
> Why are even some affluent parts of the world running out of fresh water? Because if they weren’t, they’d keep watering their lawns until they were.
This is the basic reason for naming anything after all a car is just a fossil fuel internal combustion kinetic comvertion wheeled people and goods pilotable transportation platform but saying a car is just easier :)
The paradox is that they tried to reduce demand to reduce consumption, but accidentally reduced price, so increased consumption.
The bit you're missing is that duality, that an action intended to reduce demand could reduce price instead. Applying rules of supply and demand happens as a step after categorising the action, that the action was miscategorised led to a misprediction.
It gets a special term because it was coined in 1865, before most of modern economics was codified and this was a cutting edge finding. You may as well ask why Newton's laws get a special term, because they're all just obvious basic equations in physics that high school students are taught.
Jevons Paradox is only tangentially related. It is based on the observation that sometimes using a resource more efficiently results in higher overall consumption. For example, say 40 kg of lithium is needed for the batteries of an electric car. At some point, 4000 tonnes are produced annually, enough for 100,000 electric cars per year. Now a new battery comes on the market that needs only 20 kg of lithium. Should the lithium producers be worried that the lithium demand will drop, since only 2000 t will be needed for the 100,000 electric cars? Maybe. But if Jevons Paradox comes into play, the annual production of electric cars might triple as their cost drops due to lower lithium usage, and the new demand will then settle at 6000 tpa. So, paradoxically, reducing the amount of lithium in each battery could be good news for lithium producers.
Whether or not Jevons Paradox occurs depends on the elasticity of supply-demand curves, in this case the curves for lithium and for electric cars.
* Engines get more efficient (fewer litres per kilometre traveled). Does the total amount of petrol consumed go down or up?
* Flushes get more efficient (less water / successful flush). Does the total amount of water consumed go down or up?
Both of these have a more efficient use of a consumable quantity. Often, however, more efficient engines lead to more traveling and larger vehicles whereas more efficient flushing leads to reduced total water consumption usually.
The fact that gains from efficiency can be outraced by the induced demand can be seemingly paradoxical. And "seemingly paradoxical" is the only thing that makes anything labelled "Paradox" interesting.
There's a clear and identifiable trend or pattern resultant of the general model, there's no reason not to assign it a shorthand way of being referred to in discussion or study.
Jevons: Quantity required per use goes down, so you might expect total demand to decrease. Instead total consumption goes up.
Giffen: Price per use goes up, so you might expect total demand to decrease. Instead, total consumption goes up.
Either could increase consumption by displacing available substitutes, though that's not necessarily the case with Jevons. They are indeed different phenomena, they just have some similarities.
You know that Andreas Baader and Ulrike Meinhof were the main founders of the terrorist organization RAF (Rote Armee Fraktion (Red Army Fraction)) in Germany. RAF was also the reason that grid investigation was used in the 70th (where lots of innocent people were accused wrongfully) after a RAF terror series, after which some constitutional principles were quashed. The German word for this is "Deutscher Herbst" (German Autumn; https://en.wikipedia.org/wiki/German_Autumn).
These experiences lead (indirectly) to the rise of a completely new party (Die Grünen; The Green Party) and are (besides the experiences with the two dictatorial regimes on German ground in 20th century) one of the reason why data privacy is taken very seriously in Germany.
Thus mentioning RAF, Andreas Baader or Ulrike Meinhof to (in particular older) Germans is perhaps like mentioning Al-Kaida, 9/11, Mohammed Atta etc. to US citizens.
The case of website cost going down and demand going up seems pretty standard.
> To be a true Giffen good, the good's price must be the only thing that changes to produce a change in quantity demanded. A Giffen good should not be confused with products bought as status symbols or for conspicuous consumption (Veblen goods)
Veblen goods = Goods for which demand rises with price because they are status symbols Giffen = Goods for which demand rises with price - Veblen Goods
However there are no examples there that hold, to me this signifies that the only goods for which the law of demand does not apply are status symbols.
No, it's an inferior good (in the economic sense) in which the (negative) income effect of a price increase outweighs the success substitution effect.
What you are describing is a good that has a positive elasticity of demand with respect to income (or, technically, two different goods, because the higher price represents a different good altogether - one with a higher status symbol).
The idea is that the good is the lowest quality way of fulfilling some need - so people buy it because they can't afford anything else.
In practical terms (that may not fill the theoretical definition of the giffen good), spare time in certain circumstances is quite obviously a Giffen good. Once your income increases (which means the opportunity cost of your spare time increases), you are willing to work less, i.e. consume more spare time. Of course, this is not a universal rule, but I think it is obvious that for _many_ people this is the case. If it was _not_ the case, there was no way people in sweatshops work longer hours than western middle class.
https://en.wikipedia.org/wiki/Giffen_good#cite_note-4
I bet you could find it in some video game economies.
If a package of ribeye steak normally sells for $2.99 and doesn't sell well, but then its price changes to $6.99 (but nothing else changes), and demand increases, that steak is a giffen good. The ribeye steak is not conspicuous consumption (unless your definition of status is really loose and includes posting photos of your food to Instagram). What happened there is straightforward: there's an elastic demand for ribeye steak, people saw the price and assumed quality signaling. When it increased to price parity with higher end brands, people assumed quality parity as well.
Conversely, a mechanical watch is specifically optimized to be good at time keeping in the most functional and cost inefficient ways (e.g. assembled in hand in a white gold case with a hand-decorated guilloche dial and proprietary in-house movement mechanisms, etc). That is precisely conspicuous consumption, and thus it's a veblen good.
One good's demand increases because of quality signaling, the other good's demand increases due to status signaling. The point of there being two of these definitions is the nuance in why consumers would purchase luxury items. Theoretically, people don't buy at Trader Joe's just to brag to their upper class friends that they shop at Trader Joe's (this is not a good example but take away a specific brand and you get the gist).
The article states that a necessary condition is that "The goods in question must be so inferior that the income effect is greater than the substitution effect". The reason people are buying more when the price rises is not because of the income effect (which would be because they have less money since the price went up, so demand for inferior goods increases), but rather because they now have evidence/reason to believe that the good is quality.
That's not giffen according to the definition given, which includes a causal factor for the demand curve.
It is simply not true that that a good must be "inferior" to be a Giffen good (unless you adopt a special meaning of inferior, which since it's not necessary to do, I won't agree to). The classic example (thought experiment, without regard to whether it actually happened) is potatoes in poverty stricken Ireland: a poor person's diet would be mostly potatoes (inexensive Econ-Utility (compared to steak): calories, fills the belly) with some meat a few meals a week (expensive Econ-Utility: protein, iron, B vities, tasty, "not potato", even a touch Vebleny)
So, arbitrary budget example, let's say $20 at the grocery gets you $15 potatoes every day and $5 of steak 1 days a week. If the price of potatoes goes up, you need to reduce something, but you need to eat every day so you can't reduce potatoes, so you reduce your steak consumption, but now you have some extra money which you spend on even more potatoes. Price of potatoes went up, consumption of potatoes went up. <-- there is already a theoretical problem there, you could reduce steak just enough to keep potatoes equal, so let's just say you can buy a steak or not buy a steak, no half steaks, OK? just trying to make the point "what is a Giffen good", and not trying to prove whether Giffen goods exist or not.
So, potatoes are not "inferior" to steaks, both are requirements for a balanced diet; I supposed a technical econ-definition of inferior could be designed to mean something along the lines of "inferior is defined to rule out your example, aaight"
In any case, while Giffen goods probably can't exist in a market for any length of time, the concept is completely understandable as a short-term reasonable thing that occurs: I go to the store with cash intending to buy an "assemble your own" burrito with guac, the price of beans went up, I don't have the cash at hand now to get the guac, but it's not a burrito at all without the beans, so I leave out the guac... but turns out by leaving out the guac, I can get a larger size burrito: consumption of beans just went up at the same time as the price. This effect happens for sure... does it happen enough to counteract the people who would leave out the beans and keep the guac? Can the "substition of beans for guac" function always be seen seen to be continuous and differentiable? <-- perhaps not, burrito shops like to have overly expensive add-ons for 2nd order price discrimination, so the price of guac might very well be "quantized" at an absurdly high level, and does that make beans not a Giffen good? ...
my point is, the way you guys are arguing this is leaving too much out, can't be answered and wikipedia at this level of analysis is too unreliable.
Terms of art annoy me (the legal profession and philosophy are full of them, overloaded (OOP definition) on preexisting words) because IANALinguist but I could play one on TV without rehearsing, so my point is, if you want to have a narrow morphology for a word, don't recycle a word that has broad meanings, invent a new word that is precise, like econ-inferior. Then at least when a person doesn't understand what you say, they will think to themselves "maybe I should look up the definition" as opposed to actually believing you said something different than you did.
Nobody can live on potatoes alone, you'd die. Nor can anybody live on steak alone. Neither good can be said to be precisely econ-inferior to another, only econ-inferior over some delta range of prices and/or time (and assuming demand, etc). But the whole question of Giffen goods is also valid only over some delta, so as long as they are different deltas, the definitions would not be in conflict (and vice versa all the variations of that).
Not trying to argue, just trying to clarify what I came upon. Econ theory I think is sound but requires many simplifying assumptions to teach and learn, and then when we talk about whether Giffen good actually exist or not it's easy to lose track of simplifying assumptions like "long term" or "substitution".
cheers.
I remember turning an algorithm upside down, making it so fast, it went from "number crunching wonder" to "users saw nothing, this software is meh".
This while the connection in itself is not THAT bad. I use to use a 3G/4G mobile connection and it generally works excellent, with pretty quick load times, for everything else than javascript-heavy web apps.
I have a hard time understanding why this issue is not paid more attention. Ethiopia alone has some 99 million inhabitants, with smart phone usage growing by the hour. Some sources say "the country could have some 103 million mobile subscribers by 2020, as well as 56 million internet subscribers" [1].
[1] https://www.budde.com.au/Research/Ethiopia-Telecoms-Mobile-a...
There are usually CDN nodes in India. Cloudfront has edge nodes there, google's cdn does.
There's also a Mumbai AWS datacentre.
When you get far away from the common edges, it gets real noticeable.
PING imgur.com (151.101.40.193) 56(84) bytes of data.
64 bytes from 151.101.40.193 (151.101.40.193): icmp_seq=1 ttl=53 time=342 ms
imgur.com works fine
~$ ping python.org
PING python.org (23.253.135.79) 56(84) bytes of data.
64 bytes from 23.253.135.79 (23.253.135.79): icmp_seq=1 ttl=48 time=267 ms
python.org works fine
news.ycombinator.com and reddit.com also works fine even though I'm logged in (there's about a 300ms, 700ms delay in the Network tab of Chrome's devtools for news.ycombinator.com and reddit.com)
PING python.org (23.253.135.79): 56 data bytes 64 bytes from 23.253.135.79: icmp_seq=0 ttl=44 time=615.871 ms 64 bytes from 23.253.135.79: icmp_seq=1 ttl=44 time=539.681 ms
I'm on an island lost in the middle of the Indian Ocean. But ping weren't that different (50 ms more or less) on the continent (I went to RSA and Namibia)
JS-heavy apps make a lot of requests to background servers and should one of those requests fail, apps will hang. It's quite frustrating and I would often load pages with the console open to see which requests have failed so I'm not left wondering what happened.
I think the standard of whats considered slow, bloated, complex has become absurd. I think if the processor companies today release processors that say improves the single thread performance 10 times in two years gmails and facebooks of the world will eat all that up with marginal improvement in functionality. I'm talking about the client side, in the server side yeah they may make 10 times more complex analysis though most likely 80% will go to feeding us more accurate ad.
That also happens on 'good' connections, when some crappy isp router drops the packet without any icmp. The request fails only after a tcp timeout, which is large enough to be noticed. I cannot understand why asynchronous js requests do not involve smart adaptive human-oriented timeouts and why this problem is still not solved in general. TCP timeouts are simply insane nowadays.
Any time you do an XHR you can supply both a success and a failure callback and, if you care at all about your users, the failure callback can come in handy for error recovery, handing off to a retry mechanism, etc.
Modern web apps can be a lot more like fat client apps, just running in a browser. Even there, there's no inherent need for them to be unusable, even over relatively slow connections. A lot of it comes down to latency, and the number of requests going back and forth between client and server, often caused by the sheer quantity of assets many sites load (I'm looking at YOU, almost every media site on the Internet).
I seem to spend my life citing this paper, from 1996, but "It's the latency, stupid" is still relevant today: http://www.stuartcheshire.org/rants/latency.html.
From
How much disposable income will they have though? Most web products like those you describe are produced by businesses looking to make money.
Tax on cars is upward of 200% and traffic is becoming a major issue. When it comes to services, another major challenge is that there are no widely accepted payment mechanisms besides cash and checks. Debit cards only work with ATMs and some very select retailers.
It's worth it to memorize or bookmark the address, in case you ever need it:
http://mail.google.com/mail/h/
(on mobile browsers you need to "request desktop version" and then paste the address again, before you can see it)
My problem with accessing the low-bandwidth Google tools with archaic browsers (http://dplus-browser.sourceforge.net/, etc.) is that Google still requires the high-bandwith login.
Are you aware of any alternative login URLs or authentication mechanisms?
Every time a similar question is posed on HN, someone says "If the assets aren't needed, don't serve them in the first place", but this is i) unrealistic, and ii) ignores the fact that while the typical HN user may like sparsely designed, text-orientated pages with few images, this is not at all true of users in different demographics. And in those demos, it's often not acceptable to degrade the experience of users on fast connections to accommodate users on slow connections.
So -- if I write a web page, and I want to include a large asset, but I want to indicate to user agents on slow/capped connections that they don't _need_ to download it, what approach should I take?
I think the best solution would be an optional http header. That way, the server could choose to send a different initial response to low-bandwidth users. If connection speed is solely available via JavaScript API or media query, then only subsequent assets can be adapted for users on slow connections.
I bet people w/ slow connections are much more likely to disable javascript, though.
let loadTime = window.performance.timing.domContentLoadedEventEnd- window.performance.timing.navigationStart;
if (loadTime > someArbitraryNumber) {
// Disable loading heavy things
}
Do the opposite, start loading heavy things if the page loaded quickly.
A clean way would be to set one of two classes, connection-slow or connection-fast, on the body element. Then you could use those classes in CSS to choose the correct assets for background images, fonts and so on.
So, yeah totally agree with you. Should have been clearer.
...and not loaded from cache. You need a way to determine this reliably. AFAIK there's no way to determine this for the main page itself.
Like another reply to your comment, I thought about having a very small js script in the header puting `Date.now()` in a global, then on page load, having another script checking the amount of time that had passed to see if it was worth downloading the "extra" at all. But then again where do you put the threshold? Has anyone tried this with some degree of success?
This would also handle the situation where the available bandwidth isn't indicative of whether the user wants the high-bandwidth experience. For example, if you're on a non-unlimited mobile plan, it doesn't take that long to load a 10mb image over 4G, but those 10mb chunks add up to overage charges pretty quickly, so the user may want to set his browser to report a lower bandwidth amount.
I don't know why this seems like such an imposition, but I think I'd be uncomfortable with my browser exposing information about my actual network if it didn't have to. I have a feeling way more people would be using this to track me than to considerately send me less data.
That said, browser buy-in could be a huge help, if only to add a low-tech button saying, "request the low-fi version of everything if available." This would help mobile users too -- even if you have lots of bandwidth, maybe you want to conserve.
It's just another signal, but there's already a few tens of them, so adding one more is not going to make a significant difference.
That should solve most problems without giving away too much information. But an extra button would probably just confuse people.
I think the arguments against are pretty much the same.
Because I got frustrated at fat websites downloading megabytes of useless things, I decided to start an informational site about this very thing:
It's not ready yet, but I'm adding links to smaller alternatives to popular frameworks, links to articles about making various parts of a website (frontend and backend) faster, and will possibly add articles by people (and me) directly on the site. If anyone has any suggestions, please open an issue or MR (the site is open source):
Gitlab link is 500-ing, unfortunately.
I'll look into it, thank you!
EDIT: Netlify would be setting everything properly if I hadn't turned that off... Luckily they have great support!
I would suggest swapping the current structural aesthetic of "come in and look around" for the somewhat more widespread approach of having one or more calls to action and making the homepage fully sketch out the points you want to make.
FWIW, I say this out of pragmaticness. I don't mind the "welcome! browse!" approach myself, but it won't appeal to the demographic you're trying to reach: people who themselves are being paid to eat/sleep/dream modern web design.
Another thing I would recommend is using every single trick in the book to make the site fast. For example you could get ServiceWorkers caching everything for future visits (with maybe AppCache on top just because) and use the HTML5 history API so you can preload all the site text (say, in an XHR that fires after page load) and use that to make it feel like navigation is superhumanly fast.
TL;DR, use this as your playground to learn how to make sites load better. Voila, the site will be stupidly fast, and it will self-describe too, which is kind of cool. And you'll wind up with a bunch of knowledge you could use for consulting... and then you could use the site as the home base for that, which would be even cooler.
(I realize you just started this project, and that the above suggestions are in the "Rome wasn't built in a day" category)
As for the "come browse" approach, you're definitely right, and I don't intend the finished site to look like this, but I'm also not sure how to structure the content. What do I send the user to first? Maybe I'll write a tutorial hitting all the bullet points with links, though (eg add caching to static media, bundle them, don't use heavy libraries, load js async if you can, etc etc).
Thank you very much for your feedback!
Thanks for the note that AppCache is now out of the picture. I actually think I remember reading something vaguely about it being not the greatest, but I didn't know it was actively harmful. Do you mean in a security sense or it just being bad for performance?
I wasn't sure what to say about the content structure thing at first, but then I thought: take the pragmatic approach. Gather piles and piles and piles of actual content and dump it either on the site itself or your dev version. Notions about structure, presentation and content will likely occur in the process of accumulating (or writing) what's on the site.
As for what kind of content to put up, I would suggest focusing heavily on links to (and/or articles about) pragmatic, well-argued/well-reasoned arguments for lightening page load, and the various kinds of real-world metrics that are achieved when people make the investment to do that.
An obvious example: it's one thing to say "I recommend http://vanilla-js.com!", it's quite another to say "YouTube lightened their homepage weight from 1.5MB to 98KB and made it possible for brand new demographics in 3rd-world countries to experience video playback (http://blog.chriszacharias.com/page-weight-matters). Also, the reason the site feels so fast now when you click from one video to the next is that the platform only pulls in the new video URL, comments and description - the page itself never reloads."
Regarding where to start, I was thinking that a mashup/ripoff of halfway between https://developers.google.com/web/fundamentals/ and MDN might be an interesting target to aim for. I'm definitely not saying to [re-]do that much work (although I wouldn't be protesting if someone did... some of those Fundamentals tutorials are horribly out of date now), I'm just saying, the way that info is presented could do with cleanup and you can always run rings around them in various ways (layout, design, navigational hierarchy) because of bureaucracy blah blah... but you could do worse than aiming for something that feels like those sites do. Except you'd be focusing on making everything as lightweight as possible, and you would of course make the site your own as time went by. Maybe what I'm trying to get at here is that nobody's done a full-stack (as in, "bigger picture") top-to-bottom "here's how to do everything lightweight, and here are a bunch of real resources" sort of site yet, and I'm suggesting the lightweight-focused version of Google Web Fundamentals... :/
On a related note, I've come across a few websites that are nothing more than a bunch of links and a tiny bit of text describing some technical/development issue or whatever. They almost feel like spam sites, except they talk about legitimate issues and are clearly written by a person.
I'm sure these people mean well, but the low-text high-link format (or the "I'm going to rewrite what's in this link in my own words" approach) doesn't work for blog sites (possibly because of WordPress's 10000-clicks-to-get-a-high-level-overview browsing model...tsk) and similar - I'm trawling for actual text when I'm on a site like that, if you give me a link I'm not even on your website anymore.
You've probably seen sites like that too. (Note that I'm slightly griping here, I don't see your site as similar at all. I think I got a bit off track, I was trying to demonstrate the exact opposite of the direction I would suggest you go in. :P)
Also, I just thought of https://www.webpagetest.org and https://jsperf.com. Arguably microoptimization-focused, but I thought I'd mention them anyway.
It is bad for performance. I was going to link you to the article, but I figured I'll add it to the site :) http://www.lightentheweb.com/resources/
> Regarding where to start...
Ah, good idea, thank you. Yes, I'm not really in a position to rewrite content that exists (it would take too much time), but I would like to at least index it sensibly.
> nobody's done a full-stack (as in, "bigger picture") top-to-bottom "here's how to do everything lightweight
That's exactly what I'm aiming for, with clear steps and possibly a checklist (good idea!) on what to do.
> I've come across a few websites that are nothing more than a bunch of links
I think that's hard to avoid when making an informational site, but the links could possibly be embedded into article-style copy, making it not look as spammy. I'll keep that in mind, thank you.
> I was trying to demonstrate the exact opposite of the direction I would suggest you go in
Haha, yes, I know what you mean, and the links will be the "read more" material. I'd like to add some original content and non-time-sensitive guides to the fundamentals.
> Arguably microoptimization-focused, but I thought I'd mention them anyway.
Those are great, thank you!
Then you can lazy load your assets depending on that condition.
> Every time a similar question is posed on HN, someone says "If the assets aren't needed, don't serve them in the first place", but this is i) unrealistic, and ii) ignores the fact that while the typical HN user may like sparsely designed, text-orientated pages with few images, this is not at all true of users in different demographics.
https://wicg.github.io/netinfo/
And like most such APIs, it has been kicked around for a long time and it has only been adopted by Chromium on Android, ChromeOS and iOS. It'd be great if it were more widely adopted...
Also, "on a shit home DSL connection" doesn't really distinguish me from millions of other UK residents.
That said, I always get "unique" on those fingerprinting tests. You can't be "extra unique," so I guess I don't mind it.
On client side, You can achieve some of this by heavy use of media queries. https://msdn.microsoft.com/en-us/library/windows/apps/hh4535... You can basically manipulate resolution/disable of assets based on screens quality. This is under assumption that someone with retina screen will have decent internet.
Unfortunately there is little consistency in how well browsers accommodate JS-less browsing. Firefox removed the ability to switch off JS from its standard settings panel. Brave lets you switch JS on/off for each domain from the prominent lionface button panel.
This is prejudice. People use Craigslist, for example. If the thing is useful, people will use it. If there's a product being sold, and if it's useful to the potential clientele, they'll buy it. Without regard to the UI.
In the past ten years while my connection speed increased, the speed at which I can browse decreased. As my bandwidth increased, all the major websites madly inflated.
> So -- if I write a web page, and I want to include a large asset, but I want to indicate to user agents on slow/capped connections that they don't _need_ to download it, what approach should I take?
Put a link to it with (optionally) a thumbnail.
Craigslist achieved critical mass in the 90s, so it's not a good example. Many useful products disappear because they can't attract enough users to become sustainable. A nice UI can affect users' credibility judgments and increase the chance that they'll stick around or buy things.
It isn't perfect - you'll get some mobile devices on wifi that could have consumed the hero images and some desktop devices still on dial up, but it's still a lot better than doing nothing.
If you make a page well it should render quickly under any network condition, slow or fast. As an example, you could try serving pictures quickly by providing a placeholder picture which uses lossy compression to be as small as possible. It could be byte64 encoded so it's served immediately even over a slow connection. Then after the page is rendered, a request could go out to download the 0.5Mb image and a CSS transition could fade the image in over the placeholder. People on fast connections wouldn't notice a change because it would load right away, while people on a 40kbit 2G connection would be OK with your page too.
The requests to download larger content will still go out over a slow connection but the user won't suffer having to sit through seconds of rendering. Maybe similar to how people have done mobile-first responsive design, people could try doing slow-first design. Get everything out of the critical rendering path and progressively enhance the page later.
1. Serve the AMP version of your page (https://www.ampproject.org) which uses lazy loading and other optimizations
2. Use the Network Information API (https://developer.mozilla.org/en-US/docs/Web/API/NetworkInfo...) to load heavy assets only on high bandwidth connections.
If it crashes the device, you're way off.
If it's appreciably slow or clunky, find ways to improve it.
Iterate until it's fast and usable.
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.
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 base my work on existing technologies (lately Laravel, which means Symfony, Gulp, and hundreds of other great libraries) but I always strive to:
1. Reduce the number of requests per page, ideally down to 1 combined and compressed CSS, 1 JS that contains all dependencies, 1 custom font with all the icons. Everything except HTML and AJAX should be cacheable forever and use versioned file naming.
2. Make the JS as optional as possible. I will go out of my way to make interface elements work with CSS only (including the button to slide the mobile menu, various kinds of tooltips, form widget styling, and so on.) Whenever something needs JS to work (such as picture cropping or JS popups) I'll make sure the website is usable and pretty, maybe with reduced functionality or a higher number of page loads, even if the JS fails to load or is turned off. Also, the single JS file should be loaded at the end of the body.
2b. As a corollary, the website should be usable and look good both when JS is turned off, and when it's turned on but still being loaded. This can be achieved with careful use of inline styles, short inline scripts, noscript tags, and so on.
3. Make the CSS dependency somewhat optional too. As a basic rule, the site should work in w3m, as pointed out above. Sections of HTML that make sense only when positioned by CSS should be placed at the end of the body.
I consider all of this common sense, but unfortunately not all devs seem to have the knowledge, skill, and/or time allowance to care for these things, because admittedly they only matter for < 1% of most website's viewers.
I'm going to slightly disagree with 1, though. It's somewhat important now, but should become less so as http2 gets more widely used.
I get that the web was designed to be optimized for HTML/CSS first, JS last. However, the web was also not originally designed to support web applications as complex as the marketplace currently supports. As the web matures as the only universal application platform (to compete with various native platforms), I think a paradigm shift is required -- towards replacing as much markup with programmatic code as possible. Such a paradigm shift is required for complex web applications to compete with native environments going forward.
Of course, none of this applies if your organization just requires static websites. Choose the right tool for the job, and all that.
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:
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.
Now the thing just loads and loads and loads and loads. And all I want to do is either view my statement/transactions or pay my bill! Or sometimes update my address or use rewards points. That's not complicated stuff. I open it up in a background tab and do other stuff in-between clicks to avoid excessively staring at a loading screen.
I just tried it out, going to chase.com with an empty cache took a full 16 seconds to load on my work computer and issued 96 requests to load 11MB. Why!?
I then login. The next page (account overview) takes a full 32 seconds to load. Yep, half a minute to see my recent transactions and account balances. And I have two credit cards with zero recent transactions.
I am just baffled as to who signed off on it!! "This takes 30 seconds to load on a high speed connection, looks good, ship it."
It's particularly terrible if you are ever trying to use award points. The site is painfully slow, even on the fastest of 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?"
> 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?
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.
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.
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.
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.
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.
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.
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.
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.
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.
It takes about 10 seconds before it loads to a usable state on a T1 connection.
If I pop open an inspector, requests go on for about 30 seconds before they die down. It's about 8MB.
Builtwith.com shows 48 advertising libraries being used on the site.
The newspaper has a staff of less than 50, who even has time to look through and use all that advertising data?
The site is unusable.
http://imgur.com/a/qt0Zd (59.9MB)
I don't think JavaScript is really to blame for this though, the problem here is they're dumping a whole bunch of full sized images when they could have used thumbnails.
I'm currently building a web-based application to store JVM threaddumps. This includes a JS-based frontend to efficiently sort and filter sets of JVM threads (for example based on thread names, or classes included in thread traces). Or the ability to visualize locking structures with d3, so you can see that a specific class is a bottle neck because it has many locks and many threads are waiting for it.
I'm doing that in a Ruby/Vue application because those choices make the app easy. You can upload a threaddump via curl, and share it with everyone via links. You can share sorted and filtered thread sets, you can share visualizations with a mostly readable link. This is good because it's easy to - automatically - collect and upload thread ddumps, and it's easy to collaborate with a problematic locking situation.
So, I'd call that a fairly heavy web-based application. I'm relying on JS, because JS makes my user experience better. JS can fetch a threaddump, cache it in the browser, and execute filters based on the cached data pretty much as fast as a native application would. Except you can share and link it easily, so it's better than visualvm or TDA.
But with all that heavywheight, fast moving web bollocks... Isn't it natural to think about web latency? To me it's the only sensible thing to webpack/gulp-concat/whatever my entire app so all that heavy JS is one big GET. It's the only sensible thing to fetch all information about a threaddump in on GET just to cache it and have it available. It's the only right thing to do or else network latency eats you alive.
Am I that estranged by now by having worked on one low-latency, high-throughput application by now? To avoid confusion, the threaddump storage is neither low-latency, nor high-throughput. Talking java with 100k+ events/s and < 1ms in-server latency there.
My apartment does not have a landline, not to mention any other form of wired communication, so my internet connection is relegated to a Wi-Fi router that's separated by two walls(friendly neighbour) and a GSM modem that, after using the paltry 14GB of transfer it provides, falls back to a 32kbps connection.
Things that work in these circumstances:
- Mobile Facebook(Can't say I'm not surprised here).
- Google Hangouts.
- HN (obviously).
- A few other videoconferencing solutions(naturally in audio only mode).
Things that don't work, or barely work:
- Gmail.
- Slack(ok, this one sort of works, but is not consistent).
- Most Android apps.
- Github.
EDIT: added newlines.
Use the IRC bridge. It's a lot easier on your bandwidth/resources.
https://mail.google.com/mail/h/
I've used this on my kindle keyboard while traveling but the free data speed might still have been faster than 32kbps.
txt://example.com
that shows web content in plain text, no images, no javascript, nothing, something like readability but directly without loading the whole page first?
It would also be good for mobile connections.
* Wikipedia should be the first site to offer that txt: protocol, Google second.
* Btw, hacker news is the perfect example of a text only site.
So I know the pain and decided I wouldn't do the same to my users as a web developer. I created these projects from that:
- Picnic CSS: http://picnicss.com/
- Umbrella JS (right now website in maintenance): http://github.com/franciscop/umbrella
Also I wrote an article on the topic:
- https://medium.com/@fpresencia/understanding-gzip-size-836c7...
Finally, I also have the domain http://100kb.org/ and intended to do something about it, but then I moved out of the country and after returning things got much better and now I have decent internet so I lost interest. If you want to do anything with that domain like a small website competition just drop me a line and I'll give you access.
But yes, developers (including) me not accounting for slow connections is a pet peeve of mine. As I often do it myself, I do understand the issue; it is client constraints, time/money constraints and audience. But it does annoy me when often used sites (notably airline sites and banking sites) are top heavy and their apps time out because yes I do have a bad connection often.
I was with Hacker Paradise for 3 months through SE Asia and I totally agree. I have screenshots yet-to-tweet comparing the great packages from Thailand with the prices in Spain and it's absolutely ridiculous.
I've seen this figure a few times before, and I wonder every time who these users are. Specifically I'm curious what the breakdown is between people who
- Really don't have a better option available (infrastructure in this country is unbelievably bad in some places, so I wouldn't be surprised at a large size for this group)
- Are perfectly happy with the dialup experience so they don't switch to something better
- Don't know there are better options so they stay with dialup
- Don't even realize they never cancelled AOL and are still having it auto-debited every month
- Some other option I didn't think of
Yes.
My kernel, userland, third party software and configuration choices, the entire way in which I use the computer, are optimized for consuming plain text.@1
As a consequence, the web is very fast for me compared to a user with a graphical browser. This is why every time some ad-supported company claims they are offering a means to "make the web faster" it makes them appear to me as even more dishonest. They are, at least indirectly, the ones who are responsible for slowing it down. They are promising to fix a problem they created, but will never really deliver on that promise. Conflict of interest.
@1 I find there is no better way to optimize for fast, plain text web consumption than to work with a slow connection. It is like when a batsman warms up with weights on the bat. When he takes the weights off, the bat feels weightness, and the velocity increases. When I spend a year or so on a slow connection and adjust everything I do to be as bandwidth efficient as possible, then when I get on a "fast" connection, the speed is incredible.
I also use the same technique with hardware, working with a small, resource constrained computer. When I switch to a larger, more powerful one, such as a laptop, the experience is that I instantly have an enormous quantity of extra memory and screen space, for free. I do not need a HDD/SSD to work. My entire system and storage fits easily in memory.
Now if I do the opposite, if everyday I only worked on a large, powerful computer with GB's of RAM with a fast connection, then switching to anything less is going to be an adjustment that will require some time. I would spend significant time making necessary adjustments before I could get anything else done.
Wasn't it that Google was claiming that by using AMP, you can actually make web pages load faster as it is a stripped-down form of HTML[1].
From what I am hearing from the author (Dan), bare html with minimal JS and CSS should (in theory/reality?) load pages faster.
https://moz.com/blog/accelerated-mobile-pages-whiteboard-fri...
I mean, I'm all for avoiding premature optimizations, but 23MB for one page is just... wow.
EDIT: As a sanity check, I just tried loading the CH home page from a cold cache myself. Total weight: 31.26MB. Yowch.
Looks like there's some lazy loading of later content so I actually get accessible content very quickly, indeed I thought something was up as the page appeared to be only a couple-hundred kB, which didn't match your description.
Scrolling down I continue (in FF Network Monitor) to see content loading - reviewing I see that YouTube is responsible for over 1MB of "base.js" which gets downloaded 7 times, and ¼MB of CSS files (again 7 times over). Now Atwood may be to blame in part but Google ... shouldn't they at least do better?? CodingHorror is loading very large image files [1] (which get scaled) for me, perhaps a "retina" handling issue.
[1] https://gtmetrix.com/reports/blog.codinghorror.com/d1x7zZBk
[0] https://blog.codinghorror.com/content/images/2017/01/help-ke...
[1] https://blog.codinghorror.com/content/images/2016/11/pro-pin...
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.
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.
slow clap
His data on steve-yegge.blogspot.com is particularly unfortunate: Steve's (excellent) posts are almost completely pure text, and there's no reason for them to fail to download or display, except that Google demands that one execute JavaScript in order to get a readable page.
> if you’re browsing from Mauritania, Madagascar, or Vanuatu, loading codinghorror once will cost you more than 10% of the daily per capita GNI.
Maybe the social-justice angle can convince some people to shed their megabytes of JavaScript and embrace clean, simple, static pages? There's probably some kid in rural Ethiopia who might have been inspired to create great things, if only he'd been able to read Steve Yegge's blog.
> The “ludicrously fast” guide fails to display properly on dialup or slow mobile connections because the images time out.
slow clap
> Since its publication, the “ludicrously fast” guide was updated with some javascript that only loads images if you scroll down far enough.
Incidentally, is there any way we can enforce the death penalty against people who load images with JavaScript? HTML already has a way to load images in a page: it's the <img> element. I shouldn't be required to hand code execution privileges over to any random site on the Internet in order to view text or images.
Ever since the days of running Java applications on my old Sony Ericsson phone, Opera Mini has been my favorite. As far as the browser is concerned, the website can be as heavy as it wishes -- it will pass through Operas proxy and be compressed according to user preferences. This could include not loading any images (nothing new), or load all images with very low quality. You can also select whether you want things like external fonts and JS to load, or if you want to block that too. When I moved to a new country my first SIM card had one of those "unlimited but incredibly slow" plans. Opera Mini was a life saver.
I guess my point is that we shouldn't get stuck in optimization paralysis if there is no sound and standardized server-side way to solve this issue (and there doesn't seem to be). It would be nice if browsers had a way to tell web servers that they're operating under low bandwidth, like the do-not-track flag, but AFAIK this does not exist.
Until that exists, and I don't mean to suggest we go back to the days of "Made for IE9" here, maybe some responsibility needs to be shifted to the client side. As long as you design your websites in a sane way, they will pass through these low bandwidth proxies with flying colors. Maybe you don't need to spend hundreds or thousands of man-hours optimizing your page when you could insert a discrete indicator at the top of the screen for anyone taking longer than X seconds to load that there are many browsers available for low bandwidth connections, and that they might want to try them out?
By the way, here's how we can collectively make the web faster, safer and more fun to use: [1]
My current pet hate is news sites that float up a modal window asking me to turn off my ad blocker because bidness. OK, I turn off AdBlock Pro for that domain, turn off HTTP switchboard, and it still won't load. Why? I dunno, try again, still won't load. OK, guess I'm never coming back. Obviously it must be some other extension, but without any technical details how can I tell?
For that matter why did anyone think it was ever a good idea to float dialogs over web pages to get people to share (not submit) their email address? Has anyone ever looked at how poorly these display on mobile devices? Or how making it hard to close floating dialogs is a really good way to annoy people?
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?
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
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.
It seems to me there's a business strategy, where rather than pushing for more ads, a website pushes for lighter weight and promises its few advertisers a wider audience.
Currently, FM radio stations are so typically clogged with commercials that I just switch back and forth whenever the music stops. The sole exception in my area is KZTQ "Bob FM", which has a neat policy: 60 minutes (ish) of nonstop music (aside from their normal station ID stuff), followed by at most two or three commercials, then repeat. I've found that the commercial breaks are short enough that I'm more willing to actually listen to them, since I know that the music will be back in less than a minute or so.
I reckon that has a significant value-add in terms of ad impressions, and thus could offset the normally-decreased ad revenue by charging more per ad.
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...
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.
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.
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.
There shouldn't be a reason for a big page with many resources to not load - it should just be slower. Yet I can make the same observations as soon as my mobile signal drops to EDGE: the internet is essentially unusable as soon as there's packet loss involved and the roundtrip-times increase. Interestingly mosh often still works beautifully in such scenarios. So instead of focusing on HTTP2 or AMP (and other hacks) to make the net faster for the best-case scenario, I'd rather see improvements to make it work much more reliably in less than perfect conditions. Maybe it's time for TCP2 with sane(r) defaults for our current needs.
For example, there's SCTP. From what little I've read about it, it seems as if it has most of the benefits of both TCP and UDP, with the main downside that some firewalls and routers may need to be upgraded. Being an existing protocol, however, there are already working implementations and some amount of network support. Maybe it's even fully usable as-is today!
But there also need to be sctp over udp over dtls (or just sctp over dtls) happen as you can't use TLS with SCTP unordered mode or multihoming.
SCTP slowly gain traction in userspace besides being only in mobile operator networks (lte)
Oh, we find Amazon, IMDb and Facebook are the biggest pigs on a slow connection.
We generally don't target hardware from 98, why should we target bandwidth from 98? Current smartphones and computers are really powerful, and most applications are targeted towards those devices. Native apps don't have this insane requirement to support hardware from 2 decades ago.
The web is so much more than text in 2017. And before you whine about the ads and useless stuff, go read a tabloid and whine about the waste of paper, or try to watch tv and whine about the electricity and time you're wasting watching advertisements.
Media has and always will be like that.
The time spent on backwards compatibility and optimizations are usually not worth it anyway.
Do I think mostly text sites should be 5mb? Obviously not.
ehh, but is that really a good test for sites people "frequent" ?
What happens to the heatmap when we're talking about subsequent page loads!
So... had to severely redo the code to pull 50px wide images, blur them in, and only load the visible (depending on screen dimension) then a 2-second max refresh thingyyyy (yeah I'm just making this loader-interrupter thing) it's been a mess I feel pretty stupid sometimes. Why can't I get this... JavaScript. Yeap I am lucky to have Google Fiber (and I have the cheaper plan too)
However, the web is even worse if you have no connection at all. This is important because if we provide internet access at a municipal level, we can reach 100% adoption among our pluralistic educational system and progress to primary learning materials that are web based (CA 60119 for example prohibits any primary educational materials not available to all students both in the classroom AND AT HOME).
Build software that can work on a distributed architecgure. So people in Ethiopia can run their stuff on intranets and mesh networks and only occasionally send stuff around the world.
What broadband has really caused is this assumption that the computer is "always online". Apps often break when not online. When in reality there shouldn't even be "online/offline" but rather "server reachable/unreachable". And you should be building offline first apps, with sync across instances.
And nope - no cell phone signal here either..
As someone mentioned below too, the median value would make much more sense in this case (which it often does, it seems).
Generally the distribution of bandwidth is multimodal, similarly of latency.
One thing I wonder about is, it seems many dialup ISPs these days provide some kind of "accellerator", probably a web proxy that avoids some of the issues with timeouts, perhaps compresses some content etc. So it might be that many of the remaining dialup users don't experience quite as many problems as Dan found.
After everything has been parsed, it would know (the browser knows).
Couldn't a proxy service produce super lightweight, compiled web pages? I seem to remember Opera used to offer something along those lines, but I may be wrong.
Would there be commercial value in building such a tool?
I was reminded of the slow connection with T-Mobile 2 years ago while in the Philippines. They give you free data in 120 countries, but its throttled.
This was my main motivation for rewriting my side project using highly optimized css and not a large framework that uses web fonts and bloated libraries.
You basically need to disable JS altogether to have a chance to even view many websites. And some, well, just crash the browser regardless.
It's amazing how much the web evolved in the past few years...
There used to be a time where supporting 10+ year old browsers was matter of factly. No longer.
The idea is to make the content available to all the web users as the fast connection is not as common as we might think.
As affects web apps, some of this is a conscious choice by network designers. First, click on your profile on Hacker News and turn on Showdead. You can then read this thread and my comment in it:
https://news.ycombinator.com/item?id=13597673
While the poster wasn't a web engineer specifically (or didn't say it) so much of the web architecture isn't built for front-loading payloads. But instead, on eventually getting there, through the magic of TCP/IP and letting users wait for a few dozen seconds as pages load.
I disagree with it and think these engineers are wrong and make the wrong decisions (optimize for the wrong things) and that this makes everyone poorer-off.
Thanks for listening. (Happy to discuss any replies here.)
There's the root cause. Why do I need to download executables just to read static content?
Ssh into a shell account and use a text based browser :)
I mean, yes as small as possible. But are there some size-budgets?
For 3G, 2G etc.
Actually one could make a whole slowMo WebStandard from this. No Pictures, just svgs, no constant elaborate javascript chatter, no advertising. No videos, no music, no gifs, just animated svgs. Actually, that would be something lovely. Necessity begets ingenubeauty.
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).
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.
(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.