In Chrome 130 wurden Änderungen an der Shared Storage API vorgenommen, um die Verwendung von Worklet-Scripts mit unterschiedlichen Ursprüngen mit createWorklet() und addModule() zu ermöglichen. Außerdem führen wir in Chrome 132 Updates für die Select URL API mit Shared Storage ein, die die Unterstützung gespeicherter Abfragen umfasst.
Cross-Origin-Worklets mit der Shared Storage API in Chrome 130
Wir haben in Chrome 130 Änderungen an der Shared Storage API vorgenommen, um Ihnen mehr Flexibilität bei der Arbeit mit plattformübergreifenden Worklet-Scripts zu bieten.
Änderungen
Wir haben die Same-Origin-Einschränkung für addModule() aufgehoben. Sie können jetzt Worklet-Scripts von jeder Quelle laden. Mit plattformübergreifenden Worklet-Scripts können wichtige Anwendungsfälle wie das Hosten von Worklet-Scripts in CDNs realisiert werden. Wenn das Worklet-Script eine andere Quelle als der aufrufende Browserkontext hat, wird die Quelle des aufrufenden Kontexts als Ursprung der Datenpartition für den Zugriff auf den freigegebenen Speicher verwendet.
Um dem neuen Verhalten von addModule() zu entsprechen und mögliche Verwirrung zu vermeiden, wurde dem createWorklet()-Aufruf die Property dataOrigin hinzugefügt. So können Daten in einer freigegebenen Speicherdatenpartition gelesen und geschrieben werden, die sich vom aufrufenden Browserkontext unterscheidet. So haben Sie eine genauere Kontrolle darüber, auf den gemeinsamen Speicher welcher Quelle jedes Worklet zugreift, auch wenn Sie plattformübergreifende Worklet-Scripts verwenden.
Wie hat sich das verändert?
Ab Chrome 125 können mit einem plattformübergreifenden Script eines Drittanbieters auf einer Seite plattformübergreifende Worklets erstellt werden, ohne dass plattformübergreifende iframes erforderlich sind. Dazu wird createWorklet(url) aufgerufen. Bisher wurde bei createWorklet(url) unabhängig vom Aufrufkontext die URL der Scriptdatei (url) als Ursprung der Datenpartition verwendet.
In Chrome 130 wird für createWorklet() der Aufrufkontext als Standardursprung der Datenpartition verwendet, um dem neuen Verhalten von addModule() zu entsprechen. Damit Sie weiterhin die Script-URL-Quelle als Datenpartitionsquelle verwenden können, wird die neue Property dataOrigin eingeführt, mit der Sie den Ursprung der Datenpartition explizit festlegen können.
Für die neue Property dataOrigin ist "script-origin" zulässig. Damit wird der Ursprung der Datenpartition als Ursprung des Scripts festgelegt. Mit "context-origin" wird der Ursprung der Datenpartition als Ursprung des aufgerufenen Browser-Kontexts festgelegt. In einer zukünftigen Version planen wir auch die Unterstützung benutzerdefinierter Datenpartitionsquellen, bei denen ein Worklet-Script auf freigegebene Speicherdaten aus einer beliebigen Quelle zugreifen kann.
Beim Laden eines plattformübergreifenden Scripts, bei dem der Datenursprung auf "script-origin" festgelegt ist, enthält die vom Browser gesendete Anfrage für das Script einen "Sec-Shared-Storage-Data-Origin: <origin>"-Header. Dazu muss das Script auch den Antwortheader "Shared-Storage-Cross-Origin-Worklet-Allowed: ?1" für die Einwilligung enthalten.
Verwendung
Wenn Sie createWorklet() bereits mit dem Script-Ursprung als Ursprung der Datenpartition des Worklets verwenden, können Sie dataOrigin so festlegen:
sharedStorage.createWorklet(scriptUrl, {dataOrigin: "script-origin"});
Da mit createWorklet() eine datenübergreifende Partition und mehrere Worklets erstellt werden können, empfehlen wir Ihnen, createWorklet() anstelle von addModule() zu verwenden.
Wir haben die Entwicklerleitfäden entsprechend aktualisiert und um weitere Informationen ergänzt.
Gespeicherte Abfragen mit der Select URL API in Chrome 132
Wir führen in Chrome 132 Updates für die Select URL API mit Shared Storage ein, die die Unterstützung gespeicherter Abfragen umfassen.
Was ändert sich?
Die Select URL API hat derzeit zwei Budgets pro Seitenladevorgang, die die Anzahl der API-Aufrufe bei jedem Seitenladevorgang begrenzen. Wir führen die Möglichkeit ein, Abfragen pro Seite zu speichern und wiederzuverwenden. Wenn Sie eine gespeicherte Abfrage verwenden, werden die Budgets pro Seitenladevorgang beim ersten Ausführen der gespeicherten Abfrage berechnet, nicht aber bei nachfolgenden Ausführungen der gespeicherten Abfrage während desselben Seitenladevorgangs.
Gespeicherte Abfragen implementieren
Ab der Version 132 von Chrome können Sie den Parameter savedQuery in den Optionen für selectURL() mit dem Namen der Abfrage verwenden:
await sharedStorage.selectURL('experiment', urls, {
savedQuery: 'control_or_experiment',
keepAlive: true
});
Verwenden Sie für jeden Aufruf von selectURL() denselben savedQuery-Namen, damit Folgeabfragen demselben Budget in Rechnung gestellt werden.
Wir haben die Dokumentation entsprechend aktualisiert und zusätzliche Informationen zum Budget für selectURL() hinzugefügt.
Feedback geben und erhalten
Der Vorschlag für die Shared Storage API befindet sich in der aktiven Diskussion und Entwicklung und kann sich daher ändern.
Wir würden uns sehr über Ihr Feedback zur Shared Storage API freuen.
- Angebot: Sehen Sie sich das detaillierte Angebot an.
- Diskussion: Nehmen Sie an der laufenden Diskussion teil, um Fragen zu stellen und Ihre Erkenntnisse zu teilen.
Auf dem Laufenden bleiben
- Mailingliste: Melden Sie sich für unsere Mailingliste an, um die neuesten Updates und Ankündigungen im Zusammenhang mit der Shared Storage API zu erhalten.
Benötigst du Hilfe?
- Entwicklersupport: Im Repository für den Privacy Sandbox-Entwicklersupport können Sie sich mit anderen Entwicklern austauschen und Antworten auf Ihre Fragen erhalten.