‹ Alle Einträge

Warum Googles AMP ⚡-schnell sind

 
Warum Googles AMP ⚡-schnell sind
Accelerated Mobile Pages in den mobilen Suchergebnissen.

Seit Mittwoch mischt Google unter die Ergebnisse der mobilen Suche sogenannte Accelerated Mobile Pages (AMP). ZEIT ONLINE und eine Reihe nationaler und internationaler Onlinemedien stellen dafür ihre Artikel im neuen, für mobile Performance optimierten Format AMPHTML (⚡) zur Verfügung.

AMP sollen, wie Facebooks Instant Articles, blitzschnell laden, egal ob ein Leser sie in den Suchergebnissen bei Google, oder in der Twitter-App angeklickt hat. Falls Sie sich, wie wir, fragen, was diese Artikel schneller macht als herkömmliche Websites – hier sind sieben der wichtigsten Gründe:

1. Prefetching

Das AMP Carousel in der mobilen Google Suche
Das AMP-Karussell in der mobilen Google Suche

Noch während der Leser durch das AMP-Karussell in den Ergebnissen der mobilen Google-Suche scrollt, lädt der Browser Teile der Artikel, die im Karussell angeboten werden. Dass verlinkte Inhalte schon geladen werden, bevor sie geklickt wurden, ist an sich nicht neu. Aber bei AMP werden nur die Teile geladen, die nach dem Klick direkt verfügbar sein müssen: Das Gerüst der Seite und der Text. Für Bilder, Anzeigen, Videos und alles andere werden nur Platzhalter geladen.

2. Caching und AMP CDN

Auch wenn die AMP von ZEIT ONLINE auf unseren Servern liegen, bekommt der Leser sie aus Googles Content Delivery Network (CDN). Dort werden AMP inklusive aller Bilder und Scripts gecached. Das hat gleich mehrere positive Effekte auf die Ladezeit: Zum einen wird die Seite schneller geladen, wenn alle Elemente vom selben Server geladen werden können.

Zum anderen sind Googles Server – im Gegensatz zu unseren – auf der ganzen Welt verteilt. Dadurch ist die Response-Time vor allem besser, wenn ein Leser zum Beispiel in den USA auf eine AMP von ZEIT ONLINE zugreift. Das sind die üblichen Vorteile von CDN. Im Falle des AMP CDN werden die Artikel auf dem Caching-Server aber noch optimiert. Das HTML wird komprimiert, alle Javascripts werden in einem File zusammengefügt und komprimiert und die Bilder für die Screengröße des Clients optimiert.

3. Lazy Loading und priorisierte Requests

In AMP werden nur die Bilder, Anzeigen etc. geladen, die wahrscheinlich vom Nutzer gesehen werden. Wenn er anfängt, eine AMP zu lesen, wird von oben nach unten und priorisiert weiterer Content nachgeladen – lazy, also erst, wenn’s sein muss. Als erstes wird das Dokument aufgebaut, die Schrift geladen und der Text “geschrieben”. Dann werden nach und nach die Platzhalter für Bilder, Werbung, Videos etc. durch die geladenen Elemente ersetzt. Individuelle Schriften sind ein interessanter Punkt. Üblicherweise kommt die verhältnismäßig große Schriftdatei nämlich nach den Styles, die bei AMP inline stehen. Bei AMP ist die Schrift entsprechend die erste große Datei, die geladen wird. Das beschleunigt den Seitenaufbau wiederum.

4. Asynchrones und eingeschränktes Javascript

Javascript ist essentiell, wenn wir Infografiken, KartengeschichtenBildergalerien oder andere interaktive Elemente entwickeln. Je nachdem, wie der Code geschrieben ist und wie viel davon mit einem Seitenaufruf verarbeitet werden muss, kann Javascript die Seite aber ausbremsen. In AMP ist Javascript deshalb nur sehr eingeschränkt nutzbar.

Javascript ist nur innerhalb sogenannter AMP-Extensions und in amp-iframes zugelassen. In beiden Umfeldern werden die Scripts asynchron ausgeführt. Das heißt zum Beispiel, dass die interaktiven Elemente einer Bildergalerie, amp-carousel, erst dann geladen werden, wenn der Rest der Seite schon geladen ist und, dass kein Script auf ein anderes wartet.

