How Do Accelerated Mobile Pages Work? – Learning AMP
In our first Learning AMP post, we told you that an Accelerated Mobile Page is;
A page that has been simplified specifically for mobile users. This allows for a much quicker page load time.
Although this is an extremely basic definition for what an AMP is, it tells you everything you need to know. Now that we know AMPs are great for minimising loading times, it may be useful to know how they are able to do this.
There are quite a few factors that contribute to ensuring the almost-instant load times guaranteed by AMP. But we can breakdown the workings of Accelerated Mobile Pages into 3 main components. These are: AMP HTML, AMP Java and the Google AMP Cache.
Let’s now take a look at the techniques used by these 3 components and how they help to enhance load time dramatically.
AMP HTML
AMP pages are developed using AMP HTML. This is basically regular HTML but with limitations. AMP HTML only allows for the use of certain tags and functionalities. If you are curious about the extent of these limitations, then you can watch the AMP Project’s video on what is and what isn’t allowed in AMP HTML.
Most of the HTML used in AMP pages is just the same old HTML you will be used to if you have experience in Web Development. However, there are some tags that have been ‘AMP-ed’, I suppose you could say. These are referred to as AMP HTML components and here’s one in action;
<video>
would change to
<amp-video>
In essence, AMP HTML strips the original page’s content of any unnecessary tags and functions. And this is one of the factors that helps the page to be rendered quicker.
Simplified Styling
Web pages use Cascading Style Sheets (CSS) to determine what the page will look like once it has loaded. More often than not, at least one, if not more, external stylesheets are used to identify the look and the layout of the page. This can have a serious impact on the load time of these pages.
Accelerated Mobile Pages provide a solution for this problem simply by not allowing the use of any external stylesheets. Instead, only a single stylesheet is allowed – inline style. Inline Styles are different because they allow CSS styling to be applied directly in the HTML. This allows for the browser to establish the styling for the content on the page much quicker. The reason for this is because there is no need to request external documents to be loaded before loading the content of the page.
That takes us nicely onto ‘Static Layouting’…
Static Layouting
This is the name for the system AMP pages use to identify the layout of pages.
On standard web pages, all external elements (images, iframes, ads etc) must be loaded before the layout of the page can be established; and therefore, display the content. This can be time consuming and unnecessary.
On AMP pages however, the exact size of each element must be stated in the HTML. This makes life so much easier for the web browser. Because, it then only takes a single http request to establish the exact size and position of every external element on the page. The sooner the layout is determined, the sooner the content can be loaded. That is the beauty of Static Layouting.
But if you want your page to load REALLY quickly, is it necessary to load all elements at the same time? No, is the answer to that. And this is what AMP’s Resource Loading Prioritisation is all about.
Resource Loading Prioritisation
When you click on a link and a page loads, it’s pretty unlikely that you will be able to see all of the content on that page. After all, we’re all used to having a scroll by now, whether it’s using a little wheel or a little thumb flick. But before you do any scrolling whatsoever, you will be able to see some content. In the Web Development world, we refer to this content as ‘Above the fold’.
Accelerated Mobile Pages prioritise the loading of content that is above the fold. Identifying the external elements that are going to appear above the fold is made easy by the Static Layouting system explained above. This is a simple, but extremely effective way to reduce the load time of a page. Because with standard web pages, the content is only displayed as soon as all of the external elements have been loaded. And if we are looking at a long page that has quite a lot of elements, then this can have a real impact on the load time of the page. Resource Loading Prioritisation ensures that this isn’t an issue with AMPs.
AMP JS (Java Script) Library
Java Script tends to be the number one corporate when it comes to causes of long page-load times. The simple reason for this is that scripts are executed externally and can often be complex.
This doesn’t become an issue when you don’t allow author-written Java Script. Nor does it, when you only allow asynchronous Java Script. That is exactly what the AMP Java Script Library ensures.
The AMP JS Library is what makes all four of the optimisation techniques mentioned above, possible. The JS library controls the resources on the page, ensuring that they don’t negatively impact loading time and that nothing is stopping the page from rendering. By only allowing asynchronous Java Script, the rest of the elements on the page can still load, even if the Java hasn’t.
Anyone who wishes to use interactive features on their AMP page can do so using custom AMP elements instead. This does still involve the use of Java, although it is carefully designed to guarantee fast execution of the script.
Google AMP Cache
Finally, there is the Google AMP Cache. This is a CDN (Content Delivery Network) that fetches and stores data from all AMP pages. The Google AMP Cache is the third and final component to every Accelerated Mobile Page.
It fetches, stores and delivers all valid AMP HTML documents. So, shortly after creating your AMP, there would be two versions. There would be the ‘hosted AMP’, which is the original version you publish from your domain. Then there would be the ‘cached AMP’; the version that is created as a result of Google AMP Cache storing your AMP on their network.
The Google AMP Cache has two purposes;
Enhanced Page-Load Time
The vast majority of the time, when you click on an AMP page you will be taken to the cached AMP. You can check this by clicking on an AMP on your phone and looking at the URL. If it starts with amp.gstatic.com, then you know you are on the cached page. Whereas, if it just looks like a normal domain with ‘/amp’ immediately after it (for example bakdigital.co.uk/amp/post-name) then it will be the hosted AMP.
Having the page cached means that the data from that web page is already stored on Google’s CDN. So it already knows what is on the page and what the page looks like, before you have even clicked on the link. This is yet another way to enhance the load time of an AMP.
Built-in Validation System
The Google AMP Cache also has a built-in validation system that confirms the HTML used in the page is compatible with the AMP HTML specification. Not only does it validate the AMP HTML, but it also makes sure that the page isn’t relying on any external resources, so that it will load efficiently.
And that, ladies and gentlemen, is how Accelerated Mobile Pages work! Quite an impressive initiative ayy?
If you run your own blog or the blog for a company, then you could look into having a go at creating your first Accelerated Mobile Page using AMP Project’s guide.
