So funktioniert AMP
Die Kombination der folgenden Optimierungen macht AMP Seiten so schnell, dass sie scheinbar sofort geladen werden. Dafür gibt es insgesamt 7 Gründe – aber wenn du keine Zeit zum Lesen hast, sieh dir einfach das Erklärvideo an:
Asynchrone Ausführung des gesamten AMP JavaScript Codes
JavaScript ist sehr mächtig: Es kann fast jeden Aspekt der Seite modifizieren, aber auch die DOM Erstellung blockieren und das Rendering der Seite verzögern (siehe auch Interaktivität mit JavaScript hinzufügen). Damit JavaScript das Rendering von Seiten nicht verzögert, erlaubt AMP nur asynchrones JavaScript.
AMP Komponenten enthalten zwar auch JavaScript, jedoch wird bei der Entwicklung sorgfältig darauf geachtet, dass sie keine Leistungseinbußen verursachen.
Obwohl benutzerdefiniertes JS in amp-script erlaubt ist und JS von Drittanbietern in iframes zulässig ist, kann es das Rendering nicht blockieren. Verwendet Drittanbieter JS beispielsweise die äußerst leistungsfeindliche API document.write, so blockiert sie nicht das Rendering der Startseite.
Statische Größenangabe aller Ressourcen
Externe Ressourcen wie Bilder, Ads und iframes müssen ihre Größe im HTML Code angeben, damit AMP die Größe und Position der einzelnen Elemente festlegen kann, bevor die Ressourcen heruntergeladen werden. AMP lädt das Seitenlayout, ohne den Download von Ressourcen abzuwarten.
AMP trennt Dokumentlayout und Ressourcenlayout. Eine einzige HTTP Anforderung ist ausreichend, um das gesamte Dokument zu gestalten (+Schriftarten). AMP ist so optimiert, dass aufwendige Neuberechnungen von Style und Layout im Browser vermieden werden. Daher wird das Layout beim Laden der Ressourcen nicht erneut verarbeitet.
Erweiterungsmodule dürfen nicht das Rendering blockieren
AMP verhindert, dass Erweiterungsmodule das Rendering der Seite blockieren. AMP unterstützt Erweiterungen für Elemente wie Lightboxes, Instagram Embeds, Tweets usw. Die dafür erforderlichen zusätzlichen HTTP Anforderungen blockieren das Seitenlayout und Rendering nicht.
Jede Seite, die ein benutzerdefiniertes Skript verwendet, muss dem AMP System mitteilen, dass ein benutzerdefiniertes Tag zu erwarten ist. Das Skript amp-iframe teilt dem System beispielsweise mit, dass ein amp-iframe Tag vorkommen wird. AMP erstellt das iframe Feld vorab, ohne seinen Inhalt zu kennen:
<script async custom-element="amp-iframe" src="https://cdn.ampproject.org/v0/amp-iframe-0.1.js"></script>
Kein JavaScript von Drittanbietern im kritischen Pfad
JS Code von Drittanbietern wird häufig synchron geladen. Außerdem werden synchrone Skripte oft mit document.write eingebunden. Wenn deine Seite beispielsweise fünf Ads enthält und jedes Ad drei synchrone Ladevorgänge mit einer Wartezeit von jeweils einer Sekunde verursacht, dauert es schon 15 Sekunden, nur um JS zu laden.
AMP Seiten erlauben JavaScript von Drittanbietern, jedoch nur in iframes innerhalb von Sandboxen. Da die Skripte auf iframes beschränkt sind, können sie die Ausführung der Startseite nicht blockieren. Selbst wenn sie mehrere Neuberechnungen der Styles auslösen, haben ihre winzigen iframes ein sehr kleines DOM.
Die Zeit, die für die Neuberechnung von Styles und Layouts benötigt wird, ist durch die DOM Größe begrenzt. Daher sind die Neuberechnungen der iframes verglichen mit der Neuberechnung von Styles und Layout für die Seite sehr schnell.
CSS muss vollständig inline und größenbeschränkt sein
CSS blockiert das gesamte Rendering, blockiert das Laden von Seiten und neigt zu unverhältnismäßiger Größe. In AMP HTML Seiten sind nur Inline Styles zulässig. Im Vergleich zu den meisten Webseiten wird so mindestens eine HTTP Anforderung aus dem kritischen Renderingpfad entfernt.
Außerdem ist das integrierte Stylesheet auf maximal 50 Kilobyte beschränkt. Das ist einerseits auch für sehr anspruchsvolle Seiten ausreichend, andererseits müssen Seitenautoren immer noch auf ordentliches CSS achten.
Effiziente Aktivierung von Schriftarten
Webfonts sind riesengroß, und darum ist die Optimierung von Webfonts überaus wichtig für die Leistung. Auf einer typischen Seite mit einigen Synchronisierungsskripten und einigen externen Stylesheets wartet der Browser sehr lange auf den Download dieser riesigen Schriftarten, damit es endlich weitergehen kann.
Das AMP System deklariert keine HTTP Anforderungen, bevor der Download der Schriftarten startet. Dies ist nur möglich, da in AMP alle JS Skripte das Attribut "async" haben und nur Inline Stylesheets zulässig sind. Es gibt keine HTTP Anforderungen, die den Browser am Download von Schriftarten hindern.
Möglichst seltene Neuberechnungen von Styles
Bei jedem Messvorgang werden Neuberechnungen der Styles ausgelöst. Das kostet Zeit, da der Browser die gesamte Seite umgestalten muss. In AMP Seiten werden alle DOM Lesevorgänge vor jeglichen Schreibvorgängen ausgeführt. Deshalb ist maximal eine Style Neuberechnung pro Frame erforderlich.
Erfahre mehr darüber, wie Neuberechnungen von Styles und Layout die Renderingleistung beeinflussen.
GPU Beschleunigung für Animationen
Schnelle Optimierungen sind nur möglich, wenn sie auf der GPU ausgeführt werden. Die GPU kann Ebenen verarbeiten, bestimmte Vorgänge auf diesen Ebenen ausführen, sie verschieben und ausblenden, aber sie kann das Seitenlayout nicht aktualisieren. Diese Aufgabe wird dem Browser überlassen, doch das ist nicht gut.
Spezielle Regeln für animationsbezogenes CSS stellen sicher, dass die GPU Beschleunigung von Animationen möglich ist. Genauer gesagt erlaubt AMP nur Animationen und Übergänge mit transform und opacity, sodass kein Seitenlayout erforderlich ist. Erfahre mehr über die Verwendung von transform und opacity für Animationen.
Laden von Ressourcen mit Priorität
AMP steuert die Downloads aller Ressourcen: Es priorisiert das Laden von Ressourcen, lädt nur die notwendigen Elemente und holt sich lazy-loaded Ressourcen per Vorabruf.
AMP optimiert den Download von Ressourcen so, dass die momentan wichtigsten Ressourcen zuerst heruntergeladen werden. Bilder und Ads werden nur heruntergeladen, wenn es wahrscheinlich ist, dass Nutzer sie im angezeigten Bereich sehen oder schnell zu ihnen scrollen.
AMP holt sich auch lazy-loaded Ressourcen per Vorabruf. Ressourcen werden so spät wie möglich geladen, aber so früh wie möglich vorabgerufen. Das beschleunigt den gesamten Ladevorgang, die CPU kommt aber erst zum Einsatz, sobald die Ressourcen den Nutzern tatsächlich angezeigt werden.
Sofortiges Laden von Seiten
Die neue Preconnect API wird intensiv genutzt, um sicherzustellen, dass HTTP Anforderungen bei Bedarf möglichst schnell ausgeführt werden. So kann es sein, dass eine Seite gerendert wird, noch bevor die Nutzer ausdrücklich angeben, dass sie zu ihr navigieren möchten. Sobald die Nutzer die Seite auswählen, ist sie eventuell bereits verfügbar und wird sofort geladen.
Das Prerendering kann auf alle Webinhalte angewendet werden, kann aber auch Bandbreite und CPU stark beanspruchen. AMP ist optimiert, um diese beiden Faktoren zu reduzieren. Beim Prerendering werden nur Ressourcen des angezeigten Bereichs heruntergeladen und es wird nichts gerendert, das die CPU stark auslasten könnte.
Beim Prerendering von AMP Dokumenten zum sofortigen Laden werden nur Ressourcen aus dem angezeigten Bereich heruntergeladen. Beim Prerendering von AMP Dokumenten zum sofortigen Laden werden CPU intensive Ressourcen (z. B. iframes von Drittanbietern) nicht heruntergeladen.
Erfahre mehr darüber, warum AMP HTML den Preload Scanner nicht voll ausnutzt.