Several months ago, before the redesign of Gmail was even announced, Google made even bigger waves in the email world. At their second annual AMP conference it was announced they were bringing AMP to email. What is AMP and do we even want it for email?
WHAT IS AMP⚡?
You may know of AMP, Accelerated Mobile Pages, the open-source web project started by Google. The noble and needed goal of the project was to make mobile web browsing faster and easier. While more and more people are browsing the web on mobile devices exclusively webpages are ever increasing in size and complexity. This has created a conundrum where mobile devices—traditionally strapped for bandwidth and download speeds—are increasing their market share of the web but receiving worse experiences.
AMP did just what it aimed to do and more. It’s served via normal web architecture and if a site doesn’t include the special AMP code then the good ole HTML, CSS, and JavaScript version of the site is loaded. If the AMP code is present and the end user is detected to be on a mobile device the AMP version is loaded. By having a slimmer and uniform codebase AMP versions of sites are able to be rendered quickly and as a bonus, when navigated to from a Google search, a cached version of the page is served directly from Google’s servers.
“ Why would I want to cede control over my pages to Google? ”
— John Gruber, Daring Fireball
A better experience for users, faster load times and Google even serves a cache of your AMP page lessening your server’s load, what’s not to love? It turns out—as with most things—the devil’s in the details. From the user’s perspective AMP is great, but from the publishers perspective AMP turned into a real estate grab by Google. AMP pages served by Google used Google URL’s masking the publishers domain. AMP’s strict adherence to Google’s pre-defined methods and layouts limited design and in some cases made it extremely difficult to use analytics and advertising providers other than Google. Not to mention that the project is open-source in name only; Google staff control the codebase 100% meaning changes not aligned with Google’s vision aren’t incorporated.
Google’s AMP turned out to be a mixed bag and one that was really more about Google lock-in and ensuring their continued domination of the web.
AMP⚡ 4 EMAIL
With all the issues with AMP you might already be questioning the wisdom of AMP for Email. You wouldn’t be alone; the consensus among the email marketing community has been largely mixed at best. While we’re always striving for better consistency across email clients and more modern approaches to email—including the addition of interactivity—we loath when something is introduced that could fracture email client CSS support even further than it already is. AMP for Email could solve a lot of email designers problems but like the web version it comes with a litany of questions and glaring issues.
“ A bad joke that could potentially cede even more control over the internet to Google. ”
— Jason Meeker, RootedElm
First and foremost you should question whether we need AMP for email. Unlike the web, email can’t load JavaScript and thus typically has much less code bloat meaning faster load times. If email already has reached much of the initial stated reasons for AMP then what’s the purpose of AMP for email? Well, AMP for Email would allow for interactivity and animations in Gmail clients. With Google’s increasing marketshare of email opens it would be great for marketers and subscribers alike if Google allowed for the same interactivity as the other top 4 email clients. The problem is Google could already allow for that interactivity if it standardized it’s CSS across its email clients and allowed even a minimal subset of standard CSS animations.
LOAD TIME & DELIVERABILITY CONCERNS
AMP for Email would potentially make load times for emails even longer. When an email client downloads an email it is typically downloading two separate parts—known as MIME type—in order to render the email. One part is the HTML version and the other is the Plaintext version. Both versions are typically small in their file size meaning fairly fast load times. AMP for Email would require a third part be included in emails containing the AMP code almost doubling the size of emails being downloaded. The web version of AMP doesn’t have this concern as it doesn’t need to download the non-amp version of the webpage before rendering.
Because AMP for Email is a third MIME type it would be treated like any other email attachment by the vast majority of spam and virus firewall devices. Corporate, government, and educational institutions are typically extremely slow at updating their spam and virus filtering software not to mention being overzealous with their filtering. This could lead to emails containing AMP versions being quarantined or, even worse, not being delivered.
An AMP version also allows for the loading of JavaScript. While a giant vector for phishing, scamming, and hacking on the web this has never been a concern with email. Email doesn’t permit executable scripts forcing would be phishers and scammers to face the hurdle of getting would-be victims to visit a website first. Even with the supposed limited JavaScript that AMP for Email would permit it adds an additional security vector to emails that could lead ISP’s, government agencies, educational institutions, and other email providers to restrict or even prevent the loading of AMP versions of email.
EMAIL CLIENT/ESP BUY-IN
Because AMP for Email is open-source—despite Google’s stranglehold over the codebase—other email clients can implement AMP as well. The question is would other email clients do so. Because AMP for the web happens on the server side of the equation it doesn’t matter what web client you are using—they can all render the AMP page. AMP for Email is embedded in an email just like the HTML version, because of this the only way for that AMP version to be rendered is for email clients to read and render the AMP version is for them to release new versions of their software. For web versions of email clients this isn’t an issue as they can update their code and everyone visiting the site will use that new version. For mobile and desktop email applications this is a much bigger issue; not only do they need to release new versions of their software but users have to actively install that update.
To fully implement AMP it will mean a lot of work on the part of email clients. A lot of work to achieve something that could potentially hand their competitor a leg up. Many clients also already adhere to a large subset of standardized CSS meaning they already allow for interactivity and animation in email. In the end I suspect many email clients won’t opt to implement AMP in their software and if only Google can render an AMP email then is it really worth the extra effort to create a separate AMP version? For some subscriber bases it might be but for most marketers it won’t be worth the effort.
Even if every email client decided to implement AMP in their software marketers would still have a big hurdle to overcome. Because AMP is a separate MIME type it would mean we would have to craft a third version of every email potentially increasing workloads. An even bigger hurdle is that the vast majority of marketing email is sent via a large or enterprise level ESP such as CampaignMonitor, MailChimp, Salesforce Marketing Cloud and others. Currently these ESP’s have no way to add AMP versions of an email. They would have to invest significant time and resources to add the capability to create or add an AMP version of an email in their platform. With the potential for spotty acceptance of AMP for Email and the apparent ceding of power to Google many ESP’s might opt not to implement AMP in their platform.
AVAILABILITY
Currently AMP for Email is only implemented in some versions of Gmail’s mobile apps and sites. Which ones? Google doesn’t say. Also, not everyone can even see the AMP version even if they are on a supported version of Gmail. Like Goggle’s short lived Grid View experiment marketers must opt-in to the closed beta of AMP for Email. Unlike Grid View, Google doesn’t seem to be widely accepting applicants. In fact it doesn’t appear that anyone other than Pinterest and the others Google used to demo AMP for Email at its announcement have been permitted in the closed beta.
In the end Google’s AMP for Email seems like a solution in search of a problem. A bad joke that could potentially cede even more control over the internet to Google. Everything that AMP’s stated purpose for on the web is already accomplished in email. Its only current benefit would be the addition of interactivity and animation for Gmail clients. Interactivity and animation that Google could already achieve if they would standardize their allowed CSS matching the offerings of the other top email clients. All at the cost of adding more technical hurdles and foibles to an already precarious email landscape.
As email marketers and designers we’re striving for clients to confirm to standards, not introduce secondary layers to those standards. Time will tell, but given that Google has little control over email—they only have a 24% share of opens as of June—compared to the web I don’t see AMP taking off quickly if at all.