convAMP – mein AMP Konverter

Direktlink zum AMP-Konverter: convAMP.

Wozu brauche ich einen HTML zu AMP Konverter

Wozu brauche ich überhaupt Accelerated Mobile Pages?
Webseiten (HTML-Seiten) sind mit den Jahren immer fetter geworden. Jede Menge zusätzlicher JavaScript Code wird geladen und ausgeführt, Bilder müssen mindestens eine Auflösung von 2560×1440 Pixel haben, Videos und Social Network Buttons müssen integriert sein, riesige Stylesheet-Dateien (aufgeteilt auf mehrere Brocken) müssen nachgeladen werden … ihr wisst schon, was ich meine. Jedenfalls sind manche Webseiten schweinelangsam.

Auf einem PC mag das ja noch in Ordnung sein, vor allem, wenn man über ein richtiges LAN (so mit Kabel) ins Internet kommt.

Nun ist es aber so, dass immer mehr Leute ausschließlich mit einem Tablet oder einem Smartphone ins Internet gehen. Dadurch kommt es zu zwei Herausforderungen:

1. Die Geschwindigkeit der Verbindung ist manchmal eher bescheiden.
2. Die Bildschirmgrößen sind viel kleiner, so dass man kaum etwas darauf lesen kann.

Also sind Web-Designer dazu übergegangen, verschiedene Versionen ihrer Webseiten (viel Aufwand) oder wenigstens verschiedene Darstellungsarten ihrer Webseiten anzubieten. Im Endeffekt ist die Darstellung damit wieder in Ordnung. Aber es bleibt meistens immer noch ein großer Overhead an Protokoll-Daten und eben viel zu viel Datenvolumen.

Meinen Blog habe ich bisher noch nicht für mobile Endgeräte optimiert … steht in der Pipeline. Es gibt allerdings AMP-Seiten: dieser Artikel als AMP.

Unter anderem Google will seinen Kunden zum Beispiel News in einem Karussell anbieten, die per Mausklick „instant“ lesbar sind. Die Seiten müssen also nicht schnell, sondern extrem schnell, quasi in Nullzeit laden.

Dafür wurde von Google das Projekt AMP = Accelerated Mobile Pages ins Leben gerufen. Es ist aber Open Source und nicht auf Google beschränkt.

Schön! Und was geht das mich an?

Gute Frage!

Weil AMP-Seiten generell besonders schnell laden und für mobile Endgeräte geeignet sind, werden sie in den Suchergebnislisten bei einer Suche auf einem Smartphone bevorzugt angezeigt. (Okay, ich bemerke ein Stirnrunzeln auf deiner Stirn. Du hast dich also schon mehr mit AMP und Google beschäftigt. Akzeptiere bitte an dieser Stelle diese vereinfachte Darstellung.)

Mal abgesehen davon, macht es einfach viel mehr Spaß, wenn eine Webseite schnell lädt, oder?

Ich habe vor einiger Zeit einen Artikel zu AMP geschrieben. Dort gibt es weitere Informationen zu dem Thema: AMP – Accelerated Mobile Pages – schnelles Internet.

Wenn ich entschieden habe, meinen bestehenden HTML-Seiten zusätzlich AMP-Seiten zur Seite zu stellen, so wartet einige Arbeit auf mich, denn das AMP-Format fordert von mir eine Menge Anpassungen. In Content Management Systemen wie WordPress gibt es oft die Möglichkeit, diese Umstellung automatisch durchführen zu lassen (bei WordPress ist das aktuell nur für Beiträge möglich, aber nicht für Seiten).

Oder man verwendet ein Programm, das einen Teil der Handarbeit übernimmt.

Zurück also zur Frage: Wozu brauche ich einen HTML zu AMP Konverter?

Er nimmt mir einfach einen Teil der Arbeit ab, wenn ich meinen Internet-Auftritt um AMP-Seiten ergänzen möchte.

Was macht der AMP Konverter denn nun genau?

Mein convAMP (convert to AMP) ergänzt die ursprüngliche HTML-Seite um benötigte Elemente, entfernt andere, die in AMP nicht erlaubt sind, schreibt einige Tags um und fasst Stylesheets zusammen. Am Ende purzeln zwei Dateien heraus: eine amp.html mit der AMP-Seite und eine amp.css mit allen Styles.

Die ganze Konvertiererei dauert normalerweis nur 1 Sekunde. Das hängt aber davon ab, wie viele externe Ressourcen (Bilder, Stylesheets) für die Analyse aus dem Internet nachgeladen werden müssen. Zugriffe aufs Internet kosten (relativ) viel Zeit.

Im Detail:

Die HTML-Seite einlesen

