SVGs und die Web-Performance: Best Practices

Ob UI-Designer, Frontend-Entwickler oder Backend-Spezialist, in allen Bereichen der modernen Web-Entwicklung kommt man in irgendeiner Art und Weise mit Logos und Icons in Berührung. Um eine gute User-Experience zu gewährleisten, sollten diese für den Betrachter stets gestochen scharf angezeigt werden, egal ob kleines Handy oder großer Laptop-Bildschirm. Moderne Websites müssen responsiv sein und damit auch jegliche Icons und Logos auf der Seite. Die seit 22 Jahren unangefochtene Lösung lautet hierfür: SVGs.

Die Welt der SVGs: Vorteile über Vorteile

Doch was sind SVGs überhaupt? SVG steht für scalable vector graphics und ist ein Dateiformat, welches bereits im Jahre 2001 vom World Wide Web Consortium veröffentlicht wurde.

Vektorgrafiken wie SVGs unterscheiden sich von Rastergrafiken in der Hinsicht, dass diese nicht Pixel für Pixel an Bildinformation wie auf einem Schachbrett abspeichern, sondern mathematische Formen und Funktionen nutzen, um das Bild zu berechnen. Hierfür können beispielweise Rechtecke, Kreise oder Pfade (in Form von Linien und Kurven) eingesetzt werden.

Vektorgrafiken, werden über mathematische Berechnung definiert

Dieser Ansatz bietet maßgebliche Vorteile gegenüber rasterbasierten Grafiken :

  • Animierbarkeit (siehe SMIL)
  • Manipulierbarkeit (DOM-Zugriff auf Elemente)
  • Unkomplizierte Bearbeitung (XML-Syntax)
  • Bessere SEO
  • Skalierbarkeit ohne Qualitätsverlust
  • Sehr kleine Dateigrößen

Der letztgenannte Punkt soll heute maßgeblich in den Fokus unserer Betrachtung rücken. Kleine Dateigrößen kommen leider nicht von alleine, sind jedoch ein wichtiger Faktor für die Performance der Website.

Warum wir Web Performance lieben

Viele Webprojekte begehen in ihren Entwicklungsprozess einen entscheiden Fehler: Sie lassen die Performance der Website als Qualitätskriterium völlig außer Acht. Ein Fehler, der auf lange Sicht viel Geld kostet und das Kundenerlebnis nachhaltig schädigt. Keiner wartet gerne auf Bus oder Bahn. Warum sollte das beim Laden und Aktualisieren von Websites anders sein? Die Performance der Website wirkt sich stark auf das empfundene Nutzungserlebnis aus. Langsame Ladezeiten verärgern den Besuchern und führen dadurch zu stark steigenden Abbruchsquoten. Umgekehrt begünstigen schnelle Websites die Kundenzufriedenheit, welche in Folge länger und öfter auf der Website verweilen. Dies steigert wiederum die Werbeeinahmen und erhöht die Wahrscheinlichkeit, dass angebotene Produkte auch tatsächlich gekauft werden.

Best Practices

Wer eine performante Website mit schnellen Ladezeiten und flüssiger Bildwiederholrate möchte, hat unzählige Dinge zu beachten. Dieser Artikel möchte speziell einen Fokus auf die Optimierung von Icons und Logos werfen, ohne die ein Internetauftritt heute undenkbar wäre. Nachfolgend möchte ich euch einige Tipps mit auf dem Weg geben, wie ihr mit SVGs das Beste an Web-Performance herausholen könnt. Dafür müssen jedoch in allen Entwicklungsschritten und Bereichen Maßnahmen ergriffen werden, die ich kurz anschneiden möchte:

1 – Erstellen

Zunächst einmal benötigen wir alle Assets in Form von Vektorgrafiken. Falls ihr euch in der Gunst befindet, auf einen vorhanden Designer zurückgreifen  zu können: Klasse! Eure Arbeit ist bereits so gut wie erledigt. Bittet ihn oder sie einfach euch die vorhandenen Grafiken als optimierte SVGs zukommen zulassen!

Eine weitere Möglichkeit für Faule ist das Verwenden von Vektorgrafiken aus dem Internet. Hier empfehle ich vor allem diese zwei Websites: SVG-Repo und  Google Font Icons. Beide bieten völlig kostenlos und ohne Registrierung eine Riesenauswahl an Icons und Logos an. Zudem sind diese lizenzfrei und bereits bestmöglich optimiert.

Für alle anderen gilt: selbst ist der Mann oder die Frau. Wer das Meiste aus seinen Grafiken rausholen möchte, erstellt sie immer noch selbst. Nachfolgend stelle ich euch dafür drei Tools vor, die wirklich jeden Geschmack treffen sollten:

Das Leichtgewicht: Boxy SVG

Das Online-Tool Boxy SVG ermöglicht es schnell, einfach und intuitiv im Browser simple Vektorgrafien selbst zu erstellen. Vorkenntnisse werden hierfür keine benötigt. Nachteil: Zum Speichern der Grafiken wird einen Account benötigt. Zudem werden keine Tools zur Optimierung angeboten.

Der Profi: Adobe Illustrator

Das Powertool Adobe-Illustrator lässt beim Erstellen von Grafiken keinerlei Wünsche offen. Zusätzlich existieren einige Tools und Funktionen, welche bei der Optimierung der Grafiken unterstützen. Der Haken daran: das Abo-Modell für Programme von Adobe ist nicht gerade günstig. Zusätzlich bedarf es zunächst einmal einiger Tutorials, um sich mit den unzähligen Funktionen der Software zurechtzufinden.

Der Allrounder: Inkscape

Das Open-Source-Programm Inkscape ist der Alleskönner schlechthin im Bereich Vektorgrafiken. Kein Wunder,denn genau für diesen Zweck wurde es schließlich entwickelt. Dank Open-Source ist die Nutzung zudem völlig kostenlos und eine Registrierung ist notwendig. Aufgrund der umfassenden Tools in der Erstellung und Optimierung von SVGs mein klarer Favorit und eine deutliche Empfehlung für euch.

Mein bevorzugtes SVG-Tool: Inkscape

2 – Optimieren

Der erste Schritt ist getan: Ihr besitzt nun die Werkzeuge, um Vektorgrafiken zu beschaffen oder selbst zu erstellen. Werfen wir doch jetzt ein Blick darauf, wie bereits vorhandene oder im Schaffensprozess befindliche SVGs performance-technisch optimiert werden können. Generell gibt es hierbei zwei Stellschrauben, an denen gedreht werden kann.

A: Verringerung der Dateigröße, für eine schnellere Übertragung durch das World-Wide-Web
B: Verringerung der Komplexität, um den Browser weniger Rechenleistung und -Dauer abzuverlangen.

Um dies zu erreichen, könnt ihr folgende Tricks anwenden:

  • Pfadpunkte einsparen & Genauigkeit reduzieren

Oftmals sind einzelne Elemente des Bildes teilweise oder ganz verdeckt. Weg damit! Unsichtbare Pfadpunkte können eingespart werden, beziehungsweise kann deren Genauigkeit reduziert werden, ohne dass ein Unterschied für das menschliche Auge ersichtlich wird.

Verdeckte Pfadpunkte können weggelassen werden.
  • Zusammenfassung und Gruppieren

Redundanter Code kostet Speicherplatz. Raus damit! Angewandte Styles und Eigenschaften für gleiche Objekte können in Gruppen zusammengefasst werden, anstatt jedes Mal einzeln aufgeführt zu werden. Ab wann sich das lohnt, hängt vom Einzelfall ab. Für eine bessere Lesbarkeit und Verständlichkeit sorgt es allemal und ist deshalb Best-Practice im Coding-Umfeld.

Redundanter Code sollte vermieden werden.
  • Keine Spielereien

Tags wie <filter>, <textPath>, <use> und <mask> benötigen viel Rechenleistung und schaden somit der Performance der Website. Verzichtet so gut es geht auf solche Spielereien, wenn es sich denn vermeiden lässt. Je simpler die Vektorgrafiken, desto besser die Performance.

Haltet die SVGs simpel.
  • Für alles Weitere: SVGO

Die gerade erwähnten Tipps stellen nur einen winzigen Bruchteil an unzähligen Möglichkeiten dar, mit denen der Speicherbedarf und die Komplexität von SVGs reduzieren werden können. Die meisten Dinge müssen und sollten gar nicht erst von Hand getätigt werden. Hier können beispielsweise bewährte Tools wie SVGO einspringen. SVGO ist ein Optimizer für SVGs mit einer riesigen Palette an vollautomatisierten Optimierungsmöglichkeiten. Ob als Plugin für Code-Editoren und Designtools, Webapp, GitHub-Action oder als Node-Package, das Tool ist auf jedem erdenklichen Weg kinderleicht in einen bestehenden Workflow integrierbar. Nutzt es!

3 – Komprimieren

Nach den Designern sind nun die Backend Spezialisten gefragt! Vektorgrafiken eignen sich hervorragend für eine serverseitige Kompression der übertragenen Daten. Hierbei kann die übertragene Dateigröße nochmal um gut 50% reduziert werden. Meist ist solch eine Kompression bereits voreingestellt. Trotzdem empfiehlt es sich sicherheitshalber nochmal einen Blick in die Server-Konfiguration zu werfen. Eine Komprimierung von SVGs lässt sich wie folgt aktivieren:

NGIX (.htaccess file):

server {
    gzip on;
    gzip_types image/svg+xml;
    gzip_proxied no-cache no-store private expired auth;
}

Apache (Server Configuration):

AddOutputFilterByType DEFLATE image/svg+xml

4 – Einbinden

Nach Erstellung, Optimierung und Komprimierung folgt nun die Einbindung der Grafiken. Jetzt sind die Frontend-Entwickler gefragt. Möglichkeiten, Icons und Logos einzubauen, gibt es viele. Doch unterscheiden diese sich deutlich in Sachen Performance und Feature-Umfang.

Wer maximale Performance möchte, sollte SVGs wie eine gewöhnliche Rastergrafik einbinden: z.B. mit CSS als Background-Image ein oder dem <img>-Tag. Das Plus an Performance hat jedoch einen entscheidenen Nachteil: alle Vorteile die Vektorgrafiken mit sich bringen (DOM-Zugriff, Manipulierbarkeit, Animierbarkeit und Styling) fallen dabei weg. Wer darauf nicht verzichten möchte, sollte den dafür standardmäßig vorgesehen <svg>-Tag nutzen. Aus Performance-Sicht keinesfalls empfehlenswert ist eine Einbindung über <Object>, <embed> oder <iframe>.

Praxisbeispiel: hdm-stuttgart.de

Um euch abschließend zu beweisen, dass die vorher aufgeführten Tipps und Tricks wirklich helfen können, habe ich euch auch ein Praxisbeispiel mitgebracht: die Website unserer geschätzten HdM. Dass das M in HdM für Medien steht, verschweige ich dabei lieber, denn zu allem Verdruss werden auf der Website der Hochschule keinerlei Vektorgrafiken eingesetzt. Ein Blick in die Developer Tools offenbart, dass alle 21 verwendeten Icons und Logos auf der Startseite auf Rastergrafiken wie JPEGs oder PNGs setzten. Die großen Nachteile daran: die Logos sind bei genauerem Betrachten nicht nur unscharf, sie benötigten auch deutlich mehr Bytes zum übertragen. 409KB, um genau zu sein.