Die Idee der Extensions gab es schon vor AMP und auch vor Facebooks Instant Articles. Frameworks wie Polymere definieren Standardelemente (Custom- oder Web-Components) wie interaktive Karten, Bildergalerien etc., die dann mit neuen HTML Tags wie <google-map> in Seiten eingebunden werden können. Die Idee war, diese Standardkomponenten in Browser und Betriebssysteme zu integrieren, sodass der Nutzer nur noch die Inhalte, aber nicht mehr die Scripts für die Komponenten selbst laden muss.

5. Inline Stylesheets

Stylesheets neigen dazu, auszufransen. Für jedes Element kommen ein paar Zeilen dazu und irgendwann sind die Stylesheets groß und bremsen die Seite aus. In AMP müssen alle Style-Informationen direkt in die Seite geschrieben werden. Das CSS darf nicht größer als 50 Kilobyte sein und bestimmte CSS-Features wie filter, moz-binding, universelle Selektoren, die die Performance beeinträchtigen, sind in AMP nicht verwendbar.

6. Prerendering minimiert die Paint-Zeit

Sie kennen das nervige Phänomen, wenn Sie angefangen haben zu lesen und der Inhalt der Seite sich verschiebt. In der Regel passiert es, wenn Bilder oder andere Elemente erst fertig geladen werden, nachdem Sie zu lesen begonnen haben. Der Effekt ist nicht nur nervig. Er bedeutet auch, dass der Browser die Dimensionen der Seite noch einmal neu berechnen musste, was Zeit und Rechenleistung kostet. In AMP wird das verhindert, indem jedes Element feste Dimensionen haben muss. Anstatt zu sagen “hier kommt gleich eine Anzeige hin”, sagt der Entwickler in AMP “hier kommt gleich eine Anzeige hin, die X Pixel hoch und Y Pixel breit ist”. Darüber, wie die Neuberechnung des DOMs den Seitenaufbau ausbremst, hat Paul Lewis einen lesenswerten Post geschrieben.

Feste Dimensionen klingt erst mal falsch in der Ära responsiven Webdesigns. Tatsächlich gibt der Entwickler mit width und height im amp-img-Tag mit dem Attribut responsive aber nur das Seitenverhältnis des Bildes an.

7. Universelle Analytics-API

Google hat naturgemäß nichts gegen Nutzungsanalysen, weiß aber auch um die schweren Tracking-Scripts der verschiedenen Anbieter und den Trend, gleich mehrere Analysetools auf derselben Seite einzubinden. Deshalb bietet das AMP-Projekt eine Tracking-API, welche die üblicherweise interessanten Daten standardisiert bereitstellt. An die Analytics-API haben große Anbieter wie Adobe Analytics, Comscore, Chartbeat, die IVW, Webtrekk und natürlich auch Google selbst mit Google Analytics angedockt.

Der Nutzer im Fokus

Eines hat Google mit der AMP-Initiative auf jeden Fall schon erreicht: Das Open Source Projekt gibt der Branche eine Reihe von Beispielen, wie Websites beschleunigt werden können. Laut Projekt-Website laden AMP durchschnittlich viermal so schnell wie die normale Webversion und verbrauchen dabei nur etwa ein Zehntel der Daten. Wenn sich die AMP-Versionen der ZEIT-ONLINE-Artikel jetzt auch noch im Ergebnis-Ranking behaupten, hat sich der Aufwand allemal gelohnt.

Sie finden unsere AMP, wenn Sie mit Ihrem Smartphone auf Google nach aktuellen Nachrichtenthemen wie “Flüchtlinge” oder “Löwenzahn” suchen. Auf iOS-Geräten erscheint das AMP-Carousel bisher (Stand Donnerstag, 25.02.2016) nur im Safari. Auf Android-Geräten nur im Chrome-Browser.

Hier Sehen Sie eine ZEIT-ONLINE-AMP zum Thema Asylpolitik.

