API & load testing
k6
Load testing written as code, run from one binary.
k6 in practice
A load testing tool where the test is a JavaScript file and the engine beneath it is a single compiled binary. Scenarios describe how many virtual users arrive and over what shape of time, thresholds state the conditions under which a run should be considered a failure, and the process exits with a status code a pipeline can act on without anyone interpreting a graph. That last property is why it slots into continuous integration in a way the older generation of load tools never comfortably managed.
We use it when a client needs to know whether a service holds up at a defined arrival rate, and needs that answer to become a repeatable check rather than a one-off exercise somebody performed once before a launch. Written as code, the test lives in the repository beside everything else, goes through review like everything else, and can hold a release against a threshold. It is also the sane instrument for API-level performance work, where the question concerns the service rather than the page around it.
The load engine speaks protocols, not pages. It reports what a service does under pressure and says nothing about what a rendered page feels like, because no browser is doing layout, executing scripts and fetching assets inside the measurement loop.
Its JavaScript runtime is not Node. Reaching for a package from the wider ecosystem means bundling it first, and a fair number of packages will not survive that trip at all.
One machine can only generate so much, and going beyond it means either the hosted service or operating the tooling yourself across a cluster. Either path is a decision with a cost attached rather than a flag you pass.
There is no way to build a test without writing code, which rules it out wherever the person who understands the performance requirement is not the person who can express it in JavaScript.
Correlating a run against what the system was doing at the time still depends entirely on your own observability. The tool measures the outside of the service and cannot tell you which query inside it gave up.
FAQ
k6 questions we hear often
k6 or JMeter?
This one where the test should live in the repository and execute in a pipeline, and where the people writing it are comfortable in JavaScript. The other where protocols beyond HTTP are involved, where the team would rather assemble a plan visually, or where an existing body of work already exists. On ordinary web APIs they overlap heavily and either will answer the question put to it.
Can it measure how fast our pages load?
Not the way a person experiences it, at least not from the protocol-level engine doing the load generation. It measures request timings, which is exactly the right instrument for a service under strain and exactly the wrong one for rendering, blocking scripts and layout shift. Where the question is really about the front end, measure that separately with something that runs a browser.
When do we need distributed execution?
Later than most projects assume, and we would rather establish the real ceiling against your scenario than quote a figure that depends on request size, response payload and the machine underneath. Begin on one generator, watch its own resource consumption throughout the run, and treat a saturated generator as an invalid result rather than as a finding about your system.
Should a load test be allowed to fail the build?
Yes, once the thresholds actually mean something. The trap is setting them before a baseline exists, which produces a gate that trips on ordinary variance and gets switched off within a fortnight by someone trying to ship. Run without thresholds until the normal range is visible, set the limit above it, then treat any breach as a real event worth stopping for.
Contact
Wondering if this is the right tool?
Describe what you are trying to verify and we will tell you which instrument fits, including when the answer is one we do not use.