Facebook Instant Articles

Michael Reckhow:

As more people get their news on mobile devices, we want to make the experience faster and richer on Facebook. People share a lot of articles on Facebook, particularly on our mobile app. To date, however, these stories take an average of eight seconds to load, by far the slowest single content type on Facebook. Instant Articles makes the reading experience as much as ten times faster than standard mobile web articles.

Josh Constine (comments):

Instant Articles won’t receive preferential treatment from Facebook’s News Feed sorting algorithm just because of their format. But if users click, like, comment, and share Instant Articles more often than others, they may show up higher and more frequently in feed like any piece of popular content. That could incentivize, or implicitly force, more publishers to adopt the new hosted format.

Beyond just loading faster, Facebook will parse HTML and RSS to display articles with fonts, layouts, and formats that make Instant Articles feel like a publisher’s website. But Facebook is also providing vivid media options like embedding zoomable photos, videos, and maps with audio captions, plus contextual ‘Ambient Videos’.

Danny Sullivan:

We’ve known this would be coming, and there’s been some debate over whether it’s good or bad. But I haven’t seen that extended to what would happen if Google follows Facebook’s lead. It could, potentially causing the web to be swallowed up by two gatekeeping giants.

John Gruber:

I’m intrigued by the emphasis on speed. Not only is native mobile code winning for app development, but with things like Instant Articles, native is making the browser-based web look like a relic even just for publishing articles.

Marko Karppinen (in 2013, tweet):

To cater for a single iMac user, you need to make sure your content works with 2.5 million possible browser sizes. To cater for 150 million iPad users, you need to support just two.

To me, this fundamentally changes the math on whether complex, responsive HTML layouts make sense. Mobile browsers are slow and that’s not changing any time soon. A complicated responsive layout can take seconds to render on an iPad. Seconds!

In a world where 100ms of latency cost Amazon 1% in sales, where half a second of delay caused Google a 20% drop in traffic, we are happily spending seconds, on each and every page view, just figuring out, dynamically and in real time, the size of an iPad’s screen—a constant that’s almost literally set in stone.

Update (2015-05-15): Jason Brennan:

What makes the web the web is the open connections between documents or “apps,” the fact that anybody can participate on a mostly-agreed-upon playing field. Things like Facebook Instant Articles or even Apple’s App Store are closed up, do not allow participation by every person or every idea, and don’t really act like a “web” at all. And they could have easily been built on FTP or somesuch and it wouldn’t make a lick of difference.

Update (2015-05-17): Peter-Paul Koch:

The web definitely has a speed problem due to over-design and the junkyard of tools people feel they have to include on every single web page. However, I don’t agree that the web has an inherent slowness. The articles for the new Facebook feature will be sent over exactly the same connection as web pages. However, the web versions of the articles have an extra layer of cruft attached to them, and that’s what makes the web slow to load. The speed problem is not inherent to the web; it’s a consequence of what passes for modern web development. Remove the cruft and we can compete again.

Nick Heer:

This happens on the client side from the inclusion of Javascript frameworks, external plugins, analytics scripts, giant images, and so forth; each of these requires a DNS query, a download, and potentially rendering. This cruft also exists on the server side from related content and similar extraneous database lookups. It gets worse: the creeping of this cruft coincided with the rise of the responsive web, which means that all this crap gets served over your metered cellular connection.

Marco Arment:

The entire culture dominant among web developers today is bizarrely framework-heavy, with seemingly no thought given to minimizing dependencies and page weight. Most times I land on a Stack Overflow page with a simple Javascript question, the highest-voted answer is “Just include [framework X] and then call this function,” even though a few posts beneath it is a perfectly suitable, standalone 10-line function.

Update (2015-05-18): Accidental Tech Podcast discusses Instant Articles.

Om Malik:

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.

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.

John Gruber:

Business development deals have created problems that no web developer can solve. There’s no way to make a web page with a full-screen content-obscuring ad anything other than a shitty experience.

Facebook iOS iOS App Optimization Web

7 Comments RSS · Twitter

Leave a Comment

Name

E-mail (will not be published)

Web site

Δ