Google has long been on a mission to speed up and clean up the mobile web by prioritizing pages with responsive design in search results, creating tools to extensively test your page’s mobile friendliness, doing cutting edge research on optimizing caching and page loads, and (for the most part) leading by example. Now, Google has jumped into the fray with a far more active approach: introducing their own special version of HTML called The Accelerated Mobile Pages (AMP) Project. This new flavor of HTML from google is optimized from the ground up to deliver blazing fast mobile-first pages. Their stated goal in this is to realize the vision “that publishers can create mobile optimized content once and have it load instantly everywhere.” There are a lot of things that are interesting about Google’s chosen implementation of what essentially amounts to their stab at “the world’s fastest mobile page system.” Here I will break the differences down for clients of great web design and then the developers that make it happen.

What Clients Need to Know:

Google’s AMP project offers the single fastest way to deliver a mobile page to a user, for most simple static (not WebApp) applications. To understand why this works, there are a lot of technical steps along the way. To make a long story short, developing AMP pages requires your developers to do more with far less lines of code, to optimize images in more sizes beforehand, and possibly to work with Google’s servers for content delivery instead of your own. If this sounds like more hours of development time, the answer is most likely. AMP pages achieve their speed through small size, which means concise code and more editing time. However, it is fair to expect Google to reward that extra effort with special treatment in search results (there is even a special “AMP” icon that is appended to your result).

It is worth noting that there are AMP themes for wordpress already easily available. This represents the easiest way to transition your website to AMP, if you are already on a wordpress deployment and don’t mind losing the flexibility in styling.

The biggest sacrifice in choosing AMP is not the increase in the time it takes for pages to be developed, however. The protocols for creating AMP pages limit the amount and type of style that can be applied to a website as well as cutting the possibilities for on-page interactive content, at least for now. Before you get too nervous, however, there is a high level of support for many common embeds: instagram, facebook, pinterest—even vine, vimeo and soundcloud get specially optimized embed methods from google to include those site’s content in your AMP pages. Over time, we can expect to see this community of AMP-ready content grow quite a bit and even for now, there are ways to include any custom content with the right workarounds from your developers.

Due to AMP’s interactive nature, it is probably not time to start building your entire website out of AMP HTML. It is, however, an excellent idea to start building AMP versions of pages on your website that are geared towards content for SEO; pages like this blog on our website, for example. Google makes it easy to link the AMP version of a page to your old (“canonical”) version and to keep both online and relevant to Google searches. Again, early adopters of this new technology can expect a substantial SEO boost, just like when google switched to prioritizing responsive pages.

A 30 SECOND RUN-DOWN FOR DEVELOPERS

First the difficulties of developing with AMP: CSS is limited to one inline style tag, containing at most fifty thousand bytes of style rules, javascript is essentially banned (any interactive content comes through iFrames, some special asynchronous techniques are allowed), and images have to be prepared in more sizes and the breakpoints have to be written using the AMP protocol on the image element itself. Addressing these in order, Google has always wanted you to consolidate, inline and shorten your style sheets. If you ever run a page audit on chrome developer tools, you are familiar with this. Now, to optimize loading, Google is forcing the “good habit” on developers that want to unlock the speed and ease of amp pages.

The “ban on javascript” happening in AMP pages may seem like a deal-breaker at first, and for a lot of pages it is. But AMP is not intended to replace the standard languages of the web—at least not yet. Google emphasizes that custom content can be included in AMP iframes: elements used to lazy-load below-the-fold custom content and speed up that initial page load that Google has always been so obsessed with. For a lot of simple pages like blogs and news articles, an interactive js graph in an iframe will be adequate. Clearly, however, iframes are not conceivable for webapps or pages featuring a bulk of interactive content. Google hints that AMP improvements for interactive pages are coming soon, but for now, that seems to be the reality of the situation.

For image loading, there are a couple of new things to learn as a developer (documentation). Other than small semantic changes, the main hardship will be manually optimizing all images you wish to include in an array of sizes, or writing server code to prep the images accordingly for you. This has always been good practice to deliver the lightest and thus fastest pages possible and for developers that have already been doing something similar, this simply delivers a light and convenient implementation of loading the proper images in. If you are in search of a team of qualified developers to complete your Google Accelerated Mobile pages project, or mobile-friendly website of any nature, look no further than Mission Bay Media. Contact us today to get a project started!