How To Load Test Your Site With k6

Servers are getting faster and faster, but there are still plenty of websites suffering from poor performance. There are many variables that might cause a website to load slowly, and there are websites that have good load times, but only up to a certain number of concurrent users.

How can you find out how many users your website can handle?

In this article, we’ll take a look at a free tool that can help you send fake traffic to your site in order to measure the response. K6 is a free load tester utility that runs on JavaScript. (You don’t need to be a JavaScript expert to use it. We’ll provide a free sample script you can run in the examples below.)

Load testing on a live production site can cause traffic spikes. Proceed with caution when performing load tests.

Running Your First Test With K6

With k6, you can orchestrate highly advanced and unique load scenarios. (The more advanced settings for k6 are outside the scope of this article.)

Below you will find a sample test you can run on your website, and some instructions with regard to how the test is structured.

In order to run the test you will need to install k6.

How To Install k6

There are a few different ways to install k6, depending on your operating system. For more detailed instructions, be sure to visit the official k6 website.


For Windows users, k6 recommends using the Chocolatey package manager:

choco install k6


For Mac users, k6 recommends using the Homebrew package manager:

brew install k6


For Debian/Ubuntu Linux users, the apt package manager is recommended:

sudo gpg --no-default-keyring --keyring /usr/share/keyrings/k6-archive-keyring.gpg --keyserver hkp:// --recv-keys C5AD17C747E3415A3642D57D77C6C491D6AC1D69
echo "deb [signed-by=/usr/share/keyrings/k6-archive-keyring.gpg] stable main" | sudo tee /etc/apt/sources.list.d/k6.list
sudo apt-get update
sudo apt-get install k6

The snap package manager also works, if you want to avoid adding a new repository to your source list:

snap install k6

For Fedora/CentOS users, you can use dnf:

sudo dnf install
sudo dnf install k6

Running The First Test Script

It’s now time to run your test script. K6 provides numerous examples you can follow to set up a test scenario. The test below provides all of the basic conditions you will need to get some good data about your website’s response times under load:

import http from 'k6/http';
import { check, sleep } from 'k6';
export let options = {
  stages: [
    { duration: '15s', target: 100 },
    { duration: '30s', target: 100 },
    { duration: '15s', target: 0 },
export default function() {
  let res = http.get('');
  check(res, { 'status was 200': r => r.status == 200 });

Be sure to replace with your actual website hostname.

The section you may want to customize contains the stages of the test:

export let options = {
  stages: [
    { duration: '15s', target: 100 },
    { duration: '30s', target: 100 },
    { duration: '15s', target: 0 },

The test conditions as set forth here set up three distinct stages. Each stage has a duration parameter and a ramping target. The first stage sets a duration of 15 seconds, over which k6 will create virtual users to send a total of 100 HTTP requests to the URL of your choice. The next stage will send the same request target but spread over 30 seconds. The final stage sends out a target of 0 for 15 seconds. The last leg acts as a sort of cool down period.

You can tweak these parameters to get different results.

When it’s time to run the test, open a command line interface in your favorite terminal app, and use this command:

k6 run <filename>.js

The test will begin in your terminal window.

Running a typical k6 test

You will see results in incoming lines of text, like this:

running (0m01.0s), 007/100 VUs, 0 complete and 0 interrupted iterations
default   [   2% ] 007/100 VUs  0m01.0s/1m00.0s

running (0m02.0s), 014/100 VUs, 0 complete and 0 interrupted iterations
default   [   3% ] 014/100 VUs  0m02.0s/1m00.0s

running (0m03.0s), 020/100 VUs, 0 complete and 0 interrupted iterations
default   [   5% ] 020/100 VUs  0m03.0s/1m00.0s

running (0m04.0s), 027/100 VUs, 0 complete and 0 interrupted iterations
default   [   7% ] 027/100 VUs  0m04.0s/1m00.0s

running (0m05.0s), 033/100 VUs, 1 complete and 0 interrupted iterations
default   [   8% ] 033/100 VUs  0m05.0s/1m00.0s

Finally, you see the results. The line you most likely find most relevant to the test is the response time, labeled http_req_duration.

http_req_duration..............: avg=16.22s   min=3.06s    med=19.14s   max=21.29s   p(90)=20.46s   p(95)=20.72s

Notice you have an average response time, as well as minimum (min), median (med), and maximum (max).

Typical k6 results.

Remember, this test is sending HTTP requests. The amount of your requests your site requires will depend on how it’s coded. There is the initial request, the loading of stylesheets, images, and other resources. One goal of site speed optimization is to limit requests wherever possible.

Case Study: Testing Two WordPress Sites

For the test, we are using a VPS with 1 CPU and 6GB of RAM. NGINX caching has been disabled. For a cache, we will only be using the base settings of the W3 Total Cache plugin. One site is running a bare WordPress installation and no caching, the other is running the W3 Total Cache plugin.

For the first test, we will run the above k6 test on our bare WordPress install. We will be keeping an eye on server load and response times.

No cache k6 response times:

http_req_duration..............: avg=15.92s   min=1.54s   med=19.94s   max=22.14s   p(90)=21.09s   p(95)=21.22s

Cache site response times:

http_req_duration..............: avg=1.15s   min=155.52ms med=980.52ms max=4.9s     p(90)=2.24s   p(95)=2.62s

Note that less than 2 seconds is considered a good response time. You will notice that the cache site not only results in better response times but also lower server load.

Load average compared:

Now you know how to run load tests with k6. Be sure to leave any questions or comments below.

Christopher Maiorana Content Writer II

Christopher Maiorana joined the InMotion community team in 2015 and regularly dispenses tips and tricks in the Support Center, Community Q&A, and the InMotion Hosting Blog.

More Articles by Christopher

Was this article helpful? Let us know!