Alles, was Sie über die beschleunigten mobilen Seiten von Google wissen müssen

Im Mai 2015 stellte Facebook seine neue In-App-Publishing-Plattform Instant Articles vor. Einen Monat später erklärte Apple, dass das alte Zeitungskiosk-Erlebnis (im Wesentlichen ein schicker Ordner voller Nachrichten-Apps) in iOS 9 durch eine brandneue Nachrichtenaggregations- und Entdeckungsplattform namens Apple News ersetzt würde.

Weiterführende Literatur zu Smashing:

• Wahrgenommene Leistung
• Preload: Wozu ist es gut?
• Vorbereitung auf HTTP/2
• Progressive Enhancement
• Progressive Web-AMPs

Vier Monate später war Google an der Reihe, seinen eigenen, etwas verspäteten, aber nicht weniger ehrgeizigen Plan anzukündigen, den mobilen Nachrichtenkonsum mit einer webbasierten Open-Source-Lösung namens Accelerated Mobile Pages oder AMP zu revolutionieren. In nur wenigen Monaten haben wir gesehen, wie die relative Ruhe des mobilen digitalen Publizierens in einen weiteren umfassenden Plattformkrieg ausgebrochen ist, als Facebook, Apple und jetzt Google sowohl um die Loyalität der Herausgeber als auch um die Aufmerksamkeit der Leser konkurrieren.

Während Facebook und Apple einen deutlichen Vorsprung gegenüber Google haben, gibt es allen Grund zu der Annahme, dass AMP schnell aufholen wird (und sogar einen oder beide seiner Konkurrenten überholen könnte). Wenn Sie ein Entwickler oder Publisher sind, der sich so schnell und effizient wie möglich über das Warum, Was und Wie der Accelerated Mobile Pages von Google informieren muss, sind Sie hier genau richtig.

Aber was ist das Problem?

Bevor wir Lösungen diskutieren, lohnt es sich, sich einen Moment Zeit zu nehmen, um das Problem zu untersuchen. Wenn Sie viel auf mobilen Geräten lesen, sind die Chancen ziemlich gut, dass Sie sich bereits allzu bewusst sind, dass die Interaktion mit webbasierten Inhalten auf einem Telefon oder Tablet von kaum akzeptabel bis entsetzlich reicht. Seiten laden oft langsam, werden unregelmäßig gerendert und verhalten sich aus zwei Hauptgründen unvorhersehbar:

• Eingriffe Dritter . Anzeigen und verwandte Tracking-Techniken fügen einem bereits bandbreiten- und CPU-eingeschränkten Gerät nicht nur Massen- und zusätzliche Anfragen hinzu, sondern Seiten verhalten sich oft so, als wären sie besessen, da sie um mehrere document.write() Aufrufe herumkrampfen. Die New York Times hat kürzlich einen Test durchgeführt, der nach der Installation eines iOS-Inhaltsblockers eine deutliche Verringerung der Seitengröße und eine Verlängerung der Akkulaufzeit zeigte.
• Kollateralschäden durch Responsive Design . Während die meisten reaktionsschnell gestalteten Websites auf Bildschirmen aller Größen gut aussehen, enthalten sie oft viel Gepäck von Desktop-Websites, wenn sie auf Mobilgeräten angezeigt werden. Als Paul Irish eine Leistungsprüfung von Reddit durchführte, entdeckte er, dass ein Großteil des Overheads auf ein Asset namens SnooIcon zurückgeführt werden konnte, das Reddit-Maskottchen, das in SVG gerendert wurde, damit es animiert werden konnte (durch eine Bibliothek eines Drittanbieters, d.h mehr Overhead) bei Mouseover – keine Situation, in der sich Assets häufig auf Mobilgeräten wiederfinden.

Geben Sie Facebook Instant Articles, Apple News und Accelerated Mobile Pages ein – unsere Retter aus einer Welt, in der laut Facebook (PDF, 3,4 MB) die durchschnittliche Ladezeit eines Artikels auf Mobilgeräten 8 Sekunden beträgt. Während es offensichtlich übertrieben ist, 8 Sekunden eine Ewigkeit zu nennen, wenn man bedenkt, dass Sie in dieser Zeit gut in Ihr zweites Vine-Video eintauchen könnten, ist es wahrscheinlich fair zu sagen, dass es nach heutigen Maßstäben mindestens ein Äon ist.

Eine kurze Demo von Facebook Instant Articles, Apple News und Accelerated Mobile Pages. Beachten Sie, dass Facebook Instant Articles und Apple News In-App-Erlebnisse sind, während AMP vollständig browserbasiert ist.

Wie unterscheidet sich AMP?

Etwas Kontext dafür, wie sich AMP von Facebook Instant Articles und Apple News unterscheidet, wird einige der Entscheidungen verdeutlichen, die Google für seine neue Digital-Publishing-Initiative getroffen hat.

Facebook Instant Articles und Apple News haben mehrere Gemeinsamkeiten:

