ToolBox Image — Warum wir ToolBox Image gebaut haben, um vollständig in Ihrem Browser zu laufen

Die meisten kostenlosen Online-Bildtools funktionieren auf die gleiche Weise: Sie laden eine Datei auf deren Server hoch, der Server verarbeitet sie, und Sie laden das Ergebnis herunter. Dieses Modell ist einfach zu erstellen, hat aber versteckte Kosten — Ihre Privatsphäre, deren Serverrechnungen und Grenzen bei Dateigröße und Durchsatz.

ToolBox Image verfolgt einen anderen Ansatz. Die gesamte Anwendung — Dekodierung, Kodierung, Komprimierung, Größenänderung, Formatkonvertierung — läuft in Ihrem Browser. Es gibt keinen Server zum Hochladen. Ihre Bilder verlassen nie Ihr Gerät. Diese Architektur war eine bewusste Entscheidung und hat jede Entscheidung beeinflusst, die wir über das Produkt getroffen haben.

Warum der Browser-First-Ansatz?

Die naheliegende Alternative ist eine traditionelle Server-Architektur. Sie laden ein Bild hoch, der Server verarbeitet es mit einem Tool wie ImageMagick oder Sharp und sendet das Ergebnis zurück. Das funktioniert, schafft aber eine Reihe von Problemen, die schwer zu lösen sind:

• Datenschutz. Benutzer müssen darauf vertrauen, dass Sie ihre Bilder nicht speichern, analysieren oder preisgeben. Für sensible Dokumente — medizinische Bilder, Design-Mockups, persönliche Fotos — ist dieses Vertrauen schwer zu gewinnen.
• Kosten. Jede Komprimierung läuft auf Ihrer Infrastruktur. Je erfolgreicher Sie sind, desto mehr zahlen Sie. Dies erzeugt Druck, Dateigrößen zu begrenzen, Warteschlangen hinzuzufügen oder kostenpflichtige Stufen einzuführen.
• Latenz. Das Hochladen einer 100 MB-Datei über eine langsame Verbindung dauert Minuten, bevor die Verarbeitung überhaupt beginnt. Für Benutzer in Regionen mit schlechter Konnektivität ist das Tool praktisch unbrauchbar.
• Skalierung. Ein einzelner Server kann Dutzende gleichzeitiger Komprimierungen bewältigen. Aber was ist mit Tausenden? Sie benötigen Auto-Scaling-Gruppen, Load-Balancer, CDN-Upload-Endpunkte — all das erhöht Komplexität und Kosten.

Das Browser-First-Modell löst all dies auf einmal. Die Verarbeitung ist kostenlos (CPU-Zyklen des Benutzers), privat (keine Daten verlassen das Gerät) und unendlich skalierbar (jeder Benutzer bringt seine eigene Hardware mit).

Wie es funktioniert: WebAssembly und Web Workers

Vor zehn Jahren war es unmöglich, Bildcodecs im Browser auszuführen. Heute ermöglicht uns WebAssembly, C- und Rust-Bibliotheken direkt in ein Format zu kompilieren, das der Browser mit nahezu nativer Geschwindigkeit ausführen kann. Wir kompilieren Mozillas mozJPEG, Googles libwebp und den AVIF-Encoder libaom — alle in C geschrieben — zu WebAssembly. Der Browser führt sie so effizient aus, als wären sie nativ installiert.

Aber die Single-Thread-Kodierung ist für große Stapel langsam. Hier kommen Web Workers ins Spiel. Jeder Worker läuft auf einem separaten CPU-Kern, und wir erstellen so viele Worker, wie das Gerät Kerne hat. Auf einem modernen Laptop mit 8 Kernen bedeutet das 8 gleichzeitig komprimierte Bilder. Ein Stapel von 200 Fotos, der auf einem einzelnen Thread Minuten dauern würde, ist in Sekunden erledigt.

Was wir aufgegeben haben

Der Browser-First-Ansatz ist nicht kostenlos. Der bedeutendste Kompromiss ist der Speicher. Der Browser-Tab hat Zugriff auf den RAM des Geräts, aber ein einzelner Tab, der abstürzt, weil ein Bild den verfügbaren Speicher überschritten hat, ist eine schlechte Erfahrung. Wir begrenzen einzelne Dateien auf 100 MB und Stapelgrößen auf 200 Dateien, um innerhalb sicherer Grenzen zu bleiben.

Wir haben auch Server-seitige Funktionen wie persistenten Speicher, E-Mail-Zustellung und Analysen aufgegeben. Es gibt keine Datenbank mit komprimierten Bildern, keinen E-Mail-Newsletter, keine Aufzeichnung, welche Formate Benutzer bevorzugen. Dies ist philosophisch konsistent mit unserer Datenschutzhaltung, bedeutet aber, dass wir keine Funktionen wie "letzte Komprimierungen" oder "gespeicherte Einstellungen zwischen Sitzungen" anbieten können.

Was als nächstes kommt

Der Browser wird zu einer legitimen Laufzeitumgebung für leistungsempfindliche Anwendungen. Da WebAssembly Garbage Collection, Threading und SIMD-Unterstützung erhält, kann mehr des Anwendungsstapels clientseitig verlagert werden. Wir erkunden WebGPU für noch schnellere Pixelverarbeitung und die File System Access API für nahtlose Ordnerintegration.

Vorerst ist der Kompressor live und verarbeitet täglich Tausende von Bildern — alle bleiben genau dort, wo sie hingehören.