Google’s new Accelerated Mobile Pages, aka AMP, makes websites load fast. Like, really fast. But that speed comes with a few changes to how the open web works.
AMP achieves its remarkable speeds in two ways. First, it requires web developers to use a narrow set of web technologies to create pages. Most JavaScript is forbidden, which, as we’ve noted before, is a really good way to make web pages load faster. Second, it serves pages from its servers, at least when you visit an AMP page via a Google search.
To use AMP, you create an alternate version of your site that conforms to the specifications published by the AMP project. These standards are a lot like traditional HTML but pared down to what Google considers to be the bare minimum. Typically you’ll give your AMP-optimized site a separate address, for example: yoursite.com/yourpage/amp. If you use WordPress, there’s actually a plugin will automatically create these alternate versions and help Google find them. But you could, theoretically, just replace your whole site with AMP optimized pages, and it would still work in most modern web browsers, though it might be a bit drab.
With its AMP search results, Google is amassing content on its servers and keeping readers on Google.
Sites that follow these specifications to the letter will receive special treatment from Google. AMP-optimized new stories now appear at the top of Google’s mobile search results. That sounds great for publishers who have decided to build AMP sites, but there’s a big catch: if readers decide to share a link to an AMP page they’ve clicked on through a Google search, the link points to Google.com (for example, google.com/amp/yoursite.com/yourpage/amp), not to your site. A Google spokesperson confirms that there isn’t a way to both have your AMP-optimized appear in Google’s prioritized search listings without having that content hosted on Google’s AMP Cache servers.
That’s a significant change in how the Google search engine works. Historically, Google has acted as an index that points people away from Google to other websites. With its AMP search results, Google is amassing content on its servers and keeping readers on Google.
In that sense, Google’s use of AMP is similar to Facebook’s Instant Articles service, to which it’s often compared. Facebook Instant Articles gives publishers the option of embedding their content on Facebook’s servers so that users can read an article without ever leaving the Facebook mobile app. Unlike Instant Articles, however, sites that follow the AMP standard can also be embedded on other sites as well. Twitter and Pinterest, for example, are expected to begin using AMP to embed pages on their sites or mobile apps in the near future.
But What About Ads?
Although JavaScript is mostly forbidden on AMP sites, there are some loopholes that allow publishers to include ads, analytics, and other pieces of JavaScript on a page.
AMP includes a special analytics tag that allows publishers to send data to pre-screened analytics providers such as Chartbeat, Adobe, and Parse.ly. This is handled by a single JavaScript file instead of a separate script for each analytics provider. That file is loaded from Google’s servers, which can speed things up considerably for pages that use multiple analytics providers. Ads work in a similar way. The AMP project vets analytics servers based on performance, security, and privacy, so some of the worst offenders may be screened out. But those who want to use analytics code or other pieces of JavaScript that haven’t been pre-approved can also use the <amp-iframeiframe> tag.
The <amp-iframeiframe> tag, similar to the traditional HTML version of the <iframe>, allows publishers to add chunks of JavaScript hosted on their own websites, but there are some restrictions. Code inserted into iFrames won’t have access to all the data that a script inserted directly into a traditional page does. AMP always loading the page’s core content before any <amp-iframeiframe> content in order to keep <amp-iframeiframe>s from slowing down pages. And when AMP pages are hosted on Google’s servers, the pages are pre-rendered, so that they still load quickly.
These workarounds enable more freedom for publishers, but it also means there’s still room for them to serve invasive scripts to readers. Improved performance won’t always mean improved privacy. It also means more of the web will be shaped by Google.
