The web sucks if you have a slow connection(danluu.com)
danluu.com
The web sucks if you have a slow connection
https://danluu.com/web-bloat/
598 comments
>When I was at Google, someone told me a story about a time that “they” completed a big optimization push only to find that measured page load times increased. When they dug into the data, they found that the reason load times had increased was that they got a lot more traffic from Africa after doing the optimizations. The team’s product went from being unusable for people with slow connections to usable, which caused so many users with slow connections to start using the product that load times actually increased.
Something I have had at the back of my mind for a long time: in 2017, what's the correct way to present optional resources that will improve the experience of users on fast/uncapped connections, but that user agents on slow/capped connections can safely ignore? Like hi-res hero images, or video backgrounds, etc.
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?
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 found out this the hard way.
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.
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.
Sad thing is that most of the web sucks on rather fast connections too. Pages being almost 5mb of data, making multiple dozens of requests for librairies and ads. Ads updating in the background, consuming evermore data.
I don't notice it much on my PC, since I've got a FTTH connection, but on LTE and 3G, it's very noticeable. Enough that I avoid certain websites. And that's nowhere near slow by his standards.
I do agree that everyone would benefit from slimmer websites.
I don't notice it much on my PC, since I've got a FTTH connection, but on LTE and 3G, it's very noticeable. Enough that I avoid certain websites. And that's nowhere near slow by his standards.
I do agree that everyone would benefit from slimmer websites.
I design and write my company's framework, that other devs use to write websites and webapps.
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 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 travel fulltime and my primary internet is 4G LTE. But, even though I spend $250 per month on data, I still run out, and end up throttled to 128kbps for the last couple days of the data cycle. The internet is pretty much unusable at that rate. I can leave my email downloading in Thunderbird for a couple of hours and that's usable (gmail, however is not very usable), and I can read Hacker News (but not the articles linked, in most cases). Reddit kinda works at those speeds. But nearly everything else on the web is too slow to even bother with. When I hit that rate cap, I usually consider it a forced break and take a walk, cook something elaborate, and watch a movie (on DVD) or play a game.
So, yeah, the internet has gotten really fat. A lot of it seems gratuitous...but, I'm guilty of it, too. If I need graphs or something, I reach for whatever library does everything I need and drop it in. Likewise, I start with a framework like Bootstrap, and some JavaScript stuff, and by the time all is said and done, I'm pulling a couple MB down just to draw the page. Even as browsers bring more stuff into core (making things we used to need libs for unnecessary) folks keep pushing forward and we keep throwing more libraries at the problem. And, well, that's probably necessary growing pains.
Maybe someday the bandwidth will catch up with the apps. I do wish more people building the web tested at slower speeds, though. Could probably save users on mobile networks a lot of time, even if we accept that dial-up just can't meaningfully participate in the modern web.
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.
What really has baffled me lately is Chase's new website. They did a redesign around, maybe 6 months ago, to make it "more modern" or something, I guess.
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."
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."
> Why shouldn’t the web work with dialup or a dialup-like connection?
Because we have the capability to work beyond that capacity now in most cases. That's like asking "why shouldn't we allow horses on our highways?"
> Pretty much everything I consume online is plain text, even if it happens to be styled with images and fancy javascript.
No doubt, pretty much everyone who works on web apps for long enough understands that it's total madness. The cost however, in supporting people so far behind as to only be able to serve them text is quite frankly unmanageable. The web has grown dramatically over the past 20 years both in terms of physical scale and supported media types.
The web is becoming a platform delivery service for complex applications. Some people like to think of the web as just hyper text, and everything on it should be human parse-able. For me, as someone who has come late to the game, it has never seemed that way. The web is where I go to do things: work, learn, consume, watch, play. It's a tool that allows me to access the interfaces I use in my daily life. I think there's a ton of value in this, perhaps more than as a platform for simple reading news and blogs.
I look forward to WebAssembly and other advancements that allow us to treat the web as we once treated desktop environments, at the expense of human readability. It doesn't mean we need to abandon older + simpler protocols, because they too serve a purpose. But to stop technological advancement in order to appease the lowest common denominator seems silly to me.
Because we have the capability to work beyond that capacity now in most cases. That's like asking "why shouldn't we allow horses on our highways?"
> 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.
Something that sticks out looking at the table. How can some sites simply FAIL loading? I mean, there is something inherently wrong with our web today, where if my internet is very slow and _could_ load a page in 80 seconds if I just leave it like that, the server itself could have configured the timeout to be 60 seconds. So I can never load the page?!
The assumption is here that both points of the connection is based on earth. When we have these hard timeout limits, how will stuff even remotely work when we are a interplanetary species or even from orbit around earth?
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?
After spending a month in Mexico, including regions with spotty/inconsistent service from one minute to the next, I think the problem goes deeper.
Browsers are IMO terrible at mitigating intermittent and very slow connections. Nothing I browse seems to be effectively cached other than Hacker News. Browsers just give up when a connection disappears, rather than holding what they have and trying again in a little bit.
The only thing I used which kept working was DropBox. DropBox never gives up, it just keeps trying to sync and eventually it will succeed if there is any possibility of doing so.
I understand the assumptions of the web are different than an app like Dropbox, but I think it might be a good idea to reexamine those assumptions.
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.
Most of the web really sucks on fast internet connections too. Thanks to so many web developers thinking every dang thing needs to be a single page app using a heavy JavaScript framework. Add animation, badly optimized images and of course ads and it becomes really unbearable.
We keep repeating our same mistakes but just in a different way.
We keep repeating our same mistakes but just in a different way.
> The main table in this post is almost 50kB of HTML
Just for fun, I just took a screenshot of that table and made a PNG with indexed colors: 21243 bytes.
Just for fun, I just took a screenshot of that table and made a PNG with indexed colors: 21243 bytes.
Not related to the contents of the article, but please add a max-width styling to your paragraphs. 40em or so is good.
Joey Hess (joeyh) has been writing about this for a long time (because he uses dial-up at his home). Here is a recent thread about a 2016 blog post on this:
https://news.ycombinator.com/item?id=13397282
https://news.ycombinator.com/item?id=13397282
By far the worst site I regularly use, from a page loading perspective, is my local newspaper.
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.
http://www.telegraphherald.com/
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.
http://www.telegraphherald.com/
I might need a reality check here because this is feeling weird.
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.
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.
Kudos to the author for making the post readable using a 32kbps connection.
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.
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.
Can't browsers provide a service like
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.
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.
I totally agree. I used to have a really bad mobile connection up until a few years ago (Spain), and still when I use up all my mobile internet it reverses to 2G.
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.
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.
A unit of measure I find appropriate is the "Doom", 2015 prediction:
https://twitter.com/xbs/status/626781529054834688
https://twitter.com/xbs/status/626781529054834688
> In the U.S., AOL alone had over 2 million dialup users in 2015.
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
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
"Pretty much everything I consume online is plain text..."
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.
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.
"Google’s AMP currently has > 100kB of blocking JavaScript that has to load before the page loads"
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...
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...
Looking at that first table, one question jumps out at me: what the heck is Jeff Atwood doing on pages at Coding Horror that makes them weigh 23MB?
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.
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.
One thing that isn't mention is webfonts. On 2G I can load the whole page, CSS, JS and some images, but can't read anything because the fonts aren't loaded yet.
Here is a gallery of a couple of examples: https://imgur.com/gallery/wfjoT
My team has just started work on a new SaaS product. We are taking articles like this to heart and aiming to keep pages light and fast. We are using very little JavaScript.
Let's see if the market rewards us or punishes us for this approach...
Let's see if the market rewards us or punishes us for this approach...
Not just web, mobile apps also suck when you have slow connection. For example, you can't open Itunes when you're on GPRS. It's trying to connect to Apple Music and locks you in a screen with a big Apple logo. Same as Spotify. Just try your apps with GPRS :) I camp every weekend so noticed how much they suck long time ago
Did most of the web suck when we were on 28k or 56k modems? I'd argue that it didn't, and yet even with the light weight of pages back then, it was incredibly slower than today's pages (even heavy ones) load over our much-faster connections.
So really, I think what the author is observing is that having experienced high-speed reliable connections, it is very disappointing to move to a much slower connection. For the emerging tech markets, I can imagine the experience would not be great if the load was long enough to cause timeouts and connection failures, but at the same time, the 99% experience, as it probably was when the web was born, is "holy crap look at everything I have access to now!"
Yes, there are some really terribly optimized and redirect-happy sites out there and yes, you should do everything you can to make your page speedy. Everybody benefits when you do. I think, though, that this is more of a case of "let's be thankful for and aware of what we have," and "if you suddenly have a slower connection you might find yourself annoyed" more than "most sites suck on slow connections."
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."
> Pages are often designed so that they’re hard or impossible to read if some dependency fails to load. On a slow connection, it’s quite common for at least one depedency to fail. After refreshing the page twice, the page loaded as it was supposed to and I was able to read the blog post, a fairly compelling post on eliminating dependencies.
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.
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.
A lot of people here are talking about how 2G connections are "almost unusable" and how this should be optimized server-side and so on. I'd just like to point out that there are browser that cater to this specific demographic (slow connections).
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?
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?