Requests for comment/Accelerated Mobile Pages

Request for comment (RFC)
Accelerated Mobile Pages
Component	General
Creation date	21 January 2016
Author(s)	Ori Livneh
Document status	declined See Phabricator.

Tracked in Phabricator
Task T124243

This is a request for comments regarding Accelerated Mobile Pages.

Background

Google's Accelerated Mobile Pages (AMP) initiative seeks to improve the performance of the mobile web by creating an efficient standard format for web content. The standard comprises a small library of custom HTML templates and tags, as well JavaScript code for fetching and rendering this HTML and the assets it references (images, fonts, etc.).

Google is giving publishers two reasons to adopt this format:

it has been carefully designed by their engineers to load quickly on mobile devices and connections, and is likely to outperform most existing mobile web sites; and
Google is offering to cache AMP content and serve it using their CDN, which is fast and has good geographical distribution.

AMP is designed to fit the business model of for-profit publishers: the specification provides means for for publishers to put up paywalls, deliver advertising, and collect analytic data, even when the content is served from Google's CDN.

It is not entirely clear how AMP will influence search engine result pages (SERPs). Most people seem to think that Google intends to raise AMP content to the top of SERPs and push everything else down. Google may also provide some visual indication that non-AMP pages are liable to be slow on mobile connections. AMP is expected to debut on Google SERPs in late February 2016.

Google has not explicitly threatened publishers with the prospect of declining traffic due to fewer search engine referrals, but external commentators seem to agree that these are the stakes. Googlers have reached out to the Wikimedia Foundation to evangelize AMP, gauge our interest, and answer any questions we may have.

Open questions

Should we adopt AMP?
- If "yes": how should we resource and prioritize the work that would be needed?
- If "no": do we have any feedback to give Google?
What voice (if any) does Wikimedia want to have in the ongoing design and standardization process for AMP?

Advantages

Faster pages!
Potentially a good fit for Wikipedia Zero
Google has a lot of servers and would be a good content delivery network

Disadvantages

Major privacy concerns
- Current spec requires that AMP-compliant pages "contain a <script async src="https://cdn.ampproject.org/v0.js"></script> tag inside their head tag"
- AMP spec as written is incompatible with wmf:Privacy policy
Standard is unappealing
AMP does not allow author-written JavaScript
Negligible performance advantages
Google's for-profit ad-driven model is philosophically incompatible with Wikimedia's values and motives
Large wiki farms such as Wikia and the Wikimedia wikis already have decent content delivery networks
Large wiki farms such as Wikia and the Wikimedia wikis already have great placement in search results pages

Potential conclusions

A heading

Instead of focusing on supporting AMP, Wikimedia should pursue a view layer abstraction that allows easily transitioning content from high bandwidth, large screen richness to high latency, small form factor usability. This, of course, requires us to solve a wide variety of difficult problems rather than implementing a short-term solution of HTML munging and style stripping.