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?
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 ampproject.org). 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:
- 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.
- Paint; here the web page is rasterized (converted into pixels on the user’s screen).
- 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.
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:
- 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.
- 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.
- 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.
- 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!