Rethinking AMP and Instant Articles: Signalling & Segmentation

Published on Author Eli Fennell

Accelerated Mobile Pages

2016 will be remembered, in part, as the year that the Mobile web (the world wide web as accessed through Mobile devices, especially smartphones) went ‘Instant’, with the debut of both Accelerated Mobile Pages (AMP), an open source project backed by Google, Twitter, and hundreds of partners, and Instant Articles, a competing project backed by Facebook and a somewhat overlapping group of publisher partners. Apple News has a similar initiative, as well, though it lacks a distinctive project name like the other two.

Each of these projects share the same goal: to boost the loading speeds of web pages to a nearly instantaneous experience when accessed from Mobile devices. Mobile users are especially sensitive to wait times, and mere fractions of a second (or mere megabytes) can make all the difference between whether these users will view your web content or tap away from it.

While site and page speed have always been a priority in web development (despite the fact that most web developers haven’t always prioritized it), the greater hardware power of Personal Computers, plus the speed of home and business internet connections used by Personal Computer users, and the traditional absence of data caps (or higher caps) for such connections, have masked this importance to some degree. In addition, Personal Computer users are generally somewhat more patient by habit than their Mobile counterparts when it comes to waiting for content to load.

Mobile devices have radically changed user expectations. Even when the Mobile hardware itself isn’t laughably weak compared with its PC counterparts, as is especially the case for low end Mobile devices, Mobile data connections are often slow and Mobile data caps often absurdly low (and the data fees themselves absurdly high).

Native Mobile apps typically load and run much more smoothly and efficiently than websites, and unlike on PC’s, the browser itself hasn’t emerged as the center of gravity of Mobile internet usage, so the difference is extremely noticeable even to the average user. And with users spending most of their time in apps rather than the browser itself, being frequently ‘thrown out’ of those apps and into the browser itself when tapping on web links feels disruptive to the User Experience.

One solution to the latter problem is to load and embed web pages directly inside of these non-browser Mobile apps themselves, via a ‘Web View’ or ‘Custom Tab’ that loads within the app itself. These, however, only solve the ‘App Transition’ problem, and do little by themselves to solve the problem of slow web content. In the end, the speed at which web content loads is heavily determined by the web developers themselves, who have traditionally shown a penchant for building very heavy websites that often underperform on weak hardware and data connections.

They usually justify this by asserting that much of it is a ‘Necessary Evil’, such as the inclusion of code and scripts from multiple analytic providers to measure site traffic, multiple ad providers to monetize site content, JavaScript to enable dynamic functions, etc… As there seems to be no way to break developers of this bad habit all-at-once, AMP and Instant Articles provide a transition: developers can keep their heavier, more dynamic sites in parallel with adopting these new standards. If the parent web page is an authentic Renaissance Masterpiece hanging in a museum, its associated AMP Page or Instant Article is a wallet sized print of it to carry around and admire ‘On The Go’, each with its own intended purpose and audience.

The stick to that carrot is the likely loss of traffic to your site from Mobile users of Facebook, Google, Twitter and other online service providers who adopt these standards if you fail to adopt them for your own web content. Given that speed is basically the entire point of these projects, and that it is eminently possible to build a normal website that loads as quickly or nearly as quickly as these standards make possible, we might rightly ask why these standards should even exist in the first place, rather than just using the same pressure (i.e. reduced ranking and discoverability of slow web content) to encourage site owners to build a single, responsive, fast-loading version of their website?

One reason for the parallel standards, instead of pushing for a single ‘Universal’ standard for all sites and pages, is purely technological: these new standards are built from the ground-up to be fast and to forbid by their very limitations anything that would significantly slow them down, e.g. AMP supports only a very limited subset of JavaScript, a limited Analytics function, etc… A full web site is much more powerful in terms of the features and capabilities it makes possible, but this can be abused and misused at least as easily as it can be a boon for developers.

These standards also allow service providers (e.g. Facebook, Twitter, Google) to keep a cache of the AMP version of third-party content on their own servers, which are often faster and more reliable than the originating host servers. Instant Articles are exclusively hosted by Facebook’s servers, whereas AMP articles can be cached by participating third-parties like Google and Twitter as well as the originating servers themselves (i.e. you can also cache and display AMP versions of your content from your own servers).

