In den meisten klassischen Web-Applikationen, an deren Entwicklung ich beteiligt war, stellte das de-facto Monopol der Sprache JavaScript im Frontend kein Problem dar. Weder war das Bedürfnis nach Performance-Optimierung in einem solchen Maße gegeben, dass die Suche nach einer Lösung außerhalb des JavaScript-Ökosystems notwendig war, noch wurde die Beschränkung auf JavaScript-Librarys und -Frameworks als etwas angesehen, das man realistischerweise umgehen kann. Doch welchen Weg könnte man einschlagen, sollte das plötzlich in einem Projekt nicht mehr zutreffen? Die Antwort darauf könnte WebAssembly lauten. Um mir selbst und der Masterklasse Mobile einen Überblick über das Thema und einen Einblick in potenzielle neue Problemlösungsstrategien für die erwähnten Problemstellungen zu geben, hielt ich einen Workshop, dessen Inhalte ich im Folgenden zusammenfassend dokumentieren möchte.

Ziele und Nicht-Ziele des Workshops

Ziele:

• Das Konzept von WebAssembly veranschaulichen
  • Mögliche Einsatzbereiche ausfindig machen
  • Alle – auch mich selbst – mit neuem Wissen bereichern

Nicht-Ziele:

• Neue Programmiersprachen lernen
  • Große Applikationen bauen
  • Eine reine Frontal-Präsentation abhalten

Die Problemstellung im Detail

Wie erwähnt ist unsere Ausgangslage, dass Browser grundsätzlich nur JavaScript als Frontend-Programmiersprache ausführen können. Dies hat erhebliche Nachteile im Hinblick auf Performance, denn JavaScript ist eine interpretierte Sprache (im Gegensatz zu kompilierten Sprachen). Konkret heißt das, dass der Code nicht zuerst in Maschinensprache umgewandelt werden muss, sondern direkt im Browser zur Laufzeit übersetzt wird. Hier setzt WebAssembly an. Die Performance von Webanwendungen soll durch das browserseitige Ausführen vorher kompilierten Codes verbessert werden, denn es entfällt der Extra-Schritt der Übersetzung zur Laufzeit. Jedoch ist der Einsatz von WebAssembly nicht auf den Webbrowser beschränkt. Auch serverseitig und in Stand-Alone-Runtimes ist es möglich, dieselbe Technologie einzusetzen.

Was ist nun WebAssembly genau?

Von w3.org wird WebAssembly (kurz WASM) als binäres Instruktionsformat für eine Stack-basierte virtuelle Maschine bezeichnet. Das Ziel ist es also, eine im Browser vorhandene virtuelle Maschine mit Instruktionen in einem bestimmten standardisierten Format zu versorgen. Diese ist als Stack-Machine konzipiert, d. h. es kann jeweils nur auf den obersten Eintrag ein einem Stapel an gespeicherten Werten zugegriffen werden. Dies soll uns aber als Web-Entwickler*innen nicht zu sehr abschrecken, denn im Normalfall ist es Aufgabe des Compilers, lauffähige Instruktionen in Maschinensprache zu erzeugen.

Wir benötigen also einen geeigneten Compiler, um für unser Nicht-JavaScript-Projekt ein WASM-File zu erzeugen. Hiervon gibt es bereits einige, wie z. B. „emscripten“ für C und C++, „Pyodide“ für Python, Rust, und AssemblyScript für eine syntaktisch auf TypeScript beruhenden Sprache. Zumal WebAssembly standardisiert ist, können Compiler für so gut wie alle erdenklichen Programmiersprachen entwickelt werden.

Code-Beispiele

Zusätzlich zu WASM-Dateien generieren viele Compiler auch WAT-Dateien (WebAssembly Text Format), welche als für den Menschen lesbare Variante des Outputs diesen. Zwar kann man wie im folgenden Beispiel auch selbst WAT-Dateien schreiben und diese dann in WASM umwandeln, jedoch dient dieses Format in der Praxis in erster Linie dem Debugging.

(module
  (func $add (param $lhs i32) (param $rhs i32) (result i32)
    get_local $lhs
    get_local $rhs
    i32.add)
  (export "add" (func $add))
)

Hier wird eine simple Additions-Funktion implementiert, welche die Summe der beiden Parameter „lhs“ und „rhs“ liefert. Sie wird dann exportiert, sodass im Frontend mit JavaScript das definierte Modul geladen und ein Funktionsaufruf getätigt werden kann. Letzteres könnte dann wie folgt umgesetzt werden:

fetch("foo.wasm")
  .then((res) => res.arrayBuffer())
  .then((bytes) => WebAssembly.instantiate(bytes))
  .then((res) => {
    const result = res.instance.exports.add(5, 7);
  });

