Google AMP conf - Summary

Last week I attended AMP conference by Google in NY. In addition to the sessions I attended, I also got a chance to discuss AMP in particular and mobile performance in general with the AMP dev team and with many users of the technology.

AMP is here to stay. Although it’s definitely not the only way to achieve high-performing mobile experience and it followed similar technologies by content mongers (Apple News, Facebook Instant Articles), with AMP Google took a different approach which I find appealing.

Google is saying to publishers - we’re going to be the bad guys, we’re going to threaten with a stick and set very strict standards and you must comply if you want to get the carrot - get the lightning bolt icon and have an opportunity to be featured in the news carousel. Google keeps saying that AMP does not boost page ranking, but that’s not entirely true. It may not have a direct effect on ranking, but by this time, the lightning bolt icon have had become a standard for users - a guarantee that the page will load in an instant - and something that draws users to click. I predict that as a result, pages without this icon will soon become obsolete and will lose ranking due to lower traffic volumes.

Another way Google is trying to improve AMP is by building a community of contributors to create more and more components. As of today, there are tens of components that are mainly intended for media and social. Google is also managing this entire project, like other projects, very openly, by sharing their roadmap, inviting contributors to participate in design review meetings, submit fixes and tickets. This demonstrates, in my mind, their attempt to become an industry standard. This is an opportunity for us to see if we can push something that interests us.

The most controversial part of AMP architecture is the cache. Google caches the AMP pages and serves them from there and not from the publisher’s site. While it can represent an additional performance boost, most publishers aren’t happy with it due to lack of control, losing track of users, etc. There’s also a more philosophical question of who owns the data, but working for a platform, this isn’t my main concern.. While Google is working on improving all that by providing ways for the publisher to track users and performance in the AMP version as well, the important saying regarding the cache, in my mind, was that Google preloads the AMP sites that appear on search result pages. This is why they must use cache, to maintain user privacy - otherwise the publisher might have gotten a visit (+user info) without the user ever accessing their website, which is bad. For this reason I respect the use of AMP cache and the different means to overcome the current shortcomings it presents.