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.

Dynamic If-Modified-Since Headers

If your application sends cache-validation headers (If-Modified-Since, If-None-Match) and the resource modification dates change between recording and replay, the recorded conditional headers will be stale. To have Load Tester regenerate them dynamically:

  1. Right-click the test case → Properties → Restart Options tab
  2. Enable: "Dynamically handle If-Modified-Since headers"

This is only needed if the server's last-modified timestamps change between recording and replay, which is uncommon for static asset workflows.