Zu beachten ist, dass in diesem Beispiel die WASM-Datei „foo.wasm“ mittels HTTP-Request vom Server geladen wird. Es wäre aber auch denkbar, den Bytecode einer kompilierten WASM-Datei direkt als Literal in JavaScript an den Client mitzugeben. Auch sei an dieser Stelle festgestellt, dass WebAssembly keinen gänzlichen Ersatz für JavaScript darstellt, zumal ein WASM-Modul aus JavaScript-Code heraus aufgerufen wird. Es handelt sich also grundsätzlich um eine Möglichkeit, rechenintensive Prozesse auszulagern, während der Ausgangspunkt immer noch eine JavaScript-Anwendung bleibt.

Anwendungsfälle

Es wurde bereits eine Vielzahl an Projekten mit WebAssembly umgesetzt. Ein prominentes Beispiel stellt die von Google entwickelte App „Squoosh“ dar, welche es erlaubt, Bilddateien hochzuladen und diese clientseitig in ein anderes Format umzuwandeln. So kann der Server dahingehend entlastet werden, dass die Umwandlung von z. B. JPEG nach WebP mit vom User festgelegten Qualitätsparametern clientseitig erfolgt und auf Funktionalität zurückgegriffen werden kann, die aus einer Nicht-JavaScript-Library stammt. Ferner wurden bereits Spiele, welche ursprünglich für Spielkonsolen entwickelt wurden, oder 3D- bzw. Grafikprogramme mittels WebAssembly browserfähig gemacht.

Fazit

WebAssembly ist eine Technologie, welche die Lösung für einige spezifische Problemstellungen liefert, und potenziell performante und sichere Web-Apps hervorbringen kann bzw. dies bereits unter Beweis gestellt hat. Jedoch sollte hierbei beachtet werden, dass es sich nicht um eine Konkurrenz-Technologie zu herkömmlichen JavaScript-Apps handelt, sondern viel mehr um eine Ergänzung, welche das Auslagern rechenintensiver Prozesse in eine kompilierte Datei ermöglicht. Es wäre also gegenwärtig verfrüht, das Ende von JavaScript zu proklamieren.

The post WebAssembly (Einsteiger*innen-Workshop im WS2022/23) appeared first on Mobile USTP MKL.

Was ist Defrost?

Defrost ist ein Open-Source-Projekt (siehe GitHub und npm), welches es erlaubt, Templates für anzuzeigende Webseiten zwischen dem Backend und dem Frontend zu teilen (um bloß nicht an mehreren Stellen im Projekt Dateien duplizieren zu müssen) und diese dann server-seitig anhand vorhandener Daten zu rendern und anschließend client-seitig wieder zu entschlüsseln, welche Daten am Server gerendert wurden. Somit kann ein Ausgangszustand für eine Web-App hergestellt werden, welcher sich direkt aus dem HTML-Dokument ergibt. Darüber hinaus kann durch simple Reaktivität anschließend der „State“ wieder abgeändert und ein Update gerendert werden.

Es sei erwähnt, dass sich die Verwendung von Defrost und bekannten Frontend-Frameworks zugleich nicht unbedingt ausschließt. Da Defrost nicht unbedingt ein einzelnes leeres DOM-Element als Basis nutzt, sondern im gesamten Dokument inklusive <head> funktioniert, können somit etwa <meta>-Tags dynamisch gerendert und das eigentliche User-Interface mit anderen Librarys umgesetzt werden.

Wie kann ich ein Defrost-Projekt am einfachsten anlegen?

Dafür gibt es ein CLI-Tool, welches via npm installiert werden kann. Führe npm i -g @alex-schuster/defrost-cli aus, um es global zu installieren. Anschließend kann mit defrost create <Projektname> ein neues Projekt innerhalb des gegenwärtigen Ordners angelegt werden. Darauf kann anschließend aufgebaut werden.

Learnings

Für mich gab es einige wichtige Learnings während der Arbeit am Projekt. Zumal ich gerne zusammengehörige Teilprojekte (in diesem Fall CLI und Library) an einem zentralen Ort managen möchte, habe ich mich hier für den Monorepo-Ansatz entschieden. Dabei ist npm mit entsprechender Funktionalität behilflich, welche ich im Zuge des Projekts kennenlernen durfte – Stichwort „Workspaces“. Ebenso wichtig erscheint mir die weitgehende Konformität der Library mit Ansätzen aus dem „Functional Programming“-Paradigma, mit welchem ich mich neuerdings vermehrt befasst habe. Und schließlich sein auch noch mein (zwar nicht überwältigender, aber dennoch stattgefundener) Fortschritt in Bezug auf TypeScript erwähnt.

Schlusswort

Wie erwähnt handelt es sich bei Defrost um ein Open-Source-Projekt. Pull-Requests sind entsprechend ausdrücklich willkommen. Es gibt mit Version 0.0.0 – wie man vermutlich beim Verwenden der Library recht schnell feststellen wird – noch einige Features nicht, welche äußerst wünschenswert zu haben wären, wie z. B. If-Bedingung oder Loops in Templates etc. Dies könnte auch noch in naher Zukunft folgen.

The post Defrost: Eine JavaScript-Library appeared first on Mobile USTP MKL.

Schritt 0: Erfordernisse feststellen

