Accelerated Mobile Pages - a quick reaction

Today Google launched the Accelerated Mobile Pages Project:

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.

Which sounds very much in tune with indieweb goals, so I had a quick look. My first reaction was one of shock, as it said SVG was banned:

However, google responded that they had forgotten to update the pubic spec and most SVG is supported.

Phew. Thanks, G.

The broad goal of this spec is to simplify pages, and they do this by banning all javascript except their own (thereby confirming Marco's precept that blocking all 3rd party javascript is the answer).

That fits in with Tantek's js;dr point of view to some extent, except they leave loophole for their own js code, which while fast and well written compared to most ad content, still breaks some things.

Specifically, they replace img, audio, video with their own versions implemented as custom elements and so requiring javascript to appear. They ban loaded style sheets, requiring inline styles, but oddly allow font-face, one of the slowest things on the mobile web. They also replace the twitter embed fallback markup with a custom type made up by themselves, which combined with the iframe ban means that you need their blessing to extend the web.

This means that if javascript is not loaded, images will disappear.

They also require a lot of arbitrary weird markup (like emoji in the html element, which violates content encoding, a weird style incantation that makes the page opaque, and require the proprietary schema.org markup.

Now, my site is not very complex; indeed it loads very fast on mobile already, but it does use a few javascript enhancements: fragmention to let you link to a phrase; webmention injection for comments as seen below, and the twitter embed enhancement javascript. Without these, the page still renders and makes sense, and it is parseable as microformats. This is known as progressive enhancement; AMP looks more like graceless degradation - the amp page without js is entirely blank because of the required style tag that sets opacity to 0.

There is no good reason to use amp-video or amp-audio over video or audio tags- the reason given for img—that AMP want control over preloading—is already present in audio and video tags, as you can just set preload=none on the tag itself. Here's a page with lots of hi-def videos that loads rapidly, and waits for you to hit play.

Talking of video, I discussed AMP with Jeff Jarvis and Leo Laporte on TWiG this week:

Jeff's perspective that this is a way to get publishers out from under the weight of their accumulated adtech debt, and to get their articles out elsewhere on the web is a important one, as is Leo's reluctance as a publisher to change all his site templates again to conform to this.

Here's a version of this page with JS removed, here's the AMP version, and here's the AMP version without js