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.
...
As an aside (from me), Jeremy makes a valid point about the rise of JavaScript frameworks being a contributing factor to the problem. I’ve long argued about the appropriateness or otherwise of single-page-application sites. The truth is that there is a time and a place for them, but they are not necessary for delivering content quickly on the web. People often lose sight of this.
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).
This all said, I have spent most of the last 18 months years building complicated AngularJS-based single page application Milk. However, the reasons why a JavaScript framework is appropriate for Milk are:
- 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.
...
Mind you, that ALL said... Although JavaScript frameworks are a problem in some instances, I think the real culprit in the case of the Buzzfeeds of this world, is the amount of advertising and sponsored content adding bloat to their pages. If publishers had spent more time testing their sites on edge and 3G mobile connections maybe we’d not be in this situation where Facebook Instant Articles look set to be a hit.
[Edit]
This article on A List Apart also makes some good points