Zunächst muss man festhalten, dass Projekte sehr unterschiedlich sein können und entsprechend individuelle Abfolgen von Instruktionen in einer CI/CD-Pipeline erforderlich bzw. erwünscht sind. Es gilt also zunächst festzustellen, was genau eigentlich automatisiert werden soll. Ein beliebtes Schema, aus welchen Phasen sich die Pipeline zusammensetzt, beinhaltet etwa die Abschnitte „Test“, „Build“ und „Deploy“. Diese Abfolge kann nach Bedarf verkürzt und erweitert werden. Der Artikel orientiert sich jedoch stark daran und liefert Beispiel-Lösungen für Problemstellungen aus den genannten drei Phasen.

Schritt 1: Runner

Zunächst gilt es zu beachten, dass bei gitlab.com – im Gegensatz zu selbst (oder von einer Organisation) gehosteten GitLab-Instanzen – bereits ohne eigenes Zutun sogenannte „Runner“ zur Verfügung stehen. Dabei handelt es sich um Software, welche für das Ausführen bzw. das Abarbeiten der Tasks innerhalb einer Pipeline verantwortlich ist. Möchte man keine Begrenzung der Dauer, wie lange Pipelines pro Monat arbeiten dürfen, so lohnt es sich ebenso wie bei selbst gehosteten Instanzen, einen eigenen Runner aufzusetzen. Hierzu muss die Runner-Software auf einem mit dem Internet verbundenen Gerät installiert und eingerichtet werden. Es kann sich hierbei um die Maschine selbst handeln, auf welche später deployt werden soll, oder aber auch um ein separates Gerät. Detaillierte Instruktionen finden sich in der offiziellen Dokumentation.

Nach erfolgreicher Installation kann ein Runner mit einem GitLab-Repository verbunden werden, sodass dieser schließlich Jobs entgegennehmen und abarbeiten kann. Unter Settings > CI/CD befindet sich ein Punkt „Runners“. Hier stehen nun entweder bereits verfügbare Runner aufgelistet, oder aber man muss die Verbindung (oder korrekt genannt „Registrierung“) erst mittels Registrierungstoken vornehmen. Per Klick auf einen Button erhält man genauere Informationen, welche Kommandos auf der Host-Maschine des Runners auszuführen sind.

Schritt 2: Variablen anlegen

Ebenfalls unter Settings > CI/CD ist der Punkt „Variables“ zu finden. Hier können allerlei Werte, wie etwa SSH-Keys, Zugangsdaten, etc. gespeichert werden, sodass diese beispielsweise nicht von regulären Repository-Besucher*innen eingesehen werden können, so wie es der Fall wäre, wenn diese fix in die Konfigurationsdatei geschrieben wären. Das ist bei öffentlichen Repositorys relevant, aber auch bei privaten Repositorys, in welchen nicht alle Mitglieder Zugriff auf derlei Daten haben sollen. Vorsicht ist geboten, zumal Pipelines lesbare Job-Logs produzieren, in welche die Mitglieder immer noch Einsicht nehmen könnten. Die Lösung hierfür besteht im „Maskieren“ von Variablen. Es können freilich auch nicht-geheime Werte in Variablen gespeichert werden, welche man schlichtweg nicht „hard-coden“ will.

Neben den selbst definierten existieren automatisch erzeugte Variablen, welche meist mit dem aktuellen Repository zusammenhängen bzw. Informationen über dieses liefern. Diesbezüglich existiert eine (meiner Meinung nach hilfreiche) Liste. In der Praxis erweist sich der Gebrauch der besagten automatisch erzeugten Variablen auch dann als nützlich, wenn der Wert über die gesamte Projektlaufzeit hinweg konstant bleibt, da der Code in der Pipeline-Konfigurationsdatei somit in anderen Projekten auf einfache Weise wiederverwendet werden kann.

Schritt 3: Pipeline-Konfiguration

Um nun Jobs zu definieren, fügt man im Root des Repositorys eine Datei mit dem Namen .gitlab-ci.yml hinzu. Zunächst werden die übergeordneten Phasen (die sogenannten „Stages“) aufgelistet. Dies könnte beispielsweise wie folgt aussehen:

stages:
  - test
  - build
  - deploy

Die vergebenen Stage-Namen können danach in den einzelnen Arbeitsschritten („Jobs“) referenziert werden, um den jeweiligen Job einer Stage zuzuordnen. Es können prinzipiell mehrere Jobs pro Stage definiert werden. Ferner kann einfach bestimmt werden, auf welche Git-Branches sich ein Job beschränkt.

beispiel_job:
  stage: test
  only:
    - build
    - deploy
    - a_feature_branch

Um nun tatsächlich Instruktionen für einen Job zu definieren, wird der Job um ein script ergänzt. Nun kann ein Runner prinzipiell so aufgesetzt worden sein, dass dieser Docker unterstützt. Dies bietet den Vorteil, eine vordefinierte Umgebung nutzen zu können, in welcher die Anweisungen abgearbeitet werden. Hier ein Beispiel für Unit-Tests in einem Node.js-/npm-Projekt; der Befehl npm install installiert hier diverse Abhängigkeiten, npm run test startet die eigentlichen Unit-Tests:

unit-tests:
  image: node:lts-alpine
  stage: test
  before_script:
    - npm install
  script:
    - npm run test
  only:
    - develop
    - main

Schlägt eine Instruktion fehl, so wird die gesamte Pipeline an der betreffenden Stelle abgebrochen. Über das UI ist es später möglich, einen Job bzw. die Pipeline neu zu starten. Liegt der Fehler außerhalb des Repositorys kann auf diese Weise ein neuer Versuch unternommen werden, die Jobs abzuarbeiten. Im Fall von fehlgeschlagenen Unit-Tests hingegen entspricht ein Abbruch der Pipeline üblicherweise dem gewünschten Verhalten. Immerhin soll meist kein fehlerhafter Code deployt werden.

Um nun z. B. eine React-App zu veröffentlichen, möchte man anschließend an den Test-Job ein für die Production-Umgebung optimiertes Skript erzeugen und selbiges im darauffolgenden Job auf den Server kopieren – beispielsweise mittels lftp. Um erzeugte Dateien in späteren Jobs verfügbar zu machen, kommen „Artifacts“ zum Einsatz. Hier wird nun der erzeugte build-Folder zu einem Artifact erklärt und auf den Production-Server kopiert. Man beachte den Einsatz von Variablen:

build-job:
  stage: build
  image: node:lts-alpine
  before_script:
    - npm install
  script:
    - npm run build
  artifacts:
    paths:
      - build
    expire_in: 1 day
  only:
    - main

deploy-job:
  stage: deploy
  image: alpine:latest
  before_script:
    - apk add openssh
    - apk add --no-cache lftp
  script:
    - mkdir /root/.ssh
    - chmod 700 /root/.ssh
    - touch /root/.ssh/known_hosts
    - chmod 600 /root/.ssh/known_hosts
    - ssh-keyscan -H $HOST >> /root/.ssh/known_hosts
    - lftp -e "mirror -e -P 4 --transfer-all --reverse -X .* --verbose build/ $HOST/; quit" -u $USER,$PASSWORD sftp://$HOST -p 22
  only:
    - main

Fazit

Auch in kleineren Projekten kann viel Zeit gespart werden, indem man sich wiederholende Arbeitsschritte, welche etwa oft nach Code-Commits anfallen, automatisiert. Zwar erscheint der Einstieg in die Thematik manchen Programmierer*innen sicherlich herausfordernd, jedoch kann eine Konfigurationsdatei, so sie einmal wie gewünscht funktioniert, beliebig weiterverwendet und adaptiert werden, sodass sich die Arbeit schon bald lohnt.

The post Einfache CI/CD-Pipelines bauen (mit GitLab CI/CD) appeared first on Mobile USTP MKL.

1. Projekt-Setup

Zunächst – wer hätte es geahnt – benötigt man npm lokal installiert. Um ein neues Paket zu initialisieren navigiert man einfach in der Kommandozeile in den gewünschten Ordner und führt den Befehl npm init aus. Es folgt ein Dialog, dessen Ziel darin besteht, eine package.json-Datei mit einigen Angaben zu erstellen. Möchte man den Dialog überspringen und mit den Standardwerten starten, so kann man stattdessen npm init -y ausführen.

„package.json“ sollte nun einen Paket-Namen, eine Versionsnummer (hier bietet sich „Semantic Versioning“ an), eine kurze Beschreibung sowie ein Haupt-Skript (der Einstiegspunkt für den geschriebenen Code) enthalten. Darüber hinaus kann eine Lizenz, wie beispielsweise MIT für Open-Source-Projekte und der Name des Autors/der Autorin angegeben werden. package.json könnte nun folgendermaßen aussehen:

{
  "name": "mein-tolles-package",
  "version": "1.0.0",
  "description": "Ein wirklich tolles Package",
  "main": "index.js",
  "author": "Manuela Musterfrau",
  "license": "MIT"
}

Es bietet sich an, den Projektordner mit einer README.md-Datei auszustatten. Diese wird dann später, ähnlich wie auf GitHub, als Info-Text in der Vorschau auf npmjs.com herangezogen. Wer außerdem ohnehin Git verwendet, kann noch ein paar weitere Angaben in package.json machen, nämlich wo das Git-Repository gehostet wird und wo etwaige Bugs verfolgt werden.

{
  "name": "mein-tolles-package",
  "version": "1.0.0",
  "description": "Ein wirklich tolles Package",
  "main": "index.js",
  "author": "Manuela Musterfrau",
  "license": "MIT",
  "repository": {
    "type": "git",
    "url": "git@github.com:manuela-musterfrau/mein-tolles-package.git"
  },
  "bugs": {
    "url": "https://github.com/manuela-musterfrau/mein-tolles-package/issues"
  }
}

Nun kann das eigentliche Coden erfolgen. Etwaige Abhängigkeiten von anderen Paketen werden wie gewohnt mit npm install <Paket-Name> <--save | --save-dev> hinzugefügt. Als Haupt-Skript haben wir index.js definiert; es kann aber prinzipiell ein beliebiger Name gewählt werden.