• In-App-Erlebnisse . Leser greifen über Facebook auf mobilen Geräten auf Facebook Instant Articles zu, und Apple News ist eine eigenständige App, die mit iOS 9 geliefert wird. Keine der Plattformen erlaubt es Benutzern derzeit, Artikel in ihren spezifischen Formaten außerhalb der jeweiligen App anzuzeigen. Stellen Sie sich beides als eine anwendungsspezifische Aktualisierung von RSS vor.
• syndizierungsgetrieben . Während Facebook Instant Articles und Apple News sehr unterschiedliche Syndication-Formate verwenden (Apple News Format ist JSON-basiert und Instant Article Markup ist mehr oder weniger HTML, das in einen RSS-Feed eingebettet ist), basieren sie auf ähnlichen Prinzipien: Bringen Sie Ihr CMS dazu, die notwendigen Syndication-Formate, und Facebook oder Apple News schlürfen es auf, parsen es und machen es durch angepasste und optimierte Renderer sowohl schön als auch schnell.
• erlebnisorientiert . Obwohl Facebook Instant Articles und Apple News beide auf Leistung ausgerichtet sind, geht es ihnen gleichermaßen darum, dass Artikel modern aussehen und sich auch so anfühlen. Beide Plattformen verfügen über Komponenten, die die glatten und reibungslosen Interaktionen ermöglichen, die wir normalerweise mit maßgeschneiderten, handgefertigten Leseerlebnissen verbinden.

Im Gegensatz dazu haben Accelerated Mobile Pages einen deutlichen Fokus:

• webbasierte Erfahrung . AMP-Dokumente sind so konzipiert, dass sie entweder im Browser oder in WebViews gerendert werden.
• atomare Dokumente . Obwohl AMP-Dokumente von der AMP-Laufzeit validiert, analysiert und teilweise gerendert werden (mehr dazu weiter unten), handelt es sich um vollständige und unabhängige Dokumente, die auf Ihrem eigenen Webserver (und optional in einem CDN-Cache) gespeichert sind, und nicht um Sammlungen von Metadaten, die irgendwann in Artikel umgewandelt und in Apps gerendert werden.
• leistungsorientiert . AMP kümmert sich viel mehr um die Leistung von AMP-Dokumenten als um Ästhetik oder Interaktionsmuster. Das soll nicht heißen, dass AMP-Dokumente von Natur aus gemütlich sind (sie können mit dem richtigen Styling genauso attraktiv sein wie Facebook Instant Articles oder Apple News-Artikel), aber die Laufzeit befasst sich viel mehr damit, einen Artikel schnell zu rendern, als mit ausgefallenen visuellen Effekten wie verrückte kleine wackelige Dinger.

Was ist AMP genau?

Genug philosophiert und High-Level-Handwinken. Lassen Sie uns ins Detail gehen. Während es ziemlich einfach ist, sich mit Facebook Instant Articles und Apple News vertraut zu machen (sie sind im Wesentlichen ausgefallene Nachrichtenaggregatoren mit benutzerdefinierten Renderern, die auf proprietären Syndication-Formaten aufbauen), ist AMP der Ausreißer. Es ist aus zwei Gründen etwas schwieriger zu verstehen:

• Es gibt kein einfaches Vergleichsmodell. Als RSS neu war, staunten wir alle über seine Macht, schrieben unzählige Artikel und Blogbeiträge über sein disruptives Potenzial, erklärten die Homepage (wieder einmal) für tot und vergaßen sie dann ganz. Facebook Instant Articles und Apple News sind im Wesentlichen ein RSS-Neustart, außer dass sie auf alle Nachteile von Standards verzichten und beide nur in einer Anwendung funktionieren.
• AMP ist kein Client. . Während Facebook Instant Articles, Apple News und AMP mehrere Elemente gemeinsam haben, wie z. B. proprietäre Syndication-Formate und benutzerdefinierte Renderer, ist AMP das einzige ohne einen dedizierten Client (außer dem Browser). Mehr noch als seine Brüder ist AMP eine Reihe von Spezifikationen, Konventionen und Technologien, die zu einer Lösung kombiniert werden können, anstatt eine End-to-End-Lösung (Publisher-to-Reader) an und für sich zu sein.

Nun, da wir wissen, dass wir AMP als eine Sammlung von Zutaten und nicht als einen vollständig gebackenen Kuchen betrachten müssen, schauen wir uns an, was diese einzelnen Komponenten sind:

• AMP-HTML,
• die AMP-Laufzeit,
• den AMP-Cache.

AMP-HTML

AMP-Dokumente werden in HTML geschrieben, aber nicht in irgendeinem HTML. Einige Tags werden gesperrt, während einige neue Tags eingeführt werden (teilweise, um die gesperrten zu ersetzen, und teilweise, um interaktive Funktionen zu kapseln). Sie können sich AMP HTML so vorstellen, wie HTML aussehen würde, wenn es nur mit Blick auf die mobile Leistung entwickelt worden wäre (im Gegensatz dazu, dass es ganze 14 Jahre vor der Einführung des iPhones eingeführt wurde).

Da AMP HTML auf optimale Leistung ausgelegt ist, müssen wir die Probleme verstehen, die es löst, um seinen Wert zu verstehen und zu schätzen. Hier sind die drei größten Dinge, die das Laden und Rendern von Webseiten auf Mobilgeräten beeinträchtigen:

• Nutzlastgröße . Responsives Webdesign hat uns gute Dienste geleistet, da es uns ermöglicht, eine einzige Website für jedes Gerät und jeden Bildschirm zu erstellen. Aber das bedeutet manchmal auch, Nutzlasten in Desktop-Größe (HTML, JavaScript, CSS und Assets) an Mobilgeräte mit extrem eingeschränkter Bandbreite und CPU bereitzustellen. (Diejenigen, die ihre Telefone als kleine Desktop-Computer betrachten, geben mobiler Hardware viel zu viel Anerkennung. Ihr iPhone 6s hat 2 GB RAM, während Ihr Laptop wahrscheinlich 8 oder 16 hat.)
• Laden von Ressourcen . Ressourcen werden nicht immer in der optimalen Reihenfolge geladen, was bedeutet, dass Bandbreite, CPU und RAM oft für Assets reserviert sind, die Benutzer vielleicht gar nicht sehen. Darüber hinaus geben Ressourcen häufig ihre Breite und Höhe nicht an (insbesondere wenn sie über Werbenetzwerke bereitgestellt oder über document.write() Aufrufe eingespeist werden), was nicht nur dazu führt, dass sich die Größe der Seite selbst ändert, da Ressourcenabmessungen träge bestimmt werden, sondern auch unnötig ausgelöst wird und teure Layout-Neuberechnungen. Das ist es, was dazu führt, dass Webseiten wie laserjagende Kätzchen herumspringen, während sie sich so träge manifestieren.
• JavaScript-Ausführung . Ich werde hier nicht das Thema der JavaScript-Leistung ansprechen, aber moderne Websites häufen es oft megabyteweise an, und während es auf Desktop-Computern ohne erkennbare Latenz ausgeführt werden kann, ist Mobile immer noch eine ganz andere Umgebung, wo, denke ich Wir sind uns alle einig, dass JavaScript am besten auf ein Minimum beschränkt wird.

