Atualizações do Armazenamento compartilhado e do URL de seleção: worklets entre origens e consultas salvas

Tara Agyemang
Tara Agyemang
GitHub LinkedIn

O Chrome 130 apresenta mudanças na API Shared Storage para permitir o uso de scripts de worklet entre origens com createWorklet() e addModule(). Também estamos lançando atualizações na API Select URL com o Shared Storage no Chrome 132 com suporte a consultas salvas.

Diagrama mostrando que os sites registrados podem gravar qualquer tipo de dados de chave-valor no armazenamento compartilhado, mas a leitura dos dados é restrita a APIs de saída específicas.
A API Shared Storage permite que os sites inscritos gravem qualquer tipo de dados chave-valor no Shared Storage, mas a leitura dos dados é restrita a APIs de saída específicas.

Worklets entre origens com a API Shared Storage no Chrome 130

Fizemos mudanças na API Shared Storage no Chrome 130 para oferecer mais flexibilidade ao trabalhar com scripts de worklet de origem cruzada.

O que mudou

Removemos a restrição de mesma origem para addModule(). Agora você pode carregar scripts de worklet de qualquer origem. Os scripts de worklet entre origens permitem casos de uso importantes, como a hospedagem de scripts de worklet em CDNs. Quando o script do worklet é de origem cruzada para o contexto de navegação de invocação, a origem do contexto de invocação é usada como a origem da partição de dados para acessar o armazenamento compartilhado.

Para corresponder ao novo comportamento do addModule() e reduzir possíveis confusões, a propriedade dataOrigin foi adicionada à chamada createWorklet() para permitir a leitura e a gravação em uma partição de dados de armazenamento compartilhada que é diferente do contexto de navegação de invocação. Isso oferece um controle mais granular sobre qual armazenamento compartilhado da origem é acessado por cada worklet, mesmo ao usar scripts de worklet entre origens.

Como isso mudou

A partir do Chrome 125, um script de origem cruzada de terceiros em uma página pode criar worklets de origem cruzada sem precisar de iframes de origem cruzada, invocando createWorklet(url). Anteriormente, o createWorklet(url) usava a origem do URL do script (url) como a origem da partição de dados, independentemente do contexto de invocação.

No Chrome 130, para se alinhar ao novo comportamento de addModule(), createWorklet() também usa o contexto de invocação como a origem padrão da partição de dados. Para continuar usando a origem do URL do script como a origem da partição de dados, uma nova propriedade dataOrigin está sendo introduzida para permitir que você defina explicitamente a origem da partição de dados.

A nova propriedade dataOrigin aceita "script-origin", que define a origem da partição de dados como a origem do script, e "context-origin", que define a origem da partição de dados como a origem do contexto de navegação de invocação. Em uma versão futura, também planejamos oferecer suporte a origens de partição de dados personalizadas, em que um script de worklet pode acessar dados de armazenamento compartilhado de uma origem arbitrária com base na ativação.

Ao carregar um script entre origens com a origem de dados definida como "script-origin", a solicitação do script enviada pelo navegador vai incluir um cabeçalho "Sec-Shared-Storage-Data-Origin: <origin>". Para ativar isso, o script também precisa incluir o cabeçalho de resposta de ativação "Shared-Storage-Cross-Origin-Worklet-Allowed: ?1".

Como usar

Se você já estiver usando createWorklet() com a origem do script como a origem da partição de dados do worklet, defina dataOrigin da seguinte maneira:

sharedStorage.createWorklet(scriptUrl, {dataOrigin: "script-origin"});

Como createWorklet() permite a criação de uma partição de dados entre origens e a criação de vários worklets, recomendamos que você faça a transição para createWorklet() em vez de usar addModule().

Atualizamos a documentação para desenvolvedores para refletir essas mudanças e oferecer mais orientações.

Consultas salvas com a API Select URL no Chrome 132

Estamos lançando atualizações na API Select URL com o armazenamento compartilhado no Chrome 132 com suporte a consultas salvas.

O que muda?

No momento, a API Select URL tem dois orçamentos por carregamento de página que restringem o número de chamadas feitas para a API em cada carregamento de página. Estamos introduzindo a capacidade de salvar e reutilizar consultas por página. Quando você usa uma consulta salva, os orçamentos por carregamento de página são cobrados na primeira vez que uma consulta salva é executada, mas não para execuções subsequentes da consulta salva durante o mesmo carregamento de página.

Como implementar consultas salvas

A partir da versão 132 do Chrome, é possível usar o parâmetro savedQuery nas opções de selectURL() com o nome da consulta:

await sharedStorage.selectURL('experiment', urls, {
  savedQuery: 'control_or_experiment',
  keepAlive: true
});

Use o mesmo nome savedQuery para todas as chamadas para selectURL() e garanta que as consultas de acompanhamento sejam cobradas no mesmo orçamento.

Atualizamos a documentação para refletir essas mudanças e fornecer mais detalhes sobre o orçamento para selectURL().

Engajamento e compartilhamento de feedback

A proposta da API Shared Storage está em discussão e desenvolvimento e, portanto, está sujeita a mudanças.

Queremos saber sua opinião sobre a API Shared Storage.

Fique por dentro

  • Lista de e-mails: inscreva-se na nossa lista de e-mails para receber as atualizações e os anúncios mais recentes relacionados à API Shared Storage.

Precisa de ajuda?