

Time for fast, minimalist web aesthetic? - acl
http://usertime.posterous.com/time-for-fast-minimalist-web-aesthetic

======
jbail
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
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
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...](https://chrome.google.com/extensions/detail/jggheggpdocamneaacmfoipeehedigia))

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

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

~~~
dflock
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/>

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

------
jorangreef
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...](http://en.wikipedia.org/wiki/Fallacies_of_Distributed_Computing)).
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>.

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

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

~~~
_delirium
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.

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

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

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

