AMPed up

Apple has Apple News. Facebook has Instant Articles. Now Google has AMP: Accelerated Mobile Pages.

The big players sure are going to a lot of effort to reinvent RSS.

That may sound like a flippant remark, but it’s not too far from the truth. In the case of Apple News, its current incarnation appears to be quite literally an RSS reader, at least until the unveiling of the forthcoming Apple News Format.

Google’s AMP project looks a little bit different to the offerings from Facebook and Apple. Rather than creating a proprietary format from scratch, it mandates a subset of HTML …with some proprietary elements thrown in (or, to use the more diplomatic parlance of the extensible web, custom elements).

The idea is that alongside the regular HTML version of your document, you provide a corresponding AMP HTML version. Because the AMP HTML version will be leaner and meaner, user agents can then grab the AMP HTML version and present that to the end user for a faster browsing experience.

So if an RSS feed is an alternate representation of a homepage or a listing of articles, then an AMP document is an alternate representation of a single article.

Now, my own personal take on providing alternate representations of documents is “Sure. Why not?” Here on adactio.com I provide RSS feeds. On The Session I provide RSS, JSON, and XML. And on Huffduffer I provide RSS, Atom, JSON, and XSPF, adding:

If you would like to see another format supported, share your idea.

Also, each individual item on Huffduffer has a corresponding oEmbed version (and, in theory, an RDF version)—an alternate representation of that item …in principle, not that different from AMP. The big difference with AMP is that it’s using HTML (of sorts) for its format.

All of this sounds pretty reasonable: provide an alternate representation of your canonical HTML pages so that user-agents (Twitter, Google, browsers) can render a faster-loading version …much like an RSS reader.

So should you start providing AMP versions of your pages? My initial reaction is “Sure. Why not?”

The AMP Project website comes with a list of frequently asked questions, which of course, nobody has asked. My own list of invented frequently asked questions might look a little different.

Will this kill advertising?

We live in hope.

Alas, AMP pages will still be able to carry advertising, but in a restricted form. No more scripts that track your movement across the web …unless the script is from an authorised provider, like say, Google.

But it looks like the worst performance offenders won’t be able to get their grubby little scripts into AMP pages. This is a good thing.

Won’t this kill journalism?

Of all the horrid myths currently in circulation, the two that piss me off the most are:

  1. Journalism requires advertising to survive.
  2. Advertising requires invasive JavaScript.

Put the two together and you get the gist of most of the chicken-littling articles currently in circulation: “Journalism requires invasive JavaScript to survive.”

I could argue against the first claim, but let’s leave that for another day. Let’s suppose for now that, sure, journalism requires advertising to survive. Fine.

It’s that second point that is fundamentally wrong. The idea that the current state of advertising is the only way of advertising is incredibly short-sighted and misguided. Invasive JavaScript is not a requirement for showing me an ad. Setting a cookie is not a requirement for showing me an ad. Knowing where I live, who my friends are, what my income level is, and where I’ve been on the web …none of these are requirements for showing me an ad.

It is entirely possible to advertise to me and treat me with respect at the same time. The Deck already does this.

And you know what? Ad networks had their chance. They had their chance to treat us with respect with the Do Not Track initiative. We asked them to respect our wishes. They told us get screwed.

Now those same ad providers are crying because we’re installing ad blockers. They can get screwed.

Anyway.

It is entirely possible to advertise within AMP pages …just not using blocking JavaScript.

For a nicely nuanced take on what AMP could mean for journalism, see Joshua Benton’s article on Nieman Lab—Get AMP’d: Here’s what publishers need to know about Google’s new plan to speed up your website.

Why not just make faster web pages?

Excellent question!

For a site like adactio.com, the difference between the regular HTML version of an article and the corresponding AMP version of the same article is pretty small. It’s a shame that I can’t just say “Hey, the current version of the article is the AMP version”, but that would require that I only use a subset of HTML and that I add some required guff to my page (including an unnecessary JavaScript file).

