To achieve its performance, the AMP team have made design decisions that have resulted in aspects of AMP that seem incompatible with a distributed and open web. The most contentious of these are outlined as follows:
- The AMP cache is owned and run by Google: With the performance optimizations of AMP-HTML and AMP-JS you get fast web pages. Add pre-rendering and you get instant-loading pages. But pages are only pre-rendered when they are served from the Google controlled AMP Cache. And you only get the AMP lightning badge if your pages are pre-rendered via the cache.
So this leads to an uncomfortable situation, where you only get the benefits if you agree to have your pages hosted and served from Google's servers. The URL of the cached page is not the original URL, but instead it's served from a Google domain, for example:
https://www.google.com/amp/theampbook.com
instead of
https://theampbook.com
This is somewhat misleading for the user: it looks like you are on one site, but really you are still on Google's servers. Additionally for publishers, using a Google URL dilutes their brand.
- Preferential treatment of AMP pages in search results: Google gives special treatment to AMP pages in its search results:
- AMP pages are annotated with the AMP lightning badge and the text "AMP", to indicate that they are fast. However, fast pages that don't use AMP don't get the lightning badge. Some argue here that Google is taking advantage of its dominant position in search to push its own technology.
- Only AMP pages can be promoted to the AMP carousel. Given its prominent position on the results page, this offers a clear SEO advantage to AMP pages over alternatives. If you are competing for positioning, then you can't afford to be outside the AMP tent. Again, it can be argued that Google is giving preferential treatment to its own technology.
- Centrally hosted JavaScript: Every AMP page must include the AMP-JS library from a central location by including this line:
<script async src="https://cdn.ampproject.org/v0.js"></script>
You are not allowed to download the library and host it yourself. This means there is a central point of failure: if the library is unavailable, broken or hacked, then every AMP site will have problems.
While these are valid concerns, they have all been robustly defended by the AMP team. Take the AMP cache. According to the AMP team, the pre-render can only happen when a page is served directly from the AMP Cache, and not from the original URL. This is because Google knows that pages in the AMP Cache conform to the AMP specification, so it can guarantee that it can be efficiently pre-rendered in the background. It cannot make this guarantee about pages not served from the cache.
Likewise, the annotation of AMP pages in the search results. In the same way that it's good practice to annotate a download link with its type and size (for example download [pdf 5 MB]), isn't it acceptable to prime a user's expectation that a link will be fast and from the AMP Cache?
