Requests for comment/Accelerated Mobile Pages

This is a request for comments regarding Accelerated Mobile Pages.

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

Background edit

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 edit

  • 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 edit

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

Disadvantages edit

  • 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 edit

A heading edit

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.

See Also edit

Amp can be enabled by using the Amp extension. This extension would likely never be installed on Wikimedia wikis.