The Web Doesn’t Get Preferential Treatment (Part 1)

Note upfront: Due to an ever-increasing length this piece has been split into multiple parts, with subsequent installments to be released in the days ahead. This is Part 1.

Several weeks ago Facebook released Instant Articles, a (so far) iPhone-only specialized renderer built with native Objective C and Cocoa frameworks that takes published HTML content and displays it in a reading-optimized format, with great multimedia and UX fidelity. And above all, titularly, no loading times for the content.

Instant Articles exists because Facebook measured that external articles (loaded from within the Facebook app) take between 8 and 10 seconds to render on average, and it—like any savvy business—saw an opportunity for improvement there.

And while it is a significant user experience improvement, it remains to be seen how much content will get this Instant Article treatment, and in what layouts. At the time of writing I could find only one such article between the various launch partners’ own Facebook feeds. Even their own Instant Articles group doesn’t link beyond the launch items provided.

The documentation is still being produced, but Instant Articles may not require much in terms of code changes, as shown in these two videos. Quite likely it’s not a technical challenge that explains the dearth of Instant Articles from the launch partners thus far. More on that later.

As expected, Instant Articles caused a resurgence in the debate around native vs. web. To wit, lots of smart people weighed in: John Gruber, Peter-Paul Koch, Jeremy Keith, Marco Arment, Sebastian Markbåge, M.G. Siegler, Tim Kadlec, Jim Ray, Baldur Bjarnason and many more.

And as always, the reports of the Web’s impending death are greatly exaggerated.

For one, Instant Articles (<abbr>IA</abbr>) are nothing without web-published, HTML-structured content (whether it uses any site-provided CSS and JS at all is unclear). IA is a renderer built in native iOS code; it’s not native iOS-written content. Think of it as a highly specialized web browser, rather than a native app.

Still, there are some major problems looming over the horizon that I think the Web (community and companies) will have to address, lest this world-class platform of technology and information gets relegated to second-class citizenship for the vast majority of content as shared and consumed by people (and monetized by publishers).

The Web Lacks Governing Focus

Apple is deeply invested in its platforms, technologies, and the required innovations it must push to compete. The tools it provides to developers, to build apps and experiences of their own with, reflect that investment as well as its focus. The same holds true (in varying degrees) for Google and Microsoft, and “smaller” technology vendors like Mozilla or Opera.

The Web lacks a singular governing body that has such a focus on the Web as a platform. The body originally most suited for the task was so famously unfocused that some of the aforementioned corporations started a sister organization to give the Web the innovative focus it needed. Instead, we now have two unfocused governing bodies.

No company has its existence at stake by the marching beat of the Web that also has enough control over the platform to steer it away from long-term irrelevance. Apple’s livelihood goes away if the Mac OS X and iOS platforms stop appealing to both consumers and developers, and while neither Google nor Microsoft depend on their desktop and mobile operating systems the same way, they would cede too much control and revenue if they didn’t uphold their own platforms.

The result is that these companies have to compete by the tools and (developer) services they provide. The programming standards and conventions are constrained by a single entity having to appeal and cater to a great many third party vendors. This forces a virtuous cycle wherein the incentives are strong and clearly targeted for the platform-owning company to facilitate third-party needs.

The Web lacks such a virtuous cycle; it instead has many smaller community-run ones, much to its credit, but these are not governed or coordinated as one. There is a great deal of value and virtue in this independence, but it does not create a beneficial environment for technological progress and innovation. What one “group” does may get—and often is—rejected by various others, thereby not pushing the web one great stride forward, but two strides in miscellaneous directions. Area spread versus depth.

We cannot enforce any convention on the web; we can only convince people to adopt one by showing how it’s better. By market value, in essence (a small irony, perhaps, that the academic, socialist Web is so fundamentally capitalist in its own ways). Even when many are convinced, the convention remains unenforceable, subjective, and permits use-case-specific exceptions. Those are not criticisms per se, but it is important to recognize that these benefits come with tradeoffs, and that we must understand and acknowledge those tradeoffs if we are to improve on them somehow.

