Home > Blog > Are Accelerated Mobile Pages The Future For Mobile Web Technology

Are Accelerated Mobile Pages the future for mobile web technology?

Optimising page load times on mobile devices has been a hot topic for sometime now. Different techniques, best practices and technologies have been suggested to improve load times and provide better mobile user experience. AMP is a method that is taking a rather different approach to web page optimisation.

What is AMP?Google-AMP-Accelerated-Mobile-Pages-1

AMP stands for Accelerated Mobile Pages. The short answer is that it is an open source initiative to promote the user experience of the web for mobile device users.

The long answer is that it is the result of a collaboration between the most prolific technology giants and some of the biggest names in publishing. Tech providers including Google (obviously), Twitter, LinkedIn, Adobe Analytics and publishers (most of which are European) consisting of the BBC, The Economist, Daily Mail, The Guardian, Mashable, The Telegraph, just to name a few (full list The main objective of the partnership is to improve the experience of the entire mobile content ecosystem for all parties involved: publishers, consumer platforms, creators, and users.


Why are publishers interested in Accelerated Mobile Pages?

Well, that’s kind of obvious; content is king afterall. Instead of trying to be a general-purpose solution to mobile experience optimisation, AMP is targeting a more specific audience i.e. content generated by publishers. The reasoning behind this is that publishers generate content that is mostly static, and often include some standard widgets such as carousels, image sliders, etc. By limiting the scope of optimisation to publishers, AMP is able to eliminate a lot of the trade-offs that can arise when optimising more general websites for mobile devices.

How are they planning on achieving this?

In order to achieve this goal, the guys behind AMP looked at the browser’s critical path of rendering. This is a necessary set of steps that a browser needs to take to fully render a web page. The critical path involves the following steps:

  1. JavaScript execution; the browser will execute JavaScript in order, any blocking JS will impose a delay on page load.
  2. Style recalculations; the browser will then recalculate the styles of the elements within the page, following JavaScript execution and thus taking into account the style changes made by JavaScript code.
  3. Layout; at this step, the browser lays out the elements (depending on the calculated styles) on the page (up to this point we’re still working with the memory, nothing has been sent to the screen yet). The layout step relies heavily on CSS properties that affect the elements’ layout on the page i.e. height, width, left, right, margins, padding, etc.
  4. Paint; here the web page is rasterized (converted into pixels on the user’s screen).
  5. Composite; since the elements in a web page can be drawn on different surfaces (layers) they can overlap. At the compositing step, the browsers orders the paint calls in the correct order.

In addition to these steps, at the initial page load, prior to these steps, the browser also retrieves all HTML, JavaScript, CSS, etc from the server(s). More about the critical path of rendering can be found here.

Browsers perform these steps at a rate of 60 times per second, which means the browser needs to complete all the steps in around 16.667ms. AMP attempts to provide better performance by either minimizing some of the steps or executing them as few times as possible. This is achieved through:

  1. Minimising external dependencies and removing third-party JS from the critical path. In AMP pages, no external JavaScript/CSS files are allowed except for font stylesheets and AMP’s JS runtime and extensions. All of these are actually served from a single CDN and so, once cached by the browser, anytime you visit an AMP ready website, the browser won’t need to download the files from the server again, but serve them from the local cache.
  2. Only inline CSS style blocks are allowed. By doing so, AMP eliminate one or often more requests to get the CSS files. Also, inline CSS blocks are limited to 50K which means authors will have to keep their styles clean and tidy.  
  3. It prioritises resource loading, so that important resources (visible in the viewport i.e. above the fold) are loaded first. AMP’s runtime is able to achieve that by forcing users to specify resource sizes statically, such that AMP’s runtime can make decisions on when to load/prefetch resources as opposed to the normal way of downloading all resources at the initial page load.
  4. Use of the new preconnect web API, which allows the browser to prefetch/prerender resources before they get requested. More about the preconnect API can be found here.
  5. Since no user-authored JavaScript is allowed, the JavaScript execution step is minimised. This step is also minimised as all third-party JS/widgets such as ads, youtube, and tweets, etc, are sandboxed in iframes, and thus they won’t be blocking the main page from rendering.  
  6. Style recalculations, again, since no user-authored code is allowed, AMP’s runtime is optimised to make sure that minimum style recalculations happen at every frame. According to the project’s website, they perform a maximum of 1 style recalculation per frame. Also, AMP uses GPU-accelerated animations, these animations do not trigger style recalculations. Note: the only CSS properties that can be animated without triggering a style recalc are “opacity” and “transform”. More about optimised animations can be found here.

My personal opinion is that AMP is definitely a brave attempt to optimise mobile experience in terms of page load, power consumption, etc. However, the question here is: do we really need such extreme cases of user experience optimisations? Browser vendors are working constantly on making their browsers better. This is also met by comparable efforts from mobile device producers to make their devices more capable by adding more CPU power, memory, better battery life, etc. Which means at some point we’ll have to weigh the real gains of using AMP against using plain old HTML5. So, whether AMP is a project that will live to be a market standard or will it be another technology adventure by Google [AtScript, Dart, Wave, etc], only time will tell.

Get in touch and let me know what you think!

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code class="" title="" data-url=""> <del datetime=""> <em> <i> <q cite=""> <strike> <strong> <pre class="" title="" data-url=""> <span class="" title="" data-url="">

4 thoughts on “Are Accelerated Mobile Pages the future for mobile web technology?

  1. Digiwhiz

    Accelerated Mobile Pages is a big step forward by Google to improve the overall mobile experience as the number of mobile users are more than desktop users. Overall great article to read. Thanks for sharing.

  2. Luke

    What does this/will it mean for e-commerce?

    In AMP pages, no external JavaScript/CSS files are allowed except for font stylesheets and AMP’s JS runtime and extensions

    Magento for instance will not function properly without javascript…and of course just session data in general which is required for most shopping cart systems.