New Google thing, aimed at unsucking the “mobile” web:
The Accelerated Mobile Pages (AMP) Project is an initiative to improve the mobile web and enhance the distribution ecosystem. If content is fast, flexible and beautiful, including compelling and effective ads, we can preserve the open web publishing model as well as the revenue streams so important to the sustainability of quality publishing.
Curious the focus is on mobile only. The web has suck problems everywhere, and really, what is “mobile” these days? If I made a version of my site out of this, is it on me to diverge my traffic to the correct version? This maybe?
Through the spec, Google suggests that developers use a limited subset of HTML (and CSS_, known as AMP HTML (e.g. no transitions, no animations, no filters…) To validate your website to this specification certain markup elements are not allowed and a boilerplate document is provided to help get developers started.
The open source project reveals even more restrictions:
Primarily we are aiming at reducing the time until the content of a page can be consumed / used by the user. In concrete terms this means that:
- HTTP requests necessary to render and fully layout the document should be minimized.
- Resources such as images or ads should only be downloaded if they are likely to be seen by the user.
- Browsers should be able to calculate the space needed by every resource on the page without fetching that resource.
Developers have compared this project to Facebook’s Instant Articles, but for the web at large instead of inside an app ecosystem. In a video tutorial Addy Osmani takes a look at how this might work and the resemblance to Facebook’s project is clear.
It seems this project is likely to help an awful lot of users — and don’t forget that any movement towards fixing the terrible performance problems of the web is generally A Good Thing™. Yet Tim Kadlec argues that:
AMP isn’t encouraging better performance on the web; AMP is encouraging the use of their specific tool to build a version of a web page. It doesn’t feel like something helping the open web so much as it feels like something bringing a little bit of the walled garden mentality of native development onto the web.
That troubles me. Using a very specific tool to build a tailored version of my page in order to “reach everyone” doesn’t fit any definition of the “open web” that I’ve ever heard.
For a project that seemed to fall out of the sky, there is a crapload of major publishers and technology partners involved.
AMP is the new m.
Yeah, I agree with Tim Kadlec. I think the idea is a good one, a stripped down, “bullshit-free” version of the web that is not more than just the content does sound like a good idea. I don’t like the way AMP wants to achieve that idea. This is the kind of thing that should be created by everyone for everyone, a standard, open-source way for publishers to provide their content immediately that anyone can use.
If this takes off, and if Facebook Instant Articles takes off, there’ll be more more of this (Twitter Instant Articles, Pinterest Instant Images, Reddit Instant Posts…) instead of one rock-solid, standardized system for delivering a content-only version of pages. I think it’s a good idea marred by poor execution.
And especially coming from Google, I have play devil’s advocate here. Assuming this gets enough traction, how long will it be until Google (the search engine) decides to use AMPP as a ranking signal in search results, either publicly or internally?
The Big G will probably play it off as “putting more emphasis into fast loading websites and user experience” (which as we all know is a subtle ranking signal now) so it’ll be interesting to see if a bunch of AMPP sites start to outrank similar content (and speed).
I hate to argue semantics but the website doesn’t really go into details about what exactly “joining” the project really means. Publishers will do just about anything to get a link to their home page so are those publishers actually contributing code or just consulting on the project? Will those publishers actually deploy AMPP pages?
It’s easy for an executive to say “accelerated mobile? Sure, we’d be on board with it…” and then “leave it up to the developers” to figure out the specifics. The Guardian in particular has gone to great lengths to setup their own tools for mobile; then again, as a publisher, I suppose you want to try to publish in any format you can. (They were one of the first ones to support Facebook’s instant articles.)
So this is how they diverge attention from them being that much incompetent to manufacture cheap, accessible-to-all hi quality and performant mobile devices?
They’ll just rewrite or further complicate the web publishing so we do their job for us?? This is a joke!
I had the very same M. = AMP thought the first time I read through the AMP release article and the associated Github project.
Jeremy Keith has written an excellent post and I also weighed in with my own thoughts.
Just burn your blue beanies while you’re at it. While addressing the bloated web isn’t important doing it in such a heavy-handed manner doesn’t seem like a very future-forward approach. Pretty clear this has been brewing for awhile; it’s almost as if Google is saying: “We are so tired of trying to explain performance techniques to all of you. Paul Irish can’t explain 60fps any better than he already has — and yet you folks keep on turning out the jank.” The web belongs to everyone, not just the folks at Google. Problem is we’re all guilty of giving them so much power that in many ways people now think Google truly is the web (much the way people thought their entire web universe was AOL.) I’d rather see the Google Chrome team address their own browser’s bloat & slowness (the recent tab data expiry thing has proven to be a nightmare for most users I know) — and I can’t tell you how many times I end up shutting down Chrome and burning the cache — all the while I’m off getting work done in Firefox. And yes, AMP = M.
edit: “…addressing the bloated web is important…”