Skip to content

Browser Cache Simulation in Replay

Load Tester replays the exact transactions that were recorded. If a resource was cached by the browser during recording (so no HTTP request was sent), replay simulates the same cached behavior. If the browser fetched the resource during recording, replay sends the same request.

By default, browser cache and cookies are cleared before recording, which simulates a new user visiting the site for the first time. This means replays simulate first-time visitors by default. That's usually what you want for a load test, since the worst-case load on a server is from cold-cache users.

Simulating Returning Visitors (Pre-Loaded Cache)

To simulate users returning to the site with cached resources:

  1. Disable cache/cookie clearing under Tools → Preferences → Load Tester → Recording → Browser Configuration:
    • Uncheck: "Clear browser cache before recording"
    • Uncheck: "Clear browser cookies before recording"
  2. Pre-load the browser cache by manually browsing the site before recording. This loads images, CSS, and JavaScript into the browser cache.
  3. Record the test case. The browser uses cached resources, which means fewer HTTP requests in the recording.
  4. Re-enable cache/cookie clearing after recording so future recordings simulate new users by default.

The resulting test case represents a returning-visitor load profile: fewer asset requests per page, more pure-API or pure-HTML traffic.

Stale Conditional Cache Headers

If your application sends cache-validation headers (If-Modified-Since, If-None-Match), a recorded request carries the exact header values captured the day you recorded. Load Tester replays them as-is; it does not regenerate them. If the resource's modification date or ETag has changed since recording, the server may answer the recorded conditional request differently than it did during recording (for example, returning 200 OK with a full body where the recording received 304 Not Modified, or the reverse).

This only happens when conditional headers are present in the recording, which means you recorded with a warm browser cache (see Simulating Returning Visitors above). The default recording settings clear the browser cache first, so a cold-cache recording generally has no conditional headers and no stale-header problem.

If stale conditional headers do cause replay mismatches, either re-record with cache clearing enabled (the default), or remove the If-Modified-Since and If-None-Match headers from the affected transactions in the Headers view.