In Mobile, Slow Speed Kills

In 2004 Google established that most people are willing to wait for anything online approximately two seconds before becoming frustrated. There is no evidence to suggest that, as a civilization, we have become more patient or tolerant. JL

Om Malik comments in his blog:

Whatever you think about Facebook, they have refocused our attention on the importance of architecting apps and experiences with network performance and speed — something Google made us aware of 11 years ago. Design is not the pretty face, but the entire experience.
Google. Amazon. Walmart. Beyond a doubt, faster-loading pages increase the performance and use of a service. Sometimes even a perceived faster performance (such as in the early days of Instagram) can help boost usage and engagement. So it’s no surprise that Facebook is using speed to lure publishing companies to collaborate. Handing over the content and trying to optimize their own products to overcome the latency and other networking challenges are two different things. Facebook has used an argument that conflates the two issues.
The biggest argument in favor of Facebook Instant Articles is the speed at which they will load from Facebook’s mobile app. In a press release, Facebook noted that many news “stories take an average of eight seconds to load, by far the slowest single content type on Facebook” and that “Instant Articles makes the reading experience as much as ten times faster than standard mobile web articles.” That is 0.8 seconds, and I don’t know how the company is doing it — paint me impressed.
Facebook could assert complete control over all the content that is shown to the reader. Without Instant Articles, a click on a New York Times article would probably go to the Times‘ web server (which is likely hosted by Akamai or someone like them), which would fetch pieces of the content and assemble them together on the user’s phone. Instant Articles packages it all in one go and sends it to the user, eliminating the need to use the NYT‘s hosting provider at all.
Moreover, if there is a mix of images, video and text (very likely), the time to load those pieces of content from different sources can become significant and much harder to pre-fetch — and that is why Facebook needs to have complete control, which in turn yields a lot of the performance. In addition, Facebook has adopted all the latest technologies: It was an early adopter of Google’s SPDY, and I would expect it to already be on HTTP/2. Facebook is using AsyncDisplayKit, a UI framework developed for Paper, which in turn taps into the iPhone’s multicore processors to deliver a performance boost. (Wired has a nifty article about this.)

Fact Check

Just to fact-check Facebook’s claims, I pinged folks over at Chartbeat, since they work with a lot of publishers, to see if they have any data on page-load times in aggregate. They do, and they shared a histogram of desktop and mobile page-load times. The underlying data set is a week’s worth of data from a sample of about 70 domains that allow Chartbeat to aggregate data — about half a billion page views in all. It is not perfect, but it’s a good sample size and a directional indicator. In particular, 57 percent of mobile users and 72 percent of desktop users load within the first 8 seconds, and 12 percent and 8 percent, respectively, take longer than 20 seconds.

Facebook is right: Most of these pages take way too long to load. In 2004 Google pointed out that people are happy to wait about two seconds before getting frustrated with the page load. There is some latitude on mobile, but as LTE proliferates, people have less tolerance for slower page downloads.
But as I pointed out on Twitter, “If you need Facebook to solve the page load problem, then as media entity you need to be darwined.” My Darwin reference was prompted by all the talk about media companies ceding control of their brands and audience to Facebook. In a way it is shocking that publishing companies have not spent more energy and time shoring up their technology stacks — something web pioneer Dave Winer has been recommending for years.

Network the Experience

I won’t argue about the merits or demerits of giants ceding control to Facebook — they will have to live with the dire consequences — but for me it highlights a bigger problem. It seems as if these giants don’t understand that the underlying network performance and “content” are two separate things. And it is not just large publishers. Design is not only a pretty face but also the entire experience, and that experience is highly dependent on the network, network conditions and people’s feelings about it. “More bars in more places” is nothing more than a slogan, and a lot more thought has to go into networks when designing mobile experience.
There are many options. Obviously I am biased when I point to TwinPrime, a Redwood City, Calif.–based startup backed by True Ventures (where I am on the board), which has developed a set of technologies that improve the performance of mobile apps. For example, using their technology, the New York Times iPhone app, which is made of many objects, could see performance gains (see the table below).
Whatever you might think about Facebook Instant Articles, they have refocused our attention on the importance of architecting apps and experiences with network performance and speed — something Google made us aware of 11 years ago.
P.S.: Check out TwinPrime’s blog for additional reading into network performance and impact on the app.