Dabei konnte ich es nicht belassen,den. ein halber Megabyte für ein paar unscharfe Icons ist definitiv zu viel. Also wandte ich den vorher erwähnten Prozess an und stellte zunächst einmal komplett auf Vektorgrafiken um. Dafür reichte es bereits die meisten Logos als SVG-Version aus dem Internet zu ziehen, den Rest bastelte ich mit Adobe Illustrator selbst nach. Im zweiten Schritt unterzog ich allen SVGS einer Optimierung mit dem SVGO-Tool und reduzierte bei einigen Icons die Genauigkeit der Pfadpunkte von Hand. Im letzten Schritt simulierte ich dann noch eine serverseitige Komprimierung mit dem Online-Tool Vecta.io.

Das Resultat spricht Bände: Am Ende umfassten alle Assets eine Gesamtgröße von nur noch mickrigen 9KB. Eine Einsparung von -97,8% im Vergleich zu den nicht optimierten Rastergrafiken zu Beginn. Dieser Umstieg würde somit nicht nur den Augen des Betrachters zugutekommen (dank schärferer Auflösung), sondern sich auch positiv auf die Ladezeit der Website auswirken. Gerade im verbesserungsbedürftigen deutschen Mobilfunknetz ein Vorteil, den es nicht zu vernachlässigen gilt.

Eine Optimierung kann sehr viel Speicher sparen.

Fazit / TL;DR

Eine Optimierung von Vektorgrafiken auf Websites lohnt sich immer. Gerade wenn bisweilen Rastergrafiken wie PNGs oder JPEGs für Logos und Icons eingesetzt worden sind. Nicht nur sehen diese durch Skalierbarkeit bei allen Displaygrößen deutlich schärfer aus, auch aus performance-technischen Aspekten lohnt sich der Umstieg zu 100%. Von Erstellung bis zu Einbindung, alle Beteiligten im Entwicklungsprozess sind gefragt für eine gute Web-Performance Sorge zu tragen. Denn die Performance ist ein maßgeblicher Faktor für die Zufriedenheit des Website-Besuchers und somit auch essenziell für den finanziellen Erfolg eines Internetauftritts.

Quellen / Weiterführendes

Für alle diejenigen, die noch mehr wollen:

SVG

Web-Performance

SVG-Optimierung

DISCLAIMER: Das genutzte Blogging-Tool verbietet die Nutzung von SVGs 🤦‍♂️: Ironie des Schickals.

Business Case „Web Performance Optimization“. Wann lohnt es sich?

Onlineshops wie Amazon sind heutzutage nicht mehr wegzudenken. Doch nicht jeder Onlineshop wird automatisch erfolgreich, da die Webseiten oft aufgrund hoher Datenmengen, verursacht durch beispielsweise Bilder, eine hohe Ladezeit besitzen. Menschen werden zunehmend ungeduldiger und warten nicht gerne auf Suchergebnisse. Nahezu jede Person kennt heutzutage das Gefühl, eine Webseite zu schließen, da der Inhalt nicht schnell genug geladen wird.  Doch wie erreicht ein Unternehmen eine gute Performance der eigenen Webseite und wie hängt dies mit dem Business Case zusammen?

Um dies zu erläutern werden im Vorfeld die Grundbegriffe Web Performance und Business Case näher erläutert und im Anschluss der Zusammenhang dieser beiden Begriffe konkreter beschrieben.

Business Case

Bevor ein neues Projekt in einem Unternehmen umgesetzt wird, sollte sich dieses bewusst sein, ob sich das Projekt positiv auf das Unternehmen auswirkt. Bei einem Business Case geht es darum, finanzielle und strategische Auswirkungen einer Investition festzuhalten. Bei der Erstellung des Business Case könnte herauskommen, dass die prognostizierten Kosten den erwarteten Nutzen überschreiten. Dann wäre es von Vorteil, dieses Projekt nicht umzusetzen. Wird der Business Case gewissenhaft erstellt, bietet er dem Unternehmen einige Vorteile. Er hilft, die Entscheidung zu treffen, ob das Projekt umgesetzt wird und stellt diesbezüglich eine Transparenz dar. Zusätzlich bietet es die Möglichkeit, das Projekt mit anderen Projekten zu vergleichen und ein Risikomanagement ist ebenfalls inbegriffen.
Ein Business Case beinhaltet eine Beschreibung des Szenarios und zusätzlich eine Prognose des erzielten Nutzens. Dabei kann ein Business Case mehrere Szenarien beinhalten, die jeweils alle Rahmenbedingungen, verbundene Risiken und die erwartete Auswirkung beinhalten. Bei der Prognose des erzielten Nutzens wird eine Investitionsrechnung durchgeführt. Dies kann zum Beispiel durch eine Kosten-Nutzen-Analyse berechnet werden. Grundsätzlich gibt es ein paar Leitfragen, die nach der Erstellung des Business Case beantwortet werden. Hierzu gehören die folgenden Fragen: [1] [2]

Abbildung 1: Zusammenspiel verschiedener Faktoren im Business Case
  • Warum soll das Projekt durchgeführt werden?
  • Was passiert, wenn das Projekt nicht durchgeführt wird und alles beim aktuellen Zustand bleibt?
  • Gibt es eine Alternative?
  • Welcher Nutzen entsteht durch das Projekt?
  • Wie viel Zeit muss für das Projekt eingeplant werden?
  • Gibt es Risiken?
  • Welche Kosten werden erwartet?   

Web Performance

Abbildung 2: Web Performance Optimierung

Investiert ein Unternehmen Zeit und Geld, um die Performance einer Webseite zu verbessern, kann dies mehrere Vorteile beinhalten. Ein entscheidender Punkt ist, dass Nutzer einer Webseite zufriedener sind, wenn sie kürzer warten müssen. Somit bleiben Nutzer länger auf der Webseite, empfehlen die Webseite eventuell weiter. Ist die Performance einer Webseite gut, wird diese im Suchmaschinenranking bevorzugt.
Um Web Performance zu messen, müssen im Vorfeld Leistungsfaktoren festgelegt werden. Die sogenannten Key Performance Indicators (KPI) werden hierfür häufig eingesetzt. KPIs lassen sich in verschiedene Bereiche unterteilen, um möglichst viele verschiedene Möglichkeiten der Optimierung abzudecken. Bei den technischen KPIs handelt es sich überwiegend um die Verfügbarkeit der Webseite. Diese sollte möglichst 24h an sieben Tagen der Woche erreichbar sein, so dass der Nutzer jederzeit auf die gewünschte Webseite zugreifen kann. Hierbei gilt es zu beachten, dass der Nutzer möglicherweise mit verschiedenen Geräten von verschiedenen Standorten zugreifen möchte. Auch dies sollte ohne Komplikationen gewährleistet sein. Ein weiteres KPI befasst sich mit der Geschwindigkeit von Webseiten. Dabei gilt es, die Ladezeit der Webseite so gering wie möglich zu halten. Hierbei sollte stets die Ladezeit ab der Anfrage des Nutzers berechnet werden. Dies umfasst die Antwortzeit des Servers, die Datenübertragungsgeschwindigkeit und die Renderzeit im Browser. Ist die Webseite schnell genug, wird sie im Suchmaschinenranking etwas bevorzugt und weiter oben angezeigt. Somit steigt die Wahrscheinlichkeit, dass ein Nutzer die Webseite aufruft. Berechnet wird ebenfalls, wie viele Anfragen pro Sekunde an den Server gesendet werden. Treffen auf einen einzelnen Server zu viele Anfragen ein, verschlechtert sich die Leistung und die Geschwindigkeit der Webseite nimmt ab. Zusätzlich wird die Anzahl der serverseitigen Fehlerrate in einem bestimmten Zeitraum gemessen. Ist die Fehlerrate zu hoch, kann sich auch dies negativ auf die Webseite auswirken. KPIs können vom Unternehmen selbst definiert und festgelegt werden. Hierbei gibt es fast keine Grenzen. Mögliche weitere KPIs wären: Social Engagement (Shares, Likes, Kommentare), Anzahl der Verkäufe, Kundenkontakte und der Umsatz durch die Webseite. Zur Analyse und Auswertung der gemessenen Werte wird oftmals eine spezielle Software benötigt. [3] [4] [5]

Wie kann man die Performance einer Webseite verbessern?

Um die Performance einer Webseite zu verbessern, gibt es verschiedene Möglichkeiten. Einige Fehler werden von mehreren Unternehmen gemacht, diese werden im Folgenden kurz erläutert.
Ein sehr großer Hauptfaktor in der Optimierung von Webseiten ist die Steigerung der Geschwindigkeit. Im besten Fall sollte dieser Punkt in allen Phasen der Entwicklung berücksichtigt werden und nicht ausschließlich am Ende. Doch auch Optimierungen im Nachhinein können einen großen Effekt auf die Performance der Webseite bewirken. Zusätzlich ist es von Bedeutung, welchen Webservice ein Unternehmen nutzt. Oftmals werden hier mittelmäßige Webservices verwendet, die letztendlich jedoch zu langsam sind, um eine hohe Geschwindigkeit der Webseite zu erlauben. Sinnvoll für alle Unternehmen ist, sich im Vorfeld Gedanken zu machen, um einen qualitativ passenden Webservice zu finden. Hat ein Unternehmen bereits eine bestehende Webseite, ist es oft dazu verleitet, weitere Plug-Ins zu entwickeln, um den Kunden noch bessere und umfangreichere Funktionen zur Verfügung zu stellen. Jedoch verlangsamen Plug-Ins häufig die Ladezeit der Webseite, was die Bedienbarkeit beeinträchtigt. Aus diesem Grund empfiehlt es sich, Add-Ons auf ein Minimum zu reduzieren und Plug-Ins mit großen Datenströmen außerhalb des Servers zu hosten. Auch wenn für viele Online-Unternehmen wie Google die Haupteinnahmequelle aus Online-Werbung besteht, gilt es auch hierbei einige Faktoren zu beachten. Wird zu viel Eigentum der eigenen Webseite an Dritte verkauft, verlangsamt dies die Webseite. Jeder externe Service muss geladen werden, was Zeit in Anspruch nimmt. Ist die Webseite zu langsam, springen potenzielle Kunden ab.  [6]
Eine zusätzliche Auswirkung auf die Performance der Webseite hat die Auswahl der verwendeten Frameworks. Frameworks beschleunigen den Entwicklungsprozess und gewährleisten ein gewisses Maß an Sicherheit und Wartbarkeit. Grundsätzlich können Frameworks unterteilt werden in Backend- und Frontend-Frameworks. Die wohl bekanntesten Backend-Framework heißen Laravel, Django und Flask. Sie übernehmen beispielsweise die Aufgaben für das Routing von URLs, die Interaktion mit der Datenbank und die Verbesserung der Sicherheit. Backend-Frameworks werden auf dem Server ausgeführt. Frontend-Frameworks werden im Gegenzug in dem Browser des Nutzers ausgeführt und nutzen JavaScript oder Cascading Style Sheets (CSS).  Bekannte JavaScript Frontend-Frameworks sind React, Angular und Vue.js. Diese sind für Single Page Anwendungen konzipiert und da Änderungen des Zustands direkt in der Benutzeroberfläche angezeigt werden, reduziert das die Serverlast und Ladezeit beim Nutzer. CSS-Frameworks wie Bootstrap, Foundation und Bulma bieten Designvorlagen für Elemente wie Buttons und Checkboxen. Jedes Framework hat seine eigenen Vor-und Nachteile, die je nach Anwendungsfall hilfreich sind. [7]

