AMP. Or “Accelerated Mobile Page”. Behind this slightly barbaric acronym that is on everyone’s lips lies a small revolution in the world of the web. It’s actually Google’s latest innovation for the optimization of digital content.
Time to take a look. 😉
AMP, or the idea of an ever faster web on mobile
Like me, you must have experienced in the past the frustration of not being able to load content on your mobile, even when all you wanted to do was access a simple information.
In this situation, you probably left the website to look for the same content elsewhere. And you’re surely not the only one that reacted like this! Most Internet users react negatively to delays and favor the fastest experiences. This user behavior results in a much better user engagement rate, and better referencing, for websites that have bet on Web Performance.
And it is in this context of a quest for immediacy, that the open-source project AMP was launched in 2016, by Google. This project has since grown to become a community of more than 160 contributors around the world.
In concrete terms, AMP describes a format that allows you to create a page that will appear more quickly on mobile terminals. We are talking here about a median time perceived by users of less than 1 second.
Technically, AMP pages are just “normal” web pages, in HTML, and therefore compatible with all web browsers. They are nevertheless fine-tuned to be very light when loading on a mobile phone. And this is where this project becomes interesting for Quanta, as Google directly broaches the issue of Web Performance on mobile.
How AMP works
AMP tends to several problems for the speed of content display.
- Instant loading (originally Instant rendering)
With AMP, there is the possibility to pre-load links that the user would want to click, so that when he clicks, the content appears immediately as if it were already fully cached (in fact it’s the same principle as the cache for that matter, except that it is built even before accessing the content for the first time).
In order to not overload the CPU and the bandwidth necessary to load content that a user would not eventually see, the AMP system will simply pre-load the top of the landing page only and, when the user actually accesses the content, the rest of the page is loaded while he reads the top of the page.
- Pre-set layout while the items load
In AMP, the size of each element is set in the HTML, in order to avoid “surprises” during loading. Once the text is displayed, it will not move until the user interacts with the page, thus ensuring that the reading is not disturbed.
Of course, this principle is not limited to simple text. 😉 If you have videos and lots of funky stuff (like call-to-actions) that you need to display between the paragraphs of your text, AMP can be a valuable help thanks to the system of placeholders.
With placeholders, you can display banner ads, videos, or any other item with a variety of extensions, but the size of each item will be predefined on the page, with a pre-set area (typically a gray square).
A simple example would be a Youtube video. On an AMP page, a predefined rectangle will appear first, then fill up with the preview of a YouTube video while the user is quietly reading the article.
This system of placeholders for the elements of an AMP page makes the (recurring) problem of pages that shift, as the elements are loaded, no longer an issue. Ever tried to read a book while being disturb every 3 seconds? Nightmare… Thus, with AMP, you no longer need to “scroll down” to find the line on which you were. And that’s quite an improvement in user experience.
- Fonts
There is some technical cumbersomeness in the loading of fonts, which for most pages comes very late during the process of loading a page. Typically, fonts will be loaded after any content that can possibly call a font, or after all the javascripts. With AMP, the loading order is optimized, and the fonts will be able to load from the beginning, in parallel with the rest, which ultimately makes the final display much faster.
- Analytics and speed finally united
With AMP, the use of tags is limited so as to avoid having several tags potentially blocking the page.
At Quanta, we see that some emerchants frequently keep tags that they no longer use, which slow down their users. And each of these slowdowns has a negative impact on their conversion rates.
In AMP, the subject was therefore taken seriously to avoid as much as possible these untimely loadings. Tags can be called, but only via a single interface that can not slow down the page (asynchronous). For most tag vendors, the implementation of Google’s system is quite simple. But, if you use more “exotic” tags, you’ll need to do little technical adaptation to use them with AMP.
All these specificities of the AMP system didn’t come out of nowhere. These are the result of many tests and clever choices made by a college of performance gurus, who probably had enough of seeing that the Internet is still slow, despite all the technological progress.
An innovation and … a controversy
Google AMP ultimately aims for a loading speed, so far unmatched, on mobile; a loading that now seems “instantaneous”. Therefore, this seems a perfect web performance weapon.
However, like any technical innovation, Google AMP does not come without controversy.
Firstly, it should be noted that this new format was launched without the W3C’s approval, which, as everyone knows, act like a wise council, and is responsible for regulating the Internet in an open and independent way. This tacit respect for the role of W3C on the net often makes it possible for new formats that may appear to become technical standards, and thus to be widely used. By bypassing W3C, Google takes the risk to see the AMP format disappear quickly.
In addition, another recurring criticism made by many web analysts (especially when you look at the articles of The Register, or CSS-Tricks on the subject, which is a must-read) concerns the underlying nature of the AMP project.
As I explained in this article, the concept of AMP aims at adapting the content to technical specifications which, in turn, serve Web Performance. The fear of many authors is that in the long run, in the hope of seeing their SEO in Google maintained, and their appeal to users untouched, the creators of digital content end up impoverishing their productions to stick to the technical recommendations of Google.
Fear certainly justified, but with regard to the benefits in terms of Web Performance, at Quanta, we assume that, as always: “The truth lies somewhere in the middle.”
And you, what do you think of Google AMP? Do you use it for your website? Do not hesitate to leave us comments!