Wenn das Webdesign verschwindet: Headless Browser brauchen keine schöne Gestalt

Ist der Browser, wie wir ihn heute kennen, ein Auslaufmodell? Können wir auch ohne ihn das Web nutzen? Die Antwort auf die zweite Frage ist ein klares Ja. Das Headless Web macht es möglich.

Headless Browser: UI ohne UI

Seit gut zehn Jahren gibt es die Spezies der Headless Browser. Dabei handelt es sich um Anwendungen, die auf den gängigen Rendering-Engines (Chrome, Webkit, Gecko) basieren und Web-Inhalte darstellen können, ohne sie tatsächlich darzustellen. Es fehlt ihnen das grafische Nutzerinterface, sie sind quasi kopflos. Daraus erklärt sich auch ihre Bezeichnung, das „Headless”.

Ursprünglich wurden Headless Browser entwickelt, um Webseiten schnell und automatisiert testen zu können. Das geschieht in der Regel über die Befehlszeile (CLI) oder definierte Schnittstellen (API). Fehlerausgaben erfolgen auf Anforderung als Screenshots oder in anderen definierten Formen.

Seit der Erfindung der Headless Browser ist die Entwicklergemeinde gespaltener Meinung. Die einen halten die Technologie generell für Blödsinn und testen ihre Designs und Anwendungen lieber unter einer Vielzahl „normaler” Browser. Die Begründung ist plausibel.

Immerhin verwendet der Besucher, der letztlich das Angebot nutzen soll, ebenfalls keinen Headless Browser. PhantomJS, als einer der bekanntesten dieses Genres, erzeugt in manchen Fällen wohl auch Fehlermeldungen, die es im regulären Browser schlussendlich doch nicht gibt. Das ist nur bedingt nützlich.

Auch Node.js erfreut sich als serverseitige Basistechnologie einer gewissen Beliebtheit bei den Herstellern von Headless Browsern. Ein recht moderner Vertreter dieser Richtung ist ZombieJS, dem die Kopflosigkeit schon im Namen liegt. Anders allerdings als der Name vermuten lässt, soll ZombieJS außerordentlich schnell sein und sich deshalb für großanlegtes, effizientes Testing in besonderem Maße eignen.

Die überzeugten Verwender der Headless Browser schätzen dabei gerade die Möglichkeit, schnell und unkompliziert eine Vielzahl von automatisierten Tests über einen Headless Browser oder eine ganze Gruppe solcher Dienste laufen lassen zu können. Es sind in erster Linie die Entwickler komplexer Web-Anwendungen für große Zielgruppen, die die Vorteile der Headless Browser zu schätzen wissen.

Der durchschnittliche Webentwickler mit überschaubarem Projekt- und Kundenstamm braucht die so zu erzielenden Skaleneffekte, im Sinne der Zeitersparnis, letztlich nicht und wird eher den konventionellen Weg wählen.

Headless Browser: Google skaliert den Nutzen

Schon im Jahr 2009 kam der Suchmaschinenriese Google auf die Idee, Headless Browser einmal ganz anders zu nutzen. Die Kalifornier standen nämlich vor dem Problem, per AJAX dynamisch generierte Inhalte nicht indexieren zu können. Schlussendlich wird aus solchen Inhalten erst nach deren Generierung eine indexierbare Website, weil diese eben den Browser benötigen, um korrekt gerendert und damit lesbar zu werden.

Die Suchmaschine brauchte also intern einen Browser, um die damit zu lesenden Inhalte wiederum selber nutzbar zu machen. Gesagt, getan. Seither verwendet Google Headless Browser und kann so, wenn der Webseitenbetreiber ein wenig Vorsorge betreibt, auch Inhalte lesen, die eine Front-End-Interaktion benötigen, um zur Ausgabe zu gelangen. Bing verwendet eine ähnliche Technologie.

Wenn jetzt die Browser-Engines immer leistungsfähiger werden, was bedeutet das dann für Headless Browser? Richtig, auch diese werden immer leistungsfähiger.

Progressive Web Apps (PWA) zeigen, wohin die Reise geht

Hast du schon meinen Artikel zu „Progressive Web Apps” gelesen? Dann weißt du ja, warum dem Konzept auf längere Sicht die Zukunft gehört. Denn du hast gesehen, dass PWA funktional immer mehr zu nativen Apps aufschließen.

Eine der Kerntechnologien einer jeden PWA ist der sogenannte Service Worker. Dabei handelt es sich um ein JavaScript, das Funktionen ausführen kann, ohne dass die Website überhaupt aufgerufen sein muss. Nähere Erläuterungen findest du im eben genannten Beitrag.

Der Service Worker ist somit selber ein Teil des Headless Web und kann von einem Headless Browser in gleicher Weise wie auf der Clientseite serverseitig verwendet werden. Der Headless Browser wird damit zu einem Service, der programmatische Abläufe schon auf Serverseite abwickeln kann. Dadurch wird der Browser auf der Seite des Besuchers potenziell überflüssig.