Performance Marketing

Performance Marketing hat die Aufgabe, den Zusammenhang zwischen Leistung (Performance) und dem Erfolg beziehungsweise Misserfolg aufzuzeigen. Dabei geht es vor allem um messbare Nutzerinteraktionen, wie die KPIs. Das Performance Marketing lässt sich in vier verschiedene Bereiche aufteilen, welche im Folgenden erläutert werden.  Der erste Bereich umfasst das Formulieren und Generieren von Zielen. Häufig wird hierbei ein Marketingziel (z.B. Produktbekanntheit erhöhen), ein Unternehmensziel (z.B. Marktanteile erhalten), ein Kundenbezogenes Ziel (z.B. Kundenbindung festigen) oder ein Kampagnenbezogenes Ziel (z.B. Besucherzahlen steigern) angesetzt. Der zweite Bereich befasst sich mit Marketinginitiativen, die unter anderem Search Engine Advertising (SEA) und Suchmaschinenoptimierung (SEO) beinhalten. Der dritte Bereich befasst sich mit Controlling. In diesem Bereich sollen die Ergebnisse der Marketinganalyse sichtbar gemacht werden. Der vierte und letzte Bereich beschäftigt sich mit der Optimierung der Webseite.
Performance Marketing hat einige Vor- und Nachteile. Vorteile sind, dass messbare Ergebnisse vorhanden sind und die Optimierungsmaßnahmen zielgenau eingesetzt werden können. Nachteilig ist zu betrachten, dass eine regelmäßige Datenanalyse notwendig ist und eine professionelle Auswertung benötigt wird. [8]

Suchmaschinenoptimierung (SEO)

Abbildung 3: Zusammenspiel verschiedener Komponenten der SEO

Ziel der Suchmaschinenoptimierung ist es, eine gute Platzierung zu bekommen. Dies hat die Auswirkung, dass die Webseite wahrscheinlich häufiger angeklickt wird, als bei einer schlechteren Platzierung. Der Algorithmus der Suchmaschinen beachtet hierbei jedoch weit über 200 verschiedene Faktoren, um die Platzierung festzulegen. Diese Faktoren werden in verschiedene Unterkategorien unterteilt. Bei der Onpage-Optimierung handelt es sich um alle Maßnahmen, die direkt mit der Webseite in Verbindung stehen. Dazu gehört unter anderem die Ladezeit, HTML-Code, die Strukturierung der Webseite und interne Verlinkungen. Die Offpage-Programmierung bewertet die Webseite in Bezug auf ähnliche Webseiten. Die Content und Key Strategie befasst sich mit den Keywords, die relevant sind, und mit Inhalten, die potentielle Nutzer suchen könnten. In der Suchmaschinenoptimierung ist die Seiten-Performance wichtig für die Platzierung. Die Seiten-Performance setzt sich beispielsweise aus der Page-Speed, der Anzahl der indexierten Seiten und der Anzahl an 404 Fehlerseiten zusammen. [5]

Suchmaschinenwerbung (SEA)

Bei der Suchmaschinenwerbung handelt es sich um eine bezahlte Platzierung. Im Gegensatz zur SEO spielt hierbei nicht nur ein Algorithmus eine Rolle sondern ebenfalls das höchste Gebot und die Intention des Nutzens. Die Suchmaschinenwerbung kann nach Bezahlung direkt genutzt werden. Hierzu unterscheidet sie sich ebenfalls zur SEO. Die SEO benötigt Zeit, bis die Webseite ihren Platz im Algorithmus gefunden hat. [5]

Wie wirkt sich Web Performance auf den Business Case aus?

Eine gute Web Performance ist oftmals mit viel Aufwand verbunden. Warum also sollten sich Unternehmen die Mühe machen und ihre Webseiten optimieren? Ziel ist, mit Hilfe von Web Performance den Umsatz zu steigern und die Kunden stärker an das Unternehmen zu binden. Dazu wurden einige Studien durchgeführt, welche im Anschluss kurz erläutert werden. Bereits 2009 hat Amazon festgestellt, dass sich die Geschwindigkeit der Webseite auf den Umsatz des Unternehmens auswirkt. Dabei wurde herausgefunden, dass jede 100ms Latenzzeit das Unternehmen 1% Umsatz kostet und jede Sekunde Verzögerung kann bei einem so großen Online-Händler zu über 1,5 Milliarden Dollar Verlust führen. Google hat zudem veröffentlicht, dass eine Person von vier Benutzern die Webseite verlässt, wenn diese beim Laden länger als vier Sekunden benötigt. Doch nicht nur Amazon und Google haben in dieser Richtung geforscht. 2015 hat Optimizely absichtlich Webseiten verlangsamt, um die Auswirkung zu messen. Dabei hat eine Ladezeitverzögerung von acht Sekunden die Auswirkung, dass die Webseite ca. 17,5% weniger Aufrufe bekommt. Zusätzlich hat Netflix im Jahre 2018 rausgefunden, dass das Vorabrufen und Optimieren von HTML, CSS und JavaScript die Zeit bis zur Interaktivität um ca. 50% reduziert. Die Leistung einer Webseite wirkt sich dementsprechend auf den Umsatz aus. [9] [6]

Anhand der oben genannten Faktoren scheint es sinnvoll, die Web Performance zu verbessern. Jedoch ist es wichtig, zu beachten, dass für eine gute Web Performance oftmals viel an Zeit und Geld investiert werden muss. Die unterschiedlichen Faktoren sollten stets in einem Business Case festgehalten werden, sodass das Unternehmen damit überprüfen kann, inwieweit sich die Optimierung positiv auswirkt. Wenn die erwarteten Kosten für die Umsetzung den erwarteten Nutzen überschreiten, wird die Web Performance dem Unternehmen keinen Gewinn bringen. Übersteigt der erwartete Nutzen jedoch die anfallenden Kosten, wird sich die Optimierung der Webseite lohnen. Schon mit kleineren Veränderungen kann ein großer positiver Effekt in der Schnelligkeit der Webseite erreicht werden. Ein gutes Ziel jedes Unternehmens wäre, die Performance der Webseite so weit wie möglich zu optimieren, dass die Kundenzufriedenheit steigt und die Benutzer die Webseite mit Freude besuchen. Sind die Kunden zufrieden, so wirkt sich dies positiv auf das Unternehmen aus. Ab wann sich eine Optimierung tatsächlich lohnt, muss jedes Unternehmen individuell entscheiden. Wird der Business Case im Vorfeld gewissenhaft ausgefüllt, stellt dieses Dokument eine große Hilfe dar.