Angesichts dieser drei Hindernisse für flüssige Weberlebnisse auf Mobilgeräten dient AMP-HTML hauptsächlich drei Zwecken:

• Kürze fördern . AMP-Dokumente sind keine responsiven Versionen von Desktop-Websites. Während AMP-Dokumente responsiv sein können (und normalerweise auch sind), sind sie in einem mobilen Kontext responsiv. Mit anderen Worten, anstatt dass eine Seite absolut überall funktioniert (Desktop und Mobil), sind AMP-Dokumente speziell darauf ausgelegt, auf Mobilgeräten gut zu funktionieren.
• Steuern des Ladens externer Ressourcen . Die AMP-Laufzeit steuert das Laden externer Ressourcen, um sicherzustellen, dass der Prozess hocheffizient ist und Inhalte so schnell und intelligent wie möglich auf den Bildschirmen der Benutzer erscheinen.
• interaktive Funktionalität kapseln . Obwohl AMP-Dokumente dazu tendieren, den Lesern direkte Leseerlebnisse zu bieten, heißt das nicht, dass sie nicht modern und interaktiv sein können. Die AMP-Laufzeit bietet gekapselte Funktionalität durch hochgradig optimiertes JavaScript, sodass Entwickler nicht riskieren, die Leistung zu beeinträchtigen, indem sie ihr eigenes schreiben.

AMP-HTML-Tags

Nachfolgend finden Sie eine Liste von Tags, die in AMP-HTML pauschal gesperrt sind:

• script Dies ist offensichtlich ein großes. Ich werde unten weitere Einzelheiten zur Position von AMP zu JavaScript bereitstellen. Gehen Sie zunächst davon aus, dass die einzigen script -Tags in Ihren AMP-Dokumenten diejenigen sind, die die AMP-Laufzeit laden, und optional ein Tag für JSON-basierte verknüpfte Daten.
• base Das base -Tag scheint aus Vorsicht verboten zu sein und könnte auf die Whitelist gesetzt werden, wenn sich die Community beschwert. (Meine Vermutung ist, dass es niemanden so oder so wirklich interessiert.)
• frame und frameset Nicht gerade eine gute Verwendung von mobilen Immobilien, also gute Befreiung.
• object , param , applet und embed Leider enthalten Ihre AMP-Dokumente keine Flash- oder Java-Applets. (Das war Sarkasmus, falls es nicht ganz offensichtlich war.)
• form und input (mit Ausnahme des button -Tags) Die Formularunterstützung wird wahrscheinlich irgendwann als gekapselte Komponenten implementiert, da sie ohne Skripting nur von begrenztem Nutzen sind.

Hier ist nun eine Liste von Tags, die ihre HTML-Pendants ersetzen, um das Laden von Ressourcen zu optimieren und bewährte Sicherheitspraktiken durchzusetzen:

• [amp-img](https://www.ampproject.org/docs/reference/amp-img.html) Ersetzt das img -Tag und optimiert das Laden von Ressourcen, indem Faktoren wie die Position des Ansichtsfensters, Systemressourcen und Konnektivität berücksichtigt werden.
• [amp-video](https://www.ampproject.org/docs/reference/amp-video.html) Ersetzt das HTML5 video Tag, sodass Videoinhalte träge geladen werden können (unter Berücksichtigung des Darstellungsbereichs).
• [amp-audio](https://www.ampproject.org/docs/reference/extended/amp-audio.html) Ersetzt das HTML5- audio -Tag, sodass Audioinhalte verzögert geladen werden können (unter Berücksichtigung des Darstellungsbereichs).
• [amp-iframe](https://www.ampproject.org/docs/reference/extended/amp-iframe.html) Das amp-iframe Tag erzwingt bewährte Sicherheitspraktiken, indem es Dinge wie das standardmäßige Sandboxing von Inhalten und das Auferlegen von Einschränkungen für wo Iframes erscheinen können, um sicherzustellen, dass sie ein AMP-Dokument nicht dominieren.

Schließlich sind hier alle Tags, die AMP HTML einführt, um Ihren Dokumenten Funktionalität oder Interaktivität hinzuzufügen, ohne dass Sie JavaScript schreiben müssen:

• [amp-ad](https://www.ampproject.org/docs/reference/amp-ad.html) Mit dem amp-ad Tag kann die AMP-Laufzeit das Laden von Anzeigen genauso verwalten wie alle anderen extern geladenen Ressourcen (derzeit , Anzeigen werden zuletzt geladen), und es stellt sicher, dass JavaScript von Werbenetzwerken nicht innerhalb des übergeordneten AMP-Dokuments ausgeführt werden oder unnötige Layoutberechnungen auslösen kann. (Auf Wiedersehen, document.write() !)
• [amp-analytics](https://www.ampproject.org/docs/reference/extended/amp-analytics.html) Dieses Miniatur-Framework verpackt Analysedaten und sendet sie an Drittanbieter. Ab heute kommt die AMP-Unterstützung von Adobe Analytics, Chartbeat, ClickTale, comScore, Google Analytics, Nielsen und Parse.ly.
• [amp-pixel](https://www.ampproject.org/docs/reference/amp-pixel.html) Dies wird zum Einbetten von Web-Beacons verwendet und unterstützt Tokens zum Senden mehrerer Client-Variablen an den Server.
• [amp-carousel](https://www.ampproject.org/docs/reference/extended/amp-carousel.html) Diese optimierte Komponente zeigt untergeordnete Bilder in einer interaktiven, horizontalen Ausrichtung an.
• [amp-lightbox](https://www.ampproject.org/docs/reference/extended/amp-lightbox.html) Dadurch können Leser Bilder in einer „Lightbox“-Vollbildansicht öffnen. Es unterstützt die Spezifikation sowohl von Miniaturbildern als auch von Bildern in voller Größe.
• [amp-anim](https://www.ampproject.org/docs/reference/extended/amp-anim.html) Lädt animierte GIFs und bietet dringend benötigte Platzhalterfunktionen.
• [amp-font](https://www.ampproject.org/docs/reference/extended/amp-font.html) Legen Sie eine Ladezeitüberschreitung für benutzerdefinierte Schriftarten fest und geben Sie Fallback-Schriftarten an, falls Ihre benutzerdefinierten Schriftarten nicht innerhalb der zugewiesenen Zeit geladen werden .
• [amp-fit-text](https://www.ampproject.org/docs/reference/extended/amp-fit-text.html) Text innerhalb eines amp-fit-text Tags wird automatisch eine optimierte Schriftgröße zugewiesen der verfügbare Platz. Betrachten Sie es als eine kleine vorgefertigte Reaktionsfähigkeit.
• [amp-list](https://www.ampproject.org/docs/reference/extended/amp-list.html) Mit dem amp-list Tag können Sie dynamische, sich wiederholende JSON-Daten laden und diese dann mit HTML rendern Vorlage. (Siehe das amp-mustache Tag unten.)
• [amp-mustache](https://www.ampproject.org/docs/reference/extended/amp-mustache.html) Dies unterstützt das Rendern von Moustache-HTML-Vorlagen.
• [amp-install-serviceworker](https://www.ampproject.org/docs/reference/extended/amp-install-serviceworker.html) Wenn Sie sich entscheiden, keinen AMP-Cache zu verwenden (viel mehr zum Caching weiter unten), wird der amp-install-serviceworker Tag lädt und installiert einen Service Worker für die aktuelle Seite. Servicemitarbeiter sind geschickt, aber meiner Meinung nach ist es noch ein wenig zu früh, sich auf sie zu verlassen.
• [amp-youtube](https://www.ampproject.org/docs/reference/extended/amp-youtube.html) Wie vorhersehbar, bettet dies das YouTube-Video mit der angegebenen Video-ID ein.
• [amp-twitter](https://www.ampproject.org/docs/reference/extended/amp-twitter.html) Betten Sie Tweets ein (Twitterkarten optional).
• [amp-instagram](https://www.ampproject.org/docs/reference/extended/amp-instagram.html) Instagram-Bilder einbetten.
• [amp-brightcove](https://www.ampproject.org/docs/reference/extended/amp-brightcove.html) Diese Komponente lädt und zeigt Videos (und einen Videoplayer) von Brightcove an.
• [amp-pinterest](https://www.ampproject.org/docs/reference/extended/amp-pinterest.html) Betten Sie ein Pinterest-Widget oder eine „Pin It“-Schaltfläche in Ihr AMP-Dokument ein.
• [amp-vine](https://www.ampproject.org/docs/reference/extended/amp-vine.html) Betten Sie das angegebene Vine-Video in Ihr AMP-Dokument ein.

Beachten Sie, dass amp- Präfix-Tags zwar nicht gerade Standard-HTML sind, aber auch nicht proprietär. Vielmehr handelt es sich um legitime benutzerdefinierte Elemente mit JavaScript-Implementierungen, die beispielsweise bewährte Sicherheitspraktiken durchsetzen und das Laden von Remote-Ressourcen priorisieren (mehr dazu im Abschnitt „AMP-Laufzeit“ weiter unten). Mit anderen Worten, während AMP-HTML verdächtig nach der Umarmungs-, Erweiterungs- und Löschungsstrategie aussieht, ist es wirklich nur eine clevere Anwendung von Webstandards und unterscheidet sich nicht allzu sehr von benutzerdefinierten data- .

AMP-HTML gestalten

Das Gestalten von AMP-Dokumenten erfolgt mit Standard-CSS und unterscheidet sich nicht wesentlich davon, wie Sie bereits Inhalte gestalten. Beachten Sie jedoch einige Dinge:

• Das gesamte Styling muss mit einem Inline-Stylesheet erfolgen – keine extern verknüpften Stylesheets und keine Inline-Styles auf Elementebene. (Für ein extern verknüpftes Stylesheet müsste ein zusätzliches Dokument heruntergeladen werden, bevor das Layout berechnet werden könnte, und Inline-Stile auf Elementebene könnten das Dokument aufblähen.)
• Stile sind auf 50 KB begrenzt. Die Philosophie von Google ist, dass 50 KB für ein schönes Dokument oder einen Artikel ausreichen, aber nicht genug für eine schöne Website.
• Ihr Inline-Stylesheet muss das Attribut amp-custom haben (dh <style amp-custom> ).
• Die @ -Regeln – @font-face (mehr zu Schriftarten weiter unten), @keyframes und @media – sind erlaubt.
• Einige Selektoren haben Einschränkungen, die bekanntermaßen die Leistung beeinträchtigen, wie z. B. der universelle ( * ) Selektor und der :not() Selektor.
• Der Qualifizierer !important ist gesperrt, um sicherzustellen, dass die AMP-Laufzeit das letzte Wort bei der Elementgröße hat.
• Das Styling von benutzerdefinierten AMP-Komponenten wie amp-carousel carousel erfolgt durch Überschreiben von Standardklassen wie .amp-carousel-button-prev oder durch Verwendung eines vordefinierten Satzes von benutzerdefinierten CSS-Eigenschaften wie --arrow-color .
• Für alle extern geladenen Ressourcen müssen Breiten-, Höhen- und Layouteigenschaften angegeben werden (mehr zum Layout weiter unten), um teure DOM-Layout-Neuberechnungen zu minimieren.
• Übergänge und Animationen, die GPU-beschleunigt werden können (und keine Neuberechnungen auslösen), sind zulässig. Derzeit sind opacity und transform auf der Whitelist aufgeführt.

Weitere Details zum Stylen von Dokumenten finden Sie in der AMP-HTML-Spezifikation.

Schriftarten

AMP unterstützt gerne benutzerdefinierte Schriftarten, mit ein paar Einschränkungen:

• Schriftarten müssen mit einem Link-Tag oder einer CSS- @font-face Regel geladen werden. Mit anderen Worten, Sie können keine Schriftarten mit JavaScript laden.
• Alle Schriftarten müssen über HTTPS bereitgestellt werden.
• Schriftartanbieter müssen auf der Whitelist stehen. Derzeit sind die einzigen Anbieter auf der weißen Liste fonts.googleapis.com und fast.fonts.net . Aber angesichts der Geschwindigkeit, mit der Publisher, Werbetreibende und Analyseanbieter Unterstützung für AMP hinzufügen, vermute ich, dass bald weitere folgen werden.

Layout

Der Layout-Ansatz von AMP wurde um zwei Hauptziele herum entwickelt:

• Die Laufzeit muss in der Lage sein, auf die Größe aller extern geladenen Ressourcen zu schließen, bevor sie tatsächlich geladen werden, damit möglichst schnell ein endgültiges Layout berechnet werden kann. Sobald das Layout berechnet ist, kann der Artikel gerendert werden und die Leser können mit ihm interagieren, selbst wenn die Anzeigen, Bilder, Audio- und Videodateien noch nicht vollständig geladen wurden. (Und wenn diese Ressourcen geladen werden, werden sie nahtlos gerendert, ohne das Leseerlebnis durch die Aktualisierung des Layouts des Dokuments zu stören.)
• AMP-Artikel sollten responsive sein. Wie der Name „Accelerated Mobile Pages“ schon sagt, sind AMP-Dokumente speziell für Mobilgeräte gedacht; In diesem Zusammenhang schließt „responsive“ also keine Desktop-Auflösungen ein. Vielmehr sollten AMP-Dokumente auf allen mobilen Geräten gut aussehen, von den winzigen alten iPhone 4-Relikten, die die Leute immer noch verwenden, bis hin zu den relativ gigantischen iPad Pros.

Das erstgenannte Ziel wird in erster Linie durch die Anforderung erreicht, dass alle extern geladenen Ressourcen width und height haben (und es wird weiter erzwungen, indem Skripte begrenzt werden, die sicherstellen, dass keine neuen Ressourcen hineingeschmuggelt werden können). Letzteres wird durch Standard- media , das Medienattribut, das sizes und das AMP-spezifische layout erreicht.

Im Folgenden finden Sie eine Übersicht über die derzeit von AMP unterstützten Layouts:

• nodisplay Das Element wird anfänglich nicht angezeigt, aber die Anzeige kann durch eine Benutzeraktion ausgelöst werden. (Dies wird in Verbindung mit Komponenten wie amp-lightbox verwendet.)
• fixed Das Element hat eine feste Breite und Höhe, was bedeutet, dass die Laufzeit kein reaktionsfähiges Verhalten anwenden kann.
• responsive Meiner Meinung nach ist dies die nützlichste und magischste der Layout-Optionen von AMP. Das Element verwendet den zugewiesenen Platz, während es sein Seitenverhältnis beibehält. (Im Grunde genommen „Lass dieses Ding bei jeder Auflösung gut aussehen, bitte und danke.“)
• fixed-height Das Element verwendet den zugewiesenen Platz, behält aber eine feste Höhe bei (horizontale Skalierung).
• fill Das Element füllt den Container, in dem es sich befindet, ohne Rücksicht auf das Seitenverhältnis. (Stellen Sie sich width: 100% und height: 100% .)
• container Das Element ist ein Container und lässt daher seine Kinder (im Gegensatz zu seinen Eltern) seine Größe definieren, genau wie bei einem Standard- div -Element.

Das Erreichen eines funktionalen und unkomplizierten Dokumentlayouts mit dem Layoutsystem von AMP ist relativ einfach, aber wenn Sie alles berücksichtigen, was es unterstützt, und wie Werte auf verschiedene Arten von Elementen angewendet werden, gibt es eine Menge Nuancen. Eine viel detailliertere Aufschlüsselung finden Sie in der AMP-Layout-Spezifikation.

Was ist mit SVG?

Unterstützt! Einfaches SVG genießt umfassende Unterstützung sowohl für Desktop- als auch für mobile Browser, und Grafiken werden nicht viel reaktionsschneller als Vektoren, sodass AMP und SVG ein sehr gutes Team bilden. Die größte Einschränkung besteht darin, dass Sie aufgrund von Skripteinschränkungen Ihre Vektoren nicht mit JavaScript animieren können – was Sie, wenn wir ehrlich sind, wahrscheinlich sowieso nicht auf Mobilgeräten tun sollten. Wenn Sie Ihrem SVG jedoch wirklich ein wenig Leben einhauchen müssen, können Sie dies immer noch mit CSS-Animationen tun, gemäß den gleichen Einschränkungen, die im obigen Styling-Abschnitt beschrieben wurden. Denken Sie daran, dass SVG ein Teil des DOM ist, sodass es so einfach wie jedes andere Element gestylt und animiert werden kann.

AMPs Philosophie zu JavaScript

Gute Nachrichten und schlechte Nachrichten hier. Die schlechte Nachricht ist, dass Sie in absehbarer Zeit kein JavaScript für Ihre AMP-Dokumente schreiben werden. Aber in gewisser Weise ist das auch die gute Nachricht. Denken Sie daran, dass AMP kein Framework für mobile Anwendungen ist. Vielmehr handelt es sich um ein mobiles Artikel -Framework, und da Artikel für ein nahtloses und flüssiges Leseerlebnis optimiert werden sollten, gibt es wirklich nicht viele gute Anwendungsfälle für umfangreiches clientseitiges Skripting.

Allerdings ist es sowohl unrealistisch als auch ein wenig drakonisch, JavaScript für immer zu verbieten. Die Realität sieht so aus, dass sich das Web schon seit einiger Zeit auf JavaScript verlässt – selbst im Zusammenhang mit einfachen und relativ langweiligen Leseerlebnissen – für Dinge wie Werbung, Analysen und interaktive Funktionen. Darüber hinaus ist eines der besten Dinge am Web seine Offenheit und seine scheinbar unendliche Kapazität für Experimente, Ausdrucksstärke und Kreativität – von denen ein großer Teil auf JavaScript basiert.

Das AMP-Team hat sowohl die Belastung erkannt, die willkürliches, benutzergeschriebenes JavaScript den Leistungsgarantien auferlegt, als auch die Allgegenwärtigkeit und Unvermeidbarkeit von JavaScript in einer modernen Webumgebung und hat die folgenden Skriptprinzipien entwickelt:

• Derzeit wird kein benutzerdefiniertes JavaScript unterstützt oder zugelassen. Möglicherweise haben Sie nur zwei Arten von Skript-Tags in Ihren AMP-Dokumenten: verknüpfte Daten-Tags (deren Typ application/ld+json ist) und Tags zum Einschließen sowohl der AMP-Laufzeit- als auch der erweiterten AMP-Komponenten.
• Die Autoren des AMP-Projekts haben die meisten Anforderungen für JavaScript im Kontext des mobilen Artikelkonsums vorweggenommen, und so unterstützt AMP entweder Alternativen ( amp-pixel , einschließlich benutzerdefinierter Schriftarten mit Link-Tags oder @font-face Regeln usw.) oder bietet Implementierungen, die mit der AMP-Laufzeit kompatibel sind und daher sowohl Sicherheit als auch Leistung garantieren ( amp-ad , amp-analytics , amp-carousel , etc.).
• Wenn Sie JavaScript wirklich für so etwas wie eine interaktive Funktion verwenden müssen, können Sie die Funktion unabhängig erstellen und sie dann mit einem [amp-iframe](https://www.ampproject.org/docs/reference/extended/amp-iframe.html) -Tag. Inhalt, der in einem amp-iframe enthalten ist, darf sogar eingeschränkt mit dem übergeordneten Dokument kommunizieren, z. B. für Größenänderungsanforderungen.
• AMP-Komponenten sind Open Source (Apache 2) und offen für Beiträge, sodass im Laufe der Zeit neue Komponenten erscheinen werden (im Laufe des Schreibens und Bearbeitens dieses Artikels sind tatsächlich mehrere neue Komponenten erschienen, daher habe ich bereits ein paar Mal aktualisiert). Während das AMP-Team allgemeine Komponenten gegenüber dienstspezifischen Funktionen priorisiert (z. B. ein Widget speziell für Ihr soziales Startup), ist es auch bestrebt, genügend Vielfalt bereitzustellen, um die größtmögliche Bandbreite an Inhalten aufzunehmen.
• Schließlich können sich alle diese Richtlinien ändern. Da Browserfunktionen wie Webworker, benutzerdefinierte Elemente und das Schatten-DOM immer mehr unterstützt werden, werden die Optionen zur Unterstützung von benutzerdefiniertem JavaScript und benutzerdefinierten Komponenten – bei gleichzeitiger Gewährleistung von Sicherheit und Leistung – dramatisch erweitert.

Weitere Informationen zur Zukunft von AMP-Komponenten finden Sie im Abschnitt „Extended Components“ der „AMP HTML Components“-Spezifikation.

Anatomie eines AMP-Dokuments

Nachdem Sie nun ein ziemlich solides Verständnis von AMP-HTML haben, lassen Sie uns einen Boilerplate aufschlüsseln.

Natürlich beginnen Sie Ihre AMP-Dokumente mit einer doctype Deklaration:

 <!doctype html>

Als nächstes kennzeichnen Sie Ihr HTML-Dokument als AMP-HTML, was Sie, ob Sie es glauben oder nicht, tun, indem Sie das Hochspannungs-Emoji als Attribut im html -Tag verwenden:

 <html >

Oder, wenn Sie ein altmodischer Griesgram sind und sich über die Idee ärgern, Ihren Code mit entzückenden Emojis zu schmücken, können Sie stattdessen das weitaus konservativere amp -Attribut verwenden:

 <html amp> <!-- A good sign that you're boring! -->

Vergessen Sie in Ihrem head -Tag nicht die Anweisungen zur utf-8 -Zeichencodierung:

 <meta charset="utf-8">

Und verlinken Sie auf die Nicht-AMP-Version Ihres Dokuments (als canonical markiert, damit es nicht als doppelter Inhalt angezeigt wird):

 <link rel="canonical" href="my-non-amp-index.html">

Umgekehrt sollte Ihre Nicht-AMP-Version einen Verweis auf das AMPlified-Dokument enthalten:

 <link rel="amphtml" href="my-amp-index.html">

Da AMP-Seiten für mobile Geräte gedacht sind (und Sie auch eine GPU-Rasterung wünschen), stellen Sie sicher, dass Sie ein Meta-Darstellungsbereich-Tag viewport :

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

Die nächste Codezeile wird ein wenig seltsam erscheinen, und das liegt daran, dass sie es ist. Sie wissen, wie Sie manchmal sehen, dass eine Webseite kurz Text rendert, bevor die Schriftarten geladen und angewendet wurden, dann flackert und wieder so gerendert wird, wie es der Designer beabsichtigt hat? Das Tag unten hält die Deckkraft der Seite auf 0 (unsichtbar), bis sie richtig gestaltet wurde.

 <style> body { opacity: 0 } </style> <noscript> <style> body { opacity: 1 } </style> </noscript>

Das Problem bei diesem Ansatz besteht darin, dass es technisch möglich ist, dass die Opazität der Seite niemals von 0 auf 1 geht, falls die AMP-Laufzeit nicht geladen werden kann. Um solche Eventualitäten zu kompensieren, wird der obige Code wahrscheinlich in etwas geändert, das näher an diesem liegt:

 <style> body { animation: amp-timeout 0x 5s 1 normal forwards; } @keyframes amp-timeout { 0% {opacity: 0;} 100% {opacity: 1;} } </style>

Als nächstes müssen Sie die AMP-JavaScript-Laufzeit einbinden:

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

Und schließen Sie die JavaScript-Implementierungen für die erweiterten Komponenten ein, die Sie benötigen:

 <script async custom-element="amp-youtube" src="https://cdn.ampproject.org/v0/amp-youtube-0.1.js"></script> <script async custom-element="amp-audio" src="https://cdn.ampproject.org/v0/amp-audio-0.1.js"></script> <script async custom-element="amp-carousel" src="https://cdn.ampproject.org/v0/amp-carousel-0.1.js"></script> <script async custom-element="amp-lightbox" src="https://cdn.ampproject.org/v0/amp-lightbox-0.1.js"></script> <script async custom-element="amp-anim" src="https://cdn.ampproject.org/v0/amp-anim-0.1.js"></script> <script async custom-element="amp-twitter" src="https://cdn.ampproject.org/v0/amp-twitter-0.1.js"></script> <!-- etc. -->

(Beachten Sie die Verwendung des async -Attributs. Das ist nicht optional – je weniger Blockierung, desto besser.)

Optional können Sie ein paar verknüpfte Daten wie folgt einstreuen:

 <script type="application/ld+json"> { "@context": "https://schema.org", "@type": "NewsArticle", "headline": "Turn Your AMP up to 11!", "image": [ "img/cover-opt.jpg" ], "datePublished": "2015-01-11T08:00:00+08:00" } </script>

Lassen Sie uns nun ein paar Schriftarten hinzufügen, indem Sie entweder link -Tags oder @font-face Regeln in Ihrem CSS verwenden:

 <link href='https://fonts.googleapis.com/css?family=Roboto+Condensed:300,700' rel='stylesheet' type='text/css'> <link href='https://fonts.googleapis.com/css?family=Lora:400,700,400italic,700italic' rel='stylesheet' type='text/css'>

Und dann werden wir einige Stile (nicht mehr als 50 KB wert) mit dem erforderlichen amp-custom Attribut:

 <style amp-custom>

Jetzt können Sie mit allem, was Sie gerade über AMP-HTML gelernt haben, ein mehr oder weniger standardmäßiges HTML-Dokument erstellen.

Die AMP-Laufzeit

Ich werde nicht allzu viel Zeit mit der AMP-Laufzeit verbringen, da sie, wie alle Laufzeiten, eine Art Blackbox ist. Das soll nicht heißen, dass auf die AMP-Laufzeit nicht zugegriffen werden kann (es ist Open Source, wie der Rest des Projekts). Vielmehr müssen Entwickler, wie bei allen guten Laufzeiten, nicht genau wissen, wie es funktioniert, um es nutzen zu können, solange sie im Allgemeinen verstehen, was es tut.

Die AMP-Laufzeit ist vollständig in JavaScript implementiert und wird initiiert, indem sie wie jede externe JavaScript-Datei in das AMP-Dokument eingefügt wird:

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

Von dort aus macht die AMP-Laufzeit hauptsächlich drei Dinge:

• verwaltet das Laden und Priorisieren von Ressourcen,
• implementiert AMP-Komponenten,
• enthält optional einen Laufzeit-Validator für AMP-HTML.

Der Validator ist entscheidend für die Erstellung von AMP-konformen Dokumenten. Es kann einfach durch Anhängen von #development=1 an die URL des Dokuments aktiviert werden. Dann müssen Sie nur noch Ihre Konsole öffnen, um Ihr Zeugnis zu sehen.

Fehler sehen so aus:

Ein schönes, sauberes, konformes AMP-Dokument sieht etwa so aus:

Der (optionale) AMP-Cache

AMP-Dokumente können wie jedes andere HTML-Dokument von einem Webserver bereitgestellt werden, sie können jedoch auch von einem speziellen AMP-Cache bereitgestellt werden. Der optionale Cache verwendet mehrere Techniken, um ein AMP-Dokument noch weiter zu optimieren:

• Bildreferenzen können durch Bilder ersetzt werden, deren Größe speziell auf das Betrachtungsfenster des Betrachters abgestimmt ist.
• Bilder "above the fold" können inline eingefügt werden, um zusätzliche HTTP-Anfragen zu sparen.
• CSS-Variablen können eingebettet werden, um den clientseitigen Overhead zu reduzieren.
• Erweiterte Implementierungen von AMP-Komponenten können vorab geladen werden.
• HTML und CSS können minimiert werden, um die Anzahl der über das Kabel (oder in diesem Fall den Äther) gesendeten Bytes zu reduzieren.

Jeder kann seinen eigenen AMP-Cache auf seinem eigenen CDN betreiben, oder Publisher können den von Google kostenlos nutzen. Angesichts der Tatsache, dass Google ein oder zwei Dinge über Skalierbarkeit zu wissen scheint, schätze ich, dass die meisten AMP-Anwender dieses Angebot gerne annehmen werden. (Documentation on how to opt in to Google's cache is forthcoming, but given that Google already indexes and caches the Internet, it's a safe bet that it will revolve around your link tags and perhaps an additional meta tag.)

How Do Readers Find AMP Content?

The fact that AMP document are more or less standard HTML that will render in any modern browser is, in my opinion, a huge advantage (AMP is far more open and inclusive than Facebook Instant Articles or Apple News). But from a practical perspective, it also raises the question of how audiences will find AMP content.

If readers use Google to search from a mobile device, Google can link directly to AMP versions of articles (Google has not said that it will prioritize AMP documents over non-AMP documents, but it has said that it will use “mobile friendliness” as a mobile search signal, so you do the math). In fact, Google has indicated that it will begin sending traffic to AMP pages from Google Search on mobile as early as late February 2016. Discovery and curation engines such as Pinterest may also choose to start directing mobile traffic to AMP pages (with a few infrastructure changes). Finally, websites can redirect their own mobile traffic from responsive versions of articles to their AMP counterparts. But from my perspective, a few pieces of the puzzle are still missing.

Will other search engines direct mobile traffic to AMP articles? (Perhaps not search engines that want to do business with Apple.) Will social networking apps preload AMP documents when users post links to articles, in order to make rendering nearly instantaneous? (Probably not Facebook.) Will mobile browsers start looking for link tags with amphtml relationships? (Chrome, maybe, but probably not mobile Safari.) And will aggregators and news readers out there build specifically for lightning-fast AMP content? (Time to resurrect Google Reader!)

At this point, the answers to most of these questions are the same: to be determined.

See AMP In Action

The easiest way to see AMP in action is to check out Google's search demo. If you're the trusting type, you can watch the video and just assume it all works as well as it's depicted. If you're more the trust-but-verify type, you can go to g.co/ampdemo on your mobile device and try out some AMP pages for yourself (QR code below).

You can also check out the AMP experience through desktop Chrome using Chrome's Developer Tools. All you have to do is this:

1. Go to g.co/ampdemo in Chrome.
2. Open the Developer Tools by going to “View” → “Developer” → “Developer Tools.”
3. Go into device mode by clicking on the little phone icon in the top-left corner.
4. Pick your favorite device to emulate. (For best results, reload the page in the emulator.)

Who's Adopting AMP?

It's still relatively early days for AMP, so it's hard to tell exactly who is adopting the new format in earnest, and to what extent. That being said, I've already seen several implementations out there in the wild, and according to the AMP FAQ and AMP blog, it's being taken seriously by many major publishers (metered content and subscription access is currently under review), CMS developers, advertisers, and analytics providers. I won't list them all here because I'm sure the landscape will change almost daily, but you can keep an eye on the AMP project's home page and/or the AMP blog for news.

What Do I Think?

I'm glad you asked. My guess is that just about all publishers will eventually adopt it. If companies like BuzzFeed have taught the industry anything, it's the importance of being in as many places as possible, and that digital publishing should be a technology platform capable of getting content in front of readers wherever they are, as opposed to being a singular destination waiting for readers to come to it.

The investment required to support AMP is also relatively minimal. If a publisher already supports — or plans to support — Facebook Instant Articles and Apple News, then they might as well implement support for AMP as well. While CMS strategies vary widely across the publishing industry, most CMS' have a concept of templates and/or plugins that, once implemented, would do most of the work of converting articles into AMP HTML. (WordPress, the closest thing we have to an industry leader, already has a plugin and plans on supporting AMP for all publishers in January 2016.) And because AMP is far less proprietary than its competition (meaning that it is open source, open to contributions, based on web technologies and client-agnostic), I would expect publishers to feel more comfortable distributing their content in a format that they feel they will have more control over long-term.

The reality is that publishers will back whatever syndication formats and partners will help get their content in front of the maximum number of readers with the least amount of overhead and investment. Right now, we are in the very early stages of a new type of war that is part platform, part format and in which each party will leverage its unique strengths to maneuver itself into the best possible position. At this point, it's far too early to say which will endure and which will become the RSS of tomorrow.

Zusätzliche Ressourcen

• “Introducing the Accelerated Mobile Pages Project, for a Faster, Open Mobile Web” Google Official Blog
• Accelerated Mobile Pages Project, official website
• Accelerated Mobile Pages, blog
• AMP HTML, GitHub
• Docs, Accelerated Mobile Pages Project
• Nigel Tufnel explaining why his amp goes to 11