2. Erstveröffentlichung

Um das Package entweder einem geschlossenen Personenkreis oder der Öffentlichkeit zugänglich zu machen, benötigt man zunächst einmal einen Account bei npmjs.com. Es gibt hier verschiedene Pläne mit mehr oder weniger verfügbaren Features. So ist es aktuell mit der kostenlosen Variante nicht möglich, private Pakete hochzuladen. Wer jedoch ein Open-Source-Projekt betreibt, braucht sich darüber keine Gedanken zu machen. In unserem Beispiel begnügen wir uns mit dieser Einschränkung und veröffentlichen unseren Code.

Eine Sache, die es zu beachten gilt, ist die Verfügbarkeit des gewählten Paket-Namen. Dieser darf noch nicht von einem anderen Paket verwendet worden sein. Sollte der Name bereits vergeben sein, so kann man stattdessen im eigenen „Scope“ arbeiten. Jeder User und jede Organisation haben einen eigenen Namespace, welchem einzelne Projekte untergeordnet werden können. Der Paket-Name erhält dann ein Präfix (z. B. @manuela-musterfrau/mein-tolles-package).

Bevor das Paket nun veröffentlicht wird, müssen die Zugangsdaten zum jeweiligen npm-Account eingegeben werden, und zwar nach dem Kommando npm adduser. Nach der erfolgreichen Anmeldung kann nun mit npm publish die Veröffentlichung gestartet werden. Sucht man anschließend auf npmjs.com mittels Eingabefeld nach dem eigenen Paket, sollte es bereits in den Suchergebnissen aufscheinen und zur Installation bereitstehen (siehe Abschnitt 4). Möchte man einzelne Dateien ignorieren, so kann eine Datei .npmignore angelegt werden, welche – ähnlich wie in einer .gitignore-Datei – ein Liste mit zu ignorierenden Dateinamen und Verzeichnissen enthält. Die betreffenden Dateien werden beim Publizieren nicht in das Paket aufgenommen, bleiben aber selbstverständlich lokal und im Git-Repository erhalten.

3. Updates

Um ein Update zu publizieren, sollte zunächst die Versionsnummer erhöht werden. Je nach Update-Typ (major, minor oder patch) lautet der Kommandozeilenbefehl dafür unterschiedlich, folgt aber dem Schema npm version <Update-Typ>. Auch Pre-Release-Nummern werden unterstützt. Man braucht zum Erhöhen dieser Nummer den Befehl npm version prerelease --preid=<alpha|beta|rc>. Die in package.json enthaltene Versionsnummer wird so automatisch angepasst. Mit npm publish kann die neue Version schließlich wieder veröffentlicht werden.

4. Nutzung des Packages

Die Nutzung des Pakets durch andere erfolgt nun genau gleich wie man dies bereits von anderen Projekt-Abhängigkeiten kennt. Durch Ausführen des Befehls npm install mein-tolles-package <--save | --save-dev> erhält man die aktuelle Version. Wird eine bestimmte Version benötigt, so kann die Versionsnummer folgendermaßen an den Namen des Pakets angehängt werden: npm install mein-tolles-package@<Versionsnummer>.

The post Wie veröffentlicht man eigentlich ein eigenes npm-Package? appeared first on Mobile USTP MKL.

Einen beliebten Bereich zur Performance-Optimierung moderner Websites und Web-Apps stellen Bilder dar. In diesem Artikel sollen Strategien zur Verringerung der Ladezeit von Bildern in HTML5-Dokumenten erläutert werden. Dies umfasst konkret den Einsatz effizienter Bild-Dateiformate und das Zurverfügungstellen mehrerer alternativer Versionen desselben Bilds, sodass der Client aus dem Markup die für ihn passende Auswahl treffen und von den damit einhergehenden Daten-Einsparungen profitieren kann.

1 Einleitung

Zwar ist Bandbreite in Zeiten von 5G längst nicht mehr solch ein großes Problem wie dies noch vor einigen Jahren der Fall war, jedoch kann das Vernachlässigen der Optimierung einer Website nicht zuletzt für NutzerInnen mobiler Geräte nach wie vor zu einer schlechten User-Experience führen. So kamen in der jüngeren Vergangenheit beispielsweise neue Bild-Dateiformate für das Web auf, welche eine effizientere Codierung der Bilddaten als dies bei den bereits seit Jahrzehnten etablierten Standards der Fall ist, zum Ziel haben [1], [2]. Auch wurden Standards geschaffen, um mehrere für unterschiedliche Bildschirmgrößen geeignete Bild-Dateien gleichzeitig anzugeben und zur Verfügung zu stellen, sodass der Browser eigenständig die passende Version lädt [3]. Dies ist spätestens seit dem Erscheinen von Retina-Displays mit höherer Auflösung relevant, welche nun mit den herkömmlichen Displays koexistieren.

In diesem Artikel soll ein Überblick über moderne Ansätze zur Optimierung von Bilddateien im Web gegeben und darauf eingegangen werden wie diese möglichst effizient vom Client angefordert werden können. Es werden mehrere prominente Konzepte aus diesem Themenfeld vorgestellt.