Als erstes muss die Ursprungsseite ge“cURL“t werden. (@Wolfgang: Refresh-Anweisungen in Meta-Tags werden derzeit noch nicht verfolgt.) Die Seite wird kurz daraufhin überprüft, ob es sich überhaupt um eine HTML-Seite handelt.

Aus dem HTML-Sourcecode wird im Arbeitsspeicher ein DOM-Baum aufgebaut. Das erlaubt mir später leichteren Zugriff auf die HTML-Tags und erspart mir eine Menge regulärer Ausdrücke.

Base-Tag identifizieren

Für den späteren Zugriff auf Bilder und Stylesheets wird nachgeschaut, ob es im Code eine <base>-Angabe gibt. Diese wird benötigt um valide URLs aufzubauen. Später wird der <base>-Tag komplett entfernt, weil er im AMP-Format nicht zulässig ist. Deswegen müssen alle URLs absolute Pfadangaben erhalten.

Korrekte Charset-Angabe einbauen

Für AMP ist ausschließlich <meta charset="utf-8"> zugelassen. Deswegen entfernt der Konverter alle anders lautenden Charset-Angaben und fügt schließlich die korrekte Angabe in den Head-Bereich der Seite ein.

Seite mit AMP-Kennzeichnung versehen

Bei einer AMP-Seite muss das <html>-Tag um das Attribut „amp“ erweitert werden. Alle anderen Attribute bleiben erhalten. Sollte an dieser Stelle vergessen worden sein, eine Sprache für die Seite festzulegen, wird vom Konverter einfach ein lang="de"> hinzugefügt.

AMP JavaScript-Bibliothek einbinden

Als nächstes wird im Head-Bereich die AMP-Bibliothek eingebunden. Sie ist für die gesamte Steuerung der AMP-Seite zuständig und sorgt für die hohe Geschwindigkeit. JavaScript ist grundsätzlich auf einer AMP-Seite nicht erlaubt. Es sei denn, der Code wird asynchron geladen oder er steht in einem iFrame. Die AMP-Bibliothek muss aber selbstverständlich in jedem Fall geladen werden. Sie steht auf vielen Servern über ein CDN zur Verfügung.

<script async src="https://cdn.ampproject.org/v0.js"></script>

Korrekte Viewort-Angabe einbauen

AMP-Seiten sind „von Natur aus“ responsiv. Dafür benötigen sie aber eine korrekte Viewport-Angabe. Da hier kein Spielraum für abweichende Attribute besteht, entfernt der Konverter einfach alle vorhandenen Angaben und fügt dann die einzig zugelassene Version in den Head-Bereich der Seite ein.

<meta name="viewport" content="width=device-width,minimum-scale=1,initial-scale=1">

Kanonischen Link einbauen

Normalerweise treten HTML- und AMP-Seite immer als Paar auf (dies ist aber kein Muss!). Damit sie gegenseitig voneinander wissen, werden sie über kanonische Links miteinander verbunden. In der HTML-Seite wird einer Suchmaschine auf diese Weise gesagt: „Hey, von mir gibt es auch noch eine AMP-Version. Schau doch mal, ob dir diese gerade besser zusagt.“ Und in der AMP-Seite geht es eben genau in die andere Richtung. Genau dieser Link wird nun in den Head-Bereich eingefügt. Alle anderen kanonischen Links werden entfernt, so dass in der AMP-Seite einzig und alleine die Verknüpfung zur ursprünglichen HTML-Seite bestehen bleibt.

Der Konverter überprüft auch, ob er den kanonischen Link in die ursprüngliche HTML-Datei eintragen kann. Dies wird aber regelmäßig nicht funktionieren, da der Konverter nicht die dafür benötigten Schreibrechte besitzt. Dieser Link muss also nach der Erzeugung der AMP-Seite manuell in die HTML-Seite eingetragen werden.

Alle Stylesheets verarbeiten

Dieser Programm-Teil liefert noch nicht das, was ich mir wünsche. Leider ist das Thema nicht ganz trivial.

Was momentan geschieht, ist folgendes:
Zunächst werden alle externen Stylesheets aus dem Internet gelesen und aneinander gehängt. Bei jedem Stylesheet wird überprüft, ob es zusätzliche @import-Angaben gibt, die dann gegebenenfalls rekursiv eingelesen werden. Um Endlosschleifen zu vermeiden, ist die Rekursionstiefe momentan auf 1 Ebene beschränkt.

Sollten die Stylesheets nicht für die Medientypen „screen“ oder „all“ vorgesehen sein bzw. über keine Angabe zum Medientyp verfügen, so werden sie nicht weiter beachtet.

