Google’s AMP launches, Automattic plugin integration ready

Google launched AMP in a pretty big way. The video steals a line from Donald Trump by saying, “We want to make the web great again. It’s really as simple as that.” It’s actually a nice video despite that line, and Automattic’s Paul Maiorana plays a starring role:

Much has been shared about what AMP will be, long term. The sure thing seems to be that it will be bigger and broader than it is now. Whereas right now, it’s really only compatible for serving articles, it seems the Google team envisions it can be much more — with applications for eCommerce, dynamic home pages, and more. From Nieman Lab:

WANG: This is Version 1. What’s definitely coming in Version 2?

GINGRAS: There’s a lot more we can do in evolving the format. AMP is not just about news and not just about articles. That was our initial focus. I see applications across a whole spectrum of web experiences, from e-commerce sites to the landing pages for an ad. It’s interesting if you study ad performance, that if I click on an ad, how important getting quickly to the next step is. If you could somehow collapse that to be instantaneous, then ads will be more effective. There are lots of potential areas that are succeeding, and some that are not, and we’re excited about all these next steps.

The performance results from AMP are impressive. From another Nieman Lab post (they’re crushing this story):

What kind of speed improvements does AMP deliver? Here’s one example:This desktop version of a New York Times story gets to domContentLoaded— a key point in a webpage’s load where the HTML is fully downloaded and certain important parsing has been completed — to 0.985 seconds and loads fully in 3.82 seconds. (That’s in a test in Chrome on a fast iMac.)

The mobile version of that page gets to domContentLoaded in 0.857 seconds and is fully loaded at 2.99 seconds.

The AMP version of that same webpage — note the .amp.html in the url — reaches domContentLoaded in 0.240 seconds and loads fully in 0.646 seconds.

These results don’t appear atypical from other measurements I’ve seen.

Of course, AMP has restrictions. And you have to have a specific feed for AMP to work. Automattic has been working with Google, and they have a plugin ready (implemented on and available for self-hosted users. The self-hosted plugin already has more than 10,000 active installs. Just add /amp to the URL of sites that support it, and you can see what it looks like out of the box.

Word is more customizability for the plugin template is coming, but right now it has a familiar vibe to the default Jetpack mobile theme.

Even though AMP is “open” and being contributed to by a lot of big and powerful organizations, it is still a bit scary. Speed is already a Google ranking factor, so it’s natural that AMP enabled pages will get at least that degree of a bump, and maybe (likely?) more.

Also, the need for AMP in ways just feels like sidestepping bad actors of HTML. As many, many people have stated, it’s quite possible to have fast AMPish websites right now: don’t make crappy websites. However, AMP is playing the role of belt-tightener and by and large it seems publishers and the broader web community are embracing it.

It may be years before we find out if this was all a terrible idea or not. At least, however, it’s a performance enhancing move and hopefully, hopefully will remain that way. I do relate though to those that wonder why we can’t just have nice things with regular ‘ole HTML.

By the way, many cite AMP as a response of sorts to Facebook’s Instant Articles, citing the closed nature of Facebook Instant Articles.  Dave Winer has an interesting article debunking that, noting how Instant Articles actually helps the open web. I don’t know…

Similar Posts