Client-seitige Bildkomprimierung: Was wirklich im Browser passiert

Die meisten Menschen, die einen Browser-basierten Bildkompressor verwenden, sehen es als Bequemlichkeit - kein Install, schnelles Drag-and-Drop. Was sie nicht bemerken, ist, dass das Tool oft überhaupt nicht mit einem Server kommuniziert. Das Bild bleibt auf ihrem Gerät. Für alles Private - medizinische Scans, Rechtsdokumente mit beigefügten Fotos, Produktfotos vor dem Launch - macht dieser Unterschied viel aus.

Dieser Artikel erklärt, was der Browser tatsächlich tut, wenn er ein Bild komprimiert, wo die Grenzen liegen und wann man wirklich einen Server in der Schleife braucht.

Die grundlegende Pipeline: Dekodieren, Zeichnen, Neu-Kodieren

Ob ein Tool die einfache Canvas-API oder das neuere WebCodecs verwendet, die grundlegende Pipeline ist dieselbe:

1. Datei lesen - die File-API gibt JavaScript einen Byte-Stream, ohne etwas an einen Server zu senden.
2. Dekodieren - der Browser parst das komprimierte Bild in rohe Pixeldaten (RGBA, 4 Bytes pro Pixel).
3. Optional skalieren - auf eine niedrigere Auflösung auf ein Canvas zeichnen.
4. Neu kodieren - die Pixel als JPEG, WebP oder AVIF mit einer Ziel-Qualitätseinstellung zurückschreiben.
5. Einen Blob zuruckgeben - das Ergebnis ist ein neuer Blob, den die Seite zum Download anbieten oder in einer Vorschau zeigen kann.

Schritt 2 ist, wo der Rohspeicherbedarf zuschlägt. Ein 20-Megapixel-DSLR-Foto in RGBA dekodiert benötigt ungefähr 20.000.000 x 4 = 80 MB RAM, bevor irgendeine Verarbeitung stattgefunden hat. Die meisten modernen Telefone und Laptops kommen damit zurecht, aber das ist der Grund, warum das Komprimieren großer Batches parallel bei Geräten mit wenig Speicher zu einem Tab-Absturz führen kann.

Canvas: der Arbeitspferd-Ansatz

Der canvas-Ansatz gibt es seit den frühen 2010er Jahren und funktioniert in jedem Browser aus dem letzten Jahrzehnt:

async function compressJpeg(file, quality = 0.8) {
  const bitmap = await createImageBitmap(file);
  const canvas = new OffscreenCanvas(bitmap.width, bitmap.height);
  const ctx = canvas.getContext('2d');
  ctx.drawImage(bitmap, 0, 0);
  return canvas.convertToBlob({ type: 'image/jpeg', quality });
}

Der quality-Parameter läuft von 0 bis 1. Bei 0.8 landet man typischerweise bei 60-70% kleiner als das Original-JPEG, während die sichtbare Qualität für die Web-Nutzung akzeptabel bleibt. Bei 0.6 kann man 80% Reduzierung erreichen, sieht aber Blockartefakte bei glatten Verläufen.

Es lohnt sich zu wissen: quality funktioniert nicht bei allen Ausgabetypen gleich. Für JPEG und WebP steuert es die Quantisierungstabellen - es ist ein echter Qualitätsregler. Für PNG wird der Parameter vollständig ignoriert.

Warum PNG-Komprimierung anders ist

PNG ist verlustfrei. Es gibt keine Qualitätsregler, weil keine Daten weggeworfen werden. Die Dateigröße wird durch den Deflate-Komprimierungsgrad (wie stark der Encoder versucht) und vor allem durch den Bildinhalt selbst bestimmt. Einfarbige Bereiche komprimieren schon; fotografisches Rauschen komprimiert schlecht.

Wenn man ein PNG verkleinern möchte, sind die echten Optionen:

• Farbtiefe reduzieren - wenn das Bild nur 256 Farben verwendet, als 8-Bit-Palette-PNG statt 24-Bit kodieren. Tools wie pngquant machen das gut, erfordern aber entweder eine native Binärdatei oder einen WebAssembly-Build, was zusätzliche Komplexität bringt.
• Zu WebP konvertieren - für Fotos, die als PNG gespeichert sind, erzeugt der Wechsel zu WebP mit quality: 0.85 dramatisch kleinere Dateien bei visuell ähnlicher Qualität. Das Bildformat-Konverter -Tool ausprobieren, wenn das die Situation ist.
• Skalieren - Abmessungen reduzieren ist das stumpfste, aber effektivste Werkzeug gegen große PNGs.

