Optimierung der Webspeicherung durch die Cross-Origin Storage API und ihre Integration in Transformers.js

Optimierung der Web-Performance: Die Cross-Origin Storage API im Kontext von Transformers.js

In der dynamischen Landschaft der Webentwicklung und des maschinellen Lernens im Browser stehen Entwickler häufig vor der Herausforderung, große Datenmengen effizient zu verwalten. Insbesondere beim Einsatz von KI-Modellen und zugehörigen Laufzeitumgebungen, wie sie beispielsweise in der JavaScript-Bibliothek Transformers.js zum Einsatz kommen, kann die Notwendigkeit, dieselben Ressourcen mehrfach herunterzuladen und zu speichern, zu erheblichen Performance-Engpässen und erhöhtem Speicherverbrauch führen. Die vorgeschlagene Cross-Origin Storage (COS) API tritt an, diese Problematik durch eine innovative, ursprungsübergreifende Speichermöglichkeit zu adressieren.

Die Herausforderung der Cache-Isolation

Die Architektur moderner Webbrowser sieht vor, dass Cache-Ressourcen aus Sicherheits- und Datenschutzgründen streng nach ihrem Ursprung isoliert werden. Dieses Prinzip, bekannt als Cache-Partitionierung, verhindert, dass eine Website durch die Analyse von Ladezeiten Rückschlüsse auf die Browser-Historie eines Nutzers auf anderen Websites ziehen kann. Während dies ein wichtiger Schutzmechanismus ist, führt er in der Praxis dazu, dass identische Ressourcen, die von verschiedenen Websites – selbst wenn diese denselben Content Delivery Network (CDN) nutzen – angefordert werden, mehrfach heruntergeladen und im Cache des Browsers abgelegt werden müssen.

Ein prägnantes Beispiel hierfür findet sich in der Nutzung von Transformers.js. Wenn eine Webanwendung ein KI-Modell wie Xenova/whisper-tiny.en für automatische Spracherkennung verwendet, lädt Transformers.js die notwendigen Modellgewichte und WebAssembly (Wasm)-Dateien automatisch herunter und speichert sie im Browser-Cache. Besucht der Nutzer jedoch eine andere Webanwendung, die dasselbe Modell verwendet, jedoch von einem unterschiedlichen Ursprung aus bereitgestellt wird, werden diese bis zu 177 MB an Daten erneut heruntergeladen und gespeichert. Das gleiche Phänomen tritt bei gemeinsam genutzten Wasm-Laufzeitdateien auf, wie beispielsweise der 4,7 MB großen ort-wasm-simd-threaded.asyncify.wasm-Datei, die von der zugrunde liegenden ONNX Runtime-Bibliothek stammt. Obwohl diese Datei von vielen KI-Modellen benötigt wird, führt die Ursprungsisolation des Caches zu redundanten Downloads und einer ineffizienten Speichernutzung.

Die Ursache dieser Redundanz liegt in der Art und Weise, wie Browser Cache-Einträge identifizieren. Neben der Ressourcen-URL wird ein "Network Isolation Key" verwendet, der sich aus der Top-Level-Site und der aktuellen Frame-Site zusammensetzt. Stimmt dieser Schlüssel nicht überein, kommt es zu keinem Cache-Treffer, auch wenn die Ressourcen-URL identisch ist.

Die Cross-Origin Storage API als Lösungsansatz

Die vorgeschlagene Cross-Origin Storage (COS) API zielt darauf ab, diese Ineffizienz zu beheben. Sie führt eine dedizierte navigator.crossOriginStorage-Schnittstelle ein, die es Webanwendungen ermöglicht, große Dateien ursprungsübergreifend zu speichern und abzurufen. Der entscheidende Unterschied zu herkömmlichen Caching-Mechanismen besteht darin, dass COS Dateien nicht über ihre URL oder ihren Ursprung, sondern über einen kryptografischen Hash (z.B. SHA-256) identifiziert.

Dies bedeutet, dass eine Wasm-Laufzeitdatei, die einmal von einer Anwendung auf https://googlechrome.github.io heruntergeladen und unter ihrem Hash in COS gespeichert wurde, von einer anderen Anwendung auf https://rawcdn.rawgit.net sofort gefunden und verwendet werden kann, ohne dass ein erneuter Download erforderlich ist. Der Prozess ist wie folgt konzipiert:

Ein Entwickler fordert über navigator.crossOriginStorage.requestFileHandle(hash) einen Dateihandle für einen bestimmten Hash an. - Ist die Datei in COS vorhanden, wird ein Dateihandle zurückgegeben, über den die Datei als Blob abgerufen werden kann. - Ist die Datei nicht vorhanden, wird ein Fehler ausgelöst. Die Anwendung lädt die Datei dann über das Netzwerk herunter und speichert sie anschließend mit navigator.crossOriginStorage.requestFileHandle(hash, { create: true, origins: '*' }) in COS. Die origins-Option steuert dabei die Sichtbarkeit der Datei.

Kontrolle und Integrität

Die COS API bietet präzise Kontrollmechanismen für die Sichtbarkeit gespeicherter Dateien:

• origins: '*': Macht eine Datei global verfügbar. Dies ist ideal für weit verbreitete Ressourcen wie KI-Modelle oder Wasm-Laufzeiten.
• Spezifische Ursprungslisten: Beschränkt den Zugriff auf eine definierte Liste von Websites. Dies eignet sich für proprietäre Ressourcen, die nur innerhalb eines Unternehmens geteilt werden sollen.
• Keine origins-Angabe: Macht die Datei nur für Same-Site-Ursprünge verfügbar, was eine Standardeinstellung für Ressourcen innerhalb einer Organisation sein kann.

