May 21st, 2015
Back in 2010 Sir Tim Berners Lee warned about the threat posed to the web by Facebook et al.
Yesterday Jeremy Keith made this timely post (thanks to @fjordaan for tweeting it) about how poorly-performing websites are fuelling the shift towards native apps. In case you missed it, Facebook – which has already created a closed content silo – recently launched Instant Articles, which is basically their proprietary presentation mechanism for external content that is (presumably) be pre-cached to enhance the speed of the experience.
Rather than taking you to the external site they’re keeping you on Facebook, which is obviously good for Facebook, but you can’t argue with the fact that sometimes the user experience of external news sites is pretty terrible, so users will understandably like Instant Articles.
I’ll not repeat Jeremy’s points so read his post.
In a previous guise I remember arguing against going full-single-page-app in favour of ‘proper’ indexable content URLs on a project. And for keeping the number of requests on those pages down to a minimum (and, yes, making those requests super speedy via, minification, caching et cetera).
This is all well understood good practice, and yet a BuzzFeed article I just tested triggered 335 individual server requests. And one of the reasons I don’t like WordPress particularly is that out of the box (and with most of the popular themes) it leads to bloated request-heavy pages. There’s no culture of optimisation around it, yet WordPress seems more popular than ever (Yes, this site is WordPress; it’s good at doing blogs).
- It is only for use by logged-in users.
- It serves individual user-specific content such as their personal messages. It’s much faster to load the raw JSON data of a message than to reload an entirely new document with all its assets.
- It provides live status updates on some items.
- Our caching and local storage strategy ensures that users only load the application framework once, even though they may visit hundreds of pages within the app over the course of a week.
- And even then, our uncached page load is only 242KB (on a mobile device) and 18 requests, many of which are asynchronous.
It’s an application not a website, it just happens to use web technology. This is a very different use-case to a public page of content such as a news article.
The web is natively great at delivering pages of text very quickly. I consider documents and applications quite separately. And I don’t think it’s contradictory to be a cheerleader for both. The trick is, I believe, not to try to make documents more application-like.
This article on A List Apart also makes some good points