OffscreenCanvas und Worker

Die OffscreenCanvas-API ermöglicht es, alle Canvas-Arbeiten vom Haupt-Thread zu verlagern, was bedeutet, dass die Benutzeroberfläche während der Komprimierung großer Dateien nicht einfriert. Die Unterstützung ist in Chrome, Edge und Firefox solide. Safari hat es in Version 17 (Ende 2023) hinzugefügt, sodass es Stand 2026 weitgehend sicher zu verwenden ist. Das Muster besteht darin, einen Web Worker zu starten, das Canvas dorthin zu übertragen und den resultierenden Blob zurückzuposten.

WebCodecs: mehr Kontrolle, mehr Komplexität

Die WebCodecs-API (in Chrome 94+, Edge 94+, Firefox 130+ verfügbar, aber Stand Anfang 2026 noch nicht in Safari) bietet Frame-level-Zugriff auf Codecs. Für Komprimierungszwecke ist das hauptsächlich bei AVIF relevant: der Canvas-convertToBlob-Pfad für AVIF ist langsamer und weniger konfigurierbar als das direkte Ansteuern eines AV1VideoEncoder über WebCodecs.

Wenn man viele Bilder im Browser schnell zu AVIF komprimieren muss, landet man bei WebCodecs. Der Code ist erheblich komplexer - man verwaltet Encoder-Konfiguration, Chunk-Callbacks und Stream-Assemblierung selbst.

JPEG vs. WebP vs. AVIF: die praktischen Abwägungen

Format	Komprimierung	Browser-Unterstützung	Kodierungsgeschwindigkeit im Browser	Verlustbehaftet/verlustfrei
JPEG	Gut	Universal	Schnell (nativer Codec)	Nur verlustbehaftet
WebP	25-35% besser als JPEG	Alle modernen Browser	Schnell (nativer Codec)	Beides
AVIF	50% besser als JPEG	Alle modernen (kein Safari auf altem iOS)	Langsam via Canvas, schneller via WebCodecs	Beides

Die Canvas-API leitet JPEG- und WebP-Kodierung durch den nativen Codec des Browsers, der auf den meisten Geräten hardware-beschleunigt ist. AVIF durch convertToBlob ist oft Software-only und kann auf einem mittleren Telefon mehrere Sekunden für ein großes Bild dauern.

Wenn man einen Kompressor baut und gute Ergebnisse mit breiter Kompatibilität will, ist WebP mit quality: 0.85 der pragmatische Standard 2026.

Die Qualitäts-Dateigröße-Beziehung ist nicht linear

Von quality: 1.0 auf quality: 0.9 zu gehen, reduziert die Dateigröße oft um 30-40% mit kaum wahrnehmbarer Änderung. Von 0.5 auf 0.4 zu gehen, spart möglicherweise nur weitere 5%, während offensichtliche Artefakte entstehen. Der nützliche Bereich für die meisten Web-Inhalte ist 0.7-0.85.

Der Grund ist, dass JPEG/WebP-Quantisierung zuerst hochfrequente Details wegwirft - feine Textur, Rauschen, scharfe Kanten. Unterhalb einer bestimmten Schwelle beginnt man, auch mittlere Frequenzinformationen zu verlieren, was der Ursprung von Blockartefakten in glatten Bereichen wie Himmel oder Haut ist.

Eine praktische Strategie: eine Zieldateigröße anstreben (z. B. unter 200 KB für ein Hero-Bild) und dann den Qualitätsparameter binärsuchen, bis man dort landet. Einige Tools machen das automatisch. Unser Bildkompressor lässt die Qualität manuell anpassen und zeigt Vorher/Nachher-Größen in Echtzeit.

Speicherkosten im Maßstab

Für ein einzelnes Bild, selbst ein 50-MP-Kamera-RAW, ist man in der Regel in Ordnung. Das Problem ist die Batch-Komprimierung. Wenn ein Benutzer 30 Fotos von einer kürzlichen Reise ablegt - jedes 10 MB auf der Festplatte, 60+ MB im RAM dekodiert - sind das mehrere Gigabyte Arbeitsspeicher, wenn man sie alle gleichzeitig dekodiert.

Das richtige Muster ist, ein nach dem anderen zu komprimieren (oder zwei, wenn man eine Mehrkern-CPU auslasten will) und jede Bitmap freizugeben, bevor man zur nächsten geht. bitmap.close() auf einem ImageBitmap gibt diesen Speicher sofort zurück. Das Übergehen ist die häufigste Ursache für Out-of-Memory-Abstürze in Browser-seitigen Bild-Tools.

