People’s expectations of mobile experiences are growing. They want fast and accurate content and the stats reflect this - 53% of mobile site visits are abandoned if pages take longer than three seconds to load. Slow load rates can not only lead to a negative user experience, it can also affect a company’s conversion rate and SEO performance because, as since July 2018 Google started considering page speed when ranking mobile search results. Google’s Accelerated Mobile Pages (AMP) is one way to combat slow load rates and improve mobile experiences and it’s well worth checking out
AMP aims to make websites faster on mobile devices. In fact, it makes mobile sites load almost instantly. Facebook and Apple News have incorporated something similar in the past, but Google’s approach doesn’t require a dedicated app or platform, it just works in the browser and it’s open-source.
Google announced AMP in late 2015. After the initial launch, it focused mainly on the big media sites like The New York Times, Wired and The Washington Post. But page speed wasn’t the only reason for that. By incorporating AMP on their websites, publishers also made their news prioritised in so-called ‘Google Top Stories’. As a result of those two factors, all of them noted a significant increase of mobile traffic and returning users.
Image shows AMP websites displayed on Google’s search results carousel. You can spot small thunder icon in the top-right corner of each news, indicating that result page uses AMP.
Over two years Google has put a lot of time and effort into developing AMP. They’re now not only focusing on big publishers, advertisers and e-commerce websites, but smaller websites that want to improve user experiences and increase traffic.
We wanted to know more about AMP and how it functions so we decided to give it a try. We looked at its speed, the pros and cons and whether it’s possible to build in our favourite CMS - Drupal.
How it works
How does the magic happen? AMP is a library built on existing technologies. There are three core components that create an AMP website:
AMP HTML- Mostly regular HTML, but heavily restricted. Also, some HTML tags are replaced with AMP-specific tags.
AMP CACHE - the most impactful in terms of page speed. It's used to serve a cached version of an AMP page located on a proxy-based content delivery network. It allows the page to be pre-rendered in search results. This means that the visible part of the page is loaded by the browser before the link is even clicked. As a result, the page loads instantly.
Our AMP test
With the help of AMP project documentation we managed to create a test website within a few days. We uploaded the test website to our development server. It’s available at the address: http://kbamp.dev.kolabdigital.com/. If you visit this link, you’ll see a regular website with menu, footer, few text paragraphs and images. There are also few subpages, a contact page and a content type with a description page.
Desktop version of our AMP test website
To view the AMP version of the page you just have to add ‘?amp’ to the URL address, so it becomes http://kbamp.dev.kolabdigital.com/?amp. If you’re using a mobile device and Google shows our page in search results, it will link to AMP version, rather than the standard one.
Our test site in Google search results
The most significant and visible benefit is the website load time decrease. It can be measured at three stages. Firstly the AMP page is fast. With only few custom JS, inline CSS and optimized HTML, the site loads faster than usual. The second stage of speed-up happens thanks to AMP Cache, which will perform dozens of optimizations and serve content from the fast google proxy network. The third level of speed-up is available because of the pre-render, mentioned earlier. We tested the website speed on every stage and here are the results:
During our test, we measured few page load factors. The Start Render time is the first point in time that something was displayed on the screen. The Load Time is the time from when the user started navigating to the page until the Document Complete event (usually when all of the page content has loaded).
The First Interactive metric measures when a page is minimally interactive, so most, but maybe not all, UI elements on the screen are interactive and the page responds to most user input. Time to Visually Complete measures how long it takes to display the content visible in the user's browser: content "below the fold" and non-visual content (like third-party tracking beacons) are excluded. Finally, the Fully Loaded is the time to load the whole website.
The real speed burst comes with the AMP pre-render ability. Thanks to it, the load time is almost equal to zero and the impression is that AMP pages are ready more or less instantaneously. The whole site loads in 1.6s and the first interactive version is ready in 0.7s which is lightning fast. Here’s a video comparing website render process:
The speed isn’t the only benefit AMP offers. Another undoubted one is increased click rate of amp-links in comparison with regular links. There’s a pool with the question “Are you more inclined to click on an AMP link than a regular one?” and over 50% people said yes to that question.
Also, we shouldn’t forget that on mobile devices, AMP pages are prioritized in Google News Carousel (also known as Top Stories on desktop devices), mentioned earlier. There’s a study done by Searchmetrics, which tracked the mobile search results for 50 search queries that were trending on Google News. Over 75% of the page one results were AMP-enabled, positioned either in the standard organic search results or in the Top Stories. With AMP growth and Google strong policy to promote it, we can expect a further increase of AMP-based results in result pages, not only in the news division.
There’s no money involved, but Google pre-render speed comes with a price. When visiting a site from search results, it’s displayed from Google cache, which means it’s served with AMP-specific URL instead of a regular web address. For example, our test site is available under this link. Additionally, to inform that a cached version of the page is displayed, a toolbar’s added to the browser window.
Our test AMP page served from Google cache. Notice the toolbar with actual website URL at the top.
This solution caused vast concerns around the web development community, because it may seem that despite visiting a website we’re still under Google’s domain. This can possibly divert traffic away from other websites for the benefit of Google, and at a scale of billions of users, this may further reinforce Google’s dominance of the Web.
Since AMP uses its own HTML markup, which has a lot of restrictions a custom theme for AMP-version of the website has to be developed. This task appears to be not trivial and it may be time-consuming, especially for websites with a lot of interactive features. Also the AMP project is developing rapidly, so keeping up with it technically will probably require a lot of attention and maintenance.
The page is restricted to use only 50kB of Cascading Style Sheets (CSS) inline. This requirement turned out to be very tricky to fulfil. Our website incorporated only few text paragraph styles, image styles, some simple grid and images carousel. Despite being pretty simple, we had to be a bit creative to fit the limit.
As mentioned earlier, the AMP project is growing rapidly. Just a few months ago, the cached version URL issue has been addressed and project maintainers announced that the newest AMP version will allow the sites to use publishers URL instead the google.com/amp one.
In February, Google released the AMP Stories, which is supposed to be a new, visually rich content format designed to provide publishers with new storytelling options for the mobile web. Google still cautions that the format is experimental, but this proves that we can expect more features involving amp technology in the near future.
Google also announced AMP for Email, which is an attempt to introduce some of the Accelerated Mobile Pages elements into emails. This should allow delivering complex layouts and templates, as well as interactive and dynamically updated content. Of course, Gmail will be the first email client supporting the new features.
In march Malte Ubl, Tech Lead for the AMP Project, mentioned on the AMP blog that they are looking to bring AMP techniques and benefits to open web standards. He wrote:
“We are taking what we learned from AMP, and are working on web standards that will allow instant loading for non-AMP web content. We hope this work will also unlock AMP-like embeddability that powers Google Search features like the Top Stories carousel.” This statement clearly suggests that amp won’t be the only right way to improve websites and there should be a space to use non-google alternatives.
AMP is definitely something worth looking at in the near future. It offers really powerful benefits, like site speed boost, better user experience and increased revenue. But only for those publishers, who are willing to invest the time and money to implement and maintain the AMP version of their website.
On the other hand, there’s no magic behind AMP. A well-developed and optimized website performs just as well as an AMP version. It’s the access to Google’s proxy cache and pre-rendering feature that makes the difference. Therefore, maybe it’s worth to wait until Google allows more standardised technologies to improve websites, so they’re promoted in the search engine.
We’re excited to incorporate AMP on websites we develop at Kolab, but we encourage to do so only on text-heavy subpages of the website, like news and articles. With the proper amount of time spent on development and maintenance of the website's AMP version, it will surely lead to increased mobile traffic and returning users.
1 Google Data, Aggregated, anonymized Google Analytics data from a sample of mWeb sites opted into sharing benchmark data, n=3.7K, Global, March 2016