Time for fast, minimalist web aesthetic?

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

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

It's not front-end widgets that are responsible.<p>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.<p>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" (<a href="http://en.wikipedia.org/wiki/Fallacies_of_Distributed_Computing" rel="nofollow">http://en.wikipedia.org/wiki/Fallacies_of_Distributed_Comput...</a>). The problem is there's too much CPU activity on the server and not enough on the client, when the reverse could be true.<p>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 <a href="https://szpil.com" rel="nofollow">https://szpil.com</a>.

People who want their websites fast eliminate bottlenecks and streamline their client-side load so it works fast.<p>People who want flashy, pretty, animated sites pay for it in terms of bandwidth and performance.<p>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.<p>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.<p>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.<p>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.

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

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.<p>Which is a good thing, but it does make me wonder if the author of this article has ever actually used Reader.

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.

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