v132 · offline / storage

Saved queries in sharedStorage.selectURL

sharedStorage.selectURL() now allows queries to be saved and reused on a per-page basis, where the two per-page-load budgets are charged the first time a saved query is run but not for subsequent runs of the saved query during the same page-load. This is accomplished with a savedQuery parameter in the options for selectURL() that will name the query.

concepts

  1. Saved Queries

    selectURL can re-use a previously-registered query, saving per-call worklet setup costs.

  2. budget rescue

    6 ad slots × 4 reloads — raw mode hits the cap, savedQuery reuse keeps headroom.

  3. budget economics

    Drag distinct query count, repeat count, and bits-per-query. Side-by-side budget bars show entropy and call-count drain for legacy vs saved-query approach.

  4. Entropy Budget Tracker

    Simulate selectURL() calls and watch the per-page-load entropy budget deplete in real time. Saved queries are charged once and then free for the rest of the page load — see the difference between charged and free runs as the log builds up.

  5. Worklet Simulator

    Step through every selectURL() call across multiple page loads. See exactly which calls charge budget, which are served from the savedQuery cache, and how much headroom is saved over the legacy approach.

why it shipped

Without browser support for saved queries, web developers using sharedStorage.selectURL to make the same query more than once in a page load, and wanted to do so without depleting their site's page load budget for shared storage, would be incentivized to develop their own methods to reuse queries without additional budget charges. These ad hoc methods would involve storing information bits ex filtrated from selectURL via mechanisms such as using an iframe to load the an opaque URN, or sending event-level reports, that are not intended to be permanently available.

references