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
<head><script async src="https://cdn.ampproject.org/v0.js"></script> - Changed all
<img>tags to<amp-img>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
<amp-img>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
<link>stylesheet and inlined all CSS using<style amp-custom>
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.17 MB, 8 requests | 1.7s, 1.18 MB, 5 requests |
| Test 2 | 1.2s, 1.17 MB, 8 requests | 2.0s, 1.18 MB, 5 requests |
| Test 3 | 1.3s, 1.17 MB, 8 requests | 1.0s, 1.18 MB, 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.3 MB, 14 requests | 1.6s, 1.18 MB, 5 requests |
| Test 2 | 1.1s, 2.3 MB, 14 requests | 0.9s, 1.18 MB, 5 requests |
| Test 3 | 2.3s, 2.3 MB, 14 requests | 1.1s, 1.18 MB, 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 <script>s
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 an SEO ranking signal. You heard it here first.
I don’t, if it means replacing the free and open web with one hosted on a particular platform.
I’m pretty sure you don’t change who you’re hosting with. You host wherever you want to host.
I get the point though. It IS a super weird syntax that browsers don’t natively support and you have to link up
for it to do anything. Which is a third party script that you don’t control. Looks like its an open spec though with a ton of contributors of varied interest. I have no idea what the chances of it getting to be a “real” spec though. (probably slim).
For the record, Tim Kadlec has similar concerns and there are alternatives.
Also I hope you are sleeping well ;)
I see. So you add their JS file (presumably has to be in the head) and it sort of re-parses the page. I suppose that’s better. It still relies heavily on the CDN however. And you can do a great deal of the slimming yourself (including inlining CSS if that floats your boat). I hope Google doesn’t explicitly give extra points to AMP without giving the same boost to others who can achieve the same results by other means.
Hey Casey,
the fact that we’re actually talking about coding for efficiency is already a step in the right direction.
And as Chris rightly said, you can host wherever you want. WordPress have just released a plugin to AMP your site, so no stress about hosting somewhere specific.
My “concern” is the fact that you have to have a sort of “different” version of the site. I used to hate the m.site.com thing, I feel that responsive was so much better, but this goes back to that.
Re the boost, I sure agree with not giving that sort of bias, however I do believe Google already rewards fast pages. But I’m sure they might push bit of an advantage towards AMP. They do have a habit of strong arming things that they’re like to put in place. HTTPS, Mobile-friendly… I’m sure it will happen again ;-)
Also big no-no because of non-js users (technique depends completely on js).
So good way – wrong technique.
This already exists:
http://motherfuckingwebsite.com
http://bettermotherfuckingwebsite.com
Notice how quickly those two sites load? Of course, this leads to both questionable UX and failure to meet most demands of websites. But when you do away with all the pointless fluff and cruft, sites are amazingly fast!
I have my own site that is very similar to the second. Minimal CSS and that’s it.
The web has become like software development. They are more resources, so sites and software engineers often don’t care if they are using more and more resources. Even if they are using them wastefully. Eventually everything becomes a bloated pile of junk that is kept rolling into a larger pile of junk because people depend on this pile of junk.
Well said Nadya, had to laugh when remembering that this two sites still exist.
Sometimes this all get too bloated and unnecessary…
Hey Nadya,
hehe, it’s been a while since I visited those sites!
That’s exactly the point though – the web has become bloated because many people simply get carried away with all the pretty things, or simply don’t have time to bother about efficiency (let’s just not say laziness – because I know I’m guilty of it too). Which is exactly the point of AMP – if you don’t want to do it yourself, you’re going to get forced into it.
Better still, if most of the web supports, we can simply not bother about it, and it’s all automated at the server side for us…
The fact that we’re having this conversation is already a good direction to be heading towards.
David
I think when you say “inlined all CSS” you mean you converted all external style sheets to a single embedded style sheets, right? The linked page starts by talking about inlining CSS, but the example on that page is an embedded style sheet.
Hi Sasha,
yes that’s what I did, I embedded all of the stylesheet, because it would have taken too much time to rewrite all of the page to inline the CSS.
In essence, both are ok – the point is twofold.
No external CSS need complete downloading before rendering starts
CSS is limited to 50K to ensure efficient use is made of it and in essence it is kept lean (and fast).
David
I don’t think I understand the whole AMP hype.
That large sites that focus on the blogging element benefit from it, yes absolutely, I get that. But other than that, it’s just Google’s flavour of being able to compete with Facebook and Apple.
And because it has been open sourced, everyone is so hyped up about it?
Hey Piet,
the point of AMP is that of making the mobile web faster … remember that much of the world (especially developing countries) access the internet on phones over very poor data networks. Even in developed countries, you’ll find plenty of areas where mobile data is slow.
Even when data is plentiful, many times it is highly metered, so making it more efficient has multiple advantages.
More than all of that, it makes access to AMP pages really really fast. You have to try it and experience it see the difference in reality.
Now, in terms of Google competing with Apple and Facebook, I really don’t think that this is the point. Many major publishing houses have jumped on board because it will give users a positive user experience. I’m sure they all have their own agenda, but a lot of good will come out of this in my opinion.
And how would Google be competing with Apple and Facebook with AMP?
I’m actually living in Shanghai, which is located in one of those developing countries you mention, and I can tell you that where there is coverage, 4G is WAY faster than most wifi connections :)
In the news there has been plenty published about how Google AMP compares to and/or differs from Apple News and Facebook Instant Articles.
Fortune did an article in October last year and there are plenty others too.
Don’t get me wrong, for the big publishing houses and other sites that do lots of articles, it is probably great.
But I don’t see the point of everyone starting to get hyped up about it, that is people without a blog.
There are other ways to make a site load fast, I’m thinking static loading. Now that is where the hype should be about I think :)
Ok, I see what you mean re the competition. Can’t say I disagree, but. Whatever the vested interests maybe, any time a new technology pushes how we do things to a new level (in a good way), I think that’s always a good thing – whatever the catalyst for that maybe.
And that’s why the hype is good in my opinion, because like I said in another conversation, any time we’re having a conversation about making the web faster, we’re all winners don’t you think?
I’m excited about AMP. It’s a shame that it’s centralizes on a Google CDN and on a Google-hosted script, but the rest of it are the best practises that the community have been talking about but not implementing on the whole. The speed with which AMP pages load from a Google SERP is impressive, so hopefully non-developers will start noticing that speed and demanding it from the websites they use and manage.
It’s true that you can’t load custom scripts, but you can load iframes, so you can still do embeds and the like.
(Nitpick: I’m sure that the sizes of websites were meant to be measured in megabites MB or mibibytes MiB, and not megabits Mb with a lowercase “b”.)
Hey Flimm,
I’m sure the Google CDN is something which we can get used too. Or find a better place to host it – it’s early days, improvements are bound to happen.
Agreed with the speed perception, I’m hopeful that this will eventually get adopted by more big gus … and then it’s a question of people catching up to best practices to keep up.
Agreed, as adoption grows, we’ll find more solutions to the “problems” or restrictions which currently exist.
Thanks for the nitpick, we’ll update it!
David
AMP seems a bit overplayed to me. It’s just the enforcement of performance best practices (i.e. don’t use scripts, inline necessary CSS, load everything asynchronously, etc.).
Anyways, this line from the article:
Doesn’t make much sense. AMP is for static content pages, like news articles. There’s no place for scripts and other dynamic elements on static content pages. Of course, there are some exceptions, like ads, analytics, etc. – but at the end of the day, we’re not talking about using AMP for anything dynamic whatsoever.
Hey Agop,
for sure, it’s not much more than enforcement of best practices – agreed. Given that WordPress has given it’s support to it and released an AMP plugin, I think it’s an excellent step towards making the website fast.
Re the other comment, you’re pointing out the needs yourself. My point in that part of the paragraph is: what if we had to expand AMP beyond news articles to stuff such as blog articles? Not very dynamic, but still there’s a lot of scripts there which would be crippled. There’s certainly plenty of room for improvements in my opinion.
I’m arguing for a solution to the scripts issue, rather than complaining about it.
For those who use Drupal, check out the module (really a full distribution) AMP. There’s also a walkthrough blog post on it, posted just today. There’s a beta release for Drupal 8, and a dev release for Drupal 7. The blog says there will be a beta Drupal 7 in the next two weeks.
There’s also the alternative Amp Project module and theme. Although there’re recent commits on it, there’s currently no release (not even a dev release). But you can grab it via git. Looks like Drupal 7–focused.
Thanks for sharing that Ivan
I worked hard to make my website responsive and light. 1 or 2 css max, 1 js, svg for everything except photos. The all shebang – thanks to Chris for that ! – and the result is a pretty fast mobile and desktop website. I didn’t compare with AMP, maybe AMP is faster. Maybe not. What makes the difference thought is advertisement. I have to put up wit a lot of crappy ads, with tons of js, trackers and shit that make my pages slow and bloated. And they all break the main ideas of AMP (asynchronous scripts, render blocking, etc)!
And even if it won’t be the case with AMP because it will have some effect on bad ads – or so they tells us for know – for how long ? If publishers put crappy ads on AMP, we are back at square one, but we still have two versions of our site to manage.
What’s the point of optimizing my site in the first place if I also have to do AMP pages ? Isn’t it the end of the responsive design we all embraced few years ago ?
And won’t Google make something of a monopoly out of ad serving on AMP pages in the long run ?
Why implementing a new syntax for something that can be done with the syntax that already exists, with already good browser support and common knowledge ? The choice doesn’t seems logical, or am I being too stuck in the past ? It seems to me that working with AMP is not a technical choice, like “Will I use Sass or not for this project ?”, “Should I use an iconfont or SVGs ?” etc. For me, it’s more about marketing than about development and web good practices.
And of course, in a world where some idealists – like me – are trying to remove all google, fb, etc. scripts from their pages, like going from Analytics to Piwik, removing FB like buttons, etc. to avoid trackers, giving all my datas to google and give some privacy to my visitors, you tell me that I must put a new Google script on all my mobile pages? Man, they are good.
This AMP thing sure rise a lot of questions in my head. This article is a good overview thought. If I was using WordPress I would certainly give it a try.
Hey Francois,
you raise a lot of interesting points. For sure, optimizing sites is not the realm of AMP only. You can (and should) implement the suggestions you put forward and you won’t have the need for any AMP pages.
I don’t think you have to “choose” whether to AMP your pages or not. My feeling is that going forward, WordPress and other content frameworks might actually do the AMPing automatically.
These would bring about benefits for everybody. You (as a developer) would not have to worry about having to work with AMP. Content writers (who are not technical) won’t have to wonder why their sites are slow. And mobile visitors will automatically get AMPed pages.
That’s an ideal world and might or might not happen. I guess we have to wait and see what happens.
David
I very much agree with all the questions and arguments you bring up. Until the last paragraph. I fail to see why a WordPress site would gain from AMP and a non-WP site would not.
Because it would be easy to just install the plugins and check this out without having to code anything. I don’t have a CMS so I need to make everything from scratch.
I didn’t mean to say that Piet, any site can benefit from AMP if it’s implemented, whether it’s a WP site or not.
So AMP is raising question, but those questions would not be there if you would have a WP install?
Sorry, doesn’t make sense. What is keeping you from setting up a WP install so you can take AMP for a spin?
Did you also run a test to determine the speed index. As I understand the main benefit of things such as inlining CSS is to get the critical content loaded first. Page load is not as meaningful a measurement.
I do think this is really a good coding approach and best practices if you are concerned with performance overall. Currently it is terrible user experience when you wait for a page, or have the page freeze in order for an ad to load. QUESTION: What will this do to a responsive approach? Thoughts?
The measurements are not very indicative of the real result as you rightly so. It’s a bit difficult to get good actual measurements because we are not timing specifically to measure AMP benefits.
It’s a very good question … I think there will have to be a way to merge both of these together. Responsive on mobiles via wifi, should be different from AMPed pages on slow mobile data connections.
AMP as an SEO signal is bad for the web as a whole.
AMP may be bad for the web in general. Google is wanting all web traffic to go through their servers at some point, and for a company and supporters who quite often criticize the idea of walled gardens, even when they don’t really exist, they sure aren’t shying away from creating their own toll roads.
Quentin, not saying I agree with this way forward, I’m just guessing it may happen in the future if Google wants to give it a good boost.
Would cloudinary’s new responsive image sizer help without having to use amp-img?
Anything which resizes images to make them smaller will help make your site faster.
It has nothing to do with AMP though
I disagree…
Allowing scripts would completely undermine what AMP is hoping to achieve. If it was allowed we’d find that within a day there’s be 4 libraries loaded, and there’s be 5000 lines of customs JavaScript on each page.
Then what would be the point in AMP at all…?
If you need to load libraries and custom scripts… Then don’t use amp… Simply optimise and streamline your responsive site.
Ray,
I do think scripts could have their usefulness in AMP. Things like Twitter, Facebook and Google Analytics already have a “solution” which is AMP compatible.
What I’m trying to say is that there might be a way in between which brings about the best of both worlds. I don’t have a solution for it of course…
I know what you mean…
It would really require the developer to exercise some restraint.
But from my point of view, ie as a digital director of a client cantered agency, I can see what’ll happen…
The client will want X, Y and Z to be on their AMP page and the developers will have to relent and start loading jQuery, etc etc
Pretty soon we’ll have undone what AMP was meant to do… And I’ll have wasted a lot of hours in developer time for no real Benifit.
As it is… AMP is new and most clients don’t know what it does and why it’s important. So as it is I can say at the technical meeting “guys… We can offer AMP on your site. But here are the limitations.”
And in a way that is actually a good thing…. Because it prevents clients running wild.
At the moment we put a lot of time and effort into optimising our mobile experience anyway… AMP simply allows us to take that further.
Totally agree with you on that point.
And given that AMP is aimed mostly at articles/news focused sites, for sure the scripts are not a critical part of it.
Yes , when you go to a client and say, listen you want the fastest experience? These are the limitations, can you live with them or not?
I’m glad we agree on the last part too of AMP pushing the envelope and helps in fully optiming the mobile experience.
I wrote an article a few weeks back asking a number of questions about Google AMP and doing some speed testing. Would love feedback! https://medium.com/@mattshull/questions-for-google-amp-a6c1963b13cd#.283qqccfa
Overall I’m very concerned about this direction of making sure the web is fast. I had a lot of questions that have been mentioned above but my biggest concern/question is the preloading of assets and how far that goes considering what I found with Buzzfeed page.
Great article David!
Hey Derek, thanks for your comments.
Quite a good dive into AMP and you raise quite a few good questions. As for the pre-loading question, I think AMP loads only the content which is currently visible (i.e. above the fold). So an image heavy site should not penalize the user because images will be loaded just in time, when the user scrolls to them. If it works that way, then that’s a very innovative AND efficient way to load images. This is also why you need to specify the dimensions of images, so that the article doesn’t bump around as the images are loading.
David