AMP is growing in importance in the web publishing world. This post describes a method for exposing AMP pages to all site visitors using DeviceAtlas so that all mobile visitors to your site get to benefit, not just those referred by Google.

First introduced in October 2015, Google’s AMP project is now solidly on the way to becoming mainstream—you can see a list of sites that have adopted the technology here. To recap briefly, AMP is a project with the aim of speeding up the load time of web pages, particularly for mobile devices.

 

AMP works by restricting the use of standard HTML tags, instead offering a broadly comparable set of custom tags with strongly restricted behaviours. This approach, combined with optional use of a CDN, is designed to remove most of the main obstacles to high-performance websites. While AMP is spearheaded by Google it is technically an open source project. In summary, AMP guarantees some basic page behaviours though it does not prevent the web designer from simply designing in too many things. 

 

Does AMP work? Yes, very much so. In our informal testing AMP versions of pages often loaded ten times faster than the non-AMP versions. The difference that this makes to casual web browsing is transformational—the friction associated with a click is almost entirely removed, making it much quicker to speculatively visit a page. Until recently, Google has limited AMP exposure to a carousel of links in news searches but recently announced that AMP links would be surfaced in all searches. In fact this change has already taken place for some people. 

 

 

 

So how does all of this relate to DeviceAtlas? Well, right now the only way that AMP pages are served to site visitors is if they are referred to a site by a Google search. Pages that have AMP versions are advertised through a link in the page header:

 

<link rel="amphtml" href=“/path/to/amp/page”>

 

This header lets web crawlers (or any site visitor for that matter) know that there is a page corresponding to the current page, but built with AMP. Once the Google crawler knows about this relationship it can serve up the AMP link rather than the plain HTML link to mobile device users. These links are marked with an AMP label and a lightning bolt icon so that users have a sense that they should load quickly.

 

So, all well and good for Google users. But what about people that visit your site directly, or use any of the other search engines, none of which support AMP? Shouldn’t these people get the benefits of your speedy AMP pages also? Study after study says that website load speed is critically important so why not serve your fastest content to all mobile visitors? That’s where DeviceAtlas comes in.

With a very simple rule you can use device detection to reliably tell you if a visitor is holding a mobile device or not. If so, you can then elect to serve them the AMP version of the requested page. Yes, this could be done with client-side JavaScript but then you lose all of the lightness and speed advantages of AMP since the browser has to load a page before this logic can even run.

 

The best way to go about doing this with DeviceAtlas depends on how your web publishing system is set up. DeviceAtlas can be placed within the code of your application with a language-specific API (e.g. JavaScript, PHP or Java) or within your web server infrastructure using our web server modules for Apach, NGINX and IIS. Alternatively, this switching logic could reside in your load balancer layer with our HAProxy module, or in the web cache layer with our Varnish module. 

 

Regardless of the most appropriate implementation, the single DeviceAtlas property mobileDevice can be used to trigger the logic to switch templates or serve a different URL entirely. For specific details on how to use each version of the product please refer to the Resources section of our site where you will find API documentation and code samples.