Time for fast, minimalist web aesthetic? | Hacker News Reader

Time for fast, minimalist web aesthetic?

usertime.posterous.com

25 pointsacl19 comments

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.

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.

In case you didn't know, 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/) and Chrome/ium (https://chrome.google.com/extensions/detail/jggheggpdocamnea...)

There are also other, similar things, like iReader for Chrome/ium: https://chrome.google.com/extensions/detail/ppelffpjgkifjfgn...

And of course Instapaper (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.

Safari reader is actually the same codebase as Readability. http://twitter.com/chrisdary/status/15672452287

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/

It's under the Apache 2 license: http://code.google.com/p/arc90labs-readability/

And Opera has an "accessibility layout" builtin

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_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.

"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.

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/googl...

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/) 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.

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.

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.

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.

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).

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.

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

...if you include sites with JS widgets, it's probably even less.

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

Reply on news.ycombinator.com