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.
“ 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
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.
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.
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.