The web has been mobile-first for some time, yet desktop-driven technology and methodology is still evident everywhere we look on the web. For the majority of websites, load times and the underpinning tech hasn’t kept up with mobile users’ expectations, despite many websites now being accessed from mobile devices over 50% of the time.
‘Mobile-first’ isn’t new news…
Last year, the tech giants made a move to begin to bring this user experience in line with the wants and needs of users of the mobile web:
- Facebook launched its Instant Articles format
- Google released its open source AMPP (Accelerated Mobile Pages Project)
- Apple launched Apple News for iOS devices
All three are examples of stripped down mobile content formats which have been pre-released to select publishers. It’s our belief that adopting these formats early may lead to future inclusion in new content discovery formats.
In the UK, you can already see both Facebook and Apple’s new formats in the wild, and Google have been very forthcoming with their anticipated user experience when AMPP indexing is rolled out into search results.
As you can see, the direction is clear — less clutter, well-formatted content and full-bleed media. The mobile web certainly doesn’t have to be boring, but it does need to load quickly. Recent reports (plus some tests of our own!) indicate that load time can be reduced by around 300-400% with Google’s Accelerated Mobile Pages.
The tech behind accelerated mobile pages
Focussing now on Google’s Accelerated Mobile Pages (AMP) for the explanation, here’s how and why we’re able to gain these performance enhancements;
Lighter codebase
AMP pages are supposed to load fast. Mobile users don’t want or need extra web page clutter. As a result, the AMP project promotes lightweight code including a number of AMP-specific tags, some of which are listed below, which modern browsers and the AMP JavaScript libraries will know how to interpret. Added benefits are lazy image loading, for example.
amp-img amp-audio amp-pixel amp-video amp-carousel amp-anim amp-iframe amp-twitter amp-youtube
Limited JavaScript
AMP ships with its own JavaScript library and actually restricts both first and third party JS files being included. This puts the onus on CSS3 for animations and causes a number of issues with external tracking scripts such as Google Analytics (for which there is a pixel-based work around with the amp-pixel tag above).
Sandboxed ads and external content
The AMP runtime and validator doesn’t care about anything external. Ad blocks and third party content is included only via iframe so that the content is sandboxed and won’t impact page load time. Also, pertinent to the point below, this is content that shouldn’t be core to the page and therefore doesn’t require the same level of caching.
Datacenter caching
Google will cache and serve AMP-validated content. Note the emphasis on serve. In Google’s traditional search engine model, pages are cached however when visited from the search results page, the web server hosting the content still plays an important role in serving that visitor with content. The AMP model is different, in that the Google web cache will now be used to serve up AMP pages without touching the website’s own server. We’ll have to wait and see whether this is helpful or not outside of the realm of speed…
Here’s how the HTML tags work behind the scenes to instruct Google on which version is AMP HTML and which is the canonical, “normal” URL for the web page.
AMP in practice
We’ve implemented AMP for our site already – take a look at it in practice here [note – we actually removed AMP from our site. Watch out for a follow-up blog on why!].
This has only scratched the surface of the pros and cons of this tech, but we’re going to have our eyes and ears peeled for when this hits the UK search market.
Read more about AMP here on GitHub.
