Chrome 130 introduce modifiche all'API Shared Storage per consentire l'utilizzo di script worklet cross-origin con createWorklet() e addModule(). Stiamo anche introducendo aggiornamenti all'API Select URL con archiviazione condivisa in Chrome 132 con il supporto delle query salvate.
Worklet cross-origin con l'API Shared Storage in Chrome 130
Abbiamo introdotto modifiche all'API Shared Storage in Chrome 130 per offrirti maggiore flessibilità quando lavori con script worklet cross-origin.
Che cosa è cambiato
Abbiamo rimosso la limitazione same-origin per addModule(), quindi ora puoi caricare gli script worklet da qualsiasi origine. Gli script worklet cross-origin consentono casi d'uso chiave come l'hosting di script worklet sulle CDN. Quando lo script del worklet è di origine diversa da quella del contesto di navigazione invocante, l'origine del contesto invocante viene utilizzata come origine della partizione dei dati per accedere allo spazio di archiviazione condiviso.
Per allinearsi al nuovo comportamento di addModule() e ridurre la potenziale confusione, la proprietà dataOrigin è stata aggiunta alla chiamata createWorklet() per consentire la lettura e la scrittura in una partizione di dati di archiviazione condivisa diversa dal contesto di navigazione dell'invocazione. In questo modo puoi avere un controllo più granulare sullo spazio di archiviazione condiviso a cui accede ogni worklet, anche quando utilizzi script di worklet cross-origin.
Come è cambiato
A partire da Chrome 125, uno script cross-origin di terze parti su una pagina è in grado di creare worklet cross-origin senza la necessità di iframe cross-origin chiamandocreateWorklet(url). In precedenza, createWorklet(url) utilizzava l'origine dell'URL dello script (url) come origine della partizione dei dati, indipendentemente dal contesto di chiamata.
In Chrome 130, per allinearsi al nuovo comportamento di addModule(), createWorklet()
utilizza anche il contesto di chiamata come origine predefinita della partizione dei dati. Per continuare
a utilizzare l'origine URL dello script come origine della partizione di dati, viene introdotta una nuova proprietàdataOrigin che consente di impostare esplicitamente l'origine della partizione di dati.
La nuova proprietà dataOrigin accetta "script-origin", che imposta l'origine della partizione di dati come origine dello script, e "context-origin", che imposta l'origine della partizione di dati come origine del contesto di navigazione che richiama. In una release futura prevediamo anche di supportare le origini di partizione dei dati personalizzate, in cui uno script worklet può accedere ai dati di archiviazione condivisi da un'origine arbitraria su base facoltativa.
Quando carichi uno script cross-origin con l'origine dati impostata su "script-origin",
la richiesta dello script inviata dal browser includerà un'intestazione
"Sec-Shared-Storage-Data-Origin: <origin>". Per attivare questa opzione, lo script deve includere anche l'intestazione di risposta di attivazione "Shared-Storage-Cross-Origin-Worklet-Allowed: ?1".
Modalità di utilizzo
Se utilizzi già createWorklet() con l'origine dello script come origine della partizione dei dati del worklet, puoi impostare dataOrigin come segue:
sharedStorage.createWorklet(scriptUrl, {dataOrigin: "script-origin"});
Poiché createWorklet() consente la creazione di una partizione di dati cross-origin e di più worklet, ti invitiamo a eseguire la transizione a createWorklet() rispetto all'utilizzo di addModule().
Abbiamo aggiornato la documentazione per gli sviluppatori in base a queste modifiche e per fornire ulteriori indicazioni.
Query salvate con l'API Select URL in Chrome 132
Stiamo introducendo aggiornamenti all'API Select URL con lo spazio di archiviazione condiviso in Chrome 132 con il supporto delle query salvate.
Che cosa cambia
L'API Select URL attualmente ha due budget per caricamento di pagina che limitano il numero di chiamate all'API a ogni caricamento di pagina. Stiamo introducendo la possibilità di salvare e riutilizzare le query su base di pagina. Quando utilizzi una query salvata, i budget per caricamento di pagina vengono addebitati la prima volta che viene eseguita la query salvata, ma non per le esecuzioni successive della query salvata durante lo stesso caricamento di pagina.
Come implementare le query salvate
A partire dalla release 132 di Chrome, puoi utilizzare il parametro savedQuery nelle opzioni per selectURL() con il nome della query:
await sharedStorage.selectURL('experiment', urls, {
savedQuery: 'control_or_experiment',
keepAlive: true
});
Utilizza lo stesso nome savedQuery per ogni chiamata a selectURL() per assicurarti che le query di follow-up vengano addebitate allo stesso budget.
Abbiamo aggiornato la documentazione per riflettere queste modifiche e fornire ulteriori dettagli sulla definizione del budget per selectURL().
Coinvolgere e condividere feedback
Tieni presente che la proposta dell'API Shared Storage è in discussione e in fase di sviluppo ed è quindi soggetta a modifiche.
Non vediamo l'ora di conoscere la tua opinione sull'API Shared Storage.
- Proposta: esamina la proposta dettagliata.
- Discussione: partecipa alla discussione in corso per porre domande e condividere i tuoi approfondimenti.
Tenersi informati
- Mailing list: iscriviti alla nostra mailing list per ricevere gli ultimi aggiornamenti e annunci relativi all'API Shared Storage.
Hai bisogno di aiuto?
- Assistenza per gli sviluppatori: entra in contatto con altri sviluppatori e ricevi risposte alle tue domande nel repository Privacy Sandbox Developer Support.