WebP: Komprimierungsformat für Webseiten

 (purplesyringa.moe)
1 Punkte von GN⁺ 2024-09-08 | 1 Kommentare | Auf WhatsApp teilen

WebP: Komprimierungsformat für Webseiten

Hürden

  • HTML wird minimiert, um die Zugänglichkeit der Website zu erhöhen und die Ladezeit der Seite zu verkürzen
  • GitHub Pages unterstützt keine Brotli-Komprimierung
  • gzip wird standardmäßig verwendet, aber Brotli bietet eine bessere Kompressionsrate

Einfache Idee

  • Da GitHub Pages Brotli nicht unterstützt, wird erwogen, im Client JavaScript zum Dekomprimieren zu verwenden
  • Mit brotli-dec-wasm und tiny-brotli-dec-wasm ist Brotli-Dekomprimierung möglich

Zweiter Versuch

  • Die Compression Streams API unterstützt gzip- und DEFLATE-Formate, aber kein Brotli
  • Die Zopfli-Bibliothek kann gzip effizienter komprimieren, bleibt aber dennoch hinter Brotli zurück

Das Gesetz brechen

  • Es wird erwogen, Daten mithilfe von Bildkomprimierung zu komprimieren
  • PNG und GIF verwenden den DEFLATE-Algorithmus, aber WebP bietet eine bessere Leistung

Vorteile von WebP

  • WebP verwendet eine ähnliche prädiktive Transformation wie PNG, nutzt aber statt DEFLATE ein von Google entwickeltes Verfahren
  • Durch verschiedene Huffman-Bäume wird eine effizientere Komprimierung erreicht
  • Ein Farb-Cache speichert wiederkehrende Farben effizient

Experiment

  • Es wurde versucht, HTML-Dateien mit dem webp-Crate zu komprimieren
  • Erste Ergebnisse zeigten eine im Vergleich zu gzip halb so große Dateigröße

Zusätzliche Optimierung

  • Durch Anpassen der Bildgröße wird eine bessere Kompressionsleistung erzielt
  • Es werden verschiedene Komprimierungsmethoden ausprobiert, um das beste Ergebnis zu finden

Benchmarks

  • gzip, bzip2, Brotli und WebP werden für verschiedene Dateiformate verglichen
  • WebP zeigt in den meisten Fällen eine bessere Leistung als gzip
  • Gegenüber Brotli ist die Leistung schwächer, bietet aber dennoch eine sinnvolle Verbesserung

Dekodierung in JavaScript

  • Es wird erklärt, wie sich WebP mit der Canvas API dekodieren lässt
  • Mit WebGL werden Techniken zum Schutz vor Fingerprinting umgangen

Letzte Anpassungen

  • Um Flackern beim Laden der Seite zu verringern, bleiben Styling und der obere Bereich per gzip erhalten
  • Eine Behelfslösung zum Beibehalten der Scroll-Position wird vorgeschlagen

Einbettung

  • WebP wird direkt in JavaScript eingebettet, um die Latenz zu verringern
  • Mithilfe von base64-Daten-URLs wird die Größe minimiert

Beispiele

  • Es werden Beispiele realer Webseiten gezeigt, die mit WebP komprimiert wurden
  • Nach der Komprimierung lässt sich eine verringerte Seitengröße feststellen

Zusammenfassung von GN⁺

  • Dieser Artikel untersucht verschiedene Methoden zur Verbesserung der Kompressionsleistung von Webseiten
  • Das WebP-Format liefert bessere Ergebnisse als gzip, bleibt aber hinter Brotli zurück
  • Es wird erklärt, wie sich WebP auf der Client-Seite mit JavaScript und WebGL dekodieren lässt
  • Es werden verschiedene Optimierungstechniken vorgeschlagen, um die Ladezeit der Seite zu verkürzen
  • Andere Projekte mit ähnlicher Funktionalität sind unter anderem Brotli und Zopfli

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2024-09-08
Hacker-News-Kommentare

  • Obwohl die Größe eines langen Beitrags von 92 KiB auf 37 KiB reduziert wurde, stieg die tatsächliche Ladezeit nur um 0,001 %

    • Durch die Dekomprimierungszeit könnte sich die User Experience eher verschlechtern

  • Ich kann nicht nachvollziehen, warum readPixels nicht unter den Schutz vor Fingerprinting fällt

    • Es gibt eine Technik, bei der das Styling am Seitenanfang erhalten bleibt und nur der Inhalt unterhalb des Viewports als WebP komprimiert wird
    • Wenn man in LibreWolf WebGL deaktiviert, wird die Seite nicht abgeschnitten

  • zstd wurde in Chrome eingeführt und sollte auch in Safari eingesetzt werden

  • Das Entfernen von Google Fonts kann die Ladezeit der Seite verbessern

    • Da sie von einem entfernten Server geladen werden, ist ein zusätzlicher Handshake erforderlich

  • Beim Blick in den Sourcecode fiel auf, dass in der Doctype-Deklaration ein Leerzeichen fehlt

    • Derzeit steht dort <!doctypehtml>, das sollte zu <!doctype html> korrigiert werden

  • HTML-Seiten lassen sich als selbstextrahierende ZIP-Datei verpacken

    • Es ist möglich, eine Datei zu erzeugen, die gleichzeitig mit HTML, ZIP und PNG kompatibel ist, einschließlich eines PNG-Bildes
    • So kann zum Beispiel auf einer HTML-Seite ein PNG-Bild angezeigt werden

  • Im Browser von Sailfish OS wird die Seite fehlerhaft dargestellt

    • Nach Absätzen gibt es große leere Bereiche
    • Der Overhead von gzip- und Brotli-Komprimierung für HTML ist im Vergleich zur Menge an JS/Bildern/Videos auf heutigen Websites vernachlässigbar

  • Obwohl Brotli ein großes Dictionary hat, zeigt es eine ähnliche Leistung wie gzip

    • Ich frage mich, ob der Komprimierungsalgorithmus schlechter ist oder ob die Bedeutung des Dictionarys geringer ist als gedacht

  • Der Grund, warum Brotli nicht in der CompressionStream API verwendet wird, ist offenbar, dass es die Browsergröße deutlich erhöht

    • Das größere Komprimierungs-Dictionary könnte darauf zurückzuführen sein, dass es vorab berechnete, besonders effiziente Repräsentationen enthält