Das Problem bei der Verarbeitung der Stylesheets ist, dass sämtliche Styles in die AMP-Datei geschrieben werden müssen, dabei aber nicht größer als 50 KB sein dürfen. Entsprechend werden fast immer keinerlei Styles in die AMP-Seite eingebunden, sondern ausschließlich als amp.css gespeichert. Die fertige AMP-Seite sieht dementsprechend auch sehr unformatiert aus. Kein Wunder … ohne Styles.

Ich habe bereits verschiedene Routinen in den Konverter eingebaut, um die Stylesheet-Datei einzudampfen. So werden Kommentare und Zeilenumbrüche sowie überflüssige Leerzeichen entfernt. Außerdem wird analysiert, welche Klassen, die in den Stylesheets stehen, überhaupt im HTML verwendet werden. Alle nicht verwendeten Klassen werden dann gnadenlos hinausgeworfen. Im Augenblick sind diese Funktionen aber allesamt deaktiviert.

Ein grundsätzliches Problem löse ich damit nicht: die AMP-Seite wird niemals so aussehen wie die HTML-Seite (und soll es auch gar nicht), kann also gar nicht die gleichen IDs und Klassen verwenden. Hier ein brauchbares Design zu finden, ist schwierig, setzt es doch eine genaue semantische Analyse des Aufbaus der Seite voraus (Was ist der Header? Wo steht der Footer? Soll dieser DIV eventuell eine Sidebar sein? Usw.) Dafür habe ich momentan noch keine Lösung.

Im Augenblick werden auch die existierenden Inline-Stylesheets und Inline-Styles noch nicht weiter beachtet. Vermutlich werde ich in Zukunft die Inline-Styles aus dem Code herauslösen und durch Klassen ersetzen, die dann zusätzlich in dem End-Stylesheet erzeugt werden müssen.

Entfernen aller externen Stylesheets

Sobald alle verfügbaren Informationen zu den Styles verarbeitet worden sind, können die externen Stylesheets entfernt werden. Danach wird geschaut, ob der große Batzen an Styles vielleicht doch kleiner als 50 KB ist. Wenn ja, dann wird er als Inline-Stylesheet eingebunden. Aber wie gesagt … normalerweise wird das nicht geschehen.

Verbotene HTML-Tags entfernen

AMP verbietet eine ganze Reihe von HTML-Tags wie zum Beispiel <applet>, <base> und <form> (Genau! Formulare sind böse!). An dieser Stelle werden also die entsprechenden Tags ersatzlos aus dem Code entfernt. Die Liste der verbotenen Tags kann sich zukünftig ändern. Das AMP-Projekt ist ein sehr junges und daher dynamisches Projekt.

Verbotene Attribute entfernen

Sollte ein HTML-Tag erlaubt sein, so heißt das noch lange nicht, dass auch alle Attribute des Tags erlaubt sind. Beispielsweise ist das Attribut „border“ bei Bildern nicht erlaubt. Genauso wenig dürfen Event-Handler wie „onclick“ in Links verwendet werden. Mir bekannte verbotene Attribute werden deswegen entfernt.

Zu den verbotenen Attributen gehören übrigens auch Inline-Styles.

Wie die Liste der verbotenen Tags kann sich auch die Liste der verbotenen Attribute täglich ändern.

Alle Bilder verarbeiten

Bilder können die Ladezeit einer Webseite erheblich beeinflussen. Aus diesem Grunde werden sie der Steuerung durch die AMP-JavaScript-Bibliothek unterworfen. Als erstes wird das <img>-Tag durch ein <amp-img>-Tag ersetzt. Dieses setzt zwingend Angaben zur Größe des Bildes, also width und height voraus. Wenn diese beiden Angaben fehlen, wird der Konverter versuchen, die tatsächliche Größe der Bilder zu ermitteln und dementsprechend in das Tag einzufügen. Dies geschieht ebenfalls, wenn nur eine der beiden Angaben fehlt.

Des Weiteren wird das Layout der Bilder auf „fixed“ festgenagelt. Eigentlich wäre hier „responsive“ die bessere Wahl. Dann richtet sich die Skalierung des Bildes aber nach dem Eltern-Element. Wenn dies nicht gescheit skaliert ist, kann es passieren, dass ein Logo von 150x150px plötzlich die gesamte Bildschirmbreite ausfüllt. Also bis auf weiteres: „fixed“.

Google Analytics Code übernehmen

