Takeaways from the First Google AMP Conference

Accelerated Mobile Pages (AMP) is a project created by Google, designed to establish a performance baseline for the mobile web. AMP HTML is HTML with some restrictions for reliable performance; those restrictions incorporate coding best practices, restrict the size of CSS, and disallow all custom javascript. Instead of writing scripts, web developers can take advantage of a library of web components that are optimized for slow or unreliable network connections, resulting in fast loading pages and superior user experience.

This March, the AMP project held its first conference in New York City. It had a good mix of speakers — from publishers, eCommerce folks, UX designers, advertisers, and search engine representatives, to open web advocates. The entire conference was recorded and live streamed (Day 1, Day 2), so I’m going to summarize some main themes I heard over and over this week.

Restrictions led to simpler design and users liked it.

Natalia Baltazar from the Guardian talked about how simplifying their navigation lead to better brand recognition and awareness. With the old header some users didn’t even realize that the Guardian is a news site!

AMP’s value is political.

Most attendees agreed that non-amp sites can be just as fast, if not faster, as AMP sites. However, there are often many stakeholders and the developers are compelled to put non-performant code in production because the business people or the clients want something. With AMP, you can easily say “no, I can’t put more tracking scripts on this page” to your PM, your boss, or your client, shrug and point to Google. “Google says you can’t do it.” And that’s that.

In this scenario Google’s name and reputation is a crucial to your clients and/or boss acquiescing, and this leads me to the next major theme of the conference.

Open web advocates have some concerns.

As many attendees who work with or for publishers and content makers noted, clients want AMP for the wrong reasons. They don’t value AMP because faster load times are better for users, they want AMP because they want to be in Google search results Top News carousel. They want the “lightning bolt of approval” from Google. They also believe (falsely, according to Googlers) that being AMP-compliant will help their content appear at the top of search results. Google lending this project its name and leverage is what makes this particular web component library more popular than others.

One area of concern for publishers and people who advocate for open web — the idea that no content should be privileged — is Google cache. Right now in order to get “the lightning bolt of approval” that indicates valid AMP markup, the publishers must cache their content on AMP CDN. Another related problem is the way the AMP viewer is implemented in Google Search. When a user clicks on Top News carousel story, it opens in the Google AMP viewer, not the site of the content creator.

You can see some of this discussion here:

Cloudflare announced AMP Cache alternative.

Partnering with Google, Cloudflare can now offer an alternative to Google cache from which the content owners can serve AMP-validated content. Those pages will have the lightning bolt symbol and will be able to appear in the Top News carousel. They also offer the ability to build your own AMP viewer. And while this does not fully address concerns about AMP, it definitely is a step in the right direction.

PWAMP is all the rage.

Several people demoed a way to use Progressive Web Apps (PWA) and Accelerated Mobile Pages (AMP) in conjunction. PWA, first conceived of by Alex Russell, seeks to bring the web browsing experience closer to native app experience. Using something called Service Workers, developers can make use of push notifications, preloading, and smart caching of resources.

AMP to PWA.

While the user is on an AMP page, the developer can use <amp-install-serviceworker> tag in order to jump-start the process. Then, when the user visits the PWA, clicks on a story, the service worker has already pre-cached assets and the story appears to load instantaneously.

PWA to AMP

Another approach is to use PWA as an app shell to serve AMP content. Instead of making a JSON request and parsing the response, the PWA can request your AMP-valid HTML and serve that. This method takes advantage of both PWA’s versatility and AMP’s optimized performance, and can deliver a lighting-fast AND rich user experience.

Looking to the future.

AMP is still at an early stage of development. There is great potential here to make mobile browsing a less frustrating experience. While there are some concerns, Google is making good-faith efforts to address them. They’re partnering with other organizations to decentralize the governance of AMP project and bring fast mobile web to everyone. The people working on the project seem dedicated to the best principles of the web. If you’re interested in getting involved and contributing to the AMP project you can start here: https://www.ampproject.org/contribute/ or with this tutorial.

Celebrating International Women’s Day at AMP Conference