15 Kommentare

  1.   Liebe Zeit Online Techies ...

    …. habt Ihr Euch Eure Lazy-Styles im Rahmen der Request-Analyse eigentlich einmal selber im Brain gepainted bzw. verstanden?

    Ich denke Mal, hier halten sich weiterdenkende Redaktionsmitglieder zurück um sich nicht als Anti-Techie die knappe Rente zu versauen. Aber das ist noch nicht das Schlimmste bzw. der Worst Case: der kommt erst angerauscht, wenn man etwas hinter die API Kulissen schaut. Bitte prefetched Euren Kram noch einmal bei eingeschaltetem Verstand.
    Wenn Ihr dabei Hilfe braucht, bitte asynchronen Request schicken.
    Euer Justus

  2.   Thomas Strothjohann

    Hallo Justus,
    das ist ein asynchroner Request… ich weiß nicht, worauf genau du hinaus willst.

    Gruß, Thomas

  3.   m_for_manu

    Da der erste Versuch wohl nicht erfolgreich war, nochmal…

    Bis auf das CDN aus Punkt 2, hat man doch selbst alles in der Hand und kann das so auf der eigenen Seite umsetzen. Man müsste nur mal auf diese ganzen Drittanbieter-Skripte verzichten, nicht wahr? :) Da haben aber bestimmt do manche hauseigene Entwickler mit den Augen gerollt, oder?

  4.   Thomas Strothjohann

    Hallo m_for_manu,
    du hast völlig Recht: das meiste könnte man auch an der “normalen” Seite umsetzen. Tatsächlich ist die Liste auch eine Art ToDo für uns. Manches ist auf einer Seite wie zeit.de, auch wegen des Business Modells schwer umsetzbar. Meine Kollegen haben allerdings nicht zu lange mit den Augen gerollt. Im Gegenteil: sie haben die AMP ja eigenhändig – und wie ich finde – sehr gut implementiert.

  5.   m_for_manu

    Ich verweise mal (auf das bei Entwicklern bestimmt bekannte) Video zum Thema „Gewichtsprobleme bei Websites“: http://www.webdirections.org/blog/the-website-obesity-crisis/ Ironischerweise kommt die Werbeseite von Google AMP dazu ja sehr übel weg. :)

    Seien wir doch mal ehrlich: die Online-Werbung braucht eine Wandlung, denn diese ist für fast 90% der Probleme welche AMP „behebt“ verantwortlich. Die Lösung von Google besteht ja eigentlich nur darin diese nicht mehr extern zu laden. Ob ich das CSS inline einbinde oder einen Request mehr habe (vorausgesetzt ich merge und minify-e meinen Kram selbst) macht doch wirklich nichts aus.

    Man müsste eventuell die Werbung selbst verkaufen und hosten. Es bleibt also ein Business-Thema und weniger ein technisches. Bzw. wird den Entwicklern, also deinen Kollegen ja das Leben schwer gemacht weil zeit.de ja nur für einen kleinen Teil des Traffics hier verantwortlich ist. Den Rest liefern Ligatus, Google (!), Addition und Konsorten. Vielleicht sollten wir Entwickler mehr mit den Verantwortlichen sprechen als immer mehr kleine Script-Requests in den Header und vor dem zu setzen. Ich meine das ganz konstruktiv.

  6.   SeppD

    Ähem,

    das schöne Logo für den Blitz erinnert aber ganz fatal an etwas aus alter Zeit. Ob das so glücklich gewählt ist?

  7.   Thomas Strothjohann

    @m_for_manu Danke für das Video. Für die Nutzer ist es in jedem Falle gut, dass die AMP – auch mit Werbung – schnell laden. Das kann der erste Schritt zu “leichteren” Ads und Seiten sein.

  8.   Axel

    @SeppD: Ja, stimmt. Mich erinnert der Blitz auch stark an das Winamp-Logo.

    Ein Zufall? Oder Absicht, weil beide das “amp” im Namen tragen? Da war anscheinend jemand der Verantwortlichen des Projekts ein großer Fan des MP3-Players.

    Wie dem auch sei. Bei mir läuft Winamp übrigens auch noch auf allen meinen Rechnern.

  9.   schmoddermonster

    @SeppD
    es erinnert an einen blitz.
    fatal wäre nur, wenn es 2 nebeneinander wären.

  10.   Robert

    Wie wär’s, wenn Ihr statt in Geschwindigkeit und neue Features mal ein wenig mehr in die Qualitätssicherung investiert?

    Ich rufe Eure Seite mit 5 verschiedenen Betriebssystemen mit drei verschiedenen Browsern auf. In mindestens einer dieser Kombinationen ist die Seite immer kaputt. Bilder laden nicht, die Navigation in den Kommentaren geht nicht, uvm…

    Testet denn keiner mehr? So aufwendig ist das nun wirklich nicht.