I recently attended AMPConf 2017 New York and there were some great discussions revolving why and how to implement AMP. Whether or not AMP is for you, it serves as a wake up call for both marketers and developers.
First of all, AMP is not just a new technology, but also a philosophy and a call to action that frontend-devs should be aware of. AMP aims to better the user experience across mobile devices and better the web for everyone.
So why should we focus on creating a better user experience on mobile? Simply because it’s where our end users spend most of their time these days and we are making their experience way too painful. Slow loading ads, ads that are blocking page content, multiple repaints of the page due to javascript manipulation and scrolling that won’t work for several seconds are just some of the problems that AMP aims to solve.
The Oatmeal also wants better user experience:
http://theoatmeal.com/comics/mobile_website
White screen of death
The mobile web often looks like the picture below. This so called “white screen of death” is one that usually makes the user go back to the search results, rather than waiting for the page to eventually show up. Well, at least that’s how it works for me.
The white screen of death.. please wait, wait, wait, wait…
Slow render time = lost convertions and pageviews
It’s a well proven fact that the longer a page takes to load, the more users will navigate away from the page before it’s rendered. Jacob Nielsen even did research proving this in the early nineties. Still, getting hard facts and numbers can be difficult. For instance, if the user leaves before the page is rendered, we won’t notice it with our standard analytics tools. According to research from Google and SOASTA, even a couple of seconds is enough to lose a large amount of visits and Amazon supposedly grew revenue by up to 1% for every 100 ms of improvement.
Source: Google/SOASTA Research, 2017
At AMPConf 2017 Natalia Baltazar from The Guardian told us that they experienced 8.6% higher CTR on AMP-pages compared to their regular pages and that they discovered AMP-links had 2% higher chance of being clicked. Wego also talked about how they experienced a 93% increase in convertions on their AMP-based progressive web app compared to their old site.
But what is AMP?
AMP is a strict set of rules and some javascript, that lets you build speedy webpages in a standardized way, so your pages can be cached and delivered equally fast on any device and platform. Google — and soon many others — will cache your content on their own servers. The benefits of caching and prerendering the content is that Google achieves blazing fast delivery of your search results. AMP is made to work reliably in any webview, whether it’s a browser, LinkedIn, Facebook, Google search, Yahoo search, Bing search or any other app that implements it.
An example of how an AMP-enabled page will be displayed on Google
As for the Google Search results, your page will be displayed with a little lightning-bolt when they have your page validated as an AMP-page. Bing and LinkedIn has also started presenting AMP-content, but so far they have not implemented an AMP-cache.
The AMP-cache
Google, as a consumer of AMP-pages, provides its own AMP-cache. The cache is used to deliver a prerendered experience in an instant, all over the world and validate pages to make sure the page is guaranteed to work. For security-reasons, only Google can host an AMP-cache, for now. As mentioned by Cloudflare CEO Matthew Prince on AMPConf 2017, Cloudflare have created their own AMP-cache and will be delivering it’s own service and SDK for use by everyone that wants to present AMP-pages in their own apps.
The key to speedOne of the key parts of AMP, is that it won’t allow any code that will block the page from rendering. Render-blocking elements will in most cases be synchronous script, link and import-tags. AMP will only allow async JavaScript. Self-written JavaScript won’t be allowed either(!) Instead, all interactive features must be handled by AMP-components. Custom JavaScript is allowed in iframes — as long as it does not block rendering of the main page. Critical and above-the-fold CSS has to be rendered inline and be of a size smaller than 50kB. This also means that it might be time to say goodbye to CSS frameworks like Bootstrap and Foundation.
“Only do things if they can be made fast.”
One of AMPs design principles is to only do things if they can be made fast. This means that you need to reconsider everything you put on your site. It also means that you should consider wether or not your marketing department really should have access to Google Tag Manager. This principle also highlights one of my issues with AMP. Ironically, if developers were in charge, we probably wouldn’t need AMP in the first place. It seems, however, that it’s more accepted to create a second mobile site that achieves great performance, than it is fixing the existing solutions. A funny comment that was made during AMPConf 2017 was that “AMP is more powerful than your CEO”.
Progressive Web Apps with AMP
Progressive web apps introduced a concept called the App Shell Model, which focuses on rendering the bare minimum of your application instantly and then load the rest of the content asynchronously. By following the App Shell Model, one could do this by rendering crititcal CSS inline, and caching the “App Shell” with the Cache-API. The “App Shell” is the base user interface. The difference between this and AMP, is that AMP aims to render all of the content instantly, by not blocking page rendering and/or to be prerendered by Google.
Even tough they often suit different use cases, PWA’s and AMP can very much live side by side, or even together as described thoroughly in this article by Paul Bakaus: https://www.smashingmagazine.com/2016/12/progressive-web-amps/
Critique
Even tough AMP has lots of great arguments for using it, there’s also a couple of very important arguments against. The first issues I personally came across is “why can’t we just make a fast mobile site?” and “I want my own domain name”.
So as mentioned, a lot can be done to improve pagespeed on a regular mobile site, especially if you follow AMP’s design principles (and also performance best practices). If you want the AMP lightning bolt in search results and in apps like LinkedIn, you must implement AMP and have it validated. The reason for this — according to Google — is that it’s the only way they can validate if your page actually is fast. If your site is not AMP, they can’t be sure that your page will be delivered consistently fast. They simply check your site to see if it’s follows the AMP restrictions and if it does, you are worthy of the lightning bolt.
Domain nameOne of the more important issues is that Googles domain name is displayed instead of yours. A page owner naturally wants the correct domain name displayed, either for branding purposes or the fact that a publisher may only have the right to serve some content, under their own domain.
**Openness**Since Google has been strict on who can operate an AMP-cache and there’s been uncertain wether it has an impact on ranking, people are worried that this will make the web more closed and locked to Google’s services. According to Google this is not the case. It’s an open source project and anyone that wants to, may implement support for AMP. There is also a wish from Google to have more developers participating in their open source project.
**AMP does not have an impact on ranking**Many people seem to believe that AMP has an impact on the sites Google ranking, but according to David Besbris, VP of engineering at Google — AMP is not a ranking signal and probably won’t be. This is because AMP can’t tell Google anything that other, currently active, ranking signals are already telling them. Since it is a continuous process with testing and research, he also says they can’t rule anything out.
So what do I think we can learn from AMP?
In my experience, we as developers need to learn to focus on page performance and take full control over the content of our pages. Do you know what every piece of code in your 400kb CSS-file does? Probably not. If you think about it, a CSS file should probably never need to be over 50kb in size for a single page. Developers also need to figure out what all the scripts on our sites are doing. When do they load, are they blocking the rendering or are they triggering repaints on the page? If a script is not tagged with “async” or “deferred”, then why isn’t it?
You don’t have to get AMP’ed up if it doesn’t fit your solution and personally I would much rather prioritize general page performance. Taking AMPs design principles and performance best practices into consideration, will undoubtedly be a good improvement to any webapp, but what really makes AMP fast is the combination of not blocking the critical renderpath, optimizing resources, lazy-loading and of course caching and prerendering with the help of Googles AMP-cache.
The AMP project does serve as a wake up call for developers and marketers. It is trying to solve a serious problem and it’s fast, uncomplicated and targeted. If your mobile site is something like Mr. Oates drawing above, you should probably be banned for using up all our internets.
So what I think we all should do with our webpages is:
- Start by following best practices for performance (why don’t you already?)
- Size all resources statically
- Inline critical CSS and make javascript load asynchronously
- Optimize fonts
- Keep the marketing department away from tag manager (yeah right)
- Consider AMP ;)
and some final words from AMP’s design principles
“When in doubt, do what’s best for the end user experience”