15 ms·

Page Weight Matters (2012)

556 points by shubhamjain 11y ago

sirtastic 11y ago
WOW! Faster load times and lighter code makes for a better user experience? (mindblown)
- jp555 11y ago
  whoosh! You missed the whole point.
  - sirtastic 11y ago
    That you can't always look at a single metric as a basis for success? This is rudimentary analytics here. Is there a single person who believes making client side code heavy is the way to go? Do people really think user experience should take a back seat to cool stuff on a site like YouTube?
    - tedunangst 11y ago
      Try "what makes a site merely inconvenient for some can render it completely unusable for others, and so one should not overlook minor issues because they don't seem worth fixing."
      - sirtastic 11y ago
        Excuse me. I didn't realize this wasn't obvious.
    - jp555 11y ago
      The problem of unknown unknowns.
teach 11y ago
Comments from the last time this was posted: https://news.ycombinator.com/item?id=4957992 https://news.ycombinator.com/item?id=4957992
- tedunangst 11y ago
  Wow. The verge was the poster child for most bloated site even three years ago, long before the recent ruckus.
  - mattmanser 11y ago
    What was the recent ruckus?
    - tedunangst 11y ago
      http://blog.lmorchard.com/2015/07/22/the-verge-web-sucks/ http://blog.lmorchard.com/2015/07/22/the-verge-web-sucks/
gketuma 11y ago
As a web dev I always have this in mind but the challenge is convincing your client who wants a video background. Maybe we need a media query that detects internet speed.
- scrollaway 11y ago
  Even then, it's fairly easy to load the video asynchronously and as part of the last assets, make its intro blend in to a single-color background, voila, problem "solved". I find video backgrounds ridiculous most of the time (though they can be done really well), but that's not the real problem here - the real problem is including 200-800kb javascript code that does nothing but track your user, and often enough doesn't do it for you! (Hi Facebook!) The real problem is using massive js frameworks for the sake of adding dynamic functionality to your site that, often enough, isn't actually worth it. The real problem is that very often, these "features" are only as necessary as the marketing team says they are... the people who have the ability to ask "why?" and the ability to understand "why not" don't have the voice (or guts...) to do so.
  - pswilson14 11y ago
    "Massive" JS frameworks aren't the issue, not by themselves. AngularJS, for instance, is only 39.5kb. Bloat sneaks into web applications in other ways, but merely bringing in a framework isn't enough to add a noticeable load on a web page.
    - kuschku 11y ago
      I’ve seen sites loading Angular, React, jQuery(+jQuery UI) and some custom frameworks. Different parts of the site rendering in different frameworks.
- chrismbarr 11y ago
  I would love this. My company just updated their public-facing website and it has a 28MB 1080p video playing in the page header. The site was outsourced, but I work as a web developer for some of our products and was asked by the marketing team to give the new site a look over. The marketing team was surprised to learn how big the file was since the outsourced team "ensured" them that the new website would be lightweight. Oh well... Now the video has been reduced to a 16MB at 720p, which is still ludicrous to me, but they just really like having the video on the home page more than they want a truly lightweight page. And to be fair, the video does not load when viewed on a mobile device, so at least there's that.
jonahx 11y ago
This is a fascinating example of Simpson's Paradox: https://en.wikipedia.org/wiki/Simpson%27s_paradox https://en.wikipedia.org/wiki/Simpson%27s_paradox It also reminds me of the phenomenon, in customer service, whereby an increase in complaints can sometimes indicate success -- it means the product has gone from bad enough to be unnoticeable to good enough to be engaged with.
- jfoutz 11y ago
  In WW1, helmets were introduced to protect soldiers. Surprisingly the frequency of head wounds went way up. It took a little while to realize soldiers were "just" being wounded, rather than outright killed if they had no helmet.
  - BostonEnginerd 11y ago
    There's a similar story about putting armor on planes during WWII - http://www.johndcook.com/blog/2008/01/21/selection-bias-and-bombers/ http://www.johndcook.com/blog/2008/01/21/selection-bias-and-...