Wann server-seitige Komprimierung noch gewinnt

Client-seitige Komprimierung deckt viel ab, aber es gibt echte Fälle, in denen sie zu kurz kommt:

Batch-Verarbeitung im Produktionsmaßstab. Das Asset-Pipeline einer Marketing-Abteilung für Hunderte von Bildern durch einen Browser-Tab laufen zu lassen, funktioniert, ist aber unzuverlässig. Eine ordentliche ImageMagick- oder libvips-Pipeline auf einem Server ist schneller, konfigurierbarer und hängt nicht davon ab, dass jemand einen Tab geöffnet hält.

AVIF auf älteren oder schwachen Telefonen. Der Encoder ist in Software langsam. Wenn das Publikum ältere Android-Geräte umfasst, wird die Browser-seitige AVIF-Generierung zeitlich überschritten oder eine unbrauchbare UX erzeugen. Server-seitige AVIF-Kodierung via libavif ist um Größenordnungen schneller.

Erweiterte Optimierungen. Dinge wie die Abstimmung von Chroma-Subsampling, mozjpeg-spezifische Quantisierungstabellen oder pngquant-Palettenreduzierung erfordern entweder eine kompilierte Binärdatei oder einen WebAssembly-Port. Einige Tools (insbesondere Squoosh - Googles Browser-basierter Kompressor, der eine bedeutende frühe Demonstration dieser Technik war) liefern WASM-Builds von Codecs genau aus diesem Grund. Es funktioniert, aber die WASM-Bundles sind groß (1-5 MB) und die Ladezeit ist merklich.

ICC-Profil-Handhabung. Einige Kameras betten Wide-Gamut-ICC-Profile ein. Die Canvas-API entfernt diese beim Neu-Kodieren, was zu Farbverschiebungen führen kann. Wenn Farbgenauigkeit wichtig ist - Druck, medizinische Bildgebung - sind server-seitige Tools, die ICC-Daten bewahren, sicherer.

Was das für den Datenschutz bedeutet

Wenn ein Tool ein Bild im Browser komprimiert, verlassen die rohen Pixeldaten das Gerät nie. Das Einzige, was ein Netzwerk überschreitet, ist die komprimierte Ausgabedatei, wenn man auf Download klickt - und das geht direkt in das lokale Dateisystem, nicht zu einem Server.

Das ist relevant, wenn das Bild etwas Sensibles enthält: ein Foto eines Dokuments, einen Screenshot eines privaten Gesprächs, Produktmockups unter NDA, medizinische Bildgebung. Die Frage, die man jedem Bild-Tool stellen sollte, ist: Gehen die Bilddaten an einen Server? Bei Canvas-basierten Client-seitigen Tools ist die Antwort strukturell nein. Bei Upload-basierten Tools vertraut man ihrer Datenschutzerklärung, ihrer Sicherheitslage und wer auch immer Zugriff auf ihren Storage-Bucket hat.

Man kann die client-seitige Verarbeitung selbst verifizieren: DevTools öffnen, den Network-Tab aufrufen und ein Bild komprimieren. Wenn keine ausgehenden Anfragen zu sehen sind, die Bilddaten übertragen, ist die Verarbeitung lokal.

Kurzreferenz: welche API verwenden

• Einfaches Skalieren + JPEG/WebP-Ausgabe: createImageBitmap + OffscreenCanvas.convertToBlob in einem Worker. Funktioniert überall, schnell.
• PNG-Palettenreduzierung: Es wird ein WASM-Port von pngquant oder ähnlichem benötigt - canvas allein schafft das nicht.
• AVIF mit akzeptabler Geschwindigkeit: WebCodecs VideoEncoder auf Chromium; auf Canvas auf Safari zurückfallen.
• Metadaten bewahren (EXIF, ICC): Mit einer Bibliothek wie piexifjs lesen, nach dem Neu-Kodieren reininjizieren. Canvas entfernt alles.

Wenn man mit den tatsächlichen Qualitätsabwägungen experimentieren möchte, ohne Code zu schreiben, unseren Bildkompressor ausprobieren oder zuerst mit dem Bildskalierungs-Tool skalieren - beide laufen vollständig im Browser.

Der Browser ist zu einer leistungsfähigen Bildverarbeitungs-Laufzeitumgebung geworden. Es ist kein ImageMagick, aber für den häufigen Fall - dieses Foto für das Web verkleinern, ohne es irgendwohin zu senden - ist es mehr als ausreichend.