In AMP we trust

Jeremy breaks AMP down into its constituent parts so that we have a better understanding around the pros and cons of Google’s approach.

This article stems from a recent conference focussed entirely upon AMP where Jeremy took place as a panellist along with Sarah Saltrick Meyer, Nicole Sullivan, Mike Adler, Gina Trapani, and host Paul Bakaus. The panel was great because they all had questions/concerns around the approach Google was using for AMP.

This article looks at the breakdown of AMP into three areas and what each of them mean and poses a very good question around whether Google should allow us to host both the Script and AMP cache location and include sites in good faith into the top carousel area of results, penalising those that abuse the privilege in the same way that your place in Google Search results are penalised if you’re found to be cheating.

When we talk about AMP, we could be talking about one of three things:

1. The AMP format. A bunch of web components. For instance, instead of using an img element on an AMP page, you use an amp-img element instead.
2. The AMP rules. There’s one JavaScript file, hosted on Google’s servers, that turns those web components from spans into working elements. No other JavaScript is allowed. All your styles must be in a style element instead of an external file, and there’s a limit on what you can do with those styles.
3. The AMP cache. The source of most confusion—and even downright enmity—this is what’s behind the fact that when you launch an AMP result from Google search, you don’t go to another website. You see Google’s cached copy of the page instead of the original.

An excerpt from In AMP we trust

View original article