Book Image

AMP: Building Accelerated Mobile Pages

By : Ruadhan O'Donoghue
Book Image

AMP: Building Accelerated Mobile Pages

By: Ruadhan O'Donoghue

Overview of this book

Google introduced the Accelerated Mobile Pages (AMP) project to give mobile users lightning-fast response times when accessing web pages on mobile devices. AMP delivers great user experiences by providing a framework for optimizing web pages that otherwise would take much longer to load on a mobile platform. This book shows how to solve page performance issues using the mobile web technologies available today. You will learn how to build instant-loading web pages, and have them featured more prominently on Google searches. If you want your website to succeed on mobile, if you care about SEO, and if you want to stay competitive, then this book is for you! You will go on a mobile web development journey that demonstrates with concrete examples how to build lightning-fast pages that will keep your visitors on-site and happy. This journey begins by showing how to build a simple blog article-style web page using AMP. As new concepts are introduced this page is gradually refined until you will have the skills and confidence to build a variety of rich and interactive mobile web pages. These will include e-commerce product pages, interactive forms and menus, maps and commenting systems, and even Progressive Web Apps.
Table of Contents (24 chapters)
Title Page
About the Author
About the Reviewer
Customer Feedback
Actions and Events
amp-bind Permitted Attribute Bindings

Controversy and criticisms of AMP

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: instead of 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=""></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?