colspan=8: AMP oder nicht AMP II
AMP wird viel kritisiert. Nichtsdestoweniger hat es Erfolg und lockt mit höherem Ranking und mehr Traffic. Auf technischer Seite scheint empfehlenswert, auf AMP zu verzichten – oder alles darauf zu setzen.
- Jens Oliver Meiert
AMP wird viel kritisiert. Nichtsdestoweniger hat es Erfolg und lockt mit höherem Ranking und mehr Traffic. Auf technischer Seite scheint empfehlenswert, auf AMP zu verzichten – oder alles darauf zu setzen.
Die Probleme mit AMP sind bekannt: Mobile-First-Idealismus nutzt Ranking-Liebe, um über technische Willkür dem Nutzer zu dienen – AMP ist nicht standardisiert, genauso wenig wie sein unglücklicherweise zu wenig beachtetes chinesisches Pendant MIP. Zumindest dem ersten Anschein nach.
Doch ein Problem taucht nicht in jeder Liste zu AMP auf: Es zwingt zu viel Duplizierung und zu vielen Sonderlösungen. Dadurch dass AMP so willkürlich ist, muss viel Code angepasst oder neu geschrieben werden – man bläht die Code-Basis auf oder hinterlässt sich selbst jede Menge technische Schulden.
AMP oder nicht AMP
An AMP scheiden sich die Geister. Aus gutem Grund, glaubt man allein der Argumentation des AMP Letter.
Wenn man nun berücksichtigt, dass wir das alles schon ein paar Mal hatten – mit WAP/WML von etwa 2001 bis 2003 und separaten mobilen Websites von 2006 bis grob 2010 – und AMP uns angesichts der ganzen Probleme und Kosten auch nicht allzu lange begleiten wird, muss die Empfehlung nun eigentlich lauten: Finger weg.
Wenn man aber einen Weg sucht, AMP einzusetzen, ohne "anderthalb bis zwei" Websites zu pflegen, dann gibt es noch eine andere Pille: nur AMP, ausschließlich AMP. Das mutet zwar erst komisch an, vor allem wenn man bedenkt, wie einschränkend das effektiv proprietäre Korsett von AMP denn wirklich ist, hat aber den Vorteil, dass man weiterhin nur eine Website (oder App, oder Template-Sammlung) baut und wartet. Sie kommt nur für die in Frage, die gerade ganz neu bauen, und mit dem Risiko, dass AMP wahrscheinlich wie alles andere in ein paar Jahren ebenfalls über den Jordan geht – aber immerhin.
Sicherlich gibt es noch Zwischenlösungen, wie sich strategisch die wichtigsten Seiten herauszupicken und nur diese dann als AMP zur Verfügung zu stellen, und das möglichst frühzeitig im Design- und Entwicklungsprozess eingebunden. Aber das ist auch alles Käse, und was wir wieder haben, ist das Problem, dass uns sofort hätte auffallen und als betroffene Gruppe rebellieren lassen müssen: dass es keine Option ist, ob nun WML oder .mobi oder AMP oder MIP genannt, Inhalte und Designs und Code x-fach neu zu schreiben und gestalten und zu bauen. Aus irgendeinem Grund wurde und wird das immer wieder vergessen. ()
