Prepare website load testing around a specific capacity question, an authorised environment and a workload that represents the intended journey. Confirm the script at minimal load before increasing activity. Interpret response time and errors alongside the actual test conditions, keeping the result distinct from a promise about every future visitor or deployment.
Start with the business question. Is the team preparing for an expected level of traffic, investigating performance during sustained use or reviewing a sudden activity peak? Write that question beside the environment and journey being tested. Different questions need different workloads and evidence.
Which test type answers the question?
Grafana’s k6 test-type guide explains the choices. A smoke test checks script behaviour and the system under minimal load. An average-load test assesses expected normal conditions. Confirm the script and the intended baseline before using its results to reason about a larger workload.
A stress test examines load beyond the expected average. A soak test examines reliability and performance over an extended period. A spike test examines a sudden large increase in activity. Choose the pattern that addresses the actual concern instead of treating all increased traffic as one kind of test.
Breakpoint tests increase load gradually to identify capacity limits. If that is the agreed objective, define the authorised scope and stopping decision with the people responsible for the environment. Keep the observed boundary tied to the tested configuration rather than presenting it as a permanent property of the website.
Document the reasoning for the chosen workload. The traffic mix, request timing and test duration should come from the actual question and available evidence. This article supplies no universal user count, run length or acceptable latency threshold.
What should a representative journey include?
Choose a task the visitor actually performs, such as opening a catalogue, viewing an item and submitting an approved test enquiry. Identify which requests belong to that task and which state changes they may cause. Use non-sensitive sample data and an arrangement approved for the intended activity.
Keep third-party effects explicit. A journey may send messages, reserve stock or call a payment service if the test follows its ordinary route. Agree which dependencies are simulated, isolated or separately authorised before running the workload. A test environment needs its real connection map, not just a reassuring name.
Define what a correct response means for the sample task. A fast error page is not successful catalogue delivery. Include the relevant response and content checks so the load result can be interpreted alongside whether the journey actually completed as intended.
| Capacity question | Test pattern to assess | Evidence to retain |
|---|---|---|
| Does the script represent the task? | Smoke test | Correct requests and intended responses |
| How does normal activity behave? | Average-load test | Approved workload and observed metrics |
| What happens during sustained use? | Soak test | Duration context and resource observations |
| How does a sudden peak behave? | Spike test | Defined traffic change and recovery behaviour |
| Where does the tested arrangement reach its limit? | Breakpoint test | Configuration, stopping decision and observed boundary |
This original question-to-workload worksheet makes the test objective reviewable. Keep the environment owner, authorisation scope and unresolved dependency questions with the selected row before execution.
Which measurements should the report explain?
The k6 metrics documentation gives the interpretation boundary. k6 metrics describe performance under the test conditions. k6 collects built-in metrics automatically. Record the build, workload and environment alongside those values so another reviewer can understand what they describe.
k6 thresholds can define failure criteria using metrics. Agree the criteria before reviewing the result and retain their source or business rationale. A condition written into a script is a project decision that needs justification; its presence does not make it a universal standard.
k6 can export summary and granular metric output. Retain the level of detail needed to investigate the question, including relevant errors and the timing of a change in behaviour. A summary alone may hide which part of a multi-step journey needs attention.
Ask the technical owner to relate the result to the actual service components. An application response, database query and external dependency may contribute differently to the observed outcome. Preserve the observations needed for that investigation rather than assigning the cause from a single aggregate number.
How should safe scope and stopping decisions be written?
Name the authorised target and people who can stop the test. Define the workload boundaries and relevant operational observations before execution. If the test touches shared infrastructure, coordinate its timing and scope with the responsible owners through their normal process.
Agree how sample records and other effects will be reviewed afterwards. An enquiry test may need a controlled recipient and a cleanup plan for approved sample data. Keep the intended data handling with the exercise so a successful test does not leave unexplained operational state.
Treat an unexpected error as evidence to assess. Pause or stop according to the agreed plan, retain the relevant output and identify what needs investigation before another run. Repeating a larger workload without understanding a broken baseline can make the result harder to interpret.
Original catalogue-and-enquiry workload exercise
Prepare a fictional catalogue journey in an isolated test arrangement. Include a sample item page and an approved enquiry route with controlled side effects. The exercise follows script validation, a chosen workload and interpretation of the retained metrics without inventing results.
First, write the expected requests and response checks. Run only the authorised minimal-load validation and inspect whether the intended content and task outcome are correct. Record any request that reaches an unintended service before increasing the workload.
Next, select the test pattern that answers the written capacity question. Retain the configuration, target and stopping plan with the run evidence. Compare the observed request, error and duration information with the agreed acceptance criteria, keeping unexpected behaviour visible.
Then ask a reviewer to explain what the result establishes about this configuration. Identify which journey steps and dependencies were included and which need separate evidence. Avoid extrapolating the sample into an unsupported site-wide capacity claim.
Finally, assign the investigation or improvement suggested by the findings and define the comparable next check. Keep the original evidence so a later run can be assessed against the same question and a clearly recorded configuration change.
Have the test owner review the retained workload file with another maintainer. They should be able to identify the target, journey and source of the selected load pattern. Record any hidden assumption about data, recipients or dependencies before considering the exercise reproducible.
For related work, see website development and hosting. Get started with your capacity question, test environment and representative visitor journey.
By Spout Team. AI-assisted drafting by Codex using the linked primary documentation.