Ein wichtiger Aspekt ist, dass die Sichtbarkeit einer Datei nur erweitert, niemals aber eingeschränkt werden kann. Eine einmal global verfügbare Datei kann nicht durch einen späteren Speichervorgang in ihrer Verfügbarkeit eingeschränkt werden. Dies verhindert Missbrauch.

Die Integrität der Daten wird durch die Hash-Verifizierung beim Schreiben in COS gewährleistet. Stimmen die geschriebenen Daten nicht mit dem deklarierten Hash überein, schlägt der Schreibvorgang fehl. Dies bietet eine automatische Integritätsprüfung, die über die Möglichkeiten heutiger CDN-Downloads hinausgeht.

Datenschutzaspekte

Die ursprungsübergreifende Natur von COS wirft naturgemäß Fragen zum Datenschutz auf. Könnte ein Angreifer durch das Abfragen der Existenz bestimmter Hashes Rückschlüsse auf die Browser-Historie eines Nutzers ziehen? Die COS API begegnet dem mit zwei Mechanismen:

• Bewusste Nutzung von origins: Entwickler werden ermutigt, proprietäre oder sensible Ressourcen nicht global mit origins: '*' zu speichern.
• Availability Gating: Selbst für global deklarierte Dateien kann der Browser die Bestätigung der Dateipräsenz unterdrücken, wenn die Datei nicht über eine ausreichende Anzahl unterschiedlicher Ursprünge hinweg angetroffen wurde. Eine Fehlermeldung könnte dann bedeuten, dass die Datei nicht gespeichert ist, oder dass der Browser die Information aus Datenschutzgründen zurückhält. Anwendungen sollten in beiden Fällen auf das Netzwerk zurückgreifen.

Implementierung in Transformers.js

Transformers.js hat bereits einen experimentellen COS-Cache-Backend implementiert, der durch das Setzen von env.experimental_useCrossOriginStorage = true aktiviert werden kann. Dies ermöglicht es der Bibliothek, die SHA-256-Hashes von Modell- und Wasm-Dateien zu nutzen, um diese in COS zu speichern oder daraus abzurufen. Der Vorteil ist, dass große Ressourcen wie Xenova/whisper-tiny.en, Xenova/distilbert-base-uncased-finetuned-sst-2-english und ort-wasm-simd-threaded.asyncify.wasm nur einmal über das Netzwerk geladen werden müssen, unabhängig davon, wie viele unterschiedliche Ursprünge sie anfordern.

Es ist wichtig zu beachten, dass der experimental_-Präfix darauf hinweist, dass die API noch nicht final ist und sich zukünftige Implementierungen ändern können.

Praktische Erprobung

Obwohl die COS API noch nicht nativ in Browsern implementiert ist, können Entwickler sie bereits heute testen. Eine spezielle Browser-Erweiterung, die einen Polyfill für navigator.crossOriginStorage injiziert, ermöglicht die vollständige Funktionsprüfung. Nach der Installation der Erweiterung und Aktivierung der experimentellen Funktion in Transformers.js können Entwickler beobachten, wie redundante Downloads im Netzwerk-Tab verschwinden und stattdessen Ressourcen aus dem COS-Cache abgerufen werden. Die Erweiterung bietet zudem eine Benutzeroberfläche zur Inspektion der im COS gespeicherten Ressourcen.

Neben Transformers.js experimentieren auch andere Projekte wie WebLLM und wllama mit dieser vielversprechenden API. Die Community ist aufgerufen, Feedback zu geben und die Entwicklung dieser API aktiv mitzugestalten.

Fazit

Die Cross-Origin Storage API stellt einen bedeutenden Schritt zur Verbesserung der Web-Performance und Effizienz im Umgang mit großen Web-Ressourcen dar, insbesondere im Kontext von KI-Anwendungen im Browser. Durch die Ermöglichung einer ursprungsübergreifenden, hash-basierten Speicherung kann sie die Ladezeiten erheblich reduzieren und den Speicherverbrauch minimieren, während gleichzeitig wichtige Sicherheits- und Datenschutzaspekte berücksichtigt werden. Für Unternehmen im B2B-Bereich, die auf performante und ressourceneffiziente Webanwendungen angewiesen sind, bietet die COS API das Potenzial für optimierte Nutzererfahrungen und geringere Betriebskosten.

Bibliographie

- Hugging Face Blog: Experimenting with the proposed Cross-Origin Storage API in Transformers.js. (Veröffentlicht: 23. Juni 2026). - GitHub: WICG/cross-origin-storage - Explainer for the Cross-Origin Storage (COS) API. (Veröffentlicht: 6. Dezember 2024). - GitHub: huggingface/transformers.js Pull Request #1549: feat: experimental Cross-Origin Storage cache backend by nico-martin. (Erstellt: 28. Februar 2026). - GitHub: huggingface/transformers.js Issue #1677: Why doesn't HuggingFace create a browser extension for transformers js? (Erstellt: 4. Mai 2026). - GitHub: WICG/cross-origin-storage README.md. - Google Chrome Blog: Gaining security and privacy by partitioning the cache. - MDN Web Docs: Cache API, FileSystemFileHandle, File System API/Origin private file system. - Chrome Web Store: Cross-Origin Storage extension. - GitHub: web-ai-community/cross-origin-storage-extension. - Chrome Status: Cross-Origin Storage API.