I just recently came across the Accelerated Mobile Pages (AMP) Project (https://www.ampproject.org/) which aims to speed up the web for mobile browsing. While it is organized as open project, Google has been the driving the initiative. Originally announced in October 2015, Google has said they will start boosting search engine rankings in January 2016.
The project aims to deliver a speedy web experience for mobile users by restricting the technologies and content that can be shown on the page. The most notable aspect is that AMP pages cannot have any custom JavaScript. Discovering that aspect of AMP was shocking, and will be a high point of contention.
Removing JavaScript will increase page speed dramatically. AMP pages will not have to download 350 kB of JavaScript (the average size of JS transfers in January 2016, according to httparchive.org), loaded synchronously for the most part, and then likely requiring a few repaints and reflows before the final page is shown to the user. After some thought, this severe restriction does make sense from a technical point of view. Many JS frameworks and libraries, not to mention custom JS, are currently expected to be loaded synchronously. If the AMP specification allowed JS with the warning about synchronous loading, that would not be enough to prevent a lot of amateur developers from getting mired in JS timing issues, and possibly a wave of backlash against AMP in general because of the difficulties following the specification. Still, no custom JS is hard to swallow for some, and will prevent many from taking a stab at creating an AMP compatible site.
Some interactivity can be added by embedding iframes on an AMP page. This comes with some severely limiting restrictions:
- Must be at least 600px or 75% of the first viewport away from the top.
- Can only request resources via HTTPS, and they must not be in the same origin as the container, unless they do not specify allow-same-origin.
The requirement to inline custom CSS will have a smaller benefit than the JS restrictions. On AMP pages, CSS should be used minimally if users are going to browse the site after landing on it since the CSS will be part of of the HTML body request and cannot be served from cache.
There are some other important restrictions such as absolutely no form elements allowed, and other tags (including img) have their own AMP specific alternatives.
The timing of this initiative is a little curious. It would have been nice in the early days of the mobile web if sites were designed to perform better on low-bandwidth, low-power, high-latency devices. Mobile devices are becoming increasingly powerful, and mobile networks are increasingly fast (not to mention that ubiquity of Wi-Fi hotspots), that mobile browsing is no longer an afterthought and sites will naturally have to consider their performance for mobile. Still, for Internet users that do not have the aforementioned luxuries, a promise of a much faster web will be welcome.
I am most interested in how much of an impact AMP compatible sites will have on search engine rankings. If one can throw together an AMP site that easily topples heavyweight sites (that are heavy in more ways than one) in their rankings, then AMP just might be an important SEO-movement in 2016. If there is little impact to search engine rankings, then I do not expect AMP, in its current form, will be very notable.
Summary
AMP is a very restrictive specification for serving speedy mobile experiences. These restrictions undoubtedly will make mobile browsing faster. The uptake of AMP will fully depend on how much of an impact AMP has on search engine rankings.
For more, see https://www.ampproject.org/