Whereas a normal web page can theoretically be lightning fast, but in practice can easily be much slower for reasons already elaborated, AMP and Instant Articles are designed to prevent the sort of bloat, or differences in server speed and reliability, that often slow web browsing to a crawl. The very fact that a web page is coded as an Instant Article or in AMP HTML (or the Apple News version of the standard, or any other present or future versions of this concept) is itself a ‘signal’ to service providers and users alike of a fast loading time, without any need to crawl the site to confirm this. Otherwise, the Googles and Facebooks of the web would need to somehow crawl every page the user might load, to determine its loading speed in advance, and then apply that as some type of ranking factor.

Some already do this to a degree, e.g. Google does in fact take your site speed and page speed factors into account in their Search rankings, but short of the ability to constantly crawl all of this content in real time (which even the largest online service providers can’t do, if for no other reason than that excessive site crawling in itself drags down site performance), their confidence in these rankings could never be sufficient to promise ‘Instant’ load times.

Suppose, for example, a site or page loaded instantly yesterday when it was last crawled by the service provider, but by the next day was updated in some way that added significant bloat, or suppose that the parent servers where the content is hosted went down or were slowed down substantially by something like a Dedicated Denial of Service (DDoS) attack. Such factors must be considered when making promises of instant loading times for web content.

As Signalling Theory predicts, in order to promote instant load times as a feature there must be a credible ‘signal’ sent by an agent to another party or principal, in this case taking the form of a standard built specifically for this purpose, one which by design almost can’t fail to deliver on that promise and which signals online service providers and others that its content can be instantly loaded by the user. That way, when they see the Lightning Bolt icon (or whatever else might be used to indicate these standards) in their Facebook app or their Google News app, they can know that it will almost certainly load very quickly once they tap on that link, regardless of any updates or server-side issues or other such concerns or even whether they’re using a cheap phone on an archaic data connection.

There is another reason, however, for these standards to exist parallel with the typical web browsing experience we’ve become accustomed to as both users and developers: contextual differences in user expectations. Mobile users are much more likely to be accessing and consuming web content in an ‘On The Go’ state of mind: they see a link in (for example) their Facebook News Feed in the Mobile app, and they expect to quickly be able to glance at its contents and read through it right away, and then return to that News Feed, in a smooth and seamless process, rather than being thrown out of the app into a browser, then waiting several seconds or longer for a page to load, only to then have to return to the Facebook app (which itself can be a disruptive transition) just to return to where they started.

While Mobile users may be accessing and consuming web content, they aren’t ‘browsing the web’ in the traditional sense of the term as it has usually been understood. Web content is often regarded by users as a mere chunk, a bite-sized unit, of the overall experience of using a Mobile app, and one best received when it loads as quickly as possible and without disrupting that experience. Mobile Operating Systems were built with the internet as a 1st Class Citizen from Day 1, unlike PC Operating Systems in which the web snuck in via the browser like a stowaway.

This is why instant Mobile formats also serve as a means of Audience Segmentation, the process of dividing an audience into subgroups: the needs of some users are being recognized as different than other users, even when accessing the selfsame web content. In this regard, it is worth noting that AMP Pages and Instant Articles both function as ‘static’ copies of a given web page’s most vital informational content, especially text and static images, embedded within the User Experience of the Mobile apps themselves.

At their root, these standards are about transforming the consumption of static web content within Mobile apps into something less like using a web browser and instead more akin to the experience of opening and reading an eBook from within an eBook Reader or eBook Reader app: a fast, smooth, and clean experience of loading static content for immediate consumption, and then returning when they’re done with that content to their original starting place (the Digital ‘Bookshelf’, the Facebook News Feed, the Google Search Results Page, etc…).

This can also be compared with the ‘Reader Mode’ of some web browsers, which converts web pages into a more stripped-down experience revolving around the site’s static content (text and images), but which doesn’t work nearly as well for dynamic web experiences or web apps. Instant Mobile formats deliver the user directly to a sort-of ‘Reader Mode’ version your content in contexts where this makes the most sense.