But for most of the news sites out there, the difference between their regular HTML pages and the corresponding AMP versions will be pretty significant. That’s because the regular HTML versions are bloated with third-party scripts, oversized assets, and cruft around the actual content.

Now it is in theory possible for these news sites to get rid of all those things, and I sincerely hope that they will. But that’s a big political struggle. I am rooting for developers—like the good folks at VOX—who have to battle against bosses who honestly think that journalism requires invasive JavaScript. Best of luck.

Along comes Google saying “If you want to play in our sandbox, you’re going to have to abide by our rules.” Those rules include performance best practices (for the most part—I take issue with some of the requirements, and I’ll go into that in more detail in a moment).

Now when the boss says “Slap a three megabyte JavaScript library on it so we can show a carousel”, the developers can only respond with “Google says No.”

When the boss says “Slap a ton of third-party trackers on it so we can monetise those eyeballs”, the developers can only respond with “Google says No.”

Google have used their influence like this before and it has brought them accusations of monopolistic abuse. Some people got very upset when they began labelling (and later ranking) mobile-friendly pages. Personally, I’ve got no issue with that.

In this particular case, Google aren’t mandating what you can and can’t do on your regular HTML pages; only what you can and can’t do on the corresponding AMP page.

Which brings up another question…

Will the AMP web kill the open web?

If we all start creating AMP versions of our pages, and those pages are faster than our regular HTML versions, won’t everyone just see the AMP versions without ever seeing the “full” versions?

Tim articulates a legitimate concern:

This promise of improved distribution for pages using AMP HTML shifts the incentive. 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.

Fair point. But I also remember that a lot of people were upset by RSS. They didn’t like that users could go for months at a time without visiting the actual website, and yet they were reading every article. They were reading every article in non-browser user agents in a format that wasn’t HTML. On paper that sounds like the antithesis of the open web, but in practice there was always something very webby about RSS, and RSS feed readers—it put the power back in the hands of the end users.

Some people chose not to play ball. They only put snippets in their RSS feeds, not the full articles. Maybe some publishers will do the same with the AMP versions of their articles: “To read more, click here…”

But I remember what generally tended to happen to the publishers who refused to put the full content in their RSS feeds. We unsubscribed.

Still, I share the concern that any one company—whether it’s Facebook, Apple, or Google—should wield so much power over how we publish on the web. I don’t think you have to be a conspiracy theorist to view the AMP project as an attempt to replace the existing web with an alternate web, more tightly controlled by Google (albeit a faster, more performant, tightly-controlled web).

My hope is that the current will flow in both directions. As well as publishers creating AMP versions of their pages in order to appease Google, perhaps they will start to ask “Why can’t our regular pages be this fast?” By showing that there is life beyond big bloated invasive web pages, perhaps the AMP project will work as a demo of what the whole web could be.

I’ve been playing around with the AMP HTML spec. It has some issues. The good news is that it’s open source and the project owners seem receptive to feedback.

JavaScript

No external JavaScript is allowed in an AMP HTML document. This covers third-party libraries, advertising and tracking scripts. This is A-okay with me.

The reasons given for this ban are related to performance and I agree with them completely. Big bloated JavaScript libraries are one of the biggest performance killers on the web. I’m happy to leave them at the door (although weirdly, web fonts—another big performance killer—are allowed in).

But then there’s a bit of an about-face. In order to have a valid AMP HTML page, you must include a piece of third-party JavaScript. In this case, the third party is Google and the JavaScript file is what handles the loading of assets.

This seems a bit strange to me; on the one hand claiming that third-party JavaScript is bad for performance and on the other, requiring some third-party JavaScript. As Justin says:

For me this is loading one thing too many… the AMP JS library. Surely the document itself is going to be faster than loading a library to try and make it load faster.

On the plus side, this third-party JavaScript is loaded asynchronously. It seems to mostly be there to handle the rendering of embedded content: images, videos, audio, etc.

Embedded content

