Requests for comment/Accelerated Mobile Pages
| Accelerated Mobile Pages | |
|---|---|
| Component | General |
| Creation date | |
| Author(s) | Ori Livneh |
| Document status | declined See Phabricator. |
This is a request for comments regarding Accelerated Mobile Pages.
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:
- 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
[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
- Current spec requires that AMP-compliant pages "contain a
- 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.