Skip to main content
Enable shared cache when separate browser sessions repeatedly download the same resources. Sessions using the same cache key can reuse cached content, subject to the browser’s normal cache behavior.

Enable shared cache

Pass these settings when starting a browser:
The cache is scoped using your API token and the key. Using the same key with another account’s token does not select your cache. Shared cache does not save a login. Use a persistent profile for cookies and other saved browser state.

Choose a key

Use a descriptive key for a workload, such as catalog-example-com. Reuse it across sessions that should share cached resources. Use different keys, or leave shared cache disabled, when jobs need independent cache state. Separate keys also make comparisons easier: you can test a fresh key without changing the configuration of other workers.

Check whether it helps

Compare similar runs with caching off and on. Keep the URLs, proxy targeting, request blocking, and worker count the same. Measure page duration and proxy traffic per successful result, allowing an initial run to populate the cache. Resources that change on every request or are not cacheable may see little benefit. Blocking an unwanted resource avoids the download entirely; see speed optimization.

Investigate unexpected content

If a problem appears only in sessions sharing a key, repeat the request with caching disabled or a fresh key. Also check the response’s cache headers and whether the page is serving personalized or challenge content. Keep the original session available for inspection while you compare results.