If you want audio, video, or images on your page, you must use propriet… custom elements like amp-audio, amp-video, and amp-img. In the case of images, I can see how this is a way of getting around the browser’s lookahead pre-parser (although responsive images also solve this problem). In the case of audio and video, the standard audio and video elements already come with a way of specifying preloading behaviour using the preload attribute. Very odd.

Justin again:

I’m not sure if this is solving anything at the moment that we’re not already fixing with something like responsive images.

To use amp-img for images within the flow of a document, you’ll need to specify the dimensions of the image. This makes sense from a rendering point of view—knowing the width and height ahead of time avoids repaints and reflows. Alas, in many of the cases here on adactio.com, I don’t know the dimensions of the images I’m including. So any of my AMP HTML pages that include images will be invalid.

Overall, the way that AMP HTML handles embedded content looks like a whole lot of wheel reinvention. I like the idea of providing custom elements as an option for authors. I hate the idea of making them a requirement.

Metadata

If you want to provide metadata about your document, AMP HTML currently requires the use of Google’s Schema.org vocabulary. This has a big whiff of vendor lock-in to it. I’ve flagged this up as an issue and Aaron is pushing a change so hopefully this will be resolved soon.

Accessibility

In its initial release, the AMP HTML spec came with some nasty surprises for accessibility. The biggest is probably the requirement to include this in your viewport meta element:

maximum-scale=1,user-scalable=no

Yowzers! That’s some slap in the face to decent web developers everywhere. Fortunately this has been flagged up and I’m hoping it will be fixed soon.

If it doesn’t get fixed, it’s quite a non-starter. It beggars belief that Google would mandate to authors that they must make their pages inaccessible to pinch/zoom. I would hope that many developers would rebel against such a draconian injunction. If that happens, it’ll be interesting to see what becomes of those theoretically badly-formed AMP HTML documents. Technically, they will fail validation, but for very good reason. Will those accessible documents be rejected?

Please get involved on this issue if this is important to you (hint: this should be important to you).

There are a few smaller issues. Initially the :focus pseudo-class was disallowed in author CSS, but that’s being fixed.

Currently AMP HTML documents must have this line:

<style>body {opacity: 0}</style><noscript><style>body {opacity: 1}</style></noscript>

shudders

That’s a horrible conflation of JavaScript availability and CSS. It’s being fixed though, and soon all the opacity jiggery-pokery will only happen via JavaScript, which will be a big improvement: it should either all happen in CSS or all happen in JavaScript, but not the current mixture of the two.

Discovery

The AMP HTML version of your page is not the canonical version. You can specify where the real HTML version of your document is by using rel="canonical". Great!

But how do you link from your canonical page out to the AMP HTML version? Currently you’re supposed to use rel="amphtml". No, they haven’t checked the registry. Again. I’ll go in and add it.

In the meantime, I’m also requesting that the amphtml value can be combined with the alternate value, seeing as rel values can be space separated:

rel="alternate amphtml" type="text/html"

See? Not that different to RSS:

rel="alterate" type="application/rss+xml"

POSSE

When I publish something on adactio.com in HTML, it already gets syndicated to different places. This is the Indie Web idea of POSSE: Publish (on your) Own Site, Syndicate Elsewhere. As well as providing RSS feeds, I’ve also got Twitter bots that syndicate to Twitter. An If This, Then That script pushes posts to Facebook. And if I publish a photo, it goes to Flickr. Now that Medium is finally providing a publishing API, I’ll probably start syndicating articles there as well. The more, the merrier.

From that perspective, providing AMP HTML pages feels like just one more syndication option. If it were the only option, and I felt compelled to provide AMP versions of my content, I’d be very concerned. But for now, I’ll give it a whirl and see how it goes.

Here’s a bit of PHP I’m using to convert a regular piece of HTML into AMP HTML—it’s horrible code; it uses regular expressions on HTML which, as we all know, will summon the Elder Gods.

Have you published a response to this? :

Responses

egojab

@zeldman lost in the “tracking scripts not allowed in AMP” as a good thing narrative is that Google just gets all tracking in serving

# Posted by egojab on Saturday, October 10th, 2015 at 7:51pm

Jeremy Keith

@stilkov The WHATWG settled on the microformats registry as the official “home” of link relations a while back.

felix schwenzel

vor ein paar tagen hat google die spezifikationen für amphtml veröffentlicht und eine demo veröffentlicht, was sie in etwas damit zu tun gedenken. die demo kann man sich hier mit einem mobilen browser (oder einem mobilen user agent) ansehen (dort dann nach obama oder zum beispiel faz suchen). die spezifikationen für amphtml hat google auf github gepackt. google hat auch eine animation erstellt, die zeigten soll wie amp-seiten in den google-sucheergebnissen funktionieren könnten.

was google mit amp bezweckt ist klar, wenn man sich die demo oder die selbstbeschreibung des projekts ansieht: schnellere (mobile) webseiten. oder im sinne der gleichen facebook-idee: sofortseiten.

jeff jarvis ist naturgemäss begeistert und sieht seine idee der einfachen verteilung (distribution) von publizistischen inhalten im web durch amp gestärkt:

But I think AMP and Instant Articles are more than that. They are a giant step toward a new, distributed content ecology on the web.

wolfgang blau auch:

what excites me most about ampproject.org is how it might allow publishers to not just distribute, but aggregate more seamlessly.

Wolfgang Blau (@wblau07.10.2015 15:16

tim kadlec formuliert den gedanken etwas ausführlicher aus:

It’s the distribution that makes AMP different. It’s the distribution that makes publishers suddenly so interested in building a highly performant version of their pages—something they’re all capable of doing otherwise. AMP’s promise of improved distribution is cutting through all the red tape that usually stands in the way.

This promise of improved distribution for pages using AMP HTML shifts the incentive. 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.

und ich finde genau das spannend. google zwingt die verleger, bzw. alle die im netz veröffentlichen dazu, sich zu beschränken. so wie twitter einen zwingt sich kurz zu fassen, zwingt amp einen dazu sich den (technischen) regeln der auslieferungsbeschleunigung zu unterwerfen (was unterm strich zu erhöhtem lesekomfort führt).

das ist an sich schon eine gute sache, weil die verleger nun einen guten grund haben, von ihren vermarktern bessere, weniger arschig programmierte anzeigen zu verlangen. anzeigen sind zwar in amp-seiten möglich, müssen sich aber an bestimmte regeln halten (bis diese womöglich ausgehelbelt werden). felix salmon formuliert das im guardian (auf einer amp-seite) so:

Ultimately it comes down to power dynamics. Advertisers and media buyers have more power than any individual publisher: they can demand more intrusive ads, trackers, scripts, and publishers will comply, lest they lose revenue. But one entity is even more powerful than the ad industry – Google. If Google tells everybody to turn off those scripts, they will – and advertisers will be forced to compete on the basis of creative output, not technological firepower.

ray daly sagt das gleiche:

So another impact of AMP will be that news organizations will have to re-evaluate their use of third party scripts and demand use of best practices by these vendors.

noch spannender finde ich, dass plötzlich verleger, denen die idee von volltext-RSS-feeds schon immer zuwider war, plötzlich bei amp an bord zu sein scheinen. selbst die FAZ pfeffert jetzt ihre inhalte in einem format raus, mit dem leser diese inhalte plötzlich wie mit RSS lesen können. denn amp erlaubt, wie RSS, durch einen festen gestaltungsrahmen ein caching (zwischenspeichern) der inhalte durch apps, reader oder, wie oben demonstriert, suchmaschinen. konzeptionell und technisch sind die parallelen zu RSS offensichtlich. jeremy keith schreibt in seiner ausführlichen und lesenswerten amp-analyse:

So if an RSS feed is an alternate representation of a homepage or a listing of articles, then an AMP document is an alternate representation of a single article.

Now, my own personal take on providing alternate representations of documents is “Sure. Why not?” Here on adactio.com I provide RSS feeds. On The Session I provide RSS, JSON, and XML. And on Huffduffer I provide RSS, Atom, JSON, and XSPF, adding:

If you would like to see another format supported, share your idea.

Also, each individual item on Huffduffer has a corresponding oEmbed version (and, in theory, an RDF version)—an alternate representation of that item …in principle, not that different from AMP. The big difference with AMP is that it’s using HTML (of sorts) for its format.

All of this sounds pretty reasonable: provide an alternate representation of your canonical HTML pages so that user-agents (Twitter, Google, browsers) can render a faster-loading version …much like an RSS reader.

So should you start providing AMP versions of your pages? My initial reaction is “Sure. Why not?”

wie die auslieferung per amp-seite funktioniert, zeigt bereits die reader-app nuzzel. sie aggregiert und filtert links aus meinen social-media-feeds und zeigt mir empfehlungen aus meinem bekanntenkreis an. klicke ich auf den link zu einer seite die auch eine amp-version anbietet, lädt sie nicht die reguläre seite, sondern die mobil-optimierte amp-version. twitter hat angekündigt das auch so zu machen und, natürlich, auch google wird das das irgendwann in seine mobile suche integrieren.

* * *

ich bin ja schon immer ein agressiver verfechter der volltext-rss-idee, der idee, inhalte so einfach wie möglich zugänglich zu machen und niemandem vorzuschreiben wo oder wie er inhalte zu lesen hat. bereits vor 4 monaten habe ich facebooks instant articles-idee mit RSS verglichen und natürlich schlägt amp in die gleiche kerbe. mit einem unterschied natürlich: facebook und google (und apple) versuchen von anfang an wege der monetarisierung (sprich werbung) in ihre lösungen einzubauen.

es dürfte spannend sein, wie die verleger langfristig zu amp, instant articles oder ähnlichen initiativen von apple und anderen stehen werden. es ist nicht auszuschliessen, dass sie irgendwann muffensausen bekommen, angesichts des unabwendbaren kontrollverlusts. möglicherweise sind sie auch irgendwann völlig überfordert mit dem irren formate-müsli, das derzeit aus dem silicon valley geliefert wird: google hat ein eigenes format, facebook verlangt ein eigenes format und apple hat sein „apple-news-format“ noch gar nicht veröffentlicht.

mir ist das (natürlich) völlig egal, ich habe an zwei abenden das amp-format in diese seite integriert. das war nicht besonders kompliziert, im prinzip habe ich die druckseitenfunktion meines CMS missbraucht, bzw. umgebaut (und um ein paar funktionen erweitert). seiten auf dieser site lassen sich dank druck-CSS-stylesheet bestens ausdrucken (wer auch immer sowas macht), also liess sich die eingebaute druckfunktion, die über wirres.net/article/print/8649/1/6/ erreichbar war, zu einer amp-funktion umbauen. weil „print“ in der url aber doof ist, sind meine seiten offiziell über /article/amp/ ampifizierbar, natürlich auch diese: wirres.net/article/amp/8649/1/6/.

(eine noch sehr frühe amp-konversions beta-version für wordpress gibt es übrigens bereits.)

* * *

erstaunlich am ampproject ist, wie fehlerhaft es noch ist. die proprietäre video-erweiterung amp-video ist noch nicht ganz fertiggestellt, bzw. buggy, viele details scheinen noch unausgegoren und besonders witzig, googles eigenes beschleunigungswerkzeug empfiehlt dem ampproject verbesserungsmassnahmen:

auch die projektseite hält google für sehr verbesserungswürdig.

* * *

insgesamt sehe ich das amp-projekt als eine der spannensten sachen die dem web seit dem web 2.0 passiert ist. das web 3.0 wird (wieder) schlanker. und das ist in diesem fall eine gute sache.

Jeremy Keith

@deadlyhifi No, I use alternate because that’s what’s specced (much like color and background-color are specced in CSS).

Dan

@Niaccurshi Well that just sounds F&%king annoying tbh. Who are these people who haver performance issues with websites? Peasants?

# Posted by Dan on Tuesday, October 13th, 2015 at 10:18pm