Taking AMP for a Spin
The following is a guest post by David Attard of DART Creations. David is going to introduce us to AMP (no idea what that is? read on) as well as how you might go about converting an existing site to an AMP site. Hint: it’s for big performance gains. AMP is becoming quite a thing. WordPress is doing it. I’ve got Google telling me to do it and that Analytics supports it.
If you have your visitors interests at heart, you’ll know that a fast website is one of the main factors of a good user experience. Speedy websites go a long way in making your users happy and coming back. Determined website administrators will always chase those few milliseconds of speed improvements.
Those milliseconds make a real difference.
One big new method for making your website fast is called
Accelerated Mobile Pages (AMP), a project spearheaded by Google. Mobile data is unlike our home WiFi connections. It’s slow. AMP aims to help fix that, in a rigidly prescribed way, by ridding sites of their most inefficient parts.
Let’s take AMP for a spin!
We’ll see how to convert an existing web design to AMP. Then we’ll measure the difference it makes.
Why Accelerated Mobile Pages?
Phones on mobile networks typically experience latency issues.
Even for simple articles with static content, pages can take a long time to load the text. Scripts, images, video… all that takes even longer. Perhaps ads come in even later, and the page adjusts itself to reflect the newly loaded content. Not exactly a pleasant loading experience.
AMP wants to change all of that. Publishers and technology companies have come together to establish best-practices which will make pages render quickly.
This is a non-trivial problem. The initial focus of AMP is on static content that allows for more radical optimization.
For now, AMP is an open-source proof-of-concept. In fact, we’ll come across some limitations which show that this technology is still in its infancy.
What makes AMP faster than a traditional web site?
AMP has very rigid rules for the source in order to get the big speed gains it’s going for.
The founding principles of AMP are:
- Only asynchronous scripts. Non-async scripts block DOM construction and delay page rendering.
In fact AMP restricts the usage of JavaScript at all. Scripts are only allowed within custom AMP elements which are carefully designed for performance. Example of custom AMP scripts include Google Analytics, Facebook, Twitter and YouTube.
3rd party scripts (such as ads, or 3rd party services) are kept out of the critical path and are only allowed in iframes. Once again, this will not block the rendering of the page.
More on scripts later.
- External resources need to have set dimensions. Things like images and iframes need to have sizes to ensure that AMP knows the size of the elements before they are downloaded.
- Don’t let anything block rendering. Simply put, nothing stops AMP from rendering. External elements are included in iframes. AMP will create the iframe box without even knowing what it will contain.
- CSS must be inlined and size bound. AMP takes the opposite of the normal choice of linking CSS in an external file. AMP obliges inline CSS, for the same reason as scripts: because CSS blocks rendering and page load.
There is a maximum of 50 kilobytes of inline CSS to make sure it is used efficiently.
- Font loading must be efficient. Web fonts can be quite large and can severely impact performance. In normal circumstances, browsers are blocked from downloading fonts until scripts and stylesheets have been downloaded and are ready. This creates a long initial wait time until the large font starts to download.
In AMP, CSS is inlined, and scripts are asynchronous. So the browser does not have to wait for these to complete before downloading the fonts.
- Only run animations on the GPU. Some animations require page layout updates done by the browser rather than the GPU. AMP limits animations to
transformandopacityso that page layout updates aren’t required and all animations are kep on the GPU, where they are fast. - Resource loading is prioritized. AMP optimizes downloads of resources such that the most important resources are downloaded first. Images are only downloaded if they are likely to be seen by the user.
- Pages are loaded in an instant. The PreConnect API is used to prefetch, render and download resources which are likely to be used by the user. This is done efficiently: content is pre-rendered and downloaded only if it is likely to be requested (such as “above the fold” content).
The Parts of AMP
There are a number of “changes” to standard HTML, CSS and JS which give pages optimized using AMP a speed boost.
- AMP HTML: These are HTML tags extended with custom AMP properties
- AMP JS: a library which ensures that AMP HTML pages render fast
- AMP CDN: delivers the HTML AMP pages using HTTP 2.0 for maximum efficiency
The Steps to Convert a Page to AMP
Since I was completely new to AMP, I followed their recommended checklist.
I wanted to start with an existing normal (non-AMP) page, so I chose a Pen from CodePen: Example Article Layout by samyerkes.
- Add the amp attribute to the tag
<html amp lang="en"> - Add a canonical link element
<link rel="canonical" href="index.html"> - Changed the charset tag. Note that this is different from the ALL-CAPS UTF-8 and AMP is touchy about this.
<meta charset="utf-8"> - Add the meta viewport tag
<meta name="viewport" content="width=device-width,minimum-scale=1"> - Add AMP Project CDN script at the bottom of the
<script async src="https://cdn.ampproject.org/v0.js"></script> - Changed all
and addedwidthandheightattributes. Example:<amp-img src="http://farm4.staticflickr.com/3595/3288866270_23cb40f37c_b.jpg" alt="Crashed plane vintage photo" height="1024" width="734"></amp-img>You need to follow this syntax when using
tags:- Must include an explicit
widthandheight. - It is recommended to include a placeholder. The placeholder is immediately shown, so that there is “something” visible until the actual resource holds. For example, you could load a low-res preview of an image which is loading.
<amp-anim src="animated.gif" width=466 height=355 layout="responsive" > <amp-img placeholder src="preview.png" layout="fill"></amp-img> </amp-anim> - Optional:
layout="responsive". Read about other layout options.
- Must include an explicit
- Removed
stylesheet and inlined all CSS using
The Results: Improved Loading Times
The test environment was a couple of subdomains created on a SiteGround GoGeek shared hosting account. Tests were run using GTMetrix and Pingdom tools and were run several times to remove any fluctuations coming from the external environments.
Test 1: Short article
The first test we ran was with the exact article as specified in the CodePen, where the article is relatively short.
| Example Article Layout (native HTML) | Example Article Layout AMP | |
|---|---|---|
| Test 1 | 3.3s, 1.17Mb, 8 requests | 1.7s, 1.18Mb, 5 requests |
| Test 2 | 1.2s, 1.17Mb, 8 requests | 2.0s, 1.18Mb, 5 requests |
| Test 3 | 1.3s, 1.17Mb, 8 requests | 1.0s, 1.18Mb, 5 requests |
You can see some fluctuation. If you look carefully at the waterfall graph, you’ll see the fluctuations are actually coming mostly from the AMP CDN. This is unfortunately a side effect of using a shared resource which could come under load.
Test 2: Tripled article length and included 3 times as many images
| Example Article Layout (native HTML) | Example Article Layout AMP | |
|---|---|---|
| Test 1 | 1.1s, 2.3Mb, 14 requests | 1.6s, 1.18Mb, 5 requests |
| Test 2 | 1.1s, 2.3Mb, 14 requests | 0.9s, 1.18Mb, 5 requests |
| Test 3 | 2.3s, 2.3Mb, 14 requests | 1.1s, 1.18Mb, 5 requests |
Interpretation of Results
Beyond the actual loading times, the number of requests in an AMP page are lower than in a normal page. By itself, that makes a page faster, due to the amount of requests being smaller and thus less latency waiting (each request is subject to latency).
Also, the total size of the page decreased significantly when pages were AMPed. Large articles with many images seem to benefit more from AMP.
In one early test we did, we tested a fairly short article with just a handful of images. This test was not very conclusive, so we upped the ante. In the test we’re presenting here, we tripled the length of the article, and tripled the number of images. Interestingly, although we tripled the number of images, in the AMP version of the article, the number of requests did not increase.
As far as I can understand, besides the actual efficiency of the AMP specification, AMP only loads the content above the fold (which explains why the number of requests stayed the same after tripling the images). It is only loading the first chunk of the article, the “above the fold content”, and that’s why the content is shorter, smaller and of course, faster.
A word about
Quoting verbatim from the How It Works page:
One thing we realized early on is that many performance issues are caused by the integration of multiple JavaScript libraries, tools, embeds, etc. into a page.
which is soon followed by:
With this in mind we made the tough decision that AMP HTML documents would not include any author-written JavaScript, nor any third-party scripts.
In my opinion, a bit drastic.
Something’s gotta give, I understand. Increased performance comes at a cost. Even when optimizing normal websites for performance, you’re going to have to make some compromises.
Sometimes it’s the quality of the imagery of your site. High quality images come at the cost of large file sizes. Sometimes at the cost of removing functionality. Sometimes at the cost of removing third party scripts, such as social site integrations.
You’re always going to have to take some tough decisions based on your own priorities.
Completely eliminating scripts is a tad too drastic in my opinion. Libraries like jQuery, Bootstrap, Angular, React… essential building blocks of today’s web development.
Completely removing scripts is shooting AMP in the foot. It’s shooting AMP completely off the planet into a small world of its own.
It only becomes practical if you are willing to make very serious compromises in terms of the functionality you want on your web pages. Even in the realm of news websites, the initial focus on AMP, there are going to be some tough pitches.
Can we guess where AMP is headed?
It’s still the early days, and it’s hard to guess on the future of AMP. Speaking from the heart, I really want AMP to succeed. Web pages have become bloated and too little attention is given to performance. We need a real effort to make the web faster. HTTP/2 is a step in the right direction. So is AMP.
Unfortunately, AMP feels crippled with the lack of support for scripts. I hope web developers will come together to find a fair solution which keeps the web fast while enabling the functionality we need.
This is an invite to you. Spare some time to help on the AMP project. If you are not technical enough, read about it and test it out. Evangelize about it and get people interested. Who doesn’t want to be part of a better, faster web for everyone?
Having been following Google for a while, one can expect what Google might do to give AMP a boost. We might soon be hearing that AMP is a SEO ranking signal. You heard it here first.
AMP Resources
Taking AMP for a Spin is a post from CSS-Tricks