2 Moderne Dateiformate

Noch bevor ein Bild vom Client angefordert wird, erscheint es relevant, die Bild-Datei an sich effizient zu kodieren, um auf diese Weise die Dateigröße zu verringern. In diesem Kontext sind die Formate WebP, JPEG 2000, JPEG XR und seit kurzem auch AVIF zu nennen, deren Browser-Unterstützung unterschiedlich ausfällt, wodurch eine einander ergänzende Einsatz-Strategie vorstellbar ist [2].

Um bestehendes Bildmaterial zu konvertieren, können beispielsweise Web-Apps, wie etwa Squoosh, genutzt werden. Diese bietet die Möglichkeit, die Qualität zu vergleichen und zeigt die prozentuelle Reduzierung der Dateigröße. Es werden jedoch nicht alle Formate unterstützt [4].

2.1 WebP

Das von Google im Jahr 2010 ins Leben gerufene Format WebP unterstützt sowohl verlustfreie als auch verlustbehaftete Datenkompression. Nach eigenen Angaben sind verlustfreie WebP-Dateien etwa um 26% kleiner als vergleichbare PNG-Dateien. Für die verlustbehaftete Variante ist sogar von von bis zu 34% Ersparnis im Vergleich zu gewöhnlichem JPEG die Rede [1], [5]. Von den hier behandelten Formaten erfährt WebP zurzeit die umfassendste Unterstützung durch gängige Web-Browser und kann durchaus als etabliert betrachtet werden [6].

2.2 AVIF

Ein neuer Standard ist AVIF, welcher auf der AV1-Intra-Frame-Codierung basiert. Dieser wurde in [7] bereits evaluiert und erzielt in zahlreichen die Qualität bzw. Effizienz betreffenden Parametern bessere Ergebnisse als WebP und JPEG. Der Test umfasste drei Datensätze bestehend aus natürlichen (fotografischen), synthetischen sowie Gaming-Bildern.

Das Format wird bereits standardmäßig von Google Chrome unterstützt [8] und auch in Mozilla Firefox kann dieses Feature bereits genutzt werden, wenngleich auch erst in einem experimentellen Stadium [9]. Es zeichnet sich gegenwärtig ein deutlicher Trend hin zur Annahme dieses Formats ab. Einen Überblick diesbezüglich bietet [10].

2.3 JPEG 2000 und JPEG XR

Zur Vollständigkeit seien hier auch JPEG 2000 und JPEG XR erwähnt. Die Browser-Unterstützung für diese Formate ist sehr rudimentär, weswegen sie sich vor allem als Fallback-Optionen für wenige spezifische Clients eignen [11], [12]. Neben der geringeren Dateigröße gegenüber herkömmlichem JPEG besteht bei JPEG 2000 auch die Möglichkeit, aus demselben Bit-Stream verschiedene Auflösungen und Bildausschnitte zu extrahieren. Durch eine solche progressive Übertragung ist es dem Browser möglich, die für den Anwendungsfall nützlichen Daten zu selektieren [13]. Der später entwickelte JPEG-XR-Standard sollte eine Alternative zu JPEG 2000 mit geringem Rechenaufwand beim Kodieren und Dekodieren bieten, Bilder mit hohem Dynamikumfang (HDR) unterstützen sowie Möglichkeiten zur Interaktion mit dem Bild im Web-Browser schaffen [14].

3 Die Attribute „srcset“ und
„sizes“

Die auf <img>-Elemente anwendbaren HTML-Attribute srcset und sizes bieten dem Client die Möglichkeit, aus mehreren verschiedenen Bildquellen (URLs) die gewünschte Version auszuwählen. Während srcset der Angabe einer URL-Liste und der originalen Bildgröße (oder der Pixel-Dichte, für die eine Quelle vorgesehen ist) dient, enthält sizes die nötige Information über die letztendliche Darstellungsgröße am Bildschirm und etwaige diesbezügliche Unterschiede zwischen verschiedenen Bildschirmgrößen. So kann beim Ändern der Fenstergröße bei Bedarf dynamisch eine weitere Version aus der Liste geladen werden. Wird sizes weggelassen, so geht der Browser von einer Darstellung über die gesamte Bildschirmbreite aus [15].

Ein Bild, welches stets die gesamte Breite des Bildschirms belegt, aber für Ausgabegeräte mit einfacher und doppelter Pixel-Dichte optimiert ist, könnte also wie in Code-Beispiel 1 in das HTML-Dokument eingebunden werden.

<img
  srcset="einfach.jpg 1x, doppelt.jpg 2x"
  src="einfach.jpg"
  alt="Ein Beispiel"
/>

Code-Beispiel 1: Auszeichnung mehrerer alternativer
Bild-Versionen

Zu beachten ist, dass das Attribut src auch hier verpflichtend anzuführen ist [3]. Es stellt die Kompatibilität mit älteren Browsern sicher, welche srcset nicht unterstützen. In Code-Beispiel 1 dient diesen die URL zur Version mit einfacher Pixel-Dichte als Fallback.