dpweb 11y ago
If you have an engineering mind and care about such things - you care about complexity. Even if you don't - user experience matters to everyone. Have you ever seen something completely insane and everyone around doesn't seem to recognize how awful it really is. That is the web of today. 60-80 requests? 1MB+ single pages? Your functionality, I don't care if its Facebook - does not need that much. It is not necessary. When broadband came on the scene, everyone started to ignore it, just like GBs of memory made people forget about conservation. The fact that there isn't a daily drumbeat about how bloated, how needlessly complex, how ridicuous most of the world's web appliactions of today really are - baffles me.
- jkaptur 11y ago
  Honestly, I think "a daily drumbeat about how bloated, how needlessly complex, how ridiculous most of the world's web applications really are" pretty much describes every HN conversation on any article with even a remote connection to web technologies.
  - draw_down 11y ago
    Jeez, you aren't kidding. It's as though, if we bitch enough about the technical deficiencies, the economic and social circumstances that cause them will, I dunno, vanish into thin air I guess. This topic is pretty much just red meat here
    - Kluny 11y ago
      Well, bitching isn't that great. But as a web developer myself, it has affected the way I work. Like, there was an article just the other day about how to achieve "lightning fast page loads". I shared it around the office and as a result, 4 people have added new steps to their workflow to help reduce page load latency on our client sites. The author knew the article would get good reception here, because of how much people complain about page latency, and I knew that page latency is a thing that's important to more people than just me, for the same reason. (My clients mostly don't seem to care, for some reason, but I bet their customers do). So yeah, having these public conversations can make a difference. We just have to stay positive and constructive.
nicolethenerd 11y ago
Nice to see this again - I've told this story to many of my web dev students. :-)
mbrock 11y ago
Everyone's sometimes on spotty WiFi or foreign expensive 3G. I'm more inclined to trust fast-loading sites and apps. I wonder what would happen if for example iOS decided to visually indicate page weight, kind of like how you can see which apps use the most energy.
- peterjmag 11y ago
  I think that's a great idea. Make it more visible, and then you get normal people to care about it and put pressure on content owners, developers, etc. Like Google did with their "mobile-friendly" tag; I could yell at my managers all day about how we need to improve our site's mobile experience to no avail, but Google steps in and threatens lower rankings and suddenly it becomes top priority. Perhaps the simplest solution is for Google to start penalizing heavy pages, but as far as I know, page weight isn't part of their mobile-friendly criteria.
bsimpson 11y ago
Thought certainly an interesting anecdote, I don't understand how a video streaming site like YouTube would be useful in a market where a 100K download takes 2+ minutes. You'd have to open a page, walk away for an hour, and hope everything was OK when you got back.
- tedunangst 11y ago
  I only ever watch youtube videos via youtube-dl, but I still use a browser to navigate the site to find videos to download.
- deleted 11y ago
  [deleted]
- IkmoIkmo 11y ago
  Well think about it. Imagine you had no alternative to getting any video on the internet? After all, if not youtube, anything else was probably slower at the time. Obviously you wouldn't simply lose the desire to watch relevant videos, it'd be dimmed quite significantly sure but you'd still want to watch a video every now and then. Whether it's a music video, or a chess match or a farming lecture, there's just a ridiculous amount of content available. I have plenty of videos I'd want to watch even if I'd have to wait hours. (take torrenting for example, or pre-youtube & pre-streaming file sharing, video and music on p2p networks were incredibly slow yet incredibly popular). But if you couldn't even load the pages to browse through the videos, that'd pretty significantly reduce your watching even further. Liken it perhaps to a library where you could only get 1 book per week. Well that's not much, but at least you can get 1 book. But if you go to the library you have to wait in line for an hour, and after examining one book section of 10 books, you have to wait 5 minutes to examine the next one. Choosing the weekly book would become such a chore you'd probably not even bother to go anymore. But if you'd suddenly be able to examine the entire library with only 1 minute of total waiting, many more would be much more inclined to do so, even if they could still only borrow 1 book per week. Beyond that in my experience, lots of requests in a slow connection often fails before completing fully. I don't know why exactly, I've never been a network engineer. While streaming in a slow connection eventually gets there. So it's entirely possible that even browsing normal pages was failing entirely before for some people, even though (if they ever did load the page and choose a video), the video download worked fine albeit at a very slow pace.
SandB0x 11y ago
It is insane. One of my favourites is the "about.me" site, which is meant to be a simple online business card. Picking a random page from https://about.me/people/featured https://about.me/people/featured, you get a page weighing over 3MB! http://tools.pingdom.com/fpt/#!/F4VDN/https://about.me/pentatonicfunk http://tools.pingdom.com/fpt/#!/F4VDN/https://about.me/penta...
motoboi 11y ago
Coming from a low bandwidth, high latency part of the world, I can't confirm this enough. Today, I have 2 mbit and can use Netflix or Youtube just fine, but mere 4 years ago, I had 600k and, boy, that was hard. Hard as in loading youtube URL and go for a coffee. UPDATE: In case Duolingo developers are listening, please test your site on high latency and very low bandwidth scenarios. I just love your site, but lessons behave too strangely when internet is bad here.
- malka 11y ago
  > Hard as in loading youtube URL and go for a coffee. You can't even to that now. Youtube videos buffer about 1m30 of videos and stops after that :(
  - voltagex_ 11y ago
    I understand that Google is doing this to save an immense amount of wasted bandwidth. These days if I need to wait for something to load, I use youtube-dl.
  - motoboi 11y ago
    At the time, I wrote an Chrome extension that would select the lowest resolution (240p at the time), but I can't remember if it was capable of autoplay.
- robin_reala 11y ago
  My train commute into work is the perfect place to brush up with Duolingo. Shame it randomly goes through patches of no signal, as this makes Duolingo fairly unusable. I have to time my practice to fit into the areas I know it’ll work in.
- jlangenauer 11y ago
  If you're looking for an alternative to Duolingo, give Memrise a try. It allows you to download entire lessons for offline use.
beatpanda 11y ago
I went to work for a company that makes a travel product used by people in almost every country in the world, after trying to use it in southeastern Europe. I told them their page weight was killing the experience, and wanted to join the front end team to fix it. After 6 months of banging my head against a wall, I realized the reason we weren't fixing page weight was because our product managers didn't care about the experience of users in poorer countries, because they didn't have any money to spend anyway. Even though we had lots of users in those countries, and even though we made a big show of how you could use this app to travel anywhere in the world. If there's a lesson there, its that as long as cold economic calculations drive product decisions, this stuff isn't going to get any better.
drikerf 11y ago
Great point and very important in times when bundling howmany? js dependencies for client apps.
Splines 11y ago
If you're on Windows you can use the Network Emulator for Windows Toolkit (NEWT): http://blogs.technet.com/b/juanand/archive/2010/03/05/standalone-network-emulator-tool.aspx http://blogs.technet.com/b/juanand/archive/2010/03/05/standa... I've used it to emulate what it's like on a high-latency or high-loss network. Relatively easy tool to use.
- latortuga 11y ago
  Chrome also has this feature if you switch to device mode (Ctrl+Shift+M).
misterbwong 11y ago
Isn't this phenomenon getting worse now that responsive design is in vogue? We've collectively decided to shoehorn a website designed for the connectivity and speed of a desktop browser into a lower powered device with slower/spotty connectivity. Genuinely curious: Why is this better than a mobile-friendly site designed specifically with the constraints of a mobile device in mind?
- jonahx 11y ago
  Simple answer: Writing a responsive site is much faster and easier to maintain than creating two versions of the same site. And it wouldn't it be just two, you also have to support tablets, various desktop sizes, and various mobile sizes. Custom versions for each one isn't feasible. Also, if you care about page and weight and optimization, your site will be light everywhere, and the criticism of shoehorning a big bloated desktop site into a phone won't apply. This is not that difficult to achieve.
foxbarrington 11y ago
If it takes two minutes to load a 100kb page, does it take twenty minutes to watch a 1MB video? Over three hours to watch a 10MB video?
- gwern 11y ago
  Probably not. Downloading the video is going to depend more on throughput than on latency. The initial connection & page load, as it hits all the domains and resources, is going to be much slower because it relies more on latency and roundtrips.
  - Brakenshire 11y ago
    The article says that the page would have taken 20 minutes to load under previous circumstances.
lnanek2 11y ago
Pretty funny story considering YouTube is back to unusable on slow connections. They used to buffer the full video, so you could load up a page, let it sit until the video buffers, then watch it eventually, maybe after reading your social news sites. Nowadays the buffering feature has been removed and you'll just come back, hit play, get a second or two of video, then it has nothing again for a long time. Feels bad for the engineer who spent all that time reducing the size and finding out it made YouTube much more usable across the globe. Amusingly, disabling buffering was probably some penny wise pound foolish way to save bandwidth.
- flippant 11y ago
  It's for the average user with a decent connection that skips parts of a video. This is tedious, but if you want to buffer a YouTube video try youtube-dl[0] or using VLC. [0]https://rg3.github.io/youtube-dl/ https://rg3.github.io/youtube-dl/
- jimworm 11y ago
  You can disable mediasource extensions in your browser to get the old download-it-all html5 video.
chadwittman 11y ago
Fantastic
- imperialdrive 11y ago
  Ditto - Loved reading this. I work on similar projects but it's a tough battle to win against marketing these days.
nostrademons 11y ago
When I joined Google in 2009, we were on the tail-end of a latency optimization kick that Larry had started in 2007. At the time, we had a budget of 20K gzipped for the entire search results page. I remember working on the visual redesign of 2010, where we had increased the page weight from 16K to 19K and there was much handwringing at the higher levels about how we were going to blow our entire latency budget on one change. We did some crazy stuff to squeeze everything in. We would literally count bytes on every change - one engineer wrote a tool that would run against your changelist demo server and output the difference in gzipped size of it. We used 'for(var i=0,e;e=arr[i++];) { ... }' as our default foreach loop because it was one character shorter than explicitly incrementing the loop counter. All HTML tags that could be left unterminated were, and all attributes that could be unquoted were. CSS classnames were manually named with 1-3 character abbreviations, with a dictionary elsewhere, to save on bytesize. I ran an experiment to see if we could use JQuery on the SRP (everything was done in raw vanilla JS), and the results were that it doubled the byte size and latency of the SRP, so that was a complete non-starter. At one point I had to do a CSS transition on an element that didn't exist in the HTML, because it was too heavy and so we had to pull it over via AJAX, so I had to do all sorts of crazy contortions to predict the height and position of revealed elements before the code for them actually existed on the client. A lot of these convolutions should've been done by compiler, and indeed, a lot were moved to one when we got an HTML-aware templating language. But it gave me a real appreciation for how to write tight, efficient code under constraints - real engineering, not just slapping libraries together. Alas, when I left the SRP was about 350K, which is atrocious. It looks like it's since been whittled down under 100K, but I still sometimes yearn for the era when Google loaded instantaneously.
- kuschku 11y ago
  Remember, http://google.com/custom http://google.com/custom still loads instantly ;)
  - deleted 11y ago
    [deleted]
  - chinathrow 11y ago
andrewstuart2 11y ago
Page weight may matter, but I think amortized page weight matters most. It's like the marshmallow experiment for the web. If you can make one request at 10x the size, but it's only made 1/100th as often (presumably spans multiple pages) then as long as people come back enough to justify that initial extra cost, you've effectively decreased to 1/10th again. That's why I think AJAX, web manifest [1], indexedDB, localStorage, etc. need to be leveraged much more. Imagine most of your app loading without making a single request, except for the latest front page JSON, or the latest . You have a bunch already in indexedDB so you just ask the server "hey, what's new after ID X or timestamp T?" So your two minutes just became a couple milliseconds (or whatever your disk latency happens to be), and the data loads shortly thereafter, assuming there's not much new data to send back. And if you don't need any new resources, you only had to make a single request. [1] https://github.com/w3c/manifest https://github.com/w3c/manifest
- nostrademons 11y ago
  The initial page load matters a lot. That's the one where the user is deciding whether he'll be coming back to your site. The unfortunate thing about many caching technologies is that they speed up subsequent page loads, but do nothing for the initial one. You still need to pay attention to clean-cache load times. Indeed, it can often be worth it to pay a cost on total page load time to get first-paint time down - that's the time at which the first visual representation of the webpage appears, even if it's just the header, layout, and a bunch of boxes.
- arohner 11y ago
  This is a bad idea, because users may not give you a second chance. The research says over and over again, users respond negatively to small increases in latency. In fact, if I knew of a way to decrease the size of the first load, at the expense of making the second load take longer, I'd probably do it.
- kellysutton 11y ago
  The Ember FastBoot project has the goal to provide exactly this: lightweight HTML/CSS on the initial load and then hydrate the page/application with JS. http://emberjs.com/blog/2014/12/22/inside-fastboot-the-road-to-server-side-rendering.html http://emberjs.com/blog/2014/12/22/inside-fastboot-the-road-... https://github.com/tildeio/ember-cli-fastboot https://github.com/tildeio/ember-cli-fastboot
ninjakeyboard 11y ago
If it took two minutes to load the framing page, how would they be able to stream the video?
jjzieve 11y ago
For some reason this whole problem reminds me of early game developers dealing with small amounts of RAM. Which clearly isn't a problem today. So would it be fair to say we should focus on increasing bandwidth to most of the world. I'm not saying page weight doesn't matter, but if you're just trying to get something off the ground maybe you shouldn't worry about it so much. I mean, why worry about users with poor bandwidth, if you don't even have users? If you already have a growing user base, then by all means refactor, reduce the footprint. But if you don't, code the damn bloated thing first.
- PavlovsCat 11y ago
  Sure, most games these days are probably more CPU/GPU bound, but then again people usually don't have more than one game running at a time, while caching the assets of thousands more. Also, isn't adding bloat "more work"? And just like in real life, I think losing bloat is often harder than gaining it. Why not worry about carousels or endless scrolling or video background when even just one person misses that stuff? Where are all the highly successful websites that started to reduce bloat after they got off the ground? It's not a rhetorical question or sarcasm, I am interested, but I honestly can't think of even one example, it doesn't really mesh with my own (admittedly rather pedestrian) experience. A site starts with a blank design doc, and empty file and a white screen, and adding something and later removing it isn't easier than simply not adding it in the first place.
csense 11y ago
The more things change, the more they stay the same. I remember visiting microprose.com with my 14.4k modem in the mid-90s and being mad that they used so many images I had to wait for about 5-10 minutes or so. I couldn't effectively read it at home and usually ended up reading it at the library.
paulirish 11y ago
More than page weight, this article demonstrates that averages are dangerous, especially for performance metrics. All key metrics should be plotted in 50/90/95/99 percentiles, and for latency-sensitive ones, geographic breakouts can often reveal a serious delta from the mean.
cr4zy 11y ago
I highly recommend turning on page throttling in the Chrome Dev Tools sometime. You'll be amazed at even how slow even 4G seems.
hyperion2010 11y ago
Heh, I've been using flask tempting to make some html forms for exploring large datasets. Turns out when you have 6000 terms that show up in 6 different UI elements putting those in as raw html results in a 13mb file that compresses down to 520kb. Pretty awful use case for forms. I'm pretty prejudiced against JavaScript, but having seen this I now deeply appreciate being able to send something other than raw html.
userbinator 11y ago
This is a bit tangential, but how did we get from "size" to "weight"? It seems a bit of an odd phrasing to me. With the exception of ESL mistakes, I don't know of anyone or any software which refers to "file weight", for example.
- plonh 11y ago
  Because the weight is hidden behind the visible page content, which had a different size. Page weight is the sum of the sizes of the resources used to build the page.
secondwtq 11y ago
" I learned a valuable lesson about the state of the Internet throughout the rest of the world. Many of us are fortunate to live in high bandwidth regions, but there are still large portions of the world that do not. " lol, I'm in China and all what you're discussing just does not exists here. What you'll get is just a "Connection Reset", no matter how compact the page is.
pneumaio 11y ago
It's not surprising large numbers of internet users in emerging markets skipped the web entirely. Delivering product via SMS and chat starts to make a lot of sense in context.

556 points by shubhamjain 11y ago

sirtastic 11y ago

WOW! Faster load times and lighter code makes for a better user experience? (mindblown)

jp555 11y ago
whoosh! You missed the whole point.
- sirtastic 11y ago
  That you can't always look at a single metric as a basis for success? This is rudimentary analytics here. Is there a single person who believes making client side code heavy is the way to go? Do people really think user experience should take a back seat to cool stuff on a site like YouTube?
  - tedunangst 11y ago
    Try "what makes a site merely inconvenient for some can render it completely unusable for others, and so one should not overlook minor issues because they don't seem worth fixing."
    - sirtastic 11y ago
      Excuse me. I didn't realize this wasn't obvious.
  - jp555 11y ago
    The problem of unknown unknowns.

teach 11y ago

Comments from the last time this was posted: https://news.ycombinator.com/item?id=4957992 https://news.ycombinator.com/item?id=4957992

tedunangst 11y ago
Wow. The verge was the poster child for most bloated site even three years ago, long before the recent ruckus.
- mattmanser 11y ago
  What was the recent ruckus?
  - tedunangst 11y ago
    http://blog.lmorchard.com/2015/07/22/the-verge-web-sucks/ http://blog.lmorchard.com/2015/07/22/the-verge-web-sucks/

gketuma 11y ago

As a web dev I always have this in mind but the challenge is convincing your client who wants a video background. Maybe we need a media query that detects internet speed.

scrollaway 11y ago
Even then, it's fairly easy to load the video asynchronously and as part of the last assets, make its intro blend in to a single-color background, voila, problem "solved". I find video backgrounds ridiculous most of the time (though they can be done really well), but that's not the real problem here - the real problem is including 200-800kb javascript code that does nothing but track your user, and often enough doesn't do it for you! (Hi Facebook!) The real problem is using massive js frameworks for the sake of adding dynamic functionality to your site that, often enough, isn't actually worth it. The real problem is that very often, these "features" are only as necessary as the marketing team says they are... the people who have the ability to ask "why?" and the ability to understand "why not" don't have the voice (or guts...) to do so.
- pswilson14 11y ago
  "Massive" JS frameworks aren't the issue, not by themselves. AngularJS, for instance, is only 39.5kb. Bloat sneaks into web applications in other ways, but merely bringing in a framework isn't enough to add a noticeable load on a web page.
  - kuschku 11y ago
    I’ve seen sites loading Angular, React, jQuery(+jQuery UI) and some custom frameworks. Different parts of the site rendering in different frameworks.
chrismbarr 11y ago
I would love this. My company just updated their public-facing website and it has a 28MB 1080p video playing in the page header. The site was outsourced, but I work as a web developer for some of our products and was asked by the marketing team to give the new site a look over. The marketing team was surprised to learn how big the file was since the outsourced team "ensured" them that the new website would be lightweight. Oh well... Now the video has been reduced to a 16MB at 720p, which is still ludicrous to me, but they just really like having the video on the home page more than they want a truly lightweight page. And to be fair, the video does not load when viewed on a mobile device, so at least there's that.

jonahx 11y ago

This is a fascinating example of Simpson's Paradox: https://en.wikipedia.org/wiki/Simpson%27s_paradox https://en.wikipedia.org/wiki/Simpson%27s_paradox It also reminds me of the phenomenon, in customer service, whereby an increase in complaints can sometimes indicate success -- it means the product has gone from bad enough to be unnoticeable to good enough to be engaged with.

jfoutz 11y ago
In WW1, helmets were introduced to protect soldiers. Surprisingly the frequency of head wounds went way up. It took a little while to realize soldiers were "just" being wounded, rather than outright killed if they had no helmet.
- BostonEnginerd 11y ago
  There's a similar story about putting armor on planes during WWII - http://www.johndcook.com/blog/2008/01/21/selection-bias-and-bombers/ http://www.johndcook.com/blog/2008/01/21/selection-bias-and-...

dpweb 11y ago

If you have an engineering mind and care about such things - you care about complexity. Even if you don't - user experience matters to everyone. Have you ever seen something completely insane and everyone around doesn't seem to recognize how awful it really is. That is the web of today. 60-80 requests? 1MB+ single pages? Your functionality, I don't care if its Facebook - does not need that much. It is not necessary. When broadband came on the scene, everyone started to ignore it, just like GBs of memory made people forget about conservation. The fact that there isn't a daily drumbeat about how bloated, how needlessly complex, how ridicuous most of the world's web appliactions of today really are - baffles me.

jkaptur 11y ago
Honestly, I think "a daily drumbeat about how bloated, how needlessly complex, how ridiculous most of the world's web applications really are" pretty much describes every HN conversation on any article with even a remote connection to web technologies.
- draw_down 11y ago
  Jeez, you aren't kidding. It's as though, if we bitch enough about the technical deficiencies, the economic and social circumstances that cause them will, I dunno, vanish into thin air I guess. This topic is pretty much just red meat here
  - Kluny 11y ago
    Well, bitching isn't that great. But as a web developer myself, it has affected the way I work. Like, there was an article just the other day about how to achieve "lightning fast page loads". I shared it around the office and as a result, 4 people have added new steps to their workflow to help reduce page load latency on our client sites. The author knew the article would get good reception here, because of how much people complain about page latency, and I knew that page latency is a thing that's important to more people than just me, for the same reason. (My clients mostly don't seem to care, for some reason, but I bet their customers do). So yeah, having these public conversations can make a difference. We just have to stay positive and constructive.

nicolethenerd 11y ago

Nice to see this again - I've told this story to many of my web dev students. :-)

mbrock 11y ago

Everyone's sometimes on spotty WiFi or foreign expensive 3G. I'm more inclined to trust fast-loading sites and apps. I wonder what would happen if for example iOS decided to visually indicate page weight, kind of like how you can see which apps use the most energy.

peterjmag 11y ago
I think that's a great idea. Make it more visible, and then you get normal people to care about it and put pressure on content owners, developers, etc. Like Google did with their "mobile-friendly" tag; I could yell at my managers all day about how we need to improve our site's mobile experience to no avail, but Google steps in and threatens lower rankings and suddenly it becomes top priority. Perhaps the simplest solution is for Google to start penalizing heavy pages, but as far as I know, page weight isn't part of their mobile-friendly criteria.

bsimpson 11y ago

Thought certainly an interesting anecdote, I don't understand how a video streaming site like YouTube would be useful in a market where a 100K download takes 2+ minutes. You'd have to open a page, walk away for an hour, and hope everything was OK when you got back.

tedunangst 11y ago
I only ever watch youtube videos via youtube-dl, but I still use a browser to navigate the site to find videos to download.
deleted 11y ago
[deleted]
IkmoIkmo 11y ago
Well think about it. Imagine you had no alternative to getting any video on the internet? After all, if not youtube, anything else was probably slower at the time. Obviously you wouldn't simply lose the desire to watch relevant videos, it'd be dimmed quite significantly sure but you'd still want to watch a video every now and then. Whether it's a music video, or a chess match or a farming lecture, there's just a ridiculous amount of content available. I have plenty of videos I'd want to watch even if I'd have to wait hours. (take torrenting for example, or pre-youtube & pre-streaming file sharing, video and music on p2p networks were incredibly slow yet incredibly popular). But if you couldn't even load the pages to browse through the videos, that'd pretty significantly reduce your watching even further. Liken it perhaps to a library where you could only get 1 book per week. Well that's not much, but at least you can get 1 book. But if you go to the library you have to wait in line for an hour, and after examining one book section of 10 books, you have to wait 5 minutes to examine the next one. Choosing the weekly book would become such a chore you'd probably not even bother to go anymore. But if you'd suddenly be able to examine the entire library with only 1 minute of total waiting, many more would be much more inclined to do so, even if they could still only borrow 1 book per week. Beyond that in my experience, lots of requests in a slow connection often fails before completing fully. I don't know why exactly, I've never been a network engineer. While streaming in a slow connection eventually gets there. So it's entirely possible that even browsing normal pages was failing entirely before for some people, even though (if they ever did load the page and choose a video), the video download worked fine albeit at a very slow pace.

SandB0x 11y ago

It is insane. One of my favourites is the "about.me" site, which is meant to be a simple online business card. Picking a random page from https://about.me/people/featured https://about.me/people/featured, you get a page weighing over 3MB! http://tools.pingdom.com/fpt/#!/F4VDN/https://about.me/pentatonicfunk http://tools.pingdom.com/fpt/#!/F4VDN/https://about.me/penta...

motoboi 11y ago

Coming from a low bandwidth, high latency part of the world, I can't confirm this enough. Today, I have 2 mbit and can use Netflix or Youtube just fine, but mere 4 years ago, I had 600k and, boy, that was hard. Hard as in loading youtube URL and go for a coffee. UPDATE: In case Duolingo developers are listening, please test your site on high latency and very low bandwidth scenarios. I just love your site, but lessons behave too strangely when internet is bad here.

malka 11y ago
> Hard as in loading youtube URL and go for a coffee. You can't even to that now. Youtube videos buffer about 1m30 of videos and stops after that :(
- voltagex_ 11y ago
  I understand that Google is doing this to save an immense amount of wasted bandwidth. These days if I need to wait for something to load, I use youtube-dl.
- motoboi 11y ago
  At the time, I wrote an Chrome extension that would select the lowest resolution (240p at the time), but I can't remember if it was capable of autoplay.
robin_reala 11y ago
My train commute into work is the perfect place to brush up with Duolingo. Shame it randomly goes through patches of no signal, as this makes Duolingo fairly unusable. I have to time my practice to fit into the areas I know it’ll work in.
jlangenauer 11y ago
If you're looking for an alternative to Duolingo, give Memrise a try. It allows you to download entire lessons for offline use.

beatpanda 11y ago

I went to work for a company that makes a travel product used by people in almost every country in the world, after trying to use it in southeastern Europe. I told them their page weight was killing the experience, and wanted to join the front end team to fix it. After 6 months of banging my head against a wall, I realized the reason we weren't fixing page weight was because our product managers didn't care about the experience of users in poorer countries, because they didn't have any money to spend anyway. Even though we had lots of users in those countries, and even though we made a big show of how you could use this app to travel anywhere in the world. If there's a lesson there, its that as long as cold economic calculations drive product decisions, this stuff isn't going to get any better.

drikerf 11y ago

Great point and very important in times when bundling howmany? js dependencies for client apps.

Splines 11y ago

If you're on Windows you can use the Network Emulator for Windows Toolkit (NEWT): http://blogs.technet.com/b/juanand/archive/2010/03/05/standalone-network-emulator-tool.aspx http://blogs.technet.com/b/juanand/archive/2010/03/05/standa... I've used it to emulate what it's like on a high-latency or high-loss network. Relatively easy tool to use.

latortuga 11y ago
Chrome also has this feature if you switch to device mode (Ctrl+Shift+M).

misterbwong 11y ago

Isn't this phenomenon getting worse now that responsive design is in vogue? We've collectively decided to shoehorn a website designed for the connectivity and speed of a desktop browser into a lower powered device with slower/spotty connectivity. Genuinely curious: Why is this better than a mobile-friendly site designed specifically with the constraints of a mobile device in mind?

jonahx 11y ago
Simple answer: Writing a responsive site is much faster and easier to maintain than creating two versions of the same site. And it wouldn't it be just two, you also have to support tablets, various desktop sizes, and various mobile sizes. Custom versions for each one isn't feasible. Also, if you care about page and weight and optimization, your site will be light everywhere, and the criticism of shoehorning a big bloated desktop site into a phone won't apply. This is not that difficult to achieve.

foxbarrington 11y ago

If it takes two minutes to load a 100kb page, does it take twenty minutes to watch a 1MB video? Over three hours to watch a 10MB video?

gwern 11y ago
Probably not. Downloading the video is going to depend more on throughput than on latency. The initial connection & page load, as it hits all the domains and resources, is going to be much slower because it relies more on latency and roundtrips.
- Brakenshire 11y ago
  The article says that the page would have taken 20 minutes to load under previous circumstances.

lnanek2 11y ago

Pretty funny story considering YouTube is back to unusable on slow connections. They used to buffer the full video, so you could load up a page, let it sit until the video buffers, then watch it eventually, maybe after reading your social news sites. Nowadays the buffering feature has been removed and you'll just come back, hit play, get a second or two of video, then it has nothing again for a long time. Feels bad for the engineer who spent all that time reducing the size and finding out it made YouTube much more usable across the globe. Amusingly, disabling buffering was probably some penny wise pound foolish way to save bandwidth.

flippant 11y ago
It's for the average user with a decent connection that skips parts of a video. This is tedious, but if you want to buffer a YouTube video try youtube-dl[0] or using VLC. [0]https://rg3.github.io/youtube-dl/ https://rg3.github.io/youtube-dl/
jimworm 11y ago
You can disable mediasource extensions in your browser to get the old download-it-all html5 video.

chadwittman 11y ago

Fantastic

imperialdrive 11y ago
Ditto - Loved reading this. I work on similar projects but it's a tough battle to win against marketing these days.

nostrademons 11y ago

When I joined Google in 2009, we were on the tail-end of a latency optimization kick that Larry had started in 2007. At the time, we had a budget of 20K gzipped for the entire search results page. I remember working on the visual redesign of 2010, where we had increased the page weight from 16K to 19K and there was much handwringing at the higher levels about how we were going to blow our entire latency budget on one change. We did some crazy stuff to squeeze everything in. We would literally count bytes on every change - one engineer wrote a tool that would run against your changelist demo server and output the difference in gzipped size of it. We used 'for(var i=0,e;e=arr[i++];) { ... }' as our default foreach loop because it was one character shorter than explicitly incrementing the loop counter. All HTML tags that could be left unterminated were, and all attributes that could be unquoted were. CSS classnames were manually named with 1-3 character abbreviations, with a dictionary elsewhere, to save on bytesize. I ran an experiment to see if we could use JQuery on the SRP (everything was done in raw vanilla JS), and the results were that it doubled the byte size and latency of the SRP, so that was a complete non-starter. At one point I had to do a CSS transition on an element that didn't exist in the HTML, because it was too heavy and so we had to pull it over via AJAX, so I had to do all sorts of crazy contortions to predict the height and position of revealed elements before the code for them actually existed on the client. A lot of these convolutions should've been done by compiler, and indeed, a lot were moved to one when we got an HTML-aware templating language. But it gave me a real appreciation for how to write tight, efficient code under constraints - real engineering, not just slapping libraries together. Alas, when I left the SRP was about 350K, which is atrocious. It looks like it's since been whittled down under 100K, but I still sometimes yearn for the era when Google loaded instantaneously.

kuschku 11y ago
Remember, http://google.com/custom http://google.com/custom still loads instantly ;)
- deleted 11y ago
  [deleted]
- chinathrow 11y ago

andrewstuart2 11y ago

Page weight may matter, but I think amortized page weight matters most. It's like the marshmallow experiment for the web. If you can make one request at 10x the size, but it's only made 1/100th as often (presumably spans multiple pages) then as long as people come back enough to justify that initial extra cost, you've effectively decreased to 1/10th again. That's why I think AJAX, web manifest [1], indexedDB, localStorage, etc. need to be leveraged much more. Imagine most of your app loading without making a single request, except for the latest front page JSON, or the latest . You have a bunch already in indexedDB so you just ask the server "hey, what's new after ID X or timestamp T?" So your two minutes just became a couple milliseconds (or whatever your disk latency happens to be), and the data loads shortly thereafter, assuming there's not much new data to send back. And if you don't need any new resources, you only had to make a single request. [1] https://github.com/w3c/manifest https://github.com/w3c/manifest

nostrademons 11y ago
The initial page load matters a lot. That's the one where the user is deciding whether he'll be coming back to your site. The unfortunate thing about many caching technologies is that they speed up subsequent page loads, but do nothing for the initial one. You still need to pay attention to clean-cache load times. Indeed, it can often be worth it to pay a cost on total page load time to get first-paint time down - that's the time at which the first visual representation of the webpage appears, even if it's just the header, layout, and a bunch of boxes.
arohner 11y ago
This is a bad idea, because users may not give you a second chance. The research says over and over again, users respond negatively to small increases in latency. In fact, if I knew of a way to decrease the size of the first load, at the expense of making the second load take longer, I'd probably do it.
kellysutton 11y ago
The Ember FastBoot project has the goal to provide exactly this: lightweight HTML/CSS on the initial load and then hydrate the page/application with JS. http://emberjs.com/blog/2014/12/22/inside-fastboot-the-road-to-server-side-rendering.html http://emberjs.com/blog/2014/12/22/inside-fastboot-the-road-... https://github.com/tildeio/ember-cli-fastboot https://github.com/tildeio/ember-cli-fastboot

ninjakeyboard 11y ago

If it took two minutes to load the framing page, how would they be able to stream the video?

jjzieve 11y ago

For some reason this whole problem reminds me of early game developers dealing with small amounts of RAM. Which clearly isn't a problem today. So would it be fair to say we should focus on increasing bandwidth to most of the world. I'm not saying page weight doesn't matter, but if you're just trying to get something off the ground maybe you shouldn't worry about it so much. I mean, why worry about users with poor bandwidth, if you don't even have users? If you already have a growing user base, then by all means refactor, reduce the footprint. But if you don't, code the damn bloated thing first.

PavlovsCat 11y ago
Sure, most games these days are probably more CPU/GPU bound, but then again people usually don't have more than one game running at a time, while caching the assets of thousands more. Also, isn't adding bloat "more work"? And just like in real life, I think losing bloat is often harder than gaining it. Why not worry about carousels or endless scrolling or video background when even just one person misses that stuff? Where are all the highly successful websites that started to reduce bloat after they got off the ground? It's not a rhetorical question or sarcasm, I am interested, but I honestly can't think of even one example, it doesn't really mesh with my own (admittedly rather pedestrian) experience. A site starts with a blank design doc, and empty file and a white screen, and adding something and later removing it isn't easier than simply not adding it in the first place.

csense 11y ago

The more things change, the more they stay the same. I remember visiting microprose.com with my 14.4k modem in the mid-90s and being mad that they used so many images I had to wait for about 5-10 minutes or so. I couldn't effectively read it at home and usually ended up reading it at the library.

paulirish 11y ago

More than page weight, this article demonstrates that averages are dangerous, especially for performance metrics. All key metrics should be plotted in 50/90/95/99 percentiles, and for latency-sensitive ones, geographic breakouts can often reveal a serious delta from the mean.

cr4zy 11y ago

I highly recommend turning on page throttling in the Chrome Dev Tools sometime. You'll be amazed at even how slow even 4G seems.

hyperion2010 11y ago

Heh, I've been using flask tempting to make some html forms for exploring large datasets. Turns out when you have 6000 terms that show up in 6 different UI elements putting those in as raw html results in a 13mb file that compresses down to 520kb. Pretty awful use case for forms. I'm pretty prejudiced against JavaScript, but having seen this I now deeply appreciate being able to send something other than raw html.

userbinator 11y ago

This is a bit tangential, but how did we get from "size" to "weight"? It seems a bit of an odd phrasing to me. With the exception of ESL mistakes, I don't know of anyone or any software which refers to "file weight", for example.

plonh 11y ago
Because the weight is hidden behind the visible page content, which had a different size. Page weight is the sum of the sizes of the resources used to build the page.

secondwtq 11y ago

" I learned a valuable lesson about the state of the Internet throughout the rest of the world. Many of us are fortunate to live in high bandwidth regions, but there are still large portions of the world that do not. " lol, I'm in China and all what you're discussing just does not exists here. What you'll get is just a "Connection Reset", no matter how compact the page is.

pneumaio 11y ago

It's not surprising large numbers of internet users in emerging markets skipped the web entirely. Delivering product via SMS and chat starts to make a lot of sense in context.