k6 load tests overstate origin traffic: no built-in browser cache emulation to model CDN hit ratios

k6 does not currently provide native HTTP cache emulation. The HTTP client treats every request as a fresh network call, regardless of Cache-Control or ETag headers. To avoid overstating origin traffic, you must manually model the cache behavior within your script logic.

Deriving and Encoding Cache-Hit Ratios

To derive a defensible hit ratio, analyze your CDN or origin access logs (e.g., CloudFront or Cloudflare logs) over a representative time window. Group your assets into classes based on content type or path prefix and calculate the ratio as follows:

Hit Ratio = Total Cache Hits / (Total Cache Hits + Total Cache Misses)

Once derived, encode these ratios as probability gates using Math.random(). This ensures that, over a large sample of VUs, the total request volume matches production patterns.

const CACHE_RATIOS = {
  static_assets: 0.85, // 85% hit ratio
  images: 0.95,       // 95% hit ratio
};

export default function () {
  // Simulate a static asset request
  if (Math.random() > CACHE_RATIOS.static_assets) {
    http.get('https://example.com/style.css');
  }
  // Requests skipped by this logic are treated as cache hits (0ms network cost)
}


Implementation Strategy

  
Scope: Apply simulation only to static assets. Do not gate dynamic or personalized endpoints, as skipping these requests will artificially deflate your latency percentiles and distort throughput metrics.
  
Warm-up Handling: To prevent "cold-cache" spikes from skewing steady-state percentiles, use exec.vu.iterationInScenario to identify the first iteration per VU. You can either discard these metrics using a custom tag or ensure the first iteration always executes the request before the probability gate takes over.
  
Stateful Modeling: For higher fidelity, use per-VU state. Instead of a random coin flip, fetch an asset once per VU session and skip it for all subsequent iterations. This better mimics a returning user with a warm browser cache.


Verification and Assumptions
This approach assumes that your VUs map to independent users. To verify that k6 is indeed overstating traffic, run a two-iteration script against a cached endpoint and check your server logs; you will see two full unconditional requests despite the presence of caching headers.

Note on k6 Browser: While the k6/browser module drives a real browser via the Chrome DevTools Protocol (CDP) and may exhibit native caching, the standard k6/http module remains stateless.