Nun wird ein sizes-Attribut hinzugefügt, welches im konkreten Fall die dargestellte Breite des Bilds für Viewport-Breiten von maximal 800 Pixel mit der vollen, andernfalls mit der halben Breite beziffert. Gemeint sind hier nicht etwa Hardware-Pixel, sondern das in CSS-Media-Querys verwendete Maß. Geräte mit höherer Pixel-Dichte rechnen die für sie gültige Entsprechung dieses Werts automatisch in Hardware-Pixel um. Ferner kann die originale Breite des Bilds in Pixel mit 500w bzw. 1000w angegeben werden. Dadurch kann der Browser schließlich – wiederum unter Berücksichtigung der Pixel-Dichte des Geräts auf welchem er läuft – berechnen, welche Quelle angefordert werden soll. In diesem Fall könnte das <img>-Element im Dokument wie in Code-Beispiel 2 angeführt werden.

<img
  sizes="(max-width: 800px) 100vw, 50vw"
  srcset="einfach.jpg 500w, doppelt.jpg 1000w"
  src="einfach.jpg"
  alt="Ein Beispiel"
/>

Code-Beispiel 2: Beispiel mit Angabe der Darstellungsgröße eines Bilds in Abhängigkeit von der Bildschirmgröße

4 Das Picture-Tag

Die in Code-Beispiel 1 und Code-Beispiel 2 veranschaulichte Strategie stößt an ihre Grenzen, sobald die einzelnen aufgelisteten URLs nicht nur auf verschiedene Versionen desselben Bilds mit unterschiedlicher Auflösung verweisen, sondern darüber hinaus auch abhängig von der Bildschirmgröße unterschiedlicher Bildinhalt gezeigt werden soll. Dies ist beispielsweise in einem Szenario denkbar, wenn ein sehr breites Bild in der Darstellung auf Mobiltelefonen speziell zugeschnitten werden muss, um das zentrale Bildelement in einer vorteilhaften Position zu behalten. Würde man dies in Code-Beispiel 2 so handhaben, würden Geräte mit unterschiedlicher Pixel-Dichte bei gleicher Bildschirmgröße womöglich unterschiedliche Bilder bzw. voneinander abweichende Bildkompositionen zeigen.

Um dem entgegenzuwirken, steht das <picture>-Element zur Verfügung, welches wiederum eine beliebige Anzahl an <source>-Elementen (und genau ein verpflichtendes <img>-Element als Fallback) enthält. Jedes <source>-Element erhält nun, analog zu den Beispielen im vorherigen Abschnitt, ein srcset– bzw. wo nötig auch ein sizes-Attribut. Optional kann durch das media-Attribut ein Überspringen des gesamten <source>-Elements erwirkt werden, wenn sich das darin spezifizierte Media-Query als unzutreffend erweist. Ebenso wird ein solches Element außer Acht gelassen, wenn ein type-Attribut einen vom Browser nicht unterstützten Typ (Internet Media Type) enthält [3]. Code-Beispiel 2 umgesetzt mittels <picture> und Dateien im WebP-Format könnte also lauten wie in Code-Beispiel 3.

<picture>
  <source
    type="image/webp"
    media="(max-width: 800px)"
    sizes="100vw"
    srcset="mobile-einfach.webp 500w, mobile-doppelt.webp 1000w"
  />
  <source
    type="image/webp"
    sizes="50vw"
    srcset="desktop-einfach.webp 1000w, desktop-doppelt.webp 2000w"
  />
  <img
    src="einfach.jpg"
    alt="Ein Beispiel"
  />
</picture>

Code-Beispiel 3: Ein Beispiel-Anwendungsfall für das
Picture-Tag

Unterstützt der Browser den Internet-Media-Type image/webp nicht, so werden beide <source>-Elemente ignoriert. Beträgt die Breite des Viewports maximal 800 Pixel, so kommt das erste <source>-Element in Betracht und entsprechend der Pixel-Dichte wird die passende Quelle aus dem srcset-Attribut geladen. Bei einer größeren Viewport-Breite fällt die Wahl hingegen auf das zweite <source>-Element.

5 Fazit

Im Zuge der Recherche zum vorliegenden Artikel wurde der Autor auf mehrere ihm bis dahin noch nicht geläufige Bild-Formate aufmerksam. Dies führt vor Augen, wie groß der Fortschritt hinsichtlich immer effizienterer Algorithmen für Bild-Kodierung ist. Diese können dazu beitragen, die User-Experience in modernen Web-Applikationen stetig zu verbessern und die benötigte Datenmenge gleichzeitig zu reduzieren. Der Autor ermutigt daher dazu, sich mit den damit einhergehenden Möglichkeiten vertraut zu machen und von den in diesem Artikel vorgestellten Konzepten Gebrauch zu machen. Gleichzeitig scheinen ebendiese Methoden zur Optimierung auch dazu zu verleiten, hohen Aufwand für kaum merkbare Performance-Verbesserungen zu betreiben. Geht man schließlich weiter ins Detail, so findet man immerhin auch bei den hier angeführten Beispielen noch deutliches Verbesserungspotential. Dieser Aspekt sollte stets bedacht werden, um nicht andere relevante Bereiche außen vor zu lassen.