Viele Websites verwenden Google Analytics, um die Besucherzugriffe zu analysieren. Der Code wird in Form eines kleinen JavaScripts eingebunden. Das ist aber in AMP verboten. Deswegen gibt es eine eigene AMP-Komponente, die dies ermöglicht. Auch andere Tracker werden durchaus von AMP unterstützt. Momentan habe ich aber nur Unterstützung für Google Analytics in den Konverter eingebaut, und dies auch nur rudimentär. Es wird auch nur Google Universal Analytics berücksichtigt. Wer (sinnvollerweise) den Tag-Manager verwendet, bleibt momentan damit noch außen vor und muss das manuell eintragen. Da werde ich sicherlich in der Zukunft noch nachlegen.

Die eigentlichen Daten (wie die UA-ID) werden auf AMP-Seiten als JSON-Objekt übergeben. Die Aufbereitung dafür übernimmt ebenfalls der Konverter.

Entfernen aller JavaScripts

Mit JavaSript kann man auf einer Seite allerlei Schabernack anstellen. Also muss das alles raus. JSON-Objekte in einem Script-Container sind davon ausgenommen, da sie keinen Programmcode, sondern nur Daten enthalten. Auch asynchron geladene Scripts dürfen bleiben.Und wer sein JavaScript in einen iFrame steckt, hat auch erst einmal Glück gehabt.

Entfernen von Kommentaren

Um die Datei weiter zu verschlanken, werden alle Kommentarzeilen entfernt. Dazu zählen auch Browserweichen. Die Lesbarkeit des Quelltextes erhöht sich dadurch zwar nicht unbedingt, aber die Datei wird um einige Bytes leichter und lädt entsprechend marginal schneller. Das Entfernen der Kommentare wird in Zukunft optional abschaltbar sein.

Entfernen von Leerzeilen

Sollten durch das ganze Herumgelösche inzwischen Leerzeilen entstanden sein oder Zeilen, die nur Tabulator-Zeichen enthalten, so werden die nun auch noch entfernt. Auch diese Funktion möchte ich in Zukunft optional abschaltbar machen.

AMP Boilerplate einbauen

Die so genannte AMP Boilerplate ist ein kleines Stylesheet, das vor allem die Darstellung der Webseite so lange verzögert, bis sie vollständig gerendert ist. Dann wird sie (mehr oder weniger) sanft eingeblendet.

<style amp-boilerplate>body{-webkit-animation:-amp-start 8s steps(1,end) 0s 1 normal both;-moz-animation:-amp-start 8s steps(1,end) 0s 1 normal both;-ms-animation:-amp-start 8s steps(1,end) 0s 1 normal both;animation:-amp-start 8s steps(1,end) 0s 1 normal both}@-webkit-keyframes -amp-start{from{visibility:hidden}to{visibility:visible}}@-moz-keyframes -amp-start{from{visibility:hidden}to{visibility:visible}}@-ms-keyframes -amp-start{from{visibility:hidden}to{visibility:visible}}@-o-keyframes -amp-start{from{visibility:hidden}to{visibility:visible}}@keyframes -amp-start{from{visibility:hidden}to{visibility:visible}}</style><noscript><style amp-boilerplate>body{-webkit-animation:none;-moz-animation:none;-ms-animation:none;animation:none}</style></noscript>

Dieser Code-Block darf nicht verändert werden. Das liegt daran, dass Google auf diesen Block mit regulären Ausdrücken zugreift, die sonst eventuell nicht mehr matchen.

Der Block wird erst so spät vom Konverter eingefügt, weil vorher Styles entfernt werden (siehe weiter oben). Die Boilerplate hätte dann auch zu den Opfern gezählt.

Generierung der AMP-Datei

Anschließend wird die AMP-Datei aus dem nun geänderten DOM-Baum generiert. Aber bevor diese Datei endlich als amp.html gespeichert werden kann, müssen noch ein paar Korrekturen durchgeführt werden, die mit dem DOM-Baum nicht möglich sind. Dazu werden noch ein paar Attribute geändert und ein paar HTML-Tags angepasst. Schließlich kann die Datei gespeichert werden.

Protokoll-Datei per E-Mail verschicken

Der AMP-Konverter schreibt ein recht umfangreiches Protokoll über die Maßnahmen, die bei der Konvertierung der HTML-Seite umgesetzt worden sind. Unter anderem steht im Protokoll, welche Elemente gelöscht wurden, welche hinzugekommen sind und an welchen Stellen Anpassungen notwendig waren. Mit Hilfe des Protokolls hoffe ich, Fehler im Programm finden zu können. Dieses Protokoll wird mir ganz am Ende per E-Mail zugeschickt.

AMP-Seiten lassen sich mit dem offiziellen Google AMP Validator überprüfen.

Mein persönliches Ziel ist es natürlich, dass mein AMP-Konverter irgendwann nur noch Seiten erzeugt, die mit null Fehlern validieren.

Hier noch einmal der Direktlink zum AMP-Konverter: convAMP.