Feature description
When k6 Studio generates protocol test scripts from recordings, all inter-request timing is discarded. Every HTTP request within a group is emitted as sequential http.request() calls with no delays between them, executing as fast as the runtime allows. The only timing inserted is sleep(1) at group boundaries.
A real user session recorded over several minutes might contain hundreds of HTTP requests. In reality, these requests were spread across time — some fired in rapid bursts (browser loading page resources), others were separated by seconds or minutes as the user read content, navigated, and interacted with the application. The HAR data captured during recording contains precise timestamps (startedDateTime) for every request, preserving exactly when each request occurred.
The generated script throws away all of this timing and replays hundreds of requests simultaneously. This produces a load profile that bears no resemblance to real user behavior:
- A single VU fires hundreds of requests in milliseconds instead of spreading them across minutes
- The server sees a burst that looks like a denial-of-service rather than a user session
- Connection pools, session management, and backend resources are stressed in ways that never occur in production
- Response time measurements are meaningless because requests are queued and contending with each other artificially
Generated scripts should replay requests at approximately the same pace they were recorded, preserving the natural timing between user actions. The HAR data already contains the information needed — it is just not being used.
Already existing or connected issues / PRs (optional)
Feature description
When k6 Studio generates protocol test scripts from recordings, all inter-request timing is discarded. Every HTTP request within a group is emitted as sequential
http.request()calls with no delays between them, executing as fast as the runtime allows. The only timing inserted issleep(1)at group boundaries.A real user session recorded over several minutes might contain hundreds of HTTP requests. In reality, these requests were spread across time — some fired in rapid bursts (browser loading page resources), others were separated by seconds or minutes as the user read content, navigated, and interacted with the application. The HAR data captured during recording contains precise timestamps (
startedDateTime) for every request, preserving exactly when each request occurred.The generated script throws away all of this timing and replays hundreds of requests simultaneously. This produces a load profile that bears no resemblance to real user behavior:
Generated scripts should replay requests at approximately the same pace they were recorded, preserving the natural timing between user actions. The HAR data already contains the information needed — it is just not being used.
Already existing or connected issues / PRs (optional)