Zukünftige Arbeiten könnten sich mit der Messung der Performance der genannten Bild-Dateiformate befassen und einen objektiven Vergleich schaffen. Dies ist keineswegs trivial, muss doch die Dateigröße der subjektiv wahrgenommenen Bildqualität gegenübergestellt werden. Immerhin bieten viele Formate mehr als nur eine Qualitätsstufe an, was zusätzliche Komplexität in einen Vergleich bringt. In der vorliegenden Arbeit hätte eine solche detaillierte Untersuchung den Rahmen gesprengt.

Literatur

[1] „A new image format for the web“, Google Developers, [Online]. Adresse: https://developers.google.com/speed/webp (besucht am 02.01.2021).

[2] „Serve images in next-gen formats“, web.dev, [Online]. Adresse: https://web.dev/uses-webp-images/ (besucht am 03.01.2021).

[3] „HTML standard: Embedded content“, Web Hypertext Application Technology Working Group (WHATWG), [Online]. Adresse: https://html.spec.whatwg.org/multipage/embedded-content.html (besucht am 03.01.2021).

[4] „Squoosh“, Squoosh, [Online]. Adresse: https://squoosh.app (besucht am 17.02.2021).

[5] J. Hu, S. Song und Y. Gong, „Comparative performance analysis of web image compression“, in 2017 10th International Congress on Image and Signal Processing, BioMedical Engineering and Informatics (CISP-BMEI), IEEE, 2017, S. 15.

[6] „WebP image format“, caniuse.com, [Online]. Adresse: https://caniuse.com/webp (besucht am 03.01.2021).

[7] N. Barman und M. G. Martini, „An evaluation of the next-generation image coding standard AVIF“, in 2020 Twelfth International Conference on Quality of Multimedia Experience (QoMEX), IEEE, 2020, S. 14. [Online]. Adresse: https://ieeexplore.ieee.org/document/9123131/ (besucht am 03.01.2021).

[8] „Feature: AVIF image decode“, Chrome Platform Status, [Online]. Adresse: https://www.chromestatus.com/feature/4905307790639104 (besucht am 03.01.2021).

[9] „Experimental features in Firefox“, MDN Web Docs, [Online]. Adresse: https://developer.mozilla.org/en-US/docs/Mozilla/Firefox/Experimental_features#AVIF_AV1_Image_File_format_support (besucht am 03.01.2021).

[10] „AVIF image format“, caniuse.com, [Online]. Adresse: https://caniuse.com/avif (besucht am 17.02.2021).

[11] „JPEG XR image format“, caniuse.com, [Online]. Adresse: https://caniuse.com/jpegxr (besucht am 03.01.2021).

[12] „JPEG 2000 image format“, caniuse.com, [Online]. Adresse: https://caniuse.com/jpeg2000 (besucht am 03.01.2021).

[13] M. W. Marcellin, M. J. Gormish, A. Bilgin und M. P. Boliek, „An overview of JPEG2000“, in Proceedings DCC 2000. Data Compression Conference, IEEE, 2000, S. 523–541. [Online]. Adresse: http://ieeexplore.ieee.org/document/838192/ (besucht am 03.01.2021).

[14] F. Dufaux, G. J. Sullivan und T. Ebrahimi, „The JPEG XR image coding standard [standards in a nutshell]“, IEEE Signal Processing Magazine, Jg. 26, Nr. 6, S. 195–204, 2009. [Online]. Adresse: http://ieeexplore.ieee.org/document/5230820/ (besucht am 03.01.2021).

[15] „HTML standard: Images“, Web Hypertext Application Technology Working Group (WHATWG), [Online]. Adresse:
https://html.spec.whatwg.org/multipage/images.html (besucht am 03.01.2021).

The post Möglichkeiten zur Optimierung von Bildern im Web im Hinblick auf Performance appeared first on Mobile USTP MKL.

Prinzipiell können mit dem Tool sogenannte “Räume” erstellt werden, welche von AdministratorInnen verwaltet werden. Gäste rufen dann einfach ein Formular wie das obige auf und bestätigen dann ihre angegebene Rufnummer mit einem per SMS empfangenen Code.

Im Administrationsbereich kann schließlich im Bedarfsfall eine Gästeliste im JSON-Format heruntergeladen werden. Hier könnten künftig noch Filteroptionen und andere Formate implementiert werden. Der angezeigte QR-Code dient zum Aushang beim Eingang zu einem Lokal und wird in der gegenwärtigen Version von einer Google-API generiert und hier ausgegeben.

Verwendete Technologien

Das Projekt wurde mit PHP (mit Composer als Package-Manager) und MySQL umgesetzt. Die Formulare werden mit Bootstrap optisch verschönert. Als SMS-API kommt Twilio zum Einsatz.

The post Yet Another COVID-19 Guest List appeared first on Mobile USTP MKL.