Over the last few years, Google has published their findings regarding two major trends:

  1. That the quantity and percentage of searches being performed from mobile devices continues to increase and has now exceeded searches from desktop
  2. That people are increasingly beginning their journey for answers, micro-moments, from a search query performed on their mobile device

Google has applied a focus on these two trends under their overall goal to use their search product to give users a high-quality experience. Quality in this case is primarily defined as fast and informative. This has led Google to two major initiatives: the first has been the internal development of a mobile index for search ranking, the second has been the embrace of Accelerated Mobile Pages (AMP).

 AMP is a return to the holistic model of delivering content specific for the mobile device form factor. It is a direct result of the current mobile-design method of responsive design leaking page bloat from the desktop to mobile. AMP utilizes previous methods for delivering mobile content with similar pros and cons of those approaches have had in the past. It creates a new twist for developers as it is the first time since mobile devices became a development concern that the environment has become more restrictive.

Mobile Speed Matters, therefore AMP

The lightning bolt icon in the results denotes an AMP page

Accelerated Mobile Pages (AMP) is a Google initiative to create a faster mobile-first content viewing experience. It is a set of restricted HTML and custom markup elements coupled to a browser based environment delivered via a global cache network. These all combine to support a focus on increasing the perceived speed of which a web page loads for mobile users.

Fundamentally AMP is built around the concept that mobile speed matters: over half of mobile users will abandon a web page taking greater than three seconds to load. Everything about the AMP specification exists to reduce the perceived speed with which a website page on mobile takes to load. The current favored web development technique for addressing the mobile device, responsive design, takes into account the mobile form factor, but not specifically the total impact of page content on delivery speed. AMP forces mobile pages to focus on both display and delivery speed. Adhering to the AMP specification for a page guarantees the page not only displays itself in a way that is compatible with the mobile device form factor but also in a way that is compatible with the other expectations of the mobile user as decided by Google’s research teams.

These other expectations of the user include reduced perceived load time for a page: the three second rule. This is a notable distinction between the actual load time of all components of a page and the perceived load time to the user. The techniques used by AMP seek to load as much of the vital and viewable content as quickly as possible. It will defer anything not directly related to the display of sought information. This includes common items such as images, advertisements, tracking pixels and below-the-fold content: items you generally find useful as a content owner. It also restricts the ability of the browser to re-render the page, requiring all content used to be structured as such to be renderable in the initial load.

AMP is held up by three legs:

  • a markup specification,
  • a browser-compatible runtime environment and
  • a global content delivery network (CDN)

This is in contrast to the responsive design model which handles details of the mobile implementation almost exclusively at the display (style) level using standard HTML. The AMP model borrows from previous methods of mobile site implementation to utilize more aspects of web page delivery and display environment to create a better user experience.

It is important to look at the history of mobile web solutions to gain an understanding of how AMP emerged as the current alternative. Because AMP utilizes a combination of these techniques, we are able to use our previous experience developing with these technologies to help identify if AMP is the right mobile solution for you.

The Progression to AMP

In some ways AMP is a throwback to mobile content in the first days of a “mobile web”. There has been a history of standards (some de facto) for delivering information via the web to mobile devices. As device capabilities grew and network bandwidth followed the approach became less holistic and focused more on the display level only, modifying the visuals based on screen size.