It is therefore no coincidence that the most supportive early partners of these projects, apart from the service providers and app developers themselves who benefit by being able to promise instant loading speeds, are online publishers of primarily written content (and static visual content, to a lesser degree).

For an eCommerce platform, by comparison, the limitations of AMP or Instant Articles may present insurmountable obstacles, next to which it would likely be much more rewarding just to improve the speed of their existing sites, or to build their own native apps. Likewise a video platform like YouTube is so inherently dynamic, and by nature its content is so much ‘heavier’ than static textual and visual content, that although Mobile users may be no less annoyed by slow-loading, it is a problem which requires very different solutions.

AMP and Instant Articles have a clear and narrow purpose: to load static web content instantly for immediate, and generally brief, consumption. They are the answer to the fundamental mistake web publishers have been making for years: they’ve been so preoccupied with whether or not they could do certain things that they didn’t often stop to think if they always should. They could micro analyze every visit and visitor to their website by installing multiple analytic providers, make more money on each ad by installing multiple ad providers, make their site more dynamic with plugins and other tools and scripts, so they didn’t stop to think if they should do those things, and even if they did, it wasn’t easy to determine when and where their visitors would benefit more from a simplified approach.

None of this is to say that ‘instant’ Mobile pages are the end-all, be-all solution for everything the Mobile web needs to survive and thrive in the coming years, or that traditional websites will be ‘going away’ entirely in favor of these new standards. There are many legitimate reasons for building out ‘heavier’ and more ‘dynamic’ websites and web apps (though no excuse, in any event, for a site to take more than a few seconds to load on almost any device or connection, unless it is in the business of providing an especially demanding service like a MassIve Multiplayer Online Game), and this has been part of the problem in itself: sometimes your site users actually need that extra ‘bloat’ that makes the difference between a dynamic web experience and a piece of static web content, and in these cases it also benefits the publisher not to settle for less, but they haven’t always been able to determine when one approach makes more sense than the other.

There is, in other words, a difference between someone using the Flipkart Mobile web app to price a new smartphone (a highly dynamic web process well beyond the current purview of these new standards), and someone casually tapping a link to a news article (a largely static piece of content) someone has shared to their favorite social media app. For that matter, there is a difference between a New York Times subscriber who actually visits the NYT website each day in the browser itself in the same way they might pick up a daily copy of the newspaper, and a non subscriber who taps on an NYT article link while using Twitter on their phone during their coffee break.

Understanding this need for site content to be adapted to specific types of applications and audiences on specific devices and in specific contexts should help to clear up the very air of controversy surrounding these new standards: that while they might be good for Facebook or Google or Apple and their users, their lack of support for all the bells and whistles of a traditional website is considered likely to be harmful to the sites themselves, denying them comprehensive analytics, ad support, support for certain plugins and extensions (e.g. many WordPress extensions), etc…

The fundamental error in that argument is that it implicitly treats all types of online users in all types of browsing contexts as having the same needs, expectations, and habits when accessing the same web content. From that perspective, a ‘stripped down’ site or page standard for instant loading might be seen as akin to airing a TV commercial at the lowest image resolution of any television still in use on the market, a preposterous example of appealing to a ‘lowest common denominator’.

If that were true, then the objections to these new standards might hold up, but in reality it isn’t like that at all: it is more like developing a consistent advertising strategy for multiple mediums such as Television, Radio, and Local Newspaper. The first will be highly visually dynamic, while the second will be acoustically dynamic, and the third will be static, and the viewers, listeners, and readers of each of these mediums wouldn’t expect it to be any other way. Each of these ads may simply be a different ‘version’ of some original advertising ‘copy’, but each will play both to the strengths of the medium and to the associated needs, expectations, and habits of their different audiences.

While many web developers are in love with their bells and whistles and are being hard pressed to give any of them up for the greater good of all web users, there are a growing number of online applications whose users will benefit more from the instant and non-disruptive loading of static content for quick consumption, of the very type promoted by AMP and Instant Articles. It isn’t a question of ‘competing’ with the traditional browsing experience or of traditional websites, but of adapting it for new contexts, experiences, and channels.