Natürlich mag ich elegante Websites.
Natürlich betrachte ich gern gute Fotos und interessante Videos und lese gern gute Geschichten.
Ich mag auch elegante Autos, extravagante Kunst, Drei-Sterne Restaurants und sündhaft teure Modekreationen.
Den Grossteil meiner Zeit verbringe ich jedoch damit, mein Leben möglichst effektiv zu organisieren. Beim Online Einkauf mag ich einfache, logische Checkouts und verständliche Artikelbeschreibungen, Blogeinträge möchte ich einfach nur lesen und kein Brimborium drumherum haben. Wenn ich eine Website besuche, möchte ich meist ein Bedürfnis befriedigen oder ein Problem lösen, beispielsweise die Postadresse des Seitenbetreibers finden.
All das wird heutzutage unter dem Begriff User Experience subsumiert und diese Experience ist überlebenswichtig für Website Anbieter.
Was ich auf meinem Telefon nicht lesen kann, lese ich vermutlich nie.
Auch im Jahr 2016 ist schnelles mobiles Internet kein Standard. Ausser Chatten geht in vielen Gegenden Europas nichts, weil die Internet Verbindung einfach zu langsam ist. Ein Grund, warum Messaging Apps so beliebt sind.
Nun gibt es grundsätzlich immer zwei Möglichkeiten so ein Problem zu lösen.
- Schnelles Internet bereit stellen
- Die Informationen so aufbereiten, dass sie auch mit langsamer Internetverbindung aufrufbar sind.
Als Website Betreiber, der ich ja auch bin, kann ich den ersten Punkt nicht umsetzen, also bleibt mir nur die zweite Variante. Auch dort gibt es zwei Möglichkeiten:
- Eine „echte, aufwendige, bunte, schöne, durchgestylte“ Website und eine „abgespeckte“ mobile Variante
- Eine Website für alle, die sich an das Ausgabegerät anpasst (responsiv)
Die zweite Variante klingt auf jeden Fall zukunftssicherer bei der Vielfalt von mobilen Endgeräten die bereits existieren oder demnächst auf den Markt kommen. Content Management Systeme wie WordPress, Joomla und Drupal sind mittlerweile standardmässig responsiv. Unglücklicherweise steigt aber damit auch die Ladezeit einer Website, also die zu übermittelnde Datenmenge und die Anzahl der zu übertragenden Dateien an.
Beide Effekte verlangsamen den Transport und Aufbau eine Website auf einem Telefon ungemein.
My modest proposal: your website should not exceed in file size the major works of Russian literature. Anna Karenina, for example, is 1.8 MB
— Pinboard (@Pinboard) October 12, 2015
Um diesen Tweet lesen zu können, werden im Browser 470,7 Kilobyte übertragen (470,700 Byte). Der relevante Text besteht bei einem Tweet aus maximal 140 Zeichen. Ein Zeichen könnte man in einem Byte darstellen, maximal in 2 Bytes. Es werden also etwa 1,650 oder 3,300 mal soviele Bytes übertragen um 140 Zeichen (in 1 oder 2 Bytes) darzustellen und das in 30 Dateien!
Nun ist das kein spezifische Problem von Twitter sondern betrifft mehr oder weniger jede Website.
Ein paar Beispiele:
- NZZ – Startseite – 1,400,000 Byte, 74 Dateien
- SPIEGEL-Online – Startseite – 1,200,000 Byte, 103 Dateien
- Medium – Chris Dixon – What’s next in Computing? – 49,600,000 Byte, 105 Dateien
Selbst die Startseite unseres Blogs bringt es auf 247,800 Byte und 23 Dateien. Ich habe aber auch gelernt, dass wir damit im Vergleich zu anderen Websites recht niedrig liegen 🙂
Werbung
Ein immer grösser werdender Posten bei den Ladezeiten sind datenintensive Werbeformen und Tracking Scripte. Ein sehr eindruckvoller Vergleich der Ladezeiten von Werbe- und redaktionellen Inhalten hat die New York Times für die USA dargestellt (The Cost of Mobile Ads on 50 News Websites – New York Times).
Was tun?
Was kann der Einzelne jetzt tun, um Websites schlanker zu machen? Einen besonders konsequenten Schritt geht Felix von Leitner mit seinem Angebot Fefes Blog (Wikipedia). Er verzichtet auf alles unnötige, nutzt HTML und schafft es, alle Artikel für den Monat Februar in 19,300 Bytes darzustellen – in EINER Datei!
Auch die Ladezeit dürfte der Beliebheit seines Blogs sehr gut tun.
Jetzt kommst du und sagst:
Ja, ja, das ist Fefe mit seinem Textblog, aber ich brauche doch Photos und Videos und Slider und JavaScript Frameworks …
Was machen die Grossen?
Die Diskussion entging den „üblichen Verdächtigen“ natürlich nicht und so erfand Facebook das Produkt Instant Articles, Apple die App News und Google schliesslich Accelerated Mobile Pages.
Facebook Instant Articles
Instant Articles werden sehr schnell dargestellt, sollen Verlage zu Facebook locken und Besucher auf der eigenen Plattform halten. Die Werbeeinnahmen von Facebook werden im Verhältnis 30/70 geteilt, 70% gehen an den Content Lieferanten.
Apple News App
Apple News ist eine News App, die momentan in UK, USA und Australien angeboten wird und ähnlich wie Flipboard ein persönliches Nachrichten-Feed anbietet das schnell läd und schön aussieht.
Google Accelerated Mobile Pages
Und jetzt kommt Google und erfindet mit dem Open Source Projekt AMP das einfache Web mehr oder weniger neu.
Auf Github findet sich der Quellcode (https://github.com/ampproject) und damit möchte Google das Web „great again“ machen.
Um ein Facebook Instant Article Publisher zu werden, muss man sich bewerben.
Um in die Apple News App zu kommen, muss man sich ebenfalls bewerben.
Google dagegen kommt zu dir und sieht nach, ob du eine AMP Version deiner Website betreibst. Wenn ja, wirst du in den Suchergebnissen bevorzugt behandelt. Wenn nein … tja … dann eben nicht!
Ich will nun gar nicht über Themen wie Plattformen, Marktmacht, Verlage und Inhalte sprechen, ich finde die Angebote der grossen Drei durchaus interessant. Sie erfinden gerade etwas neu, was es eigentlich schon gibt – HTML!
Sie erfinden es aber so, dass meine Bedürfnisse von oben vermutlich perfekt erfüllt werden.
AMP und deine Website
Da Facebook Instant Articles und die Apple News App für einfache Website Betreiber zunächst noch eher uninteressant sind, will ich etwas genauer auf Googles AMP Projekt eingehen. Das AMP Prinzip entspicht der bereits oben aufgeführten Problemlösung: Eine „echte, aufwendige, bunte, schöne, durchgestylte“ Website und eine „abgespeckte“ mobile Variante“, wobei die AMP Version die mobile Variante ist. Die AMP Version deiner Seite wird dem Besucher allerdings nicht automatisch auf dem Mobilgerät angezeigt, sie wird „nur“ über sogenannte AMP consumers genutzt, beispielsweise Google Search.
- WordPress:
WordPress bietet ein offizielles AMP Plugin an. Es erzeugt dynamisch AMP-kompatible Versionen deiner Seiten, die über den Zusatz /amp/ am Ende des URL aufrufbar sind. Wenn du beispielsweise einen WordPress Artikel mit der dem URL http://example.com/2016/02/29/mein-artikel/ hast, dann wird die AMP Version über http://example.com/2016/02/29/mein-artikel/amp/ aufgerufen. AMP-Aufrufe von Seiten (Pages) werden momentan nicht unterstützt. - Joomla:
Es lässt sich momentan (29.2.2016) nichts im Extension Directory finden, aber hinter den Kulissen schreiben viele Anbieter Plugins für AMP. Hier ein Beispiel: Weeblr – Accelerated Mobile Pages for Joomla - Drupal:
Das Drupal Modul AMP ist für die Drupal 8 als Beta Version verfügbar. Damit es funktioniert, wird die PHP AMP Library benötigt und das AMP Basis Theme. Die Installation beschreibt der Artikel AMPing up Drupal sehr gut. Für Drupal 7 liegt das Modul leider noch nicht vor und so muss ich unser Blog entweder auf Drupal 8 updaten oder auf das entsprechende Modul für Drupal 7 warten.
Fazit
Ein deutliches hmmmm :).
Ich weiss noch nicht so recht, was ich davon halten soll. Grundsätzlich sind alle drei Ideen gut durchdacht. Sie dienen aber vermutlich hauptsächlich dazu, Besucher auf der jeweiligen Plattform zu halten, weil die dort angebotenen Inhalte so schön und schnell laden. Facebook und Google können dann prinzipiell mehr Werbung verkaufen, im Falle von Facebook werden die Erlöse mit dem Inhaltsanbieter geteilt.
Bei aller Schönheit und Schnelligkeit darf man nicht vergessen, dass HTML diese Funktionalität bereits heute sehr effizient bietet. Bei Websites wie Fefes Blog beispielsweise würde eine Technik wie AMP die Grösse nur unnötig aufblähen und die Ladezeiten vergrössern.
tl;dr: Das schnelle Web wird gerade jeweils von Facebook, Apple und Google neu erfunden.