Im Headless Web werden Inhalte zu Modulen

Denn der Headless Browser hat Inhalte modular vorgerendert. Diese fertig gerenderten Stücke Webcontent liegen zur Weiterverarbeitung oder Anzeige vor. Es bedarf nicht zwingend eines Browsers, um sie korrekt darzustellen. Ebenso könnte eine native App sich um die gesamte Darstellung kümmern und die vorgerenderten Web-Schnipsel innerhalb der eigenen UI strukturiert zur Anzeige bringen.

Beispiele für solche Vorgehensweisen sind die Facebook Instant Articles oder Googles AMP-Projekt. Schon im obengenannten Beitrag hatte ich darauf hingewiesen, dass gerade Google ein besonderes Interesse daran haben muss, das offene Web zu schützen. AMP ist ein Baustein dabei, der allerdings ebenfalls nicht auf uneingeschränkte Zustimmung stößt.

In die gleiche Richtung gehen die Web-Push-Notifications, z. B. unter Googles Betriebssystem Android.

Microdata spielt hier ein wichtige Rolle. Du magst eventuell einwenden, dass es bereits heute Datenübergaben etwa per JSON gibt und das stimmt natürlich. Das Headless Web geht aber mehrere Schritte weiter, denn es übernimmt nicht bloß Daten aus einer Übergabeschnittstelle, sondern komplette Funktionsmodule, inklusive etwa integrierter programmlogischer Bestandteile.

Dazu ist es erforderlich, besonders auf semantisch korrekte Auszeichnung zu achten, um schlussendlich Bausteine zu erzeugen, die sinnvoll verwendet werden können.

Die Verfechter offener Webstandards könnten sich nun also freuen. Denn das eben diese offenen Standards in der Zukunft an Bedeutung gewinnen werden, kann aus meiner Sicht als sicher gelten.

Die Freude über den Sieg der offenen Webstandards könnte allerdings dem durchschnittlichen Webdesigner schnell vergehen. Denn klassisches Webdesign wird nicht mehr benötigt, der Aspekt der Architektur tritt noch stärker in den Vordergrund als bislang schon. Eben dieser Aspekt ist bereits bei AMP ganz deutlich zu erkennen. Die sehr standardisierte Darstellungsweise und vor allem die Auslieferung der Inhalte über Google-Server ist allerdings nicht nach jedermanns Gusto. Das Projekt ist durchaus umstritten, wird aber von Publishern, also den Inhalteanbietern, fast lückenlos unterstützt.

Ist es am Ende eher so, dass sich die Bereiche Design und Entwicklung bloß wieder stärker voneinander separieren? Heutzutage sehen wir ja doch in der Frontend-Entwicklung deutliche Vermischungen der Disziplinen. Das fängt schon da an, wo der Webdesigner die Software auf dem Server installiert und das CMS-Theme so anpasst, dass es dynamische Inhalte korrekt zeigt.

Wo wir schon beim Thema Headless sind, sollte nicht unerwähnt bleiben, dass sich der Trend auch für CMS fortsetzt. Sogar WordPress und WooCommerce lassen sich headless betreiben, also ohne Frontend. Die Inhalte können in standardisierter Form aus dem Backend gezogen und in beliebiger Weise genutzt werden, etwa in eigens dafür konzipierten nativen Apps für Mobilgeräte.

Neben den bekannten Marktteilnehmern entstehen indes auch Lösungen, die von Beginn an auf Kopflosigkeit setzen und insofern ohne Legacy-Ballast auskommen. Ein Beispiel dafür ist ButterCMS, das in der Google Cloud existiert; ein anderes Beispiel ist Kentico Cloud, das ebenfalls als Cloud-SaaS betrieben wird.

Aktuell gibt es noch keine Lösung dafür, Headless Browser so zu skalieren, dass sie Tausende von Instanzen gleichzeitig anbieten könnten. Diese technische Hürde wird zwar mit Sicherheit in der Zukunft fallen, aktuell steht sie aber noch. Mindestens solange werden Websites mit Gesicht auch nicht überflüssig werden.

Weiterführende Links:

• Was sind Progressive Web Apps und wieso sollte dich das interessieren? – Web
• Six Popular Headless Browsers for Web Testing – KeyCDNs Cody Arsenault
• The Headless Web – Paul Kinlan
• Das AMP-Projekt – Google
• Microdata-Spezifikation – W3C
• Headless Websites: What’s the Big Deal with Decoupled Architecture? – Pantheon
• Web Notifications Introduction: News on Lock(screens) – Guardian Mobile Innovation Lab
• A Proposal for Making AJAX Crawlable – Google Webmaster Central
• Headless Browsers – eine (fast) vollständige Liste