Network Cache

Most automation loads the same static files over and over. Every run downloads the same stylesheets, the same framework bundles, the same fonts and the same logos through your proxy, and you pay for that traffic every time.

The network cache stores those static resources once and reuses them on later runs. It is handled entirely by Rebrowser, it needs no changes to your code, and it is off by default — you turn it on per profile or per group in browser settings.

What gets cached

Only four resource types are eligible, and you can narrow the list further in settings:

• Stylesheets
• Scripts
• Fonts
• Images

Documents, XHR and Fetch responses, media and every other resource type are never cached. Neither is anything that is not plainly public and static. A response is skipped when it:

• sets a cookie, or the request carried a cookie or an authorization header
• is marked private, no-store or no-cache
• is not a 200 response to a GET request
• carries no explicit freshness lifetime, or is already stale when it arrives
• is larger than the maximum resource size

In other words the cache holds the same things a shared HTTP cache would be allowed to hold, and nothing else. Cached content is never shared between customers.

Two modes, and the tradeoff between them

This is the part worth reading carefully before you enable it.

When a resource is served from the cache instead of the network, the page can sometimes tell — the browser exposes timing and size information about every resource it loads, and a replayed resource does not always look exactly like one that came off the wire. Whether the page can tell depends on which resource it is.

For most automation, maximum savings is the right choice. Plenty of targets have no antibot system at all, or one that does not look at this, and the traffic savings are much larger. Use stealth mode when you are working against a target that actively fingerprints the browser and you are not willing to add any signal at all.

Stealth mode only covers third-party assets, so how much it saves depends entirely on the site. On a site that serves its own assets from its own domain it may cache almost nothing. On a site that serves assets from a separate CDN domain — which is the common modern setup — we measured roughly two thirds of all static resources as eligible.

If antibot detection matters to you, also read the section on proxy-level caching at the end of this page. It is undetectable by design, because the browser never knows it happened.

Measured results

Numbers from our own testing, so you know what order of magnitude to expect. Your results will differ — they depend on the site, on how many runs reuse the same assets, and on the cache headers the site sends.

Traffic. On a repeat load of a site whose assets are served without cookies, in maximum savings mode, 71 of 81 static resource requests were served from cache — 1.35 MB of resource bodies, avoiding 535 KB of compressed proxy traffic out of the 557 KB that same page load transferred with the cache off. That is about 96% of the static asset download removed from the proxy bill for that page. This is close to a best case: a site that attaches a cookie to its own asset requests will cache fewer of them, because we never touch a request that carries a cookie.

Eligible share on a CDN-heavy site. On a large commercial ticketing site, a single homepage load requested 225 to 256 resources, of which 150 to 177 were third-party CDN static assets — the portion stealth mode can serve.

Page load time. In a paired test on the same profile and the same browser, median navigation was 2739 ms with the cache off and 2600 ms with it on. Serving from cache was slightly faster overall, and well within the normal run-to-run spread. The cache adds a small amount of per-request work, and removes entire network fetches; in our testing the second effect was the larger one.

Settings

Every option lives under Network cache in browser settings, on a profile or on a group. Settings resolve in this order: system defaults, then the first group's settings, then the profile's own settings.

Each option has a mode selector next to it. Inherited stores nothing at this level and follows the settings above it — the selector shows you what that currently resolves to. Custom pins a value here that the levels above cannot override, and reveals the input for it.

That distinction matters most on Mode itself. Inherited and Custom — Off are not the same thing: Inherited means "whatever the group or the defaults say", so it will start caching if the group enables it, while Custom — Off means "never cache for this profile" and wins over a group that has the cache on. Choosing Off is how you exempt one profile from a group-wide setting.

When Mode is Custom — Off, the four options below it are hidden, because nothing they control can apply.

Clearing the cache

Each profile with the cache enabled has a clear network cache link on the profiles page. It takes effect immediately: from that moment on, that profile will not be served anything that was stored before you cleared it, even if the stored copy is still fresh.

Use it when a site has shipped a broken asset, or when you want to be certain a run starts from a clean slate.

What to expect in practice

The cache is a best-effort bandwidth optimization, not a guarantee. A few things follow from that:

• A cache can start cold. Expect the first run against a new site, or after a long gap, to behave like the cache is off.
• Changing the browser version, user agent or locale starts a separate cache, because a site can legitimately serve different files to a different browser.
• Your choice of proxy does not start a separate cache. Everything we store is public static content, so the exit IP does not change the bytes.
• Cached bodies are delivered to the browser over our internal connection rather than through your proxy. That is where the saving comes from, and it applies to mobile devices too.

Every run reports what the cache did. Open the run details page and look at the Network cache line to see how many resources were served from cache, how many bytes that was, and how many new resources the run stored for next time.

Proxy-level caching with Litport

There is a second, completely different way to cache static resources: let the proxy do it. The browser makes a normal request, the proxy answers it from its own cache, and the browser has no way of knowing the difference. Nothing in the page can detect it, because from the browser's point of view nothing unusual happened.

This currently works with Litport proxies only. You enable it by adding a suffix to your proxy password — not the username:

1
2
3
4
5
# normal credentials
USERNAME:PASSWORD

# same credentials, with static response caching enabled
USERNAME:PASSWORD_cache-all

Use that password when you add the proxy to Rebrowser, or in the proxy URL you pass to the API:

1
http://USERNAME:[email protected]:31337

In our own measurements, repeat fetches of the same assets through a Litport hub with caching enabled completed 5.6 to 9.3 times faster on desktop, and 1.9 to 6.2 times faster on a mobile device, compared with the first uncached fetch.

Points worth knowing before you rely on it:

• It covers HTTPS GET requests only, and responses carrying cookies, authorization headers or byte ranges are not cached.
• The default lifetime is 120 minutes, shortened automatically when the site asks for less.
• The cache belongs to a specific Litport hub, so switching hubs starts cold.
• It requires trusting the Litport root certificate, which our browsers already do.
• It is operated by Litport, not by us. Test it against your own targets before depending on it, and see their documentation for the authoritative details and for the full list of cache modes.

The two caches are independent and can be used together: Rebrowser's cache removes the request from your proxy entirely, and Litport's cache makes the requests that do go out cheaper and faster. If detection is your main concern, the proxy-level cache is the safer of the two.

If you are unsure which combination fits your workload, contact us and describe your target — we will tell you what we would use.