Warning: Informational/technical/part-opinion piece.
What is AMP?
The mobile web is slow. The Accelerated Mobile Pages (AMP) project is an initiative started by Google that is trying to make the mobile web a performant platform again. Google sets the scene with "every time a webpage takes too long to load, you lose a reader – and the opportunity to earn revenue through advertising or subscriptions".
With long-form content being the target, this affects the Careers Advice articles in our Job Board product and their positioning on Google.
Mobile is big then?
Millennials are now the largest generation in the USA, in terms of population. And 81% of them primarily use mobile to shop.
This time last year Google announced there were more searches done on mobile than desktops. Mobile is everywhere and easily seen on public transport – look around and all you see is the glow of people's faces from their phones.
And yet, the UX of the mobile web – websites on your mobile device – generally pales in comparison to a native app experience.
The web on my phone is second class
We've all been there, tap a link from the Google results, the screen goes blank and the loading bar starts its long crawl across the screen. Some branding colors appear, some layout but there's gaps where it looks like there should be text as the phone struggles to download the font. Your thumb hovers over the screen waiting for the pay-off – being able to scan over the content, when at last, the text suddenly pops into view.
A slow upward swipe of your thumb does little but splutter & stutter a scroll; like walking through molasses the ads, widgets & tracking consume your phone's limited resources as they load up. Another few seconds pass (you're never going to get this time back) when finally, if you persevered – you're there. Pop-over ads dismissed, you're scanning the content you hope is going to be relevant after all.
Whilst not always the case, we've all experienced this and it's a terrible UX. Compare this to when you open an app and it's available virtually instantly.
Performance is vital
Google has been on a performance drive for some time now, encouraging the web development community to step up. This has included making speed a factor in the search result positioning, calling out slow sites in their listings, providing great tooling to test your site performance and offering plenty of advice on how to keep your site trim.
Ericsson recently published a neuroscientific study that claimed mobile delays causes as much stress as watching a horror film.
Universal messaging being: performance isn't a nice-to-have but a requirement for good UX but with the pull of tracking, analytics and ads this seems to be falling on deaf ears.
Websites are fast by default – then we layer on poorly engineered ads, widgets, analytics and tracking codes. As the audience experiencing this bloat this costs us battery, bandwidth and frustration on our phones and loses you readers.
Google wants the web to succeed
I grew up with the web and love its engineered elegance and simplicity. Google have done pretty well on this simple platform, their ad network making them being the most valuable business in the world and have witnessed along with everyone else the performance issues the modern web is facing.
Due to these performance issues users are turning to ad-blockers, native platforms and proprietary solutions to access streamlined content quickly and easily. Solutions like Instapaper, Pocket and Readability are taking public content from the web and repurposing within a walled garden. This need for speed has introduced Facebook Instant Articles and Apple News to the masses taking readership away from the web and that's bad news for Google and their ad platform.
Ads, widgets, tracking… are we shooting ourselves in the foot?
Web pages are getting more complex. The press recently reported that the average web page is now as heavy as the classic computer game Doom. Whilst not the most useful metric, the core message isn't good news for the web.
Latency is the main issue with mobile – the round-trip time for each request. Each ad can create dozens of extra requests, each one starts on the handset then travels over the airwaves to the radio mast, across the internet then back from the server to the mast, over the radio again to your device. While the connection may be fast, the latency is high.
This is a major factor when a standard job detail page is only about 20 requests (for the HTML, CSS, images, assets etc.), then taking a sample set of our clients with ads and social media widgets the request counts generally increase by 100+.
With every ad, social widget and tracking code added, it's a little more molasses added to the site. And a slow site is bad for business – users hate slow sites. So much so, that browsers are starting to get ad blockers built in.
I think everyone would agree, content-relevant, non-intrusive ads can be useful but bloated ads are doing the web a dis-service.
We went responsive, we're good right?
Let me point out that Responsive Web Design (RWD) has little to do with performance.
Since its inception in 2010 RWD has been the defacto way to build websites. To recap, a responsive website is a website that adapts its presentation to provide the best layout for the device being used to view it.
The same website (same URL) that loads on your desktop PC spanning your big monitor, adapts that same layout to look nice on your small(ish?) screen smartphone.
Saying that, although the presentation may work well it's relatively easy to create a slow/heavy RWD site that works well on your desktop computer but will suffer on mobile.
That is unless you've made a specific effort to conditionally load assets.
At Madgex we're very careful with our performance budgets, and the slow uptake of ad platforms working well with RWD spurred us to developed our Lazy Ads project which only loads ads if they can be seen by the device your using (e.g. it won't try to load a wide desktop leaderboard ad on a small handset) and tries to load them ‘lazily' – in a way that won't impact the page load times and after the main content is available.
So how does AMP solve this?
Google (with some partners) have decided to take the matter into their own hands, gathering the current best practices on web performance and advice and providing an easy to follow set of rules.
The AMP-version of your content is publicized by placing a meta tag in the head of your original content, much like meta keywords or a meta description. This meta tag lets Google's bots know where they can find the AMP content & serve that in mobile results.
Google are also supplying (free of charge) an AMP Content Delivery Network (CDN), which is optional but allows you to cache your content on Google's own CDN.
There's nothing magic around implementing AMP. It's all standard web technologies, just wrapped up in a set of current best practice and given backing by Google.
Although AMP supports ads, it doesn't support the intrusive ads we're seeing more of and keeps everything under tight control.
What is Madgex doing about AMP?
As AMP articles are promoted near the very top of Google searches done on a smartphone, Madgex is very interested in this opportunity for our clients.
We're currently exploring and investigating how we can best use AMP in our products. As AMP is content-oriented, it lends itself to our Career Advice articles but we need to understand how all our clients various advert providers and metrics work with AMP as mentioned previously, only a few are supported.
We're pretty excited about the debate these technologies are making and really looking forward to seeing how it develops.