Eighteen years ago (~1999) we were building mobile sites using technologies like HDML and WAP in the emergent days of more-than-just-a-phone mobile devices. I was fortunate enough at the time to represent my company at the time at the WAP Forum technical meetings. WAP became functionally obsolete rapidly as phones became more capable and began running modern web browsers. Techniques then shifted to things like dedicated mobile sites (http://m yourdomain.com) and eventually responsive web design. The AMP specification merges aspects of the former approaches to address issues in the latest.

WAP

WAP (including WML: Wireless Markup Language, and its predecessor HDML) were developed in the early attempts to allow websites to deliver content to mobile phones with rudimentary processing capability, bandwidth, input and display. This was before phones had touch screens or web browsers – commands were all via abbreviated physical keypad and input buttons. The specifications, while similar to HTML, had to be unique to the environments in which they were expected to operate. The eventual markup standard (WML) was made to be familiar to web developers, but had constructs that would map better to things like phone menus and limited input. The client environment generally had no capacity to display images so only text was functional. The markup was created to allow limited capability devices to receive and display information without the burden put on wired browsers.

It is difficult for modern developers to emphasize with the restrictions present in mobile devices at the time – limited specific markup targeted for the WAP browser available on the device. AMP does much the same, it restricts HTML to a subset and adds its own markup components to address specific needs in the mobile environment. Much like WML did for WAP, the AMP markup is both constrained and targeted to achieve maximum performance in a limited environment. Unlike WAP, current devices are much more powerful. Both WAP and AMP specify custom browser environments to interpret the markup. Bringing forward the concept of restrictive custom markup and custom interpretive environments in a more powerful device his translates directly to an increase in perceived page loading speed.

WAP was also notable for operating gateway servers between the web servers and the mobile devices. This gateway would provide for translation of HTML to the WML markup where possible and provide compression for delivery. This approach to delivering mobile-specific content encompassed multiple aspects of the platform delivery into a unified protocol. AMP likewise uses browser enhancements and provides for a global cache network to deliver results faster much as the WAP protocol did with its gateways. This is part of what we call the holistic method AMP takes to address the speed problem. Like WAP it also takes the browser and network into account and offers solutions in these spaces as well. WAP had to do this because the wireless networks at the time were so limited, AMP does it to provide the speed boost.

Parallel Site

Once phones had more capable screens and better networking, they started using more-or-less lighter versions of the standard web browsers to view sites. Their issue was still centered around device constraints, sites built for a high bandwidth desktop browser would look awkward on a small screen and load slowly. The result was often a parallel site solution: one you can still see in use today. It is a separate site developed to meet the needs of a small form factor device. There is no standard to how these sites are developed, you may usually notice them functioning via a separate but similar domain (http://m.youtube.com). They would use regular HTML and leave it up to the site developers to decide what the proper subset of markup, content and technologies were to be used for display. Resource heavy content is usually omitted because the devices targeted could not be relied upon to display them capably.

Responsive Design

After CSS Media Queries became implemented in browsers websites began to consolidate to a single unified site. They used this new ability to detect and adapt the visual display of the site to enable, disable or otherwise adjust aspects of the website based on end user display capabilities. This allowed a single site to be developed that could serve mobile and desktop users, a more effective and generally simpler solution to develop and maintain.

Why is AMP on the rise?

Over time the desktop experience became richer and the underlying delivery size of the desktop sites as gotten larger. The responsive design model allows for the visual reduction in content, however, without careful implementation the overall delivery size of those sites may still be taxing for mobile devices. By using one underlying website for all platforms bloat from the desktop design has been allowed to leak into the mobile experience: unused CSS files, JavaScript, etc. While phones have become much more capable they generally still do not have the bandwidth or processing power to handle the same amounts of content as delivered to the desktop. This results in slower site loading and a reduced user experience.

AMP utilizes aspects of the WAP protocol to address the shortcomings of the responsive design model. It uses a narrow and unique set of markup components, a modified runtime environment and even the special server network. Because of the unique markup requirements parallel site solutions will once again be used to deliver this content. Removing much of the desktop bloat immediately. In the drive to deliver the sub-three second user experience the Google AMP Project has returned to the more holistic approach seen in different approaches used pre-responsive design. What was old is new again.

Why AMP your project

Hopefully you can see now that AMP, while a new specification, is not exactly breaking new ground in how mobile sites are delivered. Rather it has cherry-picked elements from previous approaches to address the deficiencies in the casual application of responsive design. The techniques used to deliver information to limited devices in the past out of necessity are being used now to deliver content with speed. The experienced mobile developer is able to recall the limitations of these approaches from the past and make informed decisions in taking the AMP approach.

Google Driven

Within Google Search Console you can monitor your site’s performance for AMP results separate from all other results

Something none of the other approaches had in their favor was the absolute juggernaut of a business like Google in their corner. While Google has been clear that AMP (for now) does not increase a site’s rank, implementing it increases mobile page speed by a large factor and page speed does matter. Likewise, AMP content gets preferred placement in mobile search so the intended effect of a rank boost is present.

Fundamentally, if you have a site that churns a lot of content and wants to increase rank, AMP is the way to go. Google wants it to succeed: if it is good for the end user experience it is good for your rank and AMP is very good for the mobile end user experience. Mobile search is only increasing, if all AMP does is have an impact on your mobile search presence it is probably worth implementing.

Google likes it, Google wants it, Google is promoting it; if you care about your presence on the Google search results you should be implementing AMP.

Difficulties with AMP

Unfortunately your pain points with AMP are a familiar combination of all the pain points from the previous approaches to mobile site delivery.

Parallel Site

Responsive design is fantastic from a development standpoint because you have a single website. This allows you to deliver all your web information using a standard set of tools, developers and servers. That saves you money in the long run and is a much simpler approach. This is why responsive design emerged as the One True Way to do mobile development in the recent past.

AMP would require you use its specific markup throughout your website and you will rediscover the reason all those “http://m.” sites existed. Even Google currently maintains one for YouTube. Trying to thread a limited and unique set of markup within your standard site does not scale past simple examples. Eventually you will have to develop a separate site for delivering the AMP content. When you marry the unique markup restrictions against the markup in a modern website you will find trying to merge the two unsustainable.

Your AMP site will end up mirroring the parallel site solution we have seen before. Having multiple sites to deliver the same information uses more technical resources to create and maintain. Changes that impact your website globally must also be implemented on your AMP site. Maintaining more than one site is a known difficulty, while it ends up being better for your end users, the increase in resources is not as great for your bottom line.

User Experience > $

AMP puts a priority on page loading speed, to accomplish this it defers non-essential elements of the page loadout. One of the deferred elements is advertisements. Site load prioritizes information users find necessary, and what the users do not find necessary is usually the stuff that makes you money. There is not much you can do about this, ads will load, but not first, and they will have to fit in the AMP specification. Same with things like analytics and tracking pixels.

Content Restrictions

If your content assumed it was operating in a normal browser environment AMP is going to be a difficult transition. The specification disallows a lot of content that has sneaked into your markup over the past few years (iframes, embeds, JavaScript, etc…). The specification is exact, if you have content that is not allowed in AMP you will fail validation, if you fail to validate the Google services built around AMP will not work for your page. This will end up being AMP’s biggest pain point: it is the first time mobile development will have to move from an increasingly liberal environment back to a restricted and validated environment. Up to now, mobile development has always become more permissive with markup and content: WML -> parallel mobile site -> responsive design. As the devices and environments allowed for more capability developers have taken advantage. If something did not work on a page the entire page was not a failure. AMP is a step backwards in this respect, to achieve speed gains it will strip capability. A validations process will ensure this has occurred. Therefore AMP will be difficult to implement if your site’s embedded markup has grown with the permissiveness of time.

The Conclusion: Figure out how to make it work for you

The end result is that AMP looks to have traction.

Mobile development has always progressed from lesser to more permissive environments. AMP represents the first time the development of mobile site pages has become more restrictive by design. This could lead to development challenges should elements of your content exceed the capabilities allowed by AMP.

Based on past approaches to mobile site development, any new established standard should stand for a few years. However, it is the support of Google that gives the system value. If Google ever abandons their preference for AMP the specification will be dead. Until that happens, and as long as it has the weight of Google behind it, it is probably worth the known difficulties to build out an AMP specific website so long as you are able to contain your goal conversions and primary calls to action.