AMP and Responsive Web Design
Google have released AMP: a new subset of HTML to make the mobile web fast. What does this mean for Responsive Web Design?
When I was first told about AMP my initial reaction was to feel threatened by it. Speed up the web? That’s what we did to the BBC News website in 2012 when we released the first version of the responsive news codebase. Our loading strategy – Cutting The Mustard – was based around using the absolute minimum (base experience) to render the content as quickly as possible and then sprinkle a rich user interface (premium experience) over it. The site was fast and worked in all browsers. But that was in 2012 when the responsive news team worked in total isolation from the rest of the BBC and was responsible just for a mobile site which lacked all of the content and features of the desktop version.
In the preceeding 3 years since we’ve gone through the very difficult tasks of working closer with the rest of the business (to create a more consistant look with the rest of the BBC online offering), take advantage of shared libraries and components (standard BBC video player, standard BBC header and footer for example), make all our content responsive and turn the design into something good enough to replace our old desktop website. A consequence of this has been that we’ve suffered “growing pains” (as John Cleveley blogged about in the post “We’ve made it”). Some of the original benefits of the site have been diluted. We’ve suffered from performance problems and we’ve had to re-evaluate how teams work together when creating responsive experiences.
Despite recent and very imminent improvements to the performance of the site there is only so much that we can do to keep the site as fast as possible. Once these performance improvements have been released the biggest impacts to the speed of the site will be latency (distance between the user and the server) and third party scripts. Latency can be solved by moving our site to CDN permenantly (we currently move to CDN only during periods of high load). Third party scripts are an issue because they are developed seperately from the site and then injected into the page, sometimes completely at random. This lack of coordinated design of the page can create terrible loading times and block page rendering.
The lack of co-ordination is a major problem. If we compare the web and native apps as content delivery systems then the web is an all rounder, capable of creating any kind of experience at a moments notice, while native apps are specialists that do one thing really, really well but is hard to change (as it requires the owner to get the new version of the app approved and then force all users to download).
The native app experience is extremely well coordinated. An advert supported web experience is a combination of different bits put together at page run time.
After my initial shock of hearing about AMP I stopped being worried about it. It’s not an existential threat to the web (or my pay check) like I initially thought. Yes AMP has been designed to help speed up the web. Yes we publishers have a speed problem. Yes we’re mostly all practicing Responsive Web Design. But no, this is not a threat to RWD.
What AMP is
Google describes AMP as thus…
Instant. Everywhere.
For many, reading on the mobile web is a slow, clunky and frustrating experience – but it doesn’t have to be that way. The Accelerated Mobile Pages (AMP) Project is an open source initiative that embodies the vision that publishers can create mobile optimized content once and have it load instantly everywhere.
I don’t think Google using the phrase “mobile web” helps really. That’s enforcing an old style thinking of “the web” and it’s little brother “the mobile web”. Despite that the important thing to note is the “everywhere” part in the description: “create mobile optimized content once and have it load instantly everywhere”.
AMP has two primary objectives:
- To improve the experience of people trying to read content on mobile devices
- To distribute content more easily
Better experience for mobile users
If you haven’t already you should play with the AMP examples Google have released, they’re incredibly fast. This is due to 3 important aspects:
- All AMP pages live on Google’s CDN.
- You don’t run your own JavaScript (despite AMP having its own JS engine).
- There is a custom markup language for content elements that aren’t text – i.e. images, video and other stuff (e.g. tweet embed).
AMP pages rely on the AMP JS engine to render content that isn’t text, its used more like CSS than a standard JS lib. This allows AMP pages to render just in time and to prioritise content either in the viewport or stuff that is imminently about to be in the viewport. The custom elements for non text content are ignored by the browser, allowing AMP to own the order of asset loading and rendering.
This loading strategy plus the fact that the page is on CDN gives the page the best possible chance of getting to the user and rendering something into the viewport as quickly as possible. It’s an implementation of a web page that prioritises performance over accessibility, semantics and SEO (important point which we’ll come back to further down). A “web app” in the truest sense (@adactio maybe this is the definition of a web app we’ve all been waiting for?).
Improved distribution
AMP has had a lot of attention by developers and also digital journalism commentators. Some of AMPs origins come as a reaction to Facebook Instant Articles and Apple News. After distrupting many other industries, the tech giants have turned their attention to online journalism. Facebook and Apple want us to give them our content. By pushing all reading experiences into native apps we could potentially see web-ad supported content disappear into the app ecosystem.
Facebook Instant Articles and Apple News have their own data format. We have to give them our content in their format of choosing. This format isn’t compatible with anything else – especially the web. AMP is essentially a competing format to Instant Articles and Apple News, but it’s also a delivery system. A format and delivery system that is based on the open web.
AMP pages have been designed to allow publishers to put their content into other experiences: a Google search, a twitter time line. AMP reminds me of RSS, remember that? RSS allowed you to give away your content for free, which was great for getting people to see your content but not so great for making money from it. AMP is better than RSS for publishers because it enables them to syndicate their content bundled up with their advertising and analytics. AMP is a format to empower “vertical publishing” – sending your content to where your users are. This is a different strategy than many publishers are practicing of expecting users to come to their website where the content is.
What AMP isn’t
If you think about AMP as being an alternative to RSS then you can see how it might (or might not) impact our industry. The following is conjecture so I might be wrong (or have to issue apologies) but I’m willing to make the following two assertions with as much evidence as possible.
AMP is not a replacement for RWD
The main benefit of Responsive Web Design is that you make the feature once and it becomes available on all the devices you want to support. If AMP is supposed to be the mobile view alternative for all our content then this invalidates the point of RWD. We’re back to where we started in 2012 with a mobile site and a site for everything else.
I don’t believe this is true for the following reasons:
- SEO – The Google AMP project want us to provide AMP alternative endpoints to our standard web pages (the element
<link rel="amphtml" href="http://www.bbc.co.uk/news/amp/34511973">is now in all BBC News story pages). This means Google wants to index your site and understand if there is an alternative AMP page. AMP elements aren’t semantically correct, they are not a part of the semantic web, so they hurt Google searchbot’s ability to understand your content. - Browser support – AMP’s stated browser support is the latest 2 versions of all major rendering engines. AMP also relies massively on JavaScript to render the page. How is this supposed to work with proxy browsers like Opera Mini? How can you design an experience that progressively enhances the page? Are you happy relying on a seperate entity to determine your product’s browser support?
- Accessibility – At the moment the AMP experience for screen readers is pretty poor. Even if you did want to replace your existing online presence with AMP right now you should think long and hard about how this impacts these kinds of users.
- It’s been designed to support publishers content – eCommerce, social media, trading platforms (e.g. eBay), software as a service (e.g. Dropbox) and other non text based experiences, i.e. anything that requires more than just consuming text, images and video don’t really fit the AMP model. If your online presence – web mail for example – relies on a rich, complex interface then AMP isn’t for you.
This doesn’t mean that AMP couldn’t be a replacement for RWD in the future. It’s just that right now its tailored to do a very specific task: create fast reading experiences.
AMP does not validate device detection as a better technique than RWD
Some people are asserting that because AMP’s stated goal is to speed up the mobile web then its an implicit acknowledgement that Responsive Web Design is failing us. I think this is bullshit for the reasons outlined above (primarily my assertion that AMP is a replacement for RSS rather than Responsive web pages and that its just for reading experiences). Anyone who thinks you should now use device detection to determine whether to show the user an AMP page or alternative, doesn’t know what they are talking about (evidence of this being the <link rel="amphtml" href="http://www.bbc.co.uk/news/amp/34511973"> now appearing in all BBC News story pages).
Device detection certainly has its uses but it fails to address the key issue that responsive web design solves: what is the “mobile web”? Where is the cut off between the “mobile web” and the “everything else web”? Device detection doesn’t tell you this, instead it tries to give you the means to solve this problem by yourself.
If web performance was a rat problem in your house, then Google AMP would be a rat extermination service that required you to gather the rats into a box and leave them outside by the road. While device detection would be a telephone book listing all the names of every rodent there has ever been, empowering you to clearly identify if what is running around your house and scaring your wife really is a rat, and leaving you to choose whether to exterminate it yourself or not.
Summary
The biggest criticism of AMP has been that its not really HTML, that its a subset of industry standards that is based on the open web but not of the open web. If AMP was an attempt to change how we make all webpages then I think this would be a valid criticism, but right now I don’t think this is true.
It also looks like we’re about to embark on a standards war between AMP, Facebook Instant Articles and Apple News. I don’t know about any other publisher, but I know that supporting all 3 on top of continuing to support our responsive codebase is going to make our jobs more difficult. I don’t believe any of the tech giants can create a content object model that caters for all the requirements of an entire industry, so what ever format ends up winning should be as flexible as possible. As AMP matures it should hopefully behave more and more like a standard webpage – especially as Google state that they want it to become an open format allowing anyone to write extensions for it. A format that allows the creator to define the layout sounds like a better strategy than one which behaves like an XML document (looks at Facebook Instant Articles and Apple News).
If we thought about AMP purely as an attempt at Google to improve the speed of the web for mobile users, then it’s a technical solution to a business problem. Publisher’s development teams are very capable of creating fast experiences for mobile users, but they don’t have the clout to coordinate all the additional cruft that is added to the page. However, if all the different publishers dev team’s got together and put their weight behind a single implementation, then we can force third parties to change their habits. AMP could end up being a great implementation for publishers practicing the technique of Responsive Web Design.
I don’t think AMP is a threat to RWD, instead I think its a beacon showing us how we can improve it.
By @tmaslen
Additional reading: