Google AMP: Top oder Flop?

Googles AMP ist ein Open Source Projekt, das ersonnen wurde, um die mobile UX des Webs zu verbessern, indem es vor allem dafür sorgt, dass Web-Inhalte weitaus schneller als bisher ausgeliefert werden. Das klingt zunächst sehr gut, spiegelt aber nur die offizielle Zielsetzung wider. 

Sicherlich ist darin ein Fünkchen Wahrheit enthalten. Der eigentliche Grund für AMP liegt jedoch auf einer anderen Hand. Denn die erstaunliche Koinzidenz ist doch, dass Google AMP als Konkurrenten zu Facebooks Instant Articles positioniert hat. Ohne Facebooks Vorstoß namens Instant Articles hätte es vermutlich auch keine Reaktion namens AMP gegeben. So lautet zu mindestens für mich die simple Wahrheit.

AMP: Startseite des Projekts. (Screenshot: D. Petereit)

Warum aber sind die Instant Articles für Google ein solches Problem, dass sie mit einer Gegenlösung kontern? Das ist einfach zu beantworten: Instant Articles bringen Webinhalte direkt in die Facebook-Umgebung. Facebook-User müssen dank Instant Articles das soziale Netzwerk quasi nie wieder verlassen.

Kommt es dazu, läuft Google trocken. Keiner braucht mehr den Suchmaschinenriesen aus Mountain View, wenn sich alles, was es zu finden gibt, innerhalb von Facebook befindet. Eine solche Entwicklung gilt es nachvollziehbarerweise (nicht nur) aus Googles Sicht unbedingt zu vermeiden. Wie wir wissen, verdient Google mit seinen sämtlichen sonstigen Geschäftsansätzen nichts. Ausschließlich die Such-Sparte ist für die satten Gewinne der Kalifornier verantwortlich. Ausgestattet mit diesem Hintergrund, fällt es leicht, den Sinn hinter AMP zu erkennen. Es geht dabei nicht um eine verbesserte Benutzererfahrung oder ein schnelleres Web (zumindest nicht in erster Linie), sondern primär darum, Googles Existenz zu sichern. Es gilt, dafür zu sorgen, dass Facebook – ohnehin schon die mit Abstand größte Website der Welt – nicht noch mehr Marktanteil gewinnt und damit gleichsam synonym zum Web wird.

Ebenfalls vor diesem Hintergrund wird auch klar, wieso AMP eine dermaßen simple Lösung ist. Es ging schließlich darum, Facebook mit einer vergleichbar simplen Lösung Paroli zu bieten. Offen sagen wollte Google das so natürlich nicht. So entstand die Mär der Verteidigung des offenen Webs gegen den blauen Riesen aus Palo Alto. Deswegen ist AMP ein Open Source Projekt und setzt auf ähnlich schmale Technologien wie die Instant Articles des Wettbewerbers. Aufgrund der Marktmacht Googles fanden sich schnell haufenweise Publisher, die sich hinter dem Ansatz versammelten, während die breite Masse der Webentwickler skeptisch blieb.

Die wesentlichen Gegenargumente lauten wie folgt:

Tatsächlich erreicht AMP einen großen Teil seiner Performancevorteile darüber, dass es nur eine beschränkte Untermenge an HTML-Befehlen zulässt. Noch mehr Geschwindigkeitsvorteil entsteht daraus, dass in AMP, abgesehen von Googles dafür erforderlichen Javascripts, keinerlei Javascript erlaubt ist.

Man könnte also die wichtigsten Effekte auch mit eigenen Optimierungsbemühungen erreichen. Schau sich nur einer die Massen an Javascript an, die heutzutage für jede noch so kleine Funktionalität geladen werden. Speckt das ab und die Seite wird schnell. Ebenso klar ist es doch, dass weniger HTML-Elemente schneller rendern. Vor allem, wenn komplexe Elemente nicht Teil des AMP-Subsets sind. Das ist nicht innovativ, sondern schlicht logisch.

Großzügigerweise stellt Google seine Cloud zu Caching-Zwecken bereit. AMP-Inhalte werden entsprechend wie bei jedem guten Content Delivery Network immer ortsnah zum Besucher ausgeliefert. Das ist natürlich schneller, als wenn jeder Request über den Webserver der Quelle laufen würde.

Der Haken an der Sache ist, dass eure Inhalte dadurch über Google-Server ausgeliefert werden, nicht über eure eigenen. Da klingeln doch bei jedem Webentwickler sämtliche Alarmglocken. Bis vor einigen Monaten war es sogar noch so, dass das weitere Teilen der so ausgelieferten Beiträge auf mobilen Geräten ebenfalls über die URL des AMP-Caches erfolgte.