Startet ein Unternehmen ein neues Projekt, ist es von Vorteil, die Performance der Webseite direkt zu Beginn mit einzubeziehen und nicht erst im Nachhinein zu verbessern. Viele Schritte können bereits während der Implementierung berücksichtigt werden, ohne dass viel Zeit verloren geht und dennoch bringt es dem Unternehmen einen großen Gewinn. Ein Beispiel hierfür ist, Bilder direkt komprimiert hochzuladen, um lange Ladezeiten der Webseite zu verhindern. Des Weiteren ist es in vielen Fällen von Vorteil, sich im Vorfeld Gedanken über mögliche Technologien und externe Dienste zu machen. Eine gründliche Recherche und eine gezielte Entscheidung kann im Nachhinein Geld und Arbeit ersparen. Zusätzlich ist es effizient, anfangs festzulegen, welche Funktionen die Webseite wirklich braucht und dem Benutzer im Umgang hilft. Sämtliche Zusatzfunktionen können genau überlegt und abgewogen werden. Hat eine Webseite zu viele Funktionen, sind für den Benutzer verwirrend. Die Benutzerfreundlichkeit nimmt ab und zusätzlich steigt die Ladezeit der Webseite, da zusätzliche Funktionen bereitgestellt werden müssen. Werden all diese Faktoren bereits bei der Planung des Projektes beachtet, besteht ein guter Grundstein, mit dem weitere Verbesserungsmaßnahmen vorgenommen werden können. Bei jeder einzelnen Verbesserung muss das Unternehmen abwägen, inwieweit sich der Aufwand, das Geld und die Zeit lohnen. Oftmals ist es nicht zielführend, sich im Detail zu verlieren und mehrere Tage zu investieren, wenn letztendlich nur eine minimale Verbesserung bewirkt wird. Um die Webseite auf ihre Performance zu testen, gibt es verschiedenen Tools (Bsp. https://www.webpagetest.org/). Diese Tools helfen dabei, Schwachstellen aufzudecken, sodass diese, falls nötig, von den Entwicklern behoben werden.

Fazit

Die Optimierung der Performance einer Webseite kann dem Unternehmen viele Vorteile bringen. Web Performance ist ein Grundstein, um die Webseite für Neukunden attraktiv zu machen, aber auch um bestehende Kunden zu erhalten. Lediglich zufriedene Kunden werden dem Unternehmen treu bleiben und dieses gegebenenfalls weiter empfehlen. Mit Hilfe des Business Case ist zu überprüfen, in wie weit sich die Optimierung positiv auf das Unternehmen auswirkt. Sobald die erwarteten Kosten für die Umsetzung höher sind als der erwartete Nutzen, ist es nicht empfehlenswert, diese Optimierung durchzuführen.

Literaturverzeichnis

1G. Dr. Angermeier, „Business Case,“ 15 05 2015. [Online]. Available: https://www.projektmagazin.de/glossarterm/business-case#:~:text=Ein%20Business%20Case%20ist%20ein,des%20Auftraggebers%20eine%20Investition%20dar. [Zugriff am 01 01 2023].
2t2informatik, „Business Case,“ [Online]. Available: https://t2informatik.de/wissen-kompakt/business-case/. [Zugriff am 01 01 2023].
3J. Dr. Fleig, „Key Performance Indicators (KPI),“ 06 09 2022. [Online]. Available: https://www.business-wissen.de/hb/key-performance-indicators-kpi-beispiele-anschaulich-erklaert/. [Zugriff am 02 01 2023].
4C. Haeringer, „The Important of Web Performance Optimization (WPO),“ 05 05 2015. [Online]. Available: https://insights.project-a.com/the-importance-of-web-performance-optimization-wpo-9ace123c1cab. [Zugriff am 02 01 2023].
5I. Kamps und D. Schetter, Performance Marketing – Der Wegweiser zu einem mess- und steuerbaren Online- Marketing – Einführung in Instrumente, Methoden und Technik, Wiesbaden: Springer Fachmedien Wiesbaden GmbH, 2020.
6„Ein Leitfaden für Anfänger zur Optimierung der Webseiten- Geschwindigkeit,“ kinsta, 07 12 2022. [Online]. Available: https://kinsta.com/de/lernen/website-geschwindigkeit/. [Zugriff am 03 01 2023].
7M. Kiefer, „Die beliebtesten Frontend und Backend Web-Frameworks,“ 07 07 2022. [Online]. Available: https://www.lakdev.de/frameworks. [Zugriff am 07 01 2023].
8D. D. Donne, „Was ist Performance-Marketing,“ HubSpot, 23 05 2022. [Online]. Available: https://blog.hubspot.de/marketing/performance-marketing. [Zugriff am 30 12 2022].
9E. Yordanov, NitroPack, 23 12 2022. [Online]. Available: https://nitropack.io/blog/post/web-performance-matters-case-studies. [Zugriff am 02 01 2023].

Quellen Abbildungen

Abbildung 1: https://www.microtool.de/wp-content/uploads/2017/04/business-case-%C3%BCberblick.png, Zugriff am 29.01.2023

Abbildung 2: https://webhoster.de/wp-content/uploads/2021/04/AdobeStock_85035287-scaled-1.jpeg, Zugriff am 29.01.2023

Abbildung 3: https://www.seocon.at/wp-content/uploads/2016/08/SEO.png, Zugriff am 29.01.2023

The Surprising Truth About Vue and React’s Web Speed with JSWFB

ReactJS vs VueJS

Comparative Web Performance evaluation of Vue & React using JSWFB

Abstract

During this period of time where, the digital world, where nearly 5 billion people are using the internet, comes the need to build a web application that is intuitive, interactive and with higher speed performance. That’s where the JavaScript Libraries and Frameworks come into the picture. In the current web development culture, ReactJS and VueJs are the most used and most loved web frameworks. They are used to develop interactive single web page applications. This paper will evaluate these frameworks regarding their performance and usage using the JS Web Framework Benchmark.

ReactJS vs VueJS
ReactJS vs VueJS
Continue reading

Neue Bildformate im Vergleich

Bilder und andere Medienelemente gelten im Internet heute als selbstverständlich. Wie aus dem HTTP Archive hervorgeht, generieren 99,9% aller Webseiten mindestens eine Anfrage für eine Bildressource und 95,9% enthalten mindestens ein <img>-Element [1]. Die restlichen 4% entfallen beispielsweise auf Favicons und Hintergrundbilder.

Für die breite Verwendung von Bildern gibt es gute Gründe: Sie transportieren Informationen schneller als Text, lockern das Layout auf und regen Nutzer zu mehr Interaktion an [2]. Wie Abbildung 1 veranschaulicht, schlägt sich dies auch im Anteil von Medienelementen an der gesamten Größe einer Webseite (Page Weight) nieder [3]. So machen Bilder, Animationen und Videos durchschnittlich zwei Drittel des gesamten Page Weights aus – und selbst im zehnten Perzentil nehmen sie noch einen Anteil von etwa 44% ein.

Continue reading

Drei Sekunden sind zu lang – Auswirkung der Ladezeit von Webseiten auf die User Experience

Warum ist es so wichtig, die optimale Ladezeit anzustreben?

Auf jemanden oder auf etwas zu waren ist uns Menschen nicht fremd. Im Schnitt verbringt jeder Mensch in seinem Leben rund ein bis zwei Jahre mit Warten. Dies kann an der Bushaltestelle, Suppermarktkasse, dem Abwarten auf die Ankunft einer Zustellung, oder die Ankunft einer geliebten Person sein. Viele Menschen erscheint das Warten auf etwas oder jemanden als lästig. Dies kann verschiedenste Gründe haben wie bspw. Langeweile, die seelische Verfassung und der allgemeine Gemütszustand, sowie Zeitdruck. Ganze Geschäftsmodelle wie das “Priority Boarding” am Flughafen beruhen darauf, dass Menschen bereit sind mehr Geld zu bezahlen, nur um nicht anstehen zu müssen. (D. Lenz 2018)

Continue reading

Automate Performance Optimization

In order to display a website as quickly as possible, performance optimization is necessary. Since manual optimization can be time-consuming and often several steps need to be performed, automating performance optimization can be a good idea. This in turn can include, for example, reporting (speed analysis of the website) and performance optimization itself (compression, code reduction, …).
This article gives an overview of where automation can be used, which tools are suitable for this and what these tools offer.

Continue reading

Progressive Web Apps – Wer braucht noch native Apps?

Progressive Web Apps sollen es ermöglichen die Vorteile des Webs und die nativer Apps zu nutzen, um so für jeden, überall und auf jedem Gerät, nutzbar zu sein. Was Progressive Web Apps eigentlich sind, welche Vor- und Nachteile sie mit sich bringen und ob sie in Zukunft native Apps komplett ersetzen können, soll in diesem Artikel beantwortet werden. 

Was sind Progressive Web Apps?

Der Name Progressive Web Apps (PWA) ist kein formeller oder offizieller Name sondern nur eine Abkürzung. Diese wurde ursprünglich von Google für das Konzept verwendet, eine flexible und anpassbare App nur mit Webtechnologien (HTML, CSS, JavaScript) zu erstellen.
Der Begriff Progressive im Namen kommt daher, dass das Konzept PWA auf der Design Philosophie Progressive Enhancement basiert.[1] Diese besagt, dass so vielen Nutzern wie möglich die grundlegende Funktionalität zur Verfügung gestellt werden soll. Mithilfe von Feature Detection wird in der Implementierung überprüft, ob der Browser mit der gewünschten Funktion umgehen kann. Falls dies nicht der Fall ist, wird eine alternative Implementierung mittels Polyfills bereitgestellt, um die fehlende Funktion mit JavaScript hinzuzufügen. Dadurch wird eine ausgezeichnete Erfahrung für voll leistungsfähige Browser ermöglicht und eine akzeptable Erfahrung für weniger leistungsfähige Browser.[2]

“These apps aren’t packaged and deployed through stores, they’re just websites that took all the right vitamins.”

Alex Russell [3]

Wie Alex Russell, der als Google Engineer das PWA Konzept mitentwickelt hat, mit seinem Zitat beschreibt, sind PWAs im Kern einfache Webanwendungen. Mithilfe von speziellen Technologien und Patterns wollen sie die Vorteile des Webs und die nativer Apps nutzen. Hierzu zählen beispielsweise die einfache Auffindbarkeit im Web oder die Möglichkeit der Offline-Nutzung nativer Apps.[1], [4]
Um eine bestmögliche Nutzererfahrung zu erzielen, die sich anfühlt wie bei einer plattformspezifischen Anwendung hat Google drei Säulen definiert, die eine PWA erfüllen sollte:

  • capable (fähig): Durch die Verwendung von modernen APIs werden Webanwendungen immer leistungsfähiger und ermöglichen die Implementierung nativer Möglichkeiten, zum Beispiel den Dateisystemzugriff oder die Mediensteuerung.
  • reliable (zuverlässig): Benutzer erwarten, dass Anwendungen immer schnell und verlässlich sind, unabhängig von der Netzwerkverbindung. Interaktionen sollten immer schnell erkannt werden und es sollte so schnell wie möglich darauf reagiert werden. Denn gerade die Geschwindigkeit ist wichtig für die UX.
  • installable (installierbar): Über den Add2Homescreen-Button sollte die PWA installierbar sein, um in einem eigenständigen Browserfenster zu laufen. Dadurch verhält sich die PWA auf der einen Seite wie eine native App. Auf der anderen Seite ändert der Nutzer seine Interaktion mit der App, da die App nun vom Homescreen oder vom Appswitcher gestartet werden kann.[4]

Aussehen und Lebenszyklus einer PWA

Der Lebenszyklus beginnt wie bei einer normalen Webseite im Browser. Durch das Anzeigen des Add2Homescreen- Buttons (im Moment nur bei Android Geräten möglich) kann der Nutzer die App zum Homescreen hinzufügen. Auf dem Homescreen wird das Appicon analog zu einer nativen App dargestellt. Öffnet man nun die App über den Homescreen, öffnet sich die PWA im Standalone- Modus und sie sieht aus wie eine native App. Außerdem wird sie, wie auch native Apps, im Appswitcher angezeigt.

Aussehen und Lebenszyklus einer PWA [3]

Wie wird aus einer Webanwendung eine PWA?

Bei Web Anwendungen ist es nicht immer direkt ersichtlich, ob es sich um eine reine Web Anwendung handelt oder um eine PWA. Damit eine Web Anwendung als PWA erkannt wird, muss sie bestimmte technische und funktionale Anforderungen erfüllen.

Technische Anforderungen

Aus technischer Sicht sollte eine Web Anwendung die folgenden drei Eigenschaften haben, um als PWA zu gelten:

HTTPS – Die Verwendung einer sicheren Netzwerkverbindung ist nicht nur Best Practice, sondern bietet auch den Vorteil, dass Nutzer der Webseite vertrauen. Zusätzlich ist eine sichere Verbindung mittels HTTPS die Voraussetzung für die Nutzung vieler Funktionen, die in PWAs verwendet werden. Hierzu zählen beispielsweise die Geolokalisierung oder auch die Verwendung eines Service Workers.[5],[7]

Service Worker – Ein Service Worker ist eine JavaScript-Datei die der Browser im Hintergrund ausführt und welche als programmierbarer Netzwerk Proxy dient. Dadurch kann bestimmt werden, wie der Browser Netzwerkanfragen und Asset-Caching behandelt. Durch die Verwendung eines Service Workers können zuverlässige und schnelle Webseiten implementiert werden, die zusätzlich Offline-Funktionalität bieten.[5]–[7]

Manifest – Das Manifest ist eine JSON-Datei die Informationen darüber enthält, wie die App aussehen und wie sie sich bei der Installation auf einem mobilen Gerät verhalten soll. Zu den wichtigsten Angaben im Manifest zählen unter anderem der App Name, die Icons, die URL, die beim Start der App aufgerufen werden soll und der Anzeigemodus. Dieser bestimmt welche Browser-Benutzeroberfläche beim Start der App angezeigt werden soll. Eine ausführlichere Erklärung zum Manifest und zu den entsprechenden Properties kann hier gefunden werden.[5],[7]

Beispiel manifest.json

Funktionale Anforderungen

” Progressive Web Apps (PWA) are built and enhanced with modern APIs to deliver enhanced capabilities, reliability, and installability while reaching anyone, anywhere, on any device with a single codebase.”

Google [4]

Wie Google beschreibt, sollten PWAs fähig, zuverlässig und installierbar sein, um eine bestmögliche Nutzererfahrung zu erzielen. Dazu hat Google zwei PWA-Checklisten erstellt:

  • Core PWA Checklist: enthält Kriterien, welche die PWA installierbar und nutzbar für alle macht.
  • Optimal PWA Checklist: enthält Kriterien, um eine PWA zu entwicklen, die eine bestmögliche Nutzererfahrung bietet und gleichzeitig die Vorteile nutzt, die das Web leistungsstark machen.

Zusätzlich hat das Mozilla Developer Network (MDN) Prinzipien definiert, die eine PWA implementieren sollte, um als solche identifiziert zu werden:

  • auffindbar: Die App kann mithilfe von Suchmaschinen gefunden werden.
  • installierbar: Die App kann vom Homescreen aus gestartet werden.
  • verlinkbar: Die App kann durch das Versenden einer URL geteilt werden.
  • netzwerkunabhängig: Die App funktioniert auch bei schlechter/ keiner Netzwerkverbindung.
  • progressiv: Anwendung von Progressive Enhancement bei der Entwicklung der App.
  • responsive: Die App ist auf jedem Gerät nutzbar.
  • sicher: Verbindungen sind vor dem Zugriff von Dritten geschützt.[1]

Architektur einer PWA

Der beliebteste Ansatz eine PWA zu bauen, ist das App-Shell-Konzept. Dieses Konzept stellt einen Mix aus serverseitigem Rendern und clientseitigem Rendern dar und verwendet zusätzlich den offline-first Ansatz. Dabei werden für die Darstellung einer minimalen UI, die minimalen HTML-, CSS- und JavaScript-Dateien so früh wie möglich geladen. Gleichzeitig werden diese direkt gecached, sodass sie auch offline verfügbar sind. Hierbei handelt es sich sozusagen um das Skelett der Benutzeroberfläche. Beim nächsten Aufruf der Seite wird die UI aus dem Cache geladen und es müssen nur die Inhalte vom Server angefordert werden, welche sich noch nicht im Cache befinden. Mithilfe des Service Workers kann hier gesteuert werden, welche Inhalte gecached werden sollen. Die Verwendung einer App-Shell und das dynamische Laden des Inhalts bietet vor allem einen Performance Vorteil. Zusätzlich fühlt sich die Anwendung für den Nutzer sehr schnell und zuverlässig an, da der Nutzer sofort etwas sieht. Im Kontrast hierzu stehen weiße Seiten oder Ladeanzeigen, wie bei einer nativen Anwendung.[8], [9]

Beispiel einer App-Shell und des dynamischen Inhalts [8]

Unterstützung der Browser

Neben den technischen und funktionalen Anforderungen einer PWA ist es auch wichtig einen Blick auf die Browserkompatibilität zu werfen. Diese beinhaltet Funktionen und APIs die letztendlich die PWAs zu nativen Apps vergleichbar machen.

Projekt Fugu

Heutzutage ist es zwar möglich durch Web APIs auf native Funktionen zuzugreifen allerdings nicht auf alle. Diese Lücke zwischen den Möglichkeiten die das Web bietet und die der nativen Anwendungen nennt Google App Gap. Das Projekt Fugu versucht diese Lücke zu schließen.
Es ist ein Web Capabilites Projekt von Google, Microsoft und Intel bei dem der Browserunterbau Chromium weiterentwickelt wird. Auf diesem basieren unter anderem die Browser Google Chrome, Samsung Internet, Opera und die neue Version von Microsoft Egde. Im Projekt Fugu wird kontinuierlich evaluiert, welche nativen Funktionen gebraucht werden um dafür Web APIs zu entwickeln. Die Web APIs sind dabei so aufgebaut, dass die Plattformunterschiede abstrahiert werden. Das heißt der Webbrowser fungiert als zusätzliche Schicht zwischen Anwendung und Endgerät und ruft die passende native Schnittstelle auf.
Der Name des Projekts Fugu kommt übrigens daher, dass dieser Fisch in Japan unter richtiger Zubereitung eine Delikatesse ist. Ist dies nicht der Fall, ist der Fisch giftig. Im übertragenden Sinne ist hier also gemeint, dass die Entwicklung der APIs zu hervorragenden Anwendungen führen kann. Das ist allerdings nur möglich, wenn bei der Entwicklung immer die Kernwerte des Webs; die Sicherheit, das Vertrauen und die Privatsphäre gewahrt bleiben.[10], [11]
Auf der Fugu-Tracker Seite kann man sich anschauen, welche APIs schon umgesetzt worden sind oder in welchem Entwicklungsstadium sie sich befinden.

Schematische Funktionsweise der Fugu APIs [10]

Firefox

Die Entwickler des Firefox Browsers haben Ende 2020 bekannt gegeben, dass die Funktion von Site Specific Browsern (SSB) nicht länger unterstützt werden soll. Diese Funktion ermöglicht es Webseiten in minimaler UI darzustellen, also ohne Browser-Steuerungselemente. Dies ist die Voraussetzung, um eine PWA im Standalone Modus zu nutzen. Bislang war diese Funktion nur versteckt nutzbar und hatte darüber hinaus viele Fehler. Außerdem wurde herausgefunden, dass sie kaum Vorteile bietet. So ist die weitere Unterstützung von PWAs im Firefox Browser offen. Auch für die Zukunft gibt es laut den Firefox Entwicklern keine genauen Pläne ob und inwiefern PWAs weiter unterstützt werden sollen.[12]

Safari

Durch die Einführung der vollständigen Blockierung von Cookies von Drittanbietern erschwert Apple die Nutzung von PWAs im Safari Browser. Je nach Anwendungsfall braucht eine PWA Zugriff auf die Geräte APIs oder technische Strukturen wie den LocalStorage. Durch die Cookie Blockade werden alle lokalen Speicherdaten einer Seite gelöscht, wenn diese Seite sieben Tage lang nicht verwendet worden ist. Dadurch ist der offline-first Ansatz nicht mehr möglich. Schon simple Apps wie eine ToDo-Listen App sind nicht mehr richtig nutzbar, da die gespeicherten Daten nach sieben Tagen gelöscht werden. Die einzige Möglichkeit die 7-Tage-Lösch-Regel zu umgehen, ist die Anwendung zum Homescreen hinzufügen. Allerdings ist das keine Voraussetzung von PWAs. Hier bleibt offen, ob es Apple wirklich um den Datenschutz der Nutzer geht oder ob es nicht auch wirtschaftliche Gründe hat. Apple profitiert durchaus von den Einnahmen aus dem App Store, der mit PWAs umgangen wird.[13] Außerdem werden auch viele andere Funktionen, wie beispielsweise das Senden von Push-Benachrichtigungen oder das Anzeigen des Add2Homescreen-Buttons noch nicht unterstützt.[14]

Vor- und Nachteile einer PWA im Vergleich zu nativen Apps

Nun stellt sich natürlich die Frage, welche Vorteile PWAs eigentlich im Vergleich zu nativen Apps bieten und an welchen Stellen native Apps den PWAs überlegen sind?
Der wohl überzeugendste Vorteil einer PWA ist, dass mit nur einer Codebasis eine Anwendung implementiert werden kann, die nicht an eine bestimmte Plattform gebunden ist. Das bedeutet daher weniger Entwicklungsaufwand und damit verbunden weniger Entwicklungskosten. Ein weiterer Vorteil ist, dass kein Installieren der Anwendung notwendig ist. Darüber hinaus ist auch das Updaten deutlich einfacher, da der Nutzer nicht jede neue Version aus einem App Store laden muss, sondern ein einfacher Reload der Webseite ausreicht. Außerdem ist durch das Auffinden der Anwendung mithilfe einer Suchmaschine und dem Teilen durch das Versenden einer URL eine einfachere Zugänglichkeit möglich.
Einen Nachteil gegenüber nativen Apps haben PWAs vor allem bei der Benutzerfreundlichkeit. Die UX einer nativen Anwendung und das Gefühl, dass die Anwendung Teil des Geräts ist, ist nicht so einfach umzusetzen. Zusätzlich stellt die Hardwarezugänglichkeit eine weitere Herausforderung für PWAs dar. Diesem Nachteil wird jedoch durch die Verwendung und stetiger Entwicklung von modernen APIs versucht entgegenzuwirken. Mithilfe dieser sollen die Fähigkeiten von nativen Anwendungen auch für PWAs verfügbar werden. Ein weiterer Nachteil aus wirtschaftlicher Sicht ist die Monetarisierung, die bei PWAs nicht so einfach umzusetzen ist, wie bei nativen Apps, die kostenpflichtig im App Store erworben werden können.[4], [15]

Vorteile PWANachteile PWA
Single Codebasis ➜ schnellere &
günstigere Entwicklung
bestmögliche UX schwieriger
kein Installieren notwendigHardwarezugänglichkeit schwieriger
einfaches UpdatenMonetarisierung schwieriger
Auffindbarkeit

Performance Test

Zusätzlich zu den allgemeinen Vor- und Nachteilen einer PWA, soll nun die Performance von PWAs im Vergleich zu nativen Apps anhand eines Performance Tests genauer untersucht werden. Dazu wurde eine simple App konzipiert, die performance-kritische Inhalte enthält. Wie in der unterstehenden Abbildung zu sehen, besteht die App aus zwei Ansichten. Die erste Ansicht Lorem Picsum enthält viel Text und die zweite Ansicht Gallery beinhaltet viele Bilder.

Implementierte PWA für den Performance Test

Für den Performance Test wurden die folgenden drei Anwendungen implementiert:

  • Eine PWA mit Angular (11.0.5)
  • Eine iOS App (14.2) mit SwiftUI
  • Eine Android App (11.0) mit Java

Um die Performance zu bewerten, wurden zwei Szenarien festgelegt. Im ersten Szenario wurde gemessen, wie schnell die erste Ansicht (Loren Picsum) geladen wird. Im zweiten Szenario wurde die Zeit ermittelt, die der Ansichtswechsel von Ansicht eins (Loren Picsum) zu Ansicht zwei (Gallery) braucht. Für jede Anwendung wurden die Szenarien fünf mal getestet und anschließend der Mittelwert aus den gemessenen Zeiten berechnet. Die implementierten Apps wurden auf einem MacBook Pro 2016 (PWA) und auf einem iPhone 8 Plus (iOS) getestet. Da zum Testzeitpunkt kein Android Endgerät zur Verfügung stand, wurde hierfür auf das Tool BrowserStack zurückgegriffen.
Die Auswertung (siehe Darstellung unten) zeigt, dass im ersten Szenario die PWA und die iOS App mit einem Mittelwert von jeweils unter einer Sekunde sehr gut abgeschnitten haben. Die Android Implementierung hingegen mit 1,2 Sekunden ist im Vergleich deutlich langsamer. Dieses Ergebnis könnte allerdings auch darauf zurückzuführen sein, dass für den Performance Test der Android App das Tool BrowserStack verwendet wurde.
Im zweiten Szenario hat ebenfalls die PWA am schnellsten reagiert. Die iOS App hat im Vergleich fast doppelt so lang und die Android App fast dreimal so lang gebraucht.

Auswertung des Performance Tests

Zusammenfassend kann also gesagt werden, dass bei diesem Performance Test die PWA mit Abstand am besten abgeschnitten hat. Allerdings muss beachtet werden, dass es sich bei den durchgeführten Performance Tests um keine voll umfänglichen Tests handelt, sondern diese nur dazu dienen einen ersten Eindruck zu vermitteln. Außerdem kann nicht davon ausgegangen werden, dass eine PWA bezüglich Performance immer besser abschneidet als eine native App, da es hier auch immer darauf ankommt mit welchem Framework die PWA umgesetzt wird.

Lighthouse Audits

Performance Optimierung

Um die Performance der PWA noch genauer zu analysieren, wurde die Anwendung zusätzlich mit dem Tool Lighthouse ausgewertet. Dabei handelt es sich um ein Tool für die Optimierung von Webanwendungen. Welches unter anderem Tests für Performance, Barrierefreiheit, progressive Web Apps und SEO bietet. Lighthouse bewertet die Performance mithilfe der folgenden sechs Metriken:

  • First Contentful Paint: Dauer, bis der erste Text oder das erste Bild angezeigt wird
  • Speed Index: Dauer, wie schnell der Inhalt einer Seite sichtbar befüllt wird
  • Largest Contentful Paint: Zeitpunkt, an dem der größte Text oder das größteBild angezeigt wird
  • Time to Interactive: Zeit, die eine Seite benötigt um vollständig interaktiv zu sein
  • Total Blocking Time: Summe aller Zeitspannen, in der die Seite nicht auf Benutzereingaben reagieren kann, da der Mainthread blockiert ist
  • Cumulative Layout Shift: Summe aller unerwarteten Layout-Verschiebungen (ein sichtbares Element ändert seine Position von einem Frame zum nächsten)

Anhand dieser Metriken wird ein Performance Score zwischen 0 und 100 ermittelt. Nähere Informationen zu den Metriken und dem Score können hier gefunden werden.
Die erste Ansicht hat einen Performance Score von 86 erreicht und die zweite Ansicht einen Score von 58 (siehe Abbildung). Bei beiden Audits ist die Metrik Largest Contentful Paint im roten Bereich. Bei der zweiten Ansicht sind zusätzlich die Metriken Total Blocking Time und Cumulative Layout Shift rot. Letzteres liegt vor allem daran, dass diese Ansicht viele Bilder enthält. Diese werden nacheinander geladen und sorgen so für Verschiebungen des Layouts. Das wirkt sich vor allem negativ auf die UX aus.[16], [17]

Lighthouse Audits vorher


Zusätzlich enthält der Lighthouse Bericht Empfehlungen, wie die Seite schneller laden könnte und Diagnosen mit weiteren Informationen über die Performance der Anwendung. Mithilfe dieser Informationen konnte auch durch die Anwendung einer Text Kompression mittels gzip und der Verwendung von online CSS statt separaten CSS-Dateien, die implementierte PWA verbessert werden. Außerdem bekamen alle img-Elemente, der verwendeten Bilder der PWA, eine feste Größe und wurden in einer geringeren Auflösung als zuvor bereitgestellt. Dadurch konnte der Performance Score der Ansichten deutlich optimiert werden, sodass die erste Ansicht nun einen Score von 97 und die zweite Ansicht einen Score von 98 erreichen konnte. Darüber hinaus sind alle Metriken im grünen Bereich. (siehe Abbildung)

Lighthouse Audits nachher

PWA Audits

Neben der Performance Auswertung sind in diesem Kontext auch die PWA Audits interessant, bei dem mit Lighthouse verschiedene Aspekte einer PWA validiert werden können. Die Validierung wird in drei Testbereiche unterteilt:

  • fast and reliable: Hier wird überprüft, ob die Seite schnell und zuverlässig lädt, unabhängig von der Netzwerkverbindung.
  • installable: Hier wird überprüft, ob die Bedingungen erfüllt sind, dass die PWA installierbar ist. Dazu zählt unter anderem, dass ein Service Worker registriert ist und dass das Manifest alle notwendigen Voraussetzungen erfüllt.
  • PWA Optimierung: Hierzu zählen Aspekte, die eine PWA optimieren, wie beispielsweise, dass der Inhalt responsive ist oder dass die Anwendung HTTPS anstatt HTTP verwendet.

Die implementierte PWA hat auch bei diesem Test gut abgeschnitten. Sie erfüllt in den Testbereichen fast and reliable sowie installable alle Aspekte. Lediglich im Bereich PWA Optimierung wurde ein Aspekt nicht erfüllt, da aufgrund der Entwicklung mit einem lokalen Server die Verwendung von HTTPS nicht möglich war.[18]

Fazit

Zusammenfassend lässt sich sagen, dass PWAs vor allem den Vorteil bieten, dass sie crossplattform entwickelt werden können. Dadurch entstehen weniger Kosten und die Apps können auf jedem Gerät ohne Installation verwendet werden. Allerdings können mit Web APIs noch nicht alle nativen Funktionen implementiert werden. Deshalb, um auf die Eingangsfrage zurückzukommen, können PWAs im Moment native APPs nicht komplett ersetzen. Google ist zwar ein großer Vorreiter und auch mit dem Projekt Fugu wird versucht die App Gap zu schließen, aber insgesamt gibt es noch zu wenig Unterstützung, vor allem von Firefox und Safari. Gerade iPhone Nutzer sind, zumindest im Moment, an Safari gebunden und können so nur wenig Funktionalitäten von PWAs nutzen.
Allerdings ist es abhängig vom Anwendungsfall möglich, dass PWAs native Apps ersetzen, wie etwa bei der Bestellung/Bezahlung in einem Restaurant. Für diesen Anwendungsfall wurde beispielsweise von Starbucks eine PWA implementiert, die es den Kunden ermöglicht schnell und einfach eine Bestellung aufzugeben.
Es bleibt auf jeden Fall spannend, was in Zukunft passiert und wie sich PWAs und deren Unterstützung weiterentwickeln.

Hands On

Hier sind noch ein paar weiterführende Links rund um das Thema Progressive Web Apps:

  • PWA Stats: Liste mit Statistiken und Neuigkeiten rund um Progressive Web Apps
  • PWA Bar: Auswahl der besten Progressive Web Apps
  • What Web can do today: Übersicht der verfügbaren Funktionen und welche Browser diese unterstützen
  • PWA Builder: Open-Source Projekt von Microsoft um PWAs zu erstellen
  • Web.dev: Sammlung von Artikeln der Google Developer zu PWAs

Quellen

[1]  MDN contributors, Introduction to progressive web apps
[2]  MDN contributors, Progressive Enhancement
[3]  A. Russell, Progressive Web Apps: Escaping Tabs Without Losing Our Soul
[4]  P. LePage, Sam Richard, What are Progressive Web Apps?
[5]  MDN contributors, Progressive web apps (PWAs)
[6]  M. Gaunt, Service Workers: an Introduction
[7]  F. Beaufort, Pete LePage, Add a web app manifest
[8]  A. Osmani, The App Shell Model
[9]  MDN contributors, Progressive web app structure
[10] C. Liebel, Project Fugu – neue Fähigkeiten braucht das Web
[11]  K. Münster, What Is Project Fugu — Google’s Initiative To Unlock All Native Device Features For The We
[12]  S. Grüner, Firefox soll PWA nicht unterstützen
[13]  D. Petereit, Unter dem Deckmantel des Guten: Apples neuer Safari-Browser behindert die Entwicklung von progressiven Web-Apps
[14]  A. Bar, What web can do today?
[15]  A. Verhoeven, Native app vs. progressive web app (PWA): Everything you need to know
[16]  Google, Lighthouse
[17]  Google Developers, Lighthouse performance scoring
[18]  Google Developers, PWA audits

ServiceWorker – Offline First

In der Vorlesung Rich Media haben wir uns viel mit Performance in Web Anwendungen beschäftigt. Dabei habe ich mich mit ServiceWorkern in Bezug auf Offlinenutzung, Funktionalität und Performance beschäftigt. Zuerst habe ich mich damit befasst, wie ein ServiceWorker funktioniert. Danach habe ich geschaut, wie sich die Nutzung eines ServiceWorker und des Ansatzes Offline First auf die Performance auswirkt.

Continue reading

WebSocket-Protokoll: Ein detaillierter technischer Einblick

Das HTTP-Protokoll existiert seit Beginn des Internets und hat sich bis heute in Bezug auf Performance immer weiter entwickelt. Die vielen TCP-Verbindungs-Aufbau-Prozeduren wurden durch das Multiplexing auf ein paar Wenige reduziert, welche jeweils mehrere verschiedene Daten übertragen [7]. Auch der Header selbst wurde auf Performance getrimmt. So wurde aus dem textuellen Format ein binär-Kodiertes. Zudem wurden neue Funktionen wie das Caching hinzugefügt, um das Laden von Daten zu minimieren [7][8].

Jedoch funktioniert das HTTP-Protokoll in seiner Grund-Funktionalität immer noch gleich. Es besteht immer noch aus einer Anfrage und einer Antwort und die Verbindung kann nicht beliebig lange offen gehalten werden.

Es ist dem Server nicht möglich, von sich aus Daten an den Client zu senden. Dieser Datenaustausch kann nur vom Client initiiert werden [7][8].

Hier knüpft das WebSocket-Protokoll [2] an. Es bietet eine bidirektionale Datenübertragung, welche es dem Server erlaubt, direkt ohne Client-Anfrage Daten zu senden, was das Realisieren von Echtzeit-Web-Anwendungen ohne große Netzlast oder Latenz ermöglicht. Zudem ist der Header sehr klein und einfach zu interpretieren. Dadurch ist das Protokoll sehr gut zum Senden vieler kleiner Nachrichten geeignet.

Im Folgenden werden zunächst allgemeine Informationen und wichtige Eigenschaften des WebSocket-Protokolls beschrieben und die Vorteile und Nachteile gegenüber dem HTTP-Protokoll offen gelegt. Daraufhin wird ein detaillierter technischer Einblick in die Implementierung und Funktionsweise des Protokolls gegeben. Am Schluss wird die JavaScript-WebSocket-API als Beispiel-API für die Client-seitige WebSocket-Implementierung vorgestellt und deren Funktionen mit dem internen Verhalten des Protokolls in Beziehung gesetzt.

Allgemein

Das WebSocket-Protokoll ist ein seit 2011 existierendes Internet-Protokoll, welches auf der Anwendungsschicht des OSI-Modells angesiedelt ist und der bidirektionalen Daten-Übermittlung über einer konstanten TCP-Verbindung dient. Dabei werden die Standard-HTTP-Ports mit verwendet, also 80 oder 8080 bei unverschlüsselten und 443 bei verschlüsselten Verbindungen. Dies hat den Vorteil, dass keine zusätzlichen Firewall-Einstellungen nötig sind, um das WebSocket-Protokoll zu berücksichtigen [9]. Das WebSocket-Protokoll ist im RFC 6455 von der IETF (Internet Engineering Task Force) standardisiert und aktuell in der Version 13 verfügbar [2]. Es dient primär der Echtzeit-Datenübertragung bei Echtzeit-Web-Anwendungen.

Protokoll-Eigenschaften

Im Folgenden werden wichtige Eigenschaften des WebSocket-Protokolls genannt und die daraus entstehenden Einschränkungen und Vorteile gegenüber dem HTTP-Protokoll beschrieben.

Übertragung großer Daten

Wie beim HTTP-Protokoll auch, können größere Daten, welche nicht auf einmal in einen Puffer passen, wie zum Beispiel größere Dateien, Stück für Stück versendet werden. Hierbei ist aber keine Fragmentierung auf Anwender-Schicht notwendig. Die Nachricht wird als eine große Nachricht mit einem Header und großer Payload interpretiert, welche je nach Puffer-Größe Stück für Stück eingelesen wird. Anhand der im Header gegebenen Payload-Größe und der bisher empfangenen Payload-Daten kann ermittelt werden, ob noch Daten fehlen oder die Nachricht vollständig ist [10].

In Abbildung 1 ist die entsprechende Nachricht und der verfügbare Puffer veranschaulicht.

Senden großer Daten durch Stück-weises einlesen in den Puffer
Abbildung 1: Senden großer Daten durch Stück-weises einlesen in den Puffer

Da dieses Verfahren von beiden Protokollen unterstützt wird, existieren hier weder Vor- noch Nachteile.

Verbindungsorientiert + konstante Verbindung + kleiner Header

Das WebSocket-Protokoll ist verbindungsorientiert [2]. Dies bedeutet, dass zunächst eine HTTP-Anfrage und eine entsprechende Antwort geschickt werden muss, bevor die eigentlichen Daten versendet werden können [7]. Dies erzeugt zunächst einen Mehraufwand in Form von Verarbeitungs-Aufwand und der Größe an Daten, welche gesendet werden müssen. Sollten jedoch mehrere Daten über eine konstante Verbindung ohne erneuten Verbindungsaufbau gesendet werden, kann das WebSocket-Protokoll seine Stärke ausspielen. Der Header des WebSocket-Protokolls ist deutlich kleiner als der des HTTP-Protokolls, auch wenn der HTTP-Header binär kodiert sein sollte. Zudem muss das HTTP-Protokoll pro Daten-Transfer zwei Header, eine Anfrage und eine Antwort, senden. Somit ist der Aufwand pro Nachricht beim WebSocket-Protokoll geringer, was bei vielen zu übermittelnden Nachrichten einen großen Vorteil bringt. Da bereits das HTTP/1.1-Protokoll mit Multiplexing-Funktionalitär ausgestattet ist [7], kann der entscheidene Vorteil darin gesehen werden, dass das WebSocket-Protokoll eine konstante Verbindung besitzt, sodass die zu übertragenden Daten nicht zu Beginn der Übertragung bekannt sein müssen, was bei HTTP-Multiplexing aber der Fall ist, da die HTTP-Verbindung wieder geschlossen werden muss.

Die folgende Formel gibt an, ab welcher Nachrichten-Anzahl sich der Einsatz von WebSockets lohnt, wenn für HTTP Multiplexing verwendet werden kann. Mit ‘WS-Header‘ oder ‘HTTP-Header‘ ist der Aufwand gemeint, welcher mit dem Versenden und Erstellen beziehungsweise Lesen des entsprechenden Headers einhergeht. Der linke Teil gibt den Aufwand des WebSocket-Protokolls, der rechte Teil den Aufwand für das HTTP-Protokoll an. ‘n‘ entspricht der Anzahl an Nachrichten [10].

2 HTTP-Header + n WS-Header + 2 WS-Header < n*2 HTTP-Header

Die zusätzlichen 2 WS-Header entsprechen dem Verbindungs-Abbau.

Maskierung

Da beim Hochladen von Daten die Payload maskiert werden muss [2], entsteht beim WebSocket-Protokoll ein Mehraufwand. Je größer die Payload einer Nachricht ist, desto mehr muss maskiert werden, was die Gesamt-Übertragungszeit reduziert. Daher sollten beim Hochladen von Daten, der Payload-Anteil möglichst gering gehalten werden.

Bidirektional vs. Polling

Bidirektional bedeutet, dass zu einer beliebigen Zeit einer der Teilnehmer eine Nachricht an die Gegenstelle senden kann. Dadurch ist es dem Server möglich, Nachrichten an den Client zu senden, ohne eine vorherige Anfrage erhalten zu haben. Dies ist vor allem in Anwendungsgebieten von Vorteil, in denen der Server dem Client möglichst schnell Zustands-Aktualisierungen mitteilen muss. Anwendungs-Gebiete sind hierbei Echtzeit-Anwendungen wie Browser-Spiele [5], in welchen der Spieler möglichst schnell vom Server informiert werden muss, wenn zum Beispiel ein neuer Gegner in sein Sichtfeld gerät. Mit Hilfe des WebSocket-Protokolls kann der Server daher direkt eine Nachricht senden, was der Latenz einer Daten-Übertragung für eine Strecke entspricht.

Die selbe Funktionalität mit dem HTTP-Protokoll muss mit Hilfe von Polling implementiert werden [6]. Dabei wird regelmäßig eine Anfrage gesendet, um den aktuellen Server-Zustand abzufragen. Dabei verursacht das permanente Abfragen eine große Netzlast, was beim WebSocket-Protokoll nicht der Fall ist. Darüber hinaus ist die Latenz meist deutlich höher und abhängig von der Abfrage-Frequenz des Clients.

In Abbildung 2 und 3 wird die Eigenschaft der Bidirektionalität und das Polling-Verfahren visuell veranschaulicht.

Server-Mitteilung mit bidirektionaler Datenübertragung.
Abbildung 2: Server-Mitteilung mit bidirektionaler Datenübertragung
Abbildung 3: Server-Mitteilung mit Polling-Verfahren

Keine Same-Origin-Policy

Das WebSocket-Protokoll folgt im Gegensatz zum HTTP-Protokoll keiner Same-Origin-Policy [1]. Es können also mehrere Verbindungen mit unterschiedlichen Domänen existieren. Um Sicherheitsprobleme wie Cross-Site-Scripting zu umgehen, muss der Server beim Verbindungsaufbau den mitgelieferten Origin-Header mit der eigenen Domäne abgleichen und eventuell die Verbindung trennen, wenn die Domäne der Client-Anwendung keine Valide ist.

Anwendungsgebiete

Anwendungsgebiete für das WebSocket-Protokoll sind alle Anwendungen, welche möglichst alle Eigenschaften und deren Einschränkungen des Protokolls optimal nutzen können. Primär wird das WebSocket-Protokoll in Echtzeit-Anwendungen wie Browser-Spielen [5], Chat-Anwendungen oder beim Streaming verwendet. Browser-Spiele tauschen viele kleine Nachrichten zwischen Server und Client aus. Zudem muss der Server dem Client schnellstmöglich mitteilen, wenn sich der Spiel-Zustand insofern ändert, dass es den entsprechenden Spieler betrifft. Aber auch beim Monitoring kann das WebSocket-Protokoll bestmöglich eingesetzt werden, da auch hier ein schneller bidirektionaler Datenverkehr zwischen Server und Client benötigt wird. Zudem kann durch das Verbinden mit verschiedener Domänen, der Zustand mehrerer Server eines größeren Netzwerks visualisiert werden [10].

Verbindungsaufbau

Der Verbindungsaufbau des WebSocket-Protokolls entspricht einem klassischen HTTP-Zyklus bestehend aus Anfrage und Antwort. Im Folgenden sind die Minimal-Header für Anfrage und Antwort gegeben [1].

HTTP-AnfrageHTTP-Antwort
GET /<URL> HTTP/1.1
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: <String-In>
Sec-WebSocket-Version: <Version-in>
HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: <String-Out>
Sec-WebSocket-Version: <Version-out>
Tabelle 1: Minimaler Anfrage/- und Antwort-HTTP-Header für WebSocket-Verbindungsaufbau [1]

Die zu übergebende <URL> kann beliebig gewählt werden, da diese für das WebSocket-Protokoll keine Bedeutung hat. Typischerweise wird die <URL> daher zur Differenzierung verschiedener WebSocket-Anwendungen, welche parallel auf dem Server laufen, verwendet [1].

Um dem Server mitzuteilen, dass auf das WebSocket-Protokoll gewechselt werden soll, müssen die Header ‘Upgrade‘ und ‘Connection‘ verwendet werden.

Im ‘Sec-WebSocket-Version‘-Header wird die vom Client unterstützte WebSocket-Version <Version-in> angegeben. Meistens entspricht dies der aktuellen Version 13 [10].

Vor dem Senden einer WebSocket-Nachricht muss der Client sicher stellen, dass der kontaktierte Server das WebSocket-Protokoll auch versteht. Andernfalls bestünde die Gefahr, dass der Server fälschlicherweise eine WebSocket-Nachricht als HTTP-Nachricht interpretiert, was zu einer Sicherheitslücke führt. Aus diesem Grund muss ein Base64-kodierter String <String-in>, welcher beliebig gewählt werden kann, im ‘Sec-WebSocket-Key‘-Header mitgeliefert werden. Der Server muss diesen entsprechend der in Tabelle 2 angegebenen Schritte konvertieren und das Ergebnis in seiner Antwort im ‘Sec-WebSocket-Accept‘-Header zurück senden [1].

Zusätzlich kann der Server eine WebSocket-Version <Version-out> angeben, falls diese von der Angabe des Clients <Version-in> abweicht.

Konnte keine Vereinbarung bezüglich der Version oder des Wechsels auf das WebSocket-Protokoll getroffen werden oder der zurück gelieferte String <String-out> falsch sein, wird der Verbindungsaufbau abgebrochen [1].

BeschreibungBeispielLänge (Byte)
<String-In>: beliebiger Base64-StringMQBbM45rKkPH/ocIaDfOjw==24
Konkatinierung mit statischem StringMQBbM45rKkPH/ocIaDfOjw==258EAFA5-E914-47DA-95CA-C5AB0DC85B1160
sha1-Hash2e9a036975af28d8828712ff45a733eb4d9c2f5340
Hex -> Int<nicht darstellbar>20
base64: <String-Out>LpoDaXWvKNiChxL/Racz602cL1M=28
Tabelle 2: Sec-WebSocket-Key-Konvertierung [1] [10]

WebSocket-Header

Der WebSocket-Header ist binär kodiert und in seiner Größe variabel. Er kann je nach Payload-Größe und Übertragungs-Richtung bis zu 14 Byte umfassen und eine minimale Größe von 2 Byte betragen [1][2], was im Gegensatz zum HTTP-Header, auch wenn dieser binär kodiert sein sollte, deutlich kleiner ist. In Abbildung 4 ist der WebSocket-Header mit seinen Bestandteilen dargestellt. Im Folgenden werden diese detailliert beschrieben.

Abbildung 4: WebSocket-Header [1]

Opcode

Der Opcode, auch Operation-Code genannt, gibt den Typ der Nachricht an [2]. Aktuell sind folgende sechs Nachrichten-Typen definiert:

CodeBeschreibung
0x0Continuation (Kontroll-Rahmen)
0x1Text (Payload-Typ: UTF-8-Text)
0x2Binary (Payload-Typ: Binär-Format)
0x3-0x7not used
0x8Close (Kontroll-Rahmen)
0x9Ping (Kontroll-Rahmen)
0xaPong (Kontroll-Rahmen)
0xb-0xfnot used
Tabelle 3: verfügbare Opcodes des WebSocket-Header

Die Opcodes ‘Text‘ und ‘Binary‘ geben an, dass in der Payload Anwendungs-bezogene Daten enthalten sind. Bei ‘Text‘ muss die Payload als UTF-8-String, bei ‘Binary‘ als Binär-Daten interpretiert werden. Die restlichen vier Kontroll-Rahmen werden in nachfolgenden Kapiteln mit Ihrem jeweiligen Verwendungszweck beschrieben.

Fin – Fragmentierung auf Anwendungsschicht

Das Fin-Flag wird im Zusammenhang mit dem Opcode ‘Continuation‘ verwendet, um Fragmentierung auf Applikations-Schicht zu ermöglichen. Dabei wird das Fin-Bit nur gesetzt, wenn es sich bei der Nachricht um das letzte Fragment der Gesamt-Nachricht handelt. Der Opcode wird zu Beginn auf den Daten-Typ der Payload, also ‘Text‘ oder ‘Binary‘ gesetzt. Der Daten-Typ ist dabei für alle Fragmente einer Gesamt-Nachricht der Selbe. Alle nachfolgenden Fragmente müssen mit Opcode ‘Continuation‘ gekennzeichnet werden [1][2].

In Tabelle 4 ist das Zusammenspiel zwischen Opcode und Fin-Flag bei fragmentierter und nicht-fragmentierter Nachricht veranschaulicht. Aus [1] inspiriert.

FinOpcodeBeschreibung
11,2Nachricht nicht fragmentiert.
01,2Nachricht mit Typ 1,2 beginnt.
=> weitere Nachrichten folgen, um Payload zu vervollständigen.
00Weiterer Teil der Nachricht mit Typ 1,2.
10Letzter Teil der Nachricht.
=> Payload jetzt vollständig.
Tabelle 4: Zusammenspiel zwischen Opcode und Fin-Flag bei fragmentierter und nicht-fragmentierter Nachricht.

Mask

Wenn das Mask-Flag gesetzt ist, ist die Nachricht gemasked. Dies bedeutet, dass die Payload der Nachricht mit dem mitgelieferten 4-Byte großen Mask-Key XOR-Verschlüsselt wurde. Das Ver/- und Entschlüsselungs-Verfahren ist dabei das Selbe und im Folgenden mit Programm-Code beschrieben, welcher von [1] inspiriert wurde:

for (unsigned int i = 0; i < payloadSize; ++i) {
     pBuffer[i] = pPayload[i] ^ pMaskKey[i % 4];
}

‘pBuffer’ enthält hierbei nach dem Verfahren entweder die verschlüsselte oder entschlüsselte Version der Payload, jenachdem, ob die Payload ‘pPayload’ ver/- oder entschlüsselt vorliegt.

Wichtig ist hierbei, dass nur Nachrichten vom Client zum Server gemasked werden müssen. Nachrichten vom Server zum Client dürfen nicht gemasked werden [2].

Sollte eine unverschlüsselte Nachricht dem Server oder eine Verschlüsselte dem Client gesendet werden, muss der Empfänger die Verbindung schließen [1].

Payload-Größe

Die Anzahl der benötigten Bytes für die Kodierung der Payload-Größe ist je nach Payload-Größe unterschiedlich. Um die Größe der Payload zu ermitteln müssen zunächst die 7 Bit des ‘Payload-Len’-Feldes interpretiert werden. Sollte dieser Wert kleiner als 126 sein, so entspricht dies der Payload-Größe. Sollte der Wert aber 126 oder 127 sein, so müssen weitere Bytes eingelesen werden und deren Wert als Payload-Größe interpretiert werden. Bei 126 sind es 2 Byte, bei 127 8 Byte, die zusätzlich eingelesen werden müssen [1]. Dadurch müssen bei kleineren Nachrichten unnötige Bytes nicht mitgesendet werden, da sich die Anzahl der zur Kodierung der Payload-Größe benötigten Bytes von der Nachrichten-Größe abhängt.

RSV

RSV steht für ‘Reserved‘ und stellt bisher ungenutzte Bits im Header dar, welche für eventuell spätere Protokoll-Erweiterungen in der Spezifikation reserviert sind.

Verbindungsabbau

Um eine WebSocket-Verbindung zu schließen, kann einer der Teilnehmer zu jeder Zeit eine Nachricht mit dem Opcode ‘Close‘ senden. Die Gegenstelle muss dann eine entsprechende Close-Nachricht zurück senden. Die Payload der Close-Nachricht ist in zwei Abschnitte eingeteilt, welche zusammen nicht größer als 125 Byte sein dürfen. Hierbei entsprechen die ersten 2 Byte dem Close-Code, einer ID zur exakten Bestimmung des Schließ-Grunds. Alle nachfolgenden Bytes enthalten, wenn vorhanden, eine textuelle Beschreibung des Close-Codes [1]. Meistens wird jedoch nur der Close-Code gesendet [10].

Nach dem Senden oder Empfangen einer Close-Nachricht dürfen keine weiteren Nachrichten gesendet und empfangene Nachrichten nicht mehr berücksichtigt werden [1].

Zusätzliche Funktionen

Pings und Pongs

Sollte die Gegenstelle auf Anwender-Schicht nicht mehr erreichbar sein, so können Ressourcen gespart werden, wenn die Verbindung getrennt wird. Um zu erkennen, ob ein anderer Teilnehmer noch erreichbar ist, oder nicht, können zu einem beliebigen Zeitpunkt, Nachrichten mit dem Opcode ‘Ping‘ gesendet werden. Die Payload kann hierbei beliebig gewählt werden, darf aber die Maximal-Größe von 125 nicht überschreiten. Durch den Empfang einer entsprechenden Ping-Nachricht ist der Empfänger dazu gezwungen, eine Nachricht mit dem Opcode ‘Pong‘ zurück zu senden. Dabei muss die Payload der Pong-Nachricht den Daten der Ping-Nachricht entsprechen [1].

Wann genau eine Ping-Nachricht gesendet werden sollte, ist in der Spezifikation nicht definiert und daher der Anwendung überlassen [2]. Die Anwendung könnte die vergangene Zeit seit der letzten angekommenen Nachricht von einem bestimmten Teilnehmer messen. Sollte diese einen bestimmten festgelegten Wert überschreiten, könnte eine Ping-Nachricht gesendet werden. Auf die entsprechende Pong-Antwort kann nun wiederum eine bestimmte festgelegte Zeit gewartet werden. Sollte bis dahin keine Pong-Nachricht ankommen, kann die TCP-Verbindung geschlossen werden [10].

Bisher konnte aber die Erfahrung gemacht werden, dass der ‘Firefox’-Browser [12] keine Ping-Nachrichten an den selbst erstellten Server gesendet hat. Dies liegt eventuell daran, dass der Browser erkennt, dass der Server lokal erreichbar ist, was bedeutet, dass sich beide Teilnehmer auf der selben Maschine befinden wodurch das Senden einer Ping-Nachricht damit unnötig ist [10].

Sollten mehrere Pings gesendet werden, genügt es, einen Pong als Antwort zu senden. Pong-Nachrichten ohne dazugehörige Ping-Nachricht werden ignoriert [1].

Sub-Protokolle

Subprotokolle dienen der Kennzeichnung bezüglich der Kodierung einer Payload. Beinhaltet die Payload beispielsweise einen JSON-String, so kann durch ein Sub-Protokoll dem Server mitgeteilt werden, dass er einen JSON-Parser zum interpretieren der Payload verwenden soll. Die Mitteilung der Sub-Protokolle geschieht über einen eigenen HTTP-Header während dem Verbindungs-Aufbau. Über den HTTP-Header ‘Sec-WebSocket-Protocol‘ können ein oder mehrere Sub-Protokolle beim Server angefragt werden, zum Beispiel mehrere Versionen eines Parsers. Der Server sendet dann das erste passende Sub-Protokoll über selbigen Header zurück an den Client [1].

JavaScript WebSocket-API

Im Folgenden werden die wichtigsten Funktionen der WebSocket-API für die Sprache JavaScript auf Client-Seite kurz erläutert, und im Parallelen veranschaulicht, welche Funktionen zu welchen Aktionen intern im Browser führen, bezogen auf das WebSocket-Protokoll. Die dafür nötigen Informationen wurden aus [3] und [4] entnommen.

Verbindungsaufbau

var ws = new WebSocket(<URL>, <subProtocols>);

Das Erzeugen eines WebSocket-Objekts entspricht dem WebSocket-Verbindungs-Aufbau. Der erste Parameter entspricht der <URL>, über welche der Server und eine auf dem Server laufende WebSocket-Anwendung gewählt werden kann, zu der eine Verbindung aufgebaut werden soll. Zu Beachten gilt, dass das ‘http://‘ oder ‘https://‘ in typischen HTTP-URL’s mit einem ‘ws://‘ für ‘WebSocket’ beziehungsweise einem ‘wss://’ für ‘WebSocket Secure‘ bei sicheren Verbindungen ersetzt werden muss.

Der zweite Parameter ist optional und kann zur Angabe bestimmter Sub-Protokolle verwendet werden. Hierbei kann entweder ein String oder Array von Strings übergeben werden.

ws.onopen = ()=>{};

Bei erfolgreichem Verbindungsaufbau wird der Anendungs-Code durch den onopen-Listener informiert.

Senden

ws.send(<Content>);

Das Senden von Daten geschieht über die send-Funktion des WebSocket-Objekts. Jenachdem, welche Objekte als Parameter übergeben werden, wird der Obcode im WebSocket-Header gesetzt. Tabelle 5 stellt alle möglichen Kombinationen zwischen übergebenem Objekt und Opcode dar.

<Content>Opcode
StringText
ArrayBuffer / BlobBinary
Tabelle 5: Mapping zwischen übergebenem Parameter und Opcode

Empfangen

ws.onmessage = ev=>{ev.data;};
ws.binaryType = <Type>;

Für den Empfang von Daten, wird der onmessage-Listener benötigt, welcher informiert wird, sobald die Payload der Nachricht vollständig vorliegt. Die für den Empfang zur Verfügung stehenden Objekte sind die Selben wie für das Senden. Jedoch muss beim Empfang einer Nachricht mit Opcode ‘Binary‘ zusätzlich bestimmt werden, ob ein ArrayBuffer-Objekt oder ein Blob-Objekt empfangen werden soll, da beide jeweils Binär-Formate darstellen. Dafür wird das Objekt-Feld ‘binaryType‘ verwendet. Ein Überblick über die möglichen Werte und deren Beziehungen ist in Tabelle 6 gegeben. ‘-‘ bedeutet, dass der Wert nicht berücksichtigt wird.

OpcodebinaryTypeev.data
TextString
Binary“arraybuffer”ArrayBuffer
Binary“blob”Blob
Tabelle 6: Abhängigkeiten zwischen Opcode, <Type> und ev.data

Verbindungsabbau

ws.onclose = ev=>{};
ws.close(<Code>, <Msg>);

Für den Verbindungsabbau existieren zum Empfangen einer Close-Nachricht ein entsprechender Listener und zum Senden einer Close-Nachricht eine Sende-Funktion. Hierbei muss aber beim Empfang einer Close-Nachricht keine Close-Nachricht manuell zurück gesendet werden. Dies wird vom Browser-Laufzeit-System übernommen. Sowohl das Event-Objekt, als auch die Sende-Funktion besitzen die Möglichkeit, den Close-Code, sowie eine optionale textuelle Close-Nachricht zu empfangen beziehungsweise zu senden.

Payload-BestandteilSendenEmpfangen
Close-Code<Code>ev.code
Close-Message<Msg>ev.reason
Tabelle 7: Komponenten zum Lesen und Schreiben der Close-Payload

Fehlermeldung

ws.onerror = ()=>{};

Sollte während der WebSocket-Kommunikation ein Fehler auftreten, kann dieser über den ‘onerror‘-Event-Listener mitgeteilt werden. Jedoch wird hier lediglich ein Event-Objekt übergeben, welches keinerlei Informationen über den Fehler enthält. Ein entsprechender Fehler-Code ist immer nur im Close-Code enthalten, da darüber alles kommuniziert wird, was das Schließen der Verbindung bewirkt hat, also auch Fehler [11].

Socket.io

‘Socket.io’ ist eine abstraktere JavaScript-Bibliothek für Client- aber auch Server-seitige Echtzeit-Kommunikation mit einer einheitlichen Schnittstelle, welche die Verwendung und Einbindung von Echtzeit-Kommunikation in Web-Anwendungen erleichtern soll. Dabei wird je nach Kompatibilität der darunterliegenden Technologien, im Hintergrund entweder auf HTTP mittels Polling oder auf das WebSocket-Protokoll zugegriffen. ‘Socket.io’ bietet aber noch weitere Funktionalitäten wie zum Beispiel Echtzeit-Analysen [13].

Quellen