Amazon Silk Was Amazons Browser anders macht

Amazon hat für sein kommendes Android Tablet Kindle Fire einen eigenen Browser entwickelt, der einiges anders macht: Silk.

Auf der O'Reilly-Konferenz Velocity Europe in Berlin gab Projektleiter Jon Jenkins einen Einblick in Amazons Browser Silk, der zusammen mit dem Kindle Fire veröffentlicht wird. Und obwohl Silk auf der Rendering-Engine Webkit und Googles Javascript-Engine V8 basiert, gibt es große Unterscheide zu anderen Browsern, denn bei Silk handelt es sich um einen geteilten Browser, der zum Teil auf dem Client, zum Teil aber auch auf dem Server läuft. Das Prinzip ist von Opera Mini und Opera Mobile mit Opera Turbo bekannt, Amazon geht aber andere Wege.

Der Grund für die geteilte Architektur von Silk ist einfach: Geschwindigkeit. Webseiten werden immer komplexer und bestehen zunehmend aus mehr Einzelbestandteilen, mobile Geräte aber haben eine vergleichsweise geringe Rechenleistung. Und die Geschwindigkeit, mit der moderne Webseiten auf dem Display landen, hängt stark von der vorhandenen Rechenkapazität ab.

Silk-Server bei EC2 sollen das Surfen beschleunigen

Silk wickelt daher einen Teil der Aufgaben auf dem Server ab, was das mobile Surfen beschleunigen soll. Anders als Opera Mini handelt es sich bei Silk aber um einen vollständigen Browser auf Basis von Webkit. Je nach Inhalt entscheidet der Browser, ob Seiten auf dem Client oder Server gerendert werden. So kann es sein, dass Silk auf der Serverseite nur die einzelnen Bestandteile einer Website lädt, um sie dann gebündelt an den Client zu liefern. Da hierbei viele Server zum Einsatz kommen, kann Amazon praktisch alle Teile einer Seite parallel laden, was die Ladezeit der Seite verkürzt. Es kann aber auch vorkommen, dass Seiten fast komplett auf dem Server gerendert und dann an den Client geliefert werden.

Zudem können Nutzer die Beschleunigung über die Silk-Server jederzeit ein- und ausschalten, wobei der Browser auch ohne Netzverbindung funktioniert, um Offline-Applikationen auszuführen. Gleiches gilt für Flash, denn Silk unterstützt Adobe Flash 10.3.

Dabei nimmt Amazon auf Serverseite verschiedene Optimierungen vor: So werden CSS- und Javascript-Dateien minimiert, falls sie nicht schon in dieser Form ausgeliefert werden. Sollten HTML-Seiten nicht komprimiert ausgeliefert werden, nimmt Amazon auch dies auf Serverseite vor.

Zudem kommt ein verteilter Cache zum Einsatz. Amazon speichert also Inhalte zwischen, so dass sie direkt aus dem Arbeitsspeicher eines Cacheservers bei Amazon geliefert werden können. Dabei teilen sich mehrere Browserinstanzen einen Cache.

Inhalte werden optimiert

Amazon nimmt aber noch weitere Optimierungen an den Inhalten vor: So werden Bilder optimiert und bestimmte Inhalte direkt aus dem Cache geliefert, ohne sie aus dem Web zu holen. Dazu setzt Silk auf Page-Indizes, um Inhalte zu identifizieren, die sich selten ändern, beispielsweise Logos. Hinzu kommt Predictive Rendering: Silk lernt mit der Zeit das Verhalten von Nutzern, um bestimmte Inhalte schon vorab zu laden. Das passiert immer dann, wenn Nutzer mit großer Wahrscheinlichkeit von einer Seite eine bestimmte andere aufrufen.

Die Kommunikation zwischen dem Silk-Client und dem Silk-Server läuft über das von Google entwickelte Protokoll SPDY ab. Die komplette Serverinfrastruktur ist auf AWS (Amazon Web Services) gehostet. Jenkins betont, Amazon speichert keine nutzerspezifischen Daten, und HTTPS-Verbindungen werden grundsätzlich nicht über Amazons Server umgeleitet.

User Agent Mode und IP

Der User-Agent-Modus wird automatisch gesetzt, so dass immer die von den meisten Nutzern bevorzugte Variante einer Website - Mobile oder Desktop - angezeigt wird. Die IP-Adresse des Nutzers wird in jedem Fall an die Website weitergereicht und anhand des User-Agents sollen Webmaster erkennen können, ob ein Zugriff über die Silk-Server beschleunigt wurde. Zudem hält sich Silk immer an die gesetzten Cache-Header.

Letztendlich gilt: Läuft etwas schief, rendert Silk Inhalte lokal auf dem Client, so wie es andere mobile Browser auch tun.