Ohne ernstzunehmende Konkurrenz im Suchmaschinenmarkt, muss Google ohne Mitbewerber für Innovationen sorgen. Denn gleichzeitig behalten Social Networks wie Facebook ihre Nutzer am liebsten bei sich. Je benutzerfreundlicher die Nutzung von Google ist und je besser die Ergebnisse sind, desto mehr wird weiterhin Google für die Recherche genutzt. Besonders wichtig war Google neben der Empfehlungen (Links) von anderen Websites auch der Inhalt – und die technische Qualität einer Website. Besonders einfach ließ sich diese z.B. über deren Geschwindigkeit bei der Auslieferung messen. Hierzu hat Google im Jahr 2009 den PageSpeed-Score eingeführt und seither stetig weiterentwickelt. Für Webmaster eine gute Möglichkeit, die Benutzererfahrung zu verbessern, denn je schneller die Website ausgeliefert wird, desto zufriedener der Besucher. Google Amp wurde 6 Jahre später, also 2015 eingeführt, da es Google mit der PageSpeed-Optimierung der Websites anscheinend nicht schnell genug voran ging. Im Gegensatz zu unserem PageSpeed 100 WordPress Theme sind viele Websites nach wie vor eher schlecht hinsichtlich ihrer Performance optimiert, eine nachträgliche Optimierung ist in vielen Fällen nur mit Abstrichen möglich. Für viele Websitebetreiber kommt aus Budgetgründen ein technischer Relaunch jedoch nicht in Frage. Ein Kompromiss sollte Google Amp bieten: Eine mobil- & performanceoptimierte Variante einer sonst nur noch schlecht optimierbaren Website.
Die Idee
Weniger ist mehr
Google Amp ist ein alternativer Standard und beschränkt die von den Internetgremien wie W3C beschlossenen Standards ein, um eine abgespeckte, mobiloptimierte Version einer Website, insbesondere von Newsbeiträgen auszuliefern. Komplexes Javascript, Tracking oder Anzeigen wurden unterbunden oder eingeschränkt, ebenso komplexe Styles via CSS oder Einbindung von Drittanbieterdiensten – all das definiert im AMP HTML Standard, eine eigene Auswahl an HTML-Tags innerhalb des Amp-Kosmos.
Nun war in der Vergangenheit selten der ursprüngliche Technologie-Standard das Problem, sondern der (häufig zweckentfremdete) Einsatz durch die Websitebetreiber.
Amp-Seiten bieten im Zweifel also viel weniger Möglichkeiten für den Websitebetreiber und den Besucher, eine Holzhammer-Methode für eine möglichst schnelle Auslieferung. Im Grunde ein Web Light.
Der restriktive Standard erlaubt es Google außerdem die einzelnen Seiten sehr leicht zwischenzuspeichern und beschleunigt auszuliefern – so dass diese noch schneller ausgeliefert werden. Google konnte sich bei einer Amp-Seite also relativ sicher sein, dass sie zügig ausgeliefert wird und machte die Verwendung von Amp zur Voraussetzung, um in den Top Stories von Google News zu erscheinen.
Jede Newsseite, die nicht auf den Traffic von Google News verzichten wollte, musste also Amp unterstützen.
Die Amp-Versionen waren unter einer eigenen Adresse als Alternativversion verfügbar und musste als separate Ausgabe der Seite technisch gepflegt werden.
Statt also die Webmaster zu motivieren, ihre lahmen Websites strukturell zu beschleunigen, wurde eine Light-Variante zur Pflicht deklariert die in manchen Fällen so aufwändig sein konnte, wie ein technischer Relaunch der eigentlichen Website.
Selbst wenn der Websitebetreiber nun eine Website mit PageSpeed 100 hat, voll responsiv für jede Auflösung – Google News bleibt ihm verwehrt, solange nicht noch zusätzlich Google Amp unterstützt wird.
Als würde man von einem Hausbauer verlangen jeweils ein Dach für Sonne, Regen und Schnee bereitzustellen, je nach Wetterlage, statt auch eines aus einem Material zu akzeptieren, das allen Bedingungen standhält.
Man hätte sich von Google gewünscht, auch Websites mit einem PageSpeed 80+ oder 90+ für die Google News Top Stories zu akzeptieren.
Häufig kommt es dann vor, dass ein Mobilnutzer auf der Amp-Variante einer Website landet und z.B. diesen Link an Freunde oder Kollegen teilt, die dann die Mobil-Amp-Version auf ihrem Desktop-PC öffnen – benutzerfreundlich ist anders. Das ganze erinnert an Websites, die statt einer Responsive-Optimierung für jede Auflösung neben einer Desktop- noch eine eigene Mobil-Version ausliefern – Web 1.0.
Ziele statt Vorgaben
Amp vs Core Web Vitals
Google hat seine Möglichkeiten zur Bewertung und Optimierung von Websites inzwischen stark verbessert – die Nutzererfahrung wird über die reine Seitenladezeit hinaus gemessen, beispielsweise ob es zu Layout-Verschiebungen beim Laden kommt oder wie die gefühlten Ladezeiten für einen Nutzer sind (sichtbare Inhalte werden zuerst geladen) oder ob die realen Ladezeiten besonders hoch sind (Simulation eines Seitenabrufs statt Nutzung eines reinen Textbrowsers).
Die Core Web Vitals fassen mehrere Key Performance Indicators (KPI) zusammen, die es erlauben die Websitequalität zu prüfen und anhand konkreter Best Practices zu verbessern. Statt den Nutzern also bestimmte restriktive Eigenstandards zu diktieren, gibt Google nur das Ziel vor – meist ohne eine bestimmte Technologie vorzuschreiben.
Schöne, individuelle und schnelle Websites werden damit belohnt und Investitionen zahlen sich eher aus – am Ende gewinnt der Nutzer, der so eher von Google die beste Antwort auf seine Suchanfrage erhalten hat – unabhängig von der konkret eingesetzten Technologie der Website. Für den Nutzer spielt es schlicht keine Rolle, ob eine Website über das Google CDN oder ein anderes CDN besonders schnell ausgeliefert wird – hauptsache schnell.
Ab Mai 2021 ist der Spuk mit Google Amp vorbei: Websites mit schlechter Grundstruktur werden weiter Amp nutzen, um in den Google News Top Stories gelistet zu werden – Websites mit PageSpeed-optimierter Struktur werden Aufwände für Amp kaum noch rechtfertigen können – die Zeit ist in die weitere Optimierung der Hauptstruktur der Website besser investiert, als in einer zusätzlichen Amp-Version.