The Web Lacks System-level Integration

Facebook created Instant Articles ostensibly because web pages take 8–10 seconds to load on mobile, if not longer. That’s because the resources they need (or prefer to use) have to be sent along to the user’s browser along with whatever small amount of content they’re requesting. Then, it goes through a slow DOM process in the browser that has to make sense of it all.

And it really is a small amount: I sampled a random page from BuzzFeed (one of the launch partners of Facebook’s Instant Articles), and clocked it in at:

    • 4.5 MB total transferred
    • 7.11 seconds for DOMContentLoaded event
    • 10.66 for Load event
    • 15.22 seconds for final page load with activity completed

Speeds will vary easily from test to test, but my point is about the size any, and it’s a fairly good average representation. The total amount of actual content my request asked for? 730 kilobytes, and that includes all of the content’s images, which comprised the bulk of the weight. That means less than one-fifth of the page was what you actually came for.

There’s a reason we cache things aggressively and try to optimize heavily, but all those efforts are completely in vain if someone is doing a one-time load not from their usual desktop or mobile browser, but from the Facebook app on their phone. This app keeps its own cache, so users only benefit from your hard caching work inside the Facebook app if they visit your site on multiple occasions inside the Facebook app.

The rest of the data transferred above was mostly for plugins, libraries, and ad- and tracking tools and services. Some of that is (re)used by thousands upon thousands of other high-profile websites. But each of them may host some of it on their own servers or CDN, losing cross-site caching benefits.

Native platforms don’t suffer this problem. What tooling resources they get to use are either already included by the OS, or are bundled inside the app. They are also compiled, offering some additional benefits.

Now, I know what you’re thinking: “If websites could make use of a handful of defined and widely agreed-upon resources and utilities that were to come preloaded by the OS the way the Core and Cocoa frameworks are on iOS, would they then have a lot less data to transmit, unpack and process while the user is waiting to see some content?”

Okay, so maybe that’s more my own thinking. The answer, however, is a resounding indifference. Yes, no, sorta, not really.

(By the way, if you’re thinking the web is the only one suffering from slow, tedious user tracking libraries and frameworks, think again: those same or similar services are bundled into most iOS and Android apps today. They just come preloaded when you install the app.)

Having access to popular shared resources locally would save some time, but still be far cry from a real solution. A much bigger slice of the problem pie is that browser engines have to deal with a lot of shit. A lot of shit. Backwards compatibility going back decades is neither easy nor is it great for performance, but it is kind of intrinsically crucial to the Web as a platform. The first-ever web page should always work in something daring to call itself a web browser, as should everything in-between it and the present (poorly constructed or intentionally broken sites and pages notwithstanding).

Then, then, there is the problem of the publishing world and its ever-shrinking capacity to compete with the free resources available on the Web while still making enough advertising money to accommodate a print-based business as well. They have to keep users on the site at all costs, track them, lure them in for more, convert them, sell to them, gather information from them, and so forth.

That Facebook can do Instant Articles makes a lot of sense: for one, they don’t have to do all of those tasks via additional code and side-content on the page itself; they already have that information from you using their app to browse in the first place. This puts Facebook in a better position to advertise to you, and thus charge higher advertising rates, while at the same time freeing up a lot of valuable technical, design and extraneous content-related resources for the actual article or video you requested to shine in the palm of your hand.

Facebook doesn’t need to keep you on the site to browse for more content. It’s already got your eyes and information, it already knows what to sell to you and when. Online publishers, however, do not have these things, let alone have such control over them within a self-contained, somewhat walled-in environment exclusively theirs to operate.

They do have it with whatever native apps they may have created for you to download from the App Store or Google Play (or Microsoft’s Apps+Games). This is why those exist.

Websites don’t get to benefit from this kind of system level integration—and from a privacy perspective, you might exclaim an enthusiastic “thankfully!”, but with the right privacy controls, this wouldn’t actually be a bad thing to have. But, this is not currently the case.

(To be continued)

All that, and I haven’t even gotten started talking about my favorite topic yet: tools. We’ll go into that in Part 2.