Ihr musstet also mit dem Einsatz von AMP auf den kompletten Traffic eurer mobilen Nutzer verzichten. Inzwischen hat Google auf die Proteste reagiert und trägt dafür Sorge, dass beim Teilen von AMP-Beiträgen über iOS und Android die Original-URL verwendet wird. Das indes, funktionierte in meinen Tests nicht sonderlich zuverlässig – oft genug blieben die Google URLs erhalten. Das ist nicht der einzige Haken. Dadurch, dass die Auslieferung aus dem Cache erfolgt, habt ihr nicht die Statistiken, die ihr ansonsten zur Verfügung hättet. Vielmehr bietet euch Google eine Untermenge statistischer Funktionen, die sie für euch als ausreichend definiert haben.

Es ist besonders die Kopplung an den Google-Cache, die Webentwickler suspekt finden. AMP als ein mögliches Framework für die Performance-Optimierung würde viel eher auf dem Markt akzeptiert. So aber verschiebt es den Wettbewerb. Performance können viele Frameworks bieten, die optimierte Distribution gleich mitliefern kann nur AMP.

Das offene Netz ist dezentral, basiert auf Standards und es privilegiert Inhalte nicht schon wegen der eingesetzten Technik. AMP hingegen ist zentralisiert, kein Standard und priorisiert Seiten, die darauf basieren. Dazu kann es keine zwei Meinungen geben.

Auffällig ist, dass die Befürworter des neuen Formats sich vornehmlich aus den Reihen der Content-Publisher, nicht aus jenen der Webentwickler, rekrutieren. Aus deren Blickwinkel ist die positive Einstellung AMP gegenüber ebenfalls verständlich.

Ob es nun Instant Articles, ein RSS-Feed, die sozialen Netzwerke oder eben AMP ist – die Hauptsache ist, dass der Content beim Konsumenten ankommt. Speziell, wenn eure Inhalte etwas verkaufen sollen, kann euch nur jeder weitere Kanal recht sein.

Sicherlich könnte man viele der Effekte, die AMP bietet, auch über eine optimierte Webprogrammierung erreichen. Mit AMP ist es aber viel leichter und erfordert weit weniger Skills in der IT-Abteilung. Durch das begrenzte Subset an möglichen Elementen habt ihr eine schöne Checkliste an der Hand, die ihr nur Punkt für Punkt abhaken müsst.

So sind es konsequenterweise weder die Publisher noch Google, die AMP den entscheidenden Schub geben. Es sind die Entwickler von Apps, die auf Dritt-Content verlinken, wie beispielsweise Flipboard.

In einem Beitrag für Search Engine Land beschreibt die Autorin Barb Palser das Phänomen, dass sie seit etwa Anfang 2017 immer mehr Traffic in ihren AMP-Statistiken sieht, der nicht von Google, sondern von Apps wie LinkedIn oder Flipboard kommt. Auch der AMP-Traffic über Twitter und Facebook stieg abrupt.

(Illustration: Search Engine Land)

Der Hintergrund ist an sich nicht schwer zu verstehen: App-Entwickler wollen Inhalte schnell darstellen, um Wartezeiten für ihre Nutzer zu reduzieren. Was liegt da näher, als app-seitig eine Funktion zu implementieren, die für einen Link prüft, ob es ihn auch als optimierte AMP-Version gibt, um dann im Zweifel diese zu laden?

Diese Prüfung ist sehr einfach, weil jede Website, die auch mit AMP arbeitet, Links zu den AMP-Varianten im Header führt. Umgekehrt führen die AMP-Seiten zurück zu den Desktop-Varianten, sodass klar zu definieren ist, welche Seiten wie zusammengehören.

Flipboard verlinkt bevorzugt AMP-Seiten. (Screenshot: D. Petereit)

Neben der Geschwindigkeit dürfte für Anbieter von Dritt-Apps auch der eher standardisierte optische Aspekt eine Rolle spielen. Das Layout lässt sich mit AMP insgesamt leichter kontrollieren. Aus App-Entwickler-Sicht spricht eigentlich alles für AMP und nichts für das Zeigen einer konventionellen, mobil-optimierten Website. Schon gar nicht, wenn der Content über verschiedene Quellen zusammengemischt wird.

Der CDN-Anbieter Cloudflare nahm zwischenzeitlich das Feature „Accelerated Mobile Links” in sein Angebot auf. Dieses automatisiert die eben beschriebene Auswahl bestehender AMP-Links für jedermann, also alle Kunden des Dienstes. Existiert von einem beliebigen Link eine AMP-Version, sorgt Cloudflare dafür, dass diese angesprochen wird, auch wenn sie nicht explizit als solche verlinkt wurde.

News-Publisher mit eigenen Apps werden verstärkt selber auf die Idee kommen, ihre Beiträge als AMP anzusteuern. Wie der Selbstversuch der Mediengruppe SH:Z aus Schleswig-Holstein zeigt, beschleunigte sich der Zugriff auf die Inhalte durch die Umstellung der hauseigenen App auf AMP um das Vierfache, was direkt dazu führte, dass pro Session rund 25 Prozent mehr Pageviews gezählt werden konnten. 

Fazit der SH:Z: Die Leserinnen und Leser bleiben durch schnellere Bereitstellung der Inhalte auch tatsächlich länger auf dem Angebot.

Wenn ihr eure Website auf der Basis von WordPress betreibt, solltet ihr über die Nutzung des offiziellen AMP-Plugins aus dem Hause "Automattic" nachdenken. Einfacher lässt sich eine Seite nicht um AMP erweitern. Das Plugin könnt ihr in gewohnter Weise über das Plugin-Verzeichnis installieren.

War es zunächst nicht möglich, etwa Formulare zu integrieren, ist das heutzutage problemlos erledigt. AMP entfernt sich immer weiter vom Konzept „Performance durch Weglassen von Elementen“ hin zu „Performance trotz vieler Elemente“. Der wesentliche Geschwindigkeitsvorteil ergibt sich dabei nach wie vor durch das Caching der AMP-Seiten auf Googles Infrastruktur. 

Der neueste Eckpfeiler wurde vor einigen Monaten gesetzt. Mit den AMP Stories bringt Google nicht weniger als eine völlig neue Art des Storytellings auf mobile Geräte – wobei,  es ist eher eine Art, die wir bislang so nicht gesehen haben, weil die Publisher den Aufwand der Erstellung scheuten.

Das neue Element soll das Storytelling auf mobilen Geräten interessanter machen. (Screenshot: Google)

Google vereinfacht diesen Prozess mit der Einführung der neuen Komponente "amp-story" so erheblich, dass die Erstellung visuell ansprechender News-Formate bald schon zum Redaktionsalltag in deutschen Medienhäusern gehören dürfte. So überrascht es auch nicht, dass es eben diese Medienhäuser sind, die zu den Pionieren der AMP Stories zählen.

Inzwischen kann jeder Seitenbetreiber seine ersten Gehversuche mit AMP-Stories machen. Schaut euch dieses Tutorial an und seht selbst, wie vergleichsweise einfach es ist, schöne Geschichten zu erzählen. Den guten Inhalt müsst ihr allerdings selber mitbringen. ;-) 

Einer der grundlegenden Kritikpunkte ist der, dass AMP keine Entwicklung des offenen Webs ist, sondern der Kontrolle durch ein einzelnes Unternehmen unterliegt. Damit haben durchaus viele ein Problem.

Nachdem seitens Google jahrelang mit Beteuerungen gearbeitet wurde, man müsse sich diese Sorgen wirklich nicht machen, sind die Kalifornier inzwischen einen Schritt weiter. Im September 2018 gaben sie bekannt, dass künftig ein Committee die Zukunft des Formats bestimmen solle. Das neu zu schaffende Committee wird sich aus Google-Mitarbeitern, aber auch aus "Kontributoren" außerhalb der Google-Sphäre zusammensetzen. Es bleibt abzuwarten, inwieweit hier mehr als eine Feigenblatt-Funktion erfüllt werden wird.

Gleichzeitig pusht der Suchmaschinenriese das Projekt mit Vehemenz nach vorne. Einem aktuellen Blogeintrag auf Polemic Digital ist zu entnehmen, dass Google die Search Console dazu benutzt, vermeintliche Fehler und Missstände auf Websites anzuprangern, die letztlich keine sind. 

Hier bemängelt Google Abweichungen in der Navigationsstruktur der AMP-Seite. (Screenshot: Polemic Digital)

Über eine Reihe von Screenshots weist Polemic Digital nach, dass die Meldungen der Google Search Console Kunden mutmaßlich dazu bringen sollen, ihre AMP-Seiten funktionsgleich zu ihrer übrigen Website zu gestalten. Die Vermutung dahinter: Google wolle den Übergang vom WWW zum AMP-Web erzwingen. 

Gleichzeitig  stellt Chartbeat in einer Studie fest, dass zwei von drei Publishern die angekündigten Traffic-Zuwächse durch AMP tatsächlich gar nicht sehen würden. Womit natürlich ein wesentliches Argument pro AMP relativiert wäre. Es bleibt spannend.