Requests for comment/Accelerated Mobile Pages

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:
 * 1) 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
 * 2) 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  tag inside their head tag"
 * AMP spec as written is incompatible with 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

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.