5 ms·

Time for fast, minimalist web aesthetic?

25 points by acl 16y ago

petervandijck 16y ago
"Website performance has stayed the same over the past 10 years". Really? I think not. 1 to 2 to 4 second load times where ok 10 years ago for a "fast" site, now we're talking 500 ms.
- itsderek23 16y ago
  Interesting - I can't think of a website that has 500 ms page load times. The average is closer to 5 seconds, or 10x 500 ms. Latency may be down, but that's only part of the equation. http://www.datacenterknowledge.com/archives/2010/06/23/google-how-were-making-the-web-faster/ http://www.datacenterknowledge.com/archives/2010/06/23/googl...
- _delirium 16y ago
  I still get several-second load times pretty regularly, a few very minimalist sites like HN excepted (though HN can take a few seconds to respond sometimes for what appear to be backend reasons). Admittedly, I have 320 kbps SDSL, so maybe things are better if you've got a multi-Mbit pipe. I think ten years ago, a typical mainstream media site would take somewhere around 5 to 10 seconds to load on a modem, which is basically what they take to load for me today. Fox News's website takes about 30 seconds to fully load! Things are a bit better with AdBlock, since it often seems to be third-party ad and analytics servers both holding up the parade with high latency, and pushing big .swfs. But the number of sites that load in 500 ms for me is pretty vanishingly small. It happens, but esp. without Adblock (which I don't always use) by the end of 500ms usually my browser still hasn't even finishing pinging all the servers the page is loading content from, much less actually pulled the content. Using Polipo (http://www.pps.jussieu.fr/~jch/software/polipo/ http://www.pps.jussieu.fr/~jch/software/polipo/) as a local caching proxy does seem to help in my case. Not sure why it would do a better job than either Firefox or Chrome, but it seems to cache and pipeline more aggressively.
pixelbath 16y ago
People who want their websites fast eliminate bottlenecks and streamline their client-side load so it works fast. People who want flashy, pretty, animated sites pay for it in terms of bandwidth and performance. Regarding the "computers faster" argument, you see the same trend in traditional desktop software. Microsoft Office used to be fast, but it gets heavier and more bloated with each release, and there are nearly no features I use that can't be found in Office 97. Linux used to be the go-to OS for a lean, fast system. You can't install any recent desktop distribution without it feeling, well, like Windows. Flash websites continue to become more elaborate, so the sites you saw a few years ago perform great, while new Flash sites still chug along. I don't see website bloat as an issue, but web designers and developers do need to realize that not everyone's machine is as fast as theirs.
semanticist 16y ago
Reader in Safari 5 doesn't strip away all images - I've frequently had it retain images that are part of the flow of the article. Which is a good thing, but it does make me wonder if the author of this article has ever actually used Reader.
- acl 16y ago
  Reader certainly does strip away most images, that's the point. Folks who like reader are using it precisely because it provides a cleaner view, highlights the content, and minimizes distractions.
  - pavs 16y ago
    Reader does the same thing readability does, because reader is based on readability. They both preserve images within articles as long as they are not in form of widgets (flickr).
jbail 16y ago
Slow loading websites usually have nothing to do with the adornments of the UI. It's most often all the JavaScript widgets people plug into their webpages (at least from my experience). These widgets use "document.write" to insert content into the webpage before it has completed loading, which if the widget server is responding slowly means your page loads slowly. To combat this, you could program your embedded widgets to not load until page loads. For most people, that's above their skill level, so they just copy and paste and call it a day. The widget authors COULD write their widgets to have them wait until the page loaded before rendering themselves into the DOM, but 99% of JavaScript widgets (Google AdWords included) use 'document.write' and don't wait for the page to load first. They want to make sure that they get the chance to count the hit.
- pavs 16y ago
  I know some popular site load their javascript ad codes within and iframe. loads much much faster, some ad agencies even allow custom iframe codes but you have to ask for them.
dflock 16y ago
In case you didn't know, Readability (http://lab.arc90.com/experiments/readability/ http://lab.arc90.com/experiments/readability/) does pretty much the same job as the Safari reader thing, but for all browsers. There are readability add-ons for both FF (https://addons.mozilla.org/en-US/firefox/addon/46442/ https://addons.mozilla.org/en-US/firefox/addon/46442/) and Chrome/ium (https://chrome.google.com/extensions/detail/jggheggpdocamneaacmfoipeehedigia https://chrome.google.com/extensions/detail/jggheggpdocamnea...) There are also other, similar things, like iReader for Chrome/ium: https://chrome.google.com/extensions/detail/ppelffpjgkifjfgnbaaldcehkpajlmbc https://chrome.google.com/extensions/detail/ppelffpjgkifjfgn...
- edash 16y ago
  And of course Instapaper (http://www.instapaper.com/ http://www.instapaper.com/) gives you the benefits of Readability while also saving the text for later reading. Available on multiple platforms, offline and on... If this sounds like an advertisement, it's only because I've recited it to friends and family members so many times.
- sp332 16y ago
  Safari reader is actually the same codebase as Readability. http://twitter.com/chrisdary/status/15672452287 http://twitter.com/chrisdary/status/15672452287
  - dflock 16y ago
    Cool, I didn't know that. I though the Safari version did de-pagination as well, which readability doesn't, I don't think? Wonder if they'll contribute back? Anyone know what license Readability is under - I couldn't see it on the page: http://lab.arc90.com/2009/03/02/readability/ http://lab.arc90.com/2009/03/02/readability/
    - umbrae 16y ago
      It's under the Apache 2 license: http://code.google.com/p/arc90labs-readability/ http://code.google.com/p/arc90labs-readability/
marknutter 16y ago
A great example of a site focusing on the content is http://quora.com http://quora.com. I hope this trend continues, I know I've been trying to follow it in my own designs lately.
frisco 16y ago
This is silly. Most of the perceived latency (the "time to interact") is synchronous backend work that has little to do with the frontend aesthetic. Almost all of the rest has to do with loading Javascript widgets from other domains.
- itsderek23 16y ago
  If by backend you mean the server-side, I don't think that's really the case. The server-side is usually less than 20% of the page load timeline: http://developer.yahoo.com/performance/rules.html http://developer.yahoo.com/performance/rules.html ...if you include sites with JS widgets, it's probably even less.
jorangreef 16y ago
It's not front-end widgets that are responsible. It's the coupling of user interface and network. The best way to achieve sub-20ms response times (instantaneous to the human eye) is to decouple the user interface from the network, to transport views and controllers separately across the network, fuse them on the client, and buffer data against the network. This cannot be done with server-side MVC frameworks (no matter how popular) as they simply were not designed to do this, to deal with network latency, one of the "8 Fallacies" (http://en.wikipedia.org/wiki/Fallacies_of_Distributed_Computing http://en.wikipedia.org/wiki/Fallacies_of_Distributed_Comput...). The problem is there's too much CPU activity on the server and not enough on the client, when the reverse could be true. What is needed is a network-aware, network-straddling framework. The "thin client/fat server" metaphor must give way to the "thin server/capable client". This would probably also encourage Javascript on both client and server, and make offline access a reality as a matter of course. For example, see https://szpil.com https://szpil.com.

25 points by acl 16y ago

"Website performance has stayed the same over the past 10 years". Really? I think not. 1 to 2 to 4 second load times where ok 10 years ago for a "fast" site, now we're talking 500 ms.

itsderek23 16y ago
Interesting - I can't think of a website that has 500 ms page load times. The average is closer to 5 seconds, or 10x 500 ms. Latency may be down, but that's only part of the equation. http://www.datacenterknowledge.com/archives/2010/06/23/google-how-were-making-the-web-faster/ http://www.datacenterknowledge.com/archives/2010/06/23/googl...
_delirium 16y ago
I still get several-second load times pretty regularly, a few very minimalist sites like HN excepted (though HN can take a few seconds to respond sometimes for what appear to be backend reasons). Admittedly, I have 320 kbps SDSL, so maybe things are better if you've got a multi-Mbit pipe. I think ten years ago, a typical mainstream media site would take somewhere around 5 to 10 seconds to load on a modem, which is basically what they take to load for me today. Fox News's website takes about 30 seconds to fully load! Things are a bit better with AdBlock, since it often seems to be third-party ad and analytics servers both holding up the parade with high latency, and pushing big .swfs. But the number of sites that load in 500 ms for me is pretty vanishingly small. It happens, but esp. without Adblock (which I don't always use) by the end of 500ms usually my browser still hasn't even finishing pinging all the servers the page is loading content from, much less actually pulled the content. Using Polipo (http://www.pps.jussieu.fr/~jch/software/polipo/ http://www.pps.jussieu.fr/~jch/software/polipo/) as a local caching proxy does seem to help in my case. Not sure why it would do a better job than either Firefox or Chrome, but it seems to cache and pipeline more aggressively.

pixelbath 16y ago

People who want their websites fast eliminate bottlenecks and streamline their client-side load so it works fast. People who want flashy, pretty, animated sites pay for it in terms of bandwidth and performance. Regarding the "computers faster" argument, you see the same trend in traditional desktop software. Microsoft Office used to be fast, but it gets heavier and more bloated with each release, and there are nearly no features I use that can't be found in Office 97. Linux used to be the go-to OS for a lean, fast system. You can't install any recent desktop distribution without it feeling, well, like Windows. Flash websites continue to become more elaborate, so the sites you saw a few years ago perform great, while new Flash sites still chug along. I don't see website bloat as an issue, but web designers and developers do need to realize that not everyone's machine is as fast as theirs.

semanticist 16y ago

Reader in Safari 5 doesn't strip away all images - I've frequently had it retain images that are part of the flow of the article. Which is a good thing, but it does make me wonder if the author of this article has ever actually used Reader.

acl 16y ago
Reader certainly does strip away most images, that's the point. Folks who like reader are using it precisely because it provides a cleaner view, highlights the content, and minimizes distractions.
- pavs 16y ago
  Reader does the same thing readability does, because reader is based on readability. They both preserve images within articles as long as they are not in form of widgets (flickr).

jbail 16y ago

Slow loading websites usually have nothing to do with the adornments of the UI. It's most often all the JavaScript widgets people plug into their webpages (at least from my experience). These widgets use "document.write" to insert content into the webpage before it has completed loading, which if the widget server is responding slowly means your page loads slowly. To combat this, you could program your embedded widgets to not load until page loads. For most people, that's above their skill level, so they just copy and paste and call it a day. The widget authors COULD write their widgets to have them wait until the page loaded before rendering themselves into the DOM, but 99% of JavaScript widgets (Google AdWords included) use 'document.write' and don't wait for the page to load first. They want to make sure that they get the chance to count the hit.

pavs 16y ago
I know some popular site load their javascript ad codes within and iframe. loads much much faster, some ad agencies even allow custom iframe codes but you have to ask for them.

dflock 16y ago

In case you didn't know, Readability (http://lab.arc90.com/experiments/readability/ http://lab.arc90.com/experiments/readability/) does pretty much the same job as the Safari reader thing, but for all browsers. There are readability add-ons for both FF (https://addons.mozilla.org/en-US/firefox/addon/46442/ https://addons.mozilla.org/en-US/firefox/addon/46442/) and Chrome/ium (https://chrome.google.com/extensions/detail/jggheggpdocamneaacmfoipeehedigia https://chrome.google.com/extensions/detail/jggheggpdocamnea...) There are also other, similar things, like iReader for Chrome/ium: https://chrome.google.com/extensions/detail/ppelffpjgkifjfgnbaaldcehkpajlmbc https://chrome.google.com/extensions/detail/ppelffpjgkifjfgn...

edash 16y ago
And of course Instapaper (http://www.instapaper.com/ http://www.instapaper.com/) gives you the benefits of Readability while also saving the text for later reading. Available on multiple platforms, offline and on... If this sounds like an advertisement, it's only because I've recited it to friends and family members so many times.
sp332 16y ago
Safari reader is actually the same codebase as Readability. http://twitter.com/chrisdary/status/15672452287 http://twitter.com/chrisdary/status/15672452287
- dflock 16y ago
  Cool, I didn't know that. I though the Safari version did de-pagination as well, which readability doesn't, I don't think? Wonder if they'll contribute back? Anyone know what license Readability is under - I couldn't see it on the page: http://lab.arc90.com/2009/03/02/readability/ http://lab.arc90.com/2009/03/02/readability/
  - umbrae 16y ago
    It's under the Apache 2 license: http://code.google.com/p/arc90labs-readability/ http://code.google.com/p/arc90labs-readability/

marknutter 16y ago

A great example of a site focusing on the content is http://quora.com http://quora.com. I hope this trend continues, I know I've been trying to follow it in my own designs lately.

frisco 16y ago

This is silly. Most of the perceived latency (the "time to interact") is synchronous backend work that has little to do with the frontend aesthetic. Almost all of the rest has to do with loading Javascript widgets from other domains.

itsderek23 16y ago
If by backend you mean the server-side, I don't think that's really the case. The server-side is usually less than 20% of the page load timeline: http://developer.yahoo.com/performance/rules.html http://developer.yahoo.com/performance/rules.html ...if you include sites with JS widgets, it's probably even less.

jorangreef 16y ago

It's not front-end widgets that are responsible. It's the coupling of user interface and network. The best way to achieve sub-20ms response times (instantaneous to the human eye) is to decouple the user interface from the network, to transport views and controllers separately across the network, fuse them on the client, and buffer data against the network. This cannot be done with server-side MVC frameworks (no matter how popular) as they simply were not designed to do this, to deal with network latency, one of the "8 Fallacies" (http://en.wikipedia.org/wiki/Fallacies_of_Distributed_Computing http://en.wikipedia.org/wiki/Fallacies_of_Distributed_Comput...). The problem is there's too much CPU activity on the server and not enough on the client, when the reverse could be true. What is needed is a network-aware, network-straddling framework. The "thin client/fat server" metaphor must give way to the "thin server/capable client". This would probably also encourage Javascript on both client and server, and make offline access a reality as a matter of course. For example, see https://szpil.com https://szpil.com.