Load Testing — Commerce

Overview

Load testing e-commerce applications requires more than hammering an endpoint with concurrent requests. Realistic test scenarios simulate actual user behavior: browsing the catalog, searching for products, adding items to a cart, and completing checkout — including the think time between actions. This skill covers building realistic shopping scenarios in k6 and Artillery, interpreting results to find bottlenecks, and establishing performance baselines before major sales events.

When to Use This Skill

When preparing for a flash sale, Black Friday, or seasonal traffic spike
When deploying a major infrastructure change (new database, CDN, checkout service)
When establishing performance SLOs and baselines for a new storefront
When a production incident was caused by load and you need to reproduce it in staging
When a new checkout feature is being released and its performance impact is unknown

Core Instructions

Step 1: Determine your platform and what you can test

Platform	Load Testing Scope	Recommended Approach
Shopify	Shopify's infrastructure scales automatically — you cannot overload it meaningfully	Test your theme's frontend performance with Google PageSpeed Insights and Lighthouse CI; test any custom apps or storefronts you host separately
WooCommerce	You own the server — load testing is critical before sales events	Use Loader.io (free tier: 1 target, 10K connections/test) against your staging site; or k6/Artillery for detailed scenario testing
BigCommerce	BigCommerce scales automatically — platform infrastructure is not a concern	Test your theme's frontend performance with PageSpeed Insights; test any custom middleware or headless layer you host
Custom / Headless	Full control — load testing is your responsibility	Use k6 (open-source, scriptable) or Artillery (YAML-based) with realistic shopping scenarios against a staging environment

Step 2: Platform-specific load testing

Shopify

Shopify's infrastructure handles virtually any traffic spike. Your load testing focus is the frontend experience:

Run Google PageSpeed Insights on your most critical pages (product page, collection page, checkout):
- Go to pagespeed.web.dev and test your product and collection pages
- Target a Performance score of 75+ on mobile; address any red/orange recommendations before your sale
Check Shopify's built-in performance report:
- Go to Online Store → Themes and click View report
- This shows your store's Core Web Vitals (LCP, CLS, FID) based on real user data
- A poor LCP score on mobile almost always means the hero image needs fetchpriority="high" or compression
Audit your installed apps before a sale:
- Go to Apps in your Shopify admin and review every app injecting scripts into your storefront
- Each third-party script adds 50–200ms; remove unused apps and disable any that load synchronously
For Shopify Plus — notify Shopify support before major launches:
- Submit a flash sale notification through your Plus support channel at least 48 hours before the event
- Shopify can pre-allocate resources and monitor your store during the event

WooCommerce

WooCommerce runs on your hosting infrastructure. Test against a staging environment that mirrors your production configuration (same PHP version, same MySQL version, same caching stack).

Quick load test with Loader.io (no code required):

Sign up at loader.io (free tier: 1 target, 10K connections per test)
Click New Test and enter your staging URL
Configure a ramp test: start at 0 clients, ramp to your expected peak traffic over 60 seconds, hold for 120 seconds
Loader.io provides a verification token — add it to a page on your staging site to confirm ownership
Run the test against your checkout page specifically — product browse is usually cached; checkout hits the database

Interpret results:

Response time under 3 seconds at peak: acceptable
Error rate above 1%: investigate server logs for PHP fatal errors, database timeouts, or memory exhaustion
If the server struggles at lower than expected traffic: upgrade your hosting tier or add Redis Object Cache before the sale

Before your test, ensure your staging stack is properly configured:

Redis Object Cache is active (Settings → Redis — green status)
WP Rocket page cache is enabled and has warmed the most-visited product pages
You're testing against the same server size you'll run in production

Custom / Headless

For custom storefronts, use k6 or Artillery against a staging environment that mirrors production.

Important before you start:

Always test against staging, never production
Use test-mode payment tokens (Stripe: tok_visa) — never run load tests against real payment processors
Tag test orders with a recognizable email domain (e.g., @test-load.invalid) so you can bulk-delete them after
Reserve test products with unlimited inventory so the checkout scenario doesn't fail due to oversells

k6 realistic shopping scenarios:

k6 uses a ramping-arrival-rate executor to control requests per second (more realistic than VU-based approaches). Typical e-commerce traffic distribution: 60% browse, 25% product detail, 10% cart, 5% checkout.

// k6/commerce-load-test.js
import http from 'k6/http';
import { check, sleep } from 'k6';
import { SharedArray } from 'k6/data';

const BASE_URL = __ENV.BASE_URL || 'https://staging.mystore.com';

const products = new SharedArray('products', function() {
  return JSON.parse(open('./data/products.json')); // array of {id, defaultVariantId}
});

export const options = {
  scenarios: {
    catalog_browsing: {
      executor: 'ramping-arrival-rate',
      startRate: 0, timeUnit: '1s',
      preAllocatedVUs: 50, maxVUs: 200,
      stages: [
        { target: 60, duration: '2m' },  // Ramp up
        { target: 60, duration: '5m' },  // Steady state
        { target: 0,  duration: '1m' },  // Ramp down
      ],
      exec: 'catalogBrowsing',
    },
    checkout_flow: {
      executor: 'ramping-arrival-rate',
      startRate: 0, timeUnit: '1s',
      preAllocatedVUs: 10, maxVUs: 50,
      stages: [
        { target: 5, duration: '2m' },
        { target: 5, duration: '5m' },
        { target: 0, duration: '1m' },
      ],
      exec: 'checkoutFlow',
    },
  },
  thresholds: {
    'http_req_duration{scenario:checkout_flow}': ['p(95)<3000'],
    'http_req_failed{scenario:checkout_flow}': ['rate<0.01'],
    'http_req_duration{scenario:catalog_browsing}': ['p(95)<1000'],
  },
};

export function catalogBrowsing() {
  http.get(`${BASE_URL}/api/collections/featured`, { tags: { step: 'homepage' } });
  sleep(2 + Math.random() * 3); // Think time: 2–5s

  const categories = ['t-shirts', 'hoodies', 'accessories'];
  const category = categories[Math.floor(Math.random() * categories.length)];
  http.get(`${BASE_URL}/api/collections/${category}?page=1&sort=popular`, { tags: { step: 'category' } });
  sleep(3 + Math.random() * 5);
}

export function checkoutFlow() {
  const product = products[Math.floor(Math.random() * products.length)];

  // View product
  const productRes = http.get(`${BASE_URL}/api/products/${product.id}`, { tags: { step: 'view_product' } });
  check(productRes, { 'product page 200': r => r.status === 200 });
  sleep(2 + Math.random() * 3);

  // Add to cart
  const cartRes = http.post(`${BASE_URL}/api/cart`, JSON.stringify({
    items: [{ productId: product.id, variantId: product.defaultVariantId, quantity: 1 }],
  }), { headers: { 'Content-Type': 'application/json' }, tags: { step: 'add_to_cart' } });
  check(cartRes, { 'add to cart 200': r => r.status === 200 });
  const cart = JSON.parse(cartRes.body);
  sleep(1 + Math.random() * 2);

  // Start checkout
  const checkoutRes = http.post(`${BASE_URL}/api/checkout/start`, JSON.stringify({
    cartId: cart.id,
    customer: { email: `test-${Math.random().toString(36).slice(7)}@test-load.invalid` },
  }), { headers: { 'Content-Type': 'application/json' }, tags: { step: 'start_checkout' } });
  check(checkoutRes, { 'checkout start 200': r => r.status === 200 });
  const checkout = JSON.parse(checkoutRes.body);
  sleep(5 + Math.random() * 10); // Think time: filling form

  // Place order
  const orderRes = http.post(`${BASE_URL}/api/checkout/complete`, JSON.stringify({
    checkoutId: checkout.id,
    paymentToken: 'tok_visa', // Stripe test token
    shippingMethodId: checkout.shippingMethods[0]?.id,
  }), { headers: { 'Content-Type': 'application/json' }, tags: { step: 'place_order' } });
  check(orderRes, { 'order placed 201': r => r.status === 201 });
}

Artillery YAML config (alternative to k6 — good for API-focused testing):

# artillery/commerce-load-test.yml
config:
  target: "{{ $processEnvironment.BASE_URL }}"
  phases:
    - name: "Warm-up"
      duration: 60
      arrivalRate: 5
    - name: "Ramp up"
      duration: 120
      arrivalRate: 5
      rampTo: 50
    - name: "Peak load"
      duration: 300
      arrivalRate: 50
    - name: "Spike"
      duration: 30
      arrivalRate: 200
    - name: "Recovery"
      duration: 60
      arrivalRate: 20
  processor: "./processors/commerce-helpers.js"

scenarios:
  - name: "Browse catalog"
    weight: 60
    flow:
      - get:
          url: "/api/collections/all?page=1"
          capture:
            json: "$.products[0].id"
            as: "productId"
      - think: 3
      - get:
          url: "/api/products/{{ productId }}"

  - name: "Complete checkout"
    weight: 10
    flow:
      - function: "generateCheckoutData"
      - post:
          url: "/api/cart"
          json:
            productId: "{{ productId }}"
            quantity: 1
          capture:
            json: "$.id"
            as: "cartId"
      - think: 8
      - post:
          url: "/api/checkout/start"
          json:
            cartId: "{{ cartId }}"
            email: "{{ email }}"
          capture:
            json: "$.checkoutId"
            as: "checkoutId"
      - think: 10
      - post:
          url: "/api/checkout/complete"
          json:
            checkoutId: "{{ checkoutId }}"
            paymentToken: "tok_visa"
          expect:
            - statusCode: 201

Run the test and capture a baseline:

k6 run \
  --env BASE_URL=https://staging.mystore.com \
  --out json=results/baseline-$(date +%Y%m%d).json \
  k6/commerce-load-test.js

Analyze results per step using tags:

# Overall summary (k6 outputs this automatically at end of run)
# Per-step breakdown from the JSON output
cat results/baseline-*.json | jq '
  [.data_points[] | select(.type=="Point" and .metric=="http_req_duration")]
  | group_by(.tags.step)
  | map({step: .[0].tags.step, p95_ms: (map(.value) | sort | .[length * 0.95 | floor])})
'

Scale targets for e-commerce:

Catalog pages p95 < 1000ms
Product detail p95 < 1500ms
Checkout flow p95 < 3000ms
Error rate < 1% at peak

Run load tests in CI before major releases (GitHub Actions):

# .github/workflows/load-test.yml
name: Load Test (Pre-Release)
on:
  workflow_dispatch:
    inputs:
      target_url:
        description: 'Staging URL to test'
        required: true
        default: 'https://staging.mystore.com'

jobs:
  load-test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Install k6
        run: |
          curl -s https://dl.k6.io/key.gpg | sudo apt-key add -
          echo "deb https://dl.k6.io/deb stable main" | sudo tee /etc/apt/sources.list.d/k6.list
          sudo apt-get update && sudo apt-get install k6
      - name: Run load test
        env:
          BASE_URL: ${{ github.event.inputs.target_url }}
        run: k6 run --env BASE_URL=$BASE_URL --out json=results.json k6/commerce-load-test.js
      - uses: actions/upload-artifact@v4
        with:
          name: load-test-results
          path: results.json

Best Practices

Simulate think time between steps — real users pause between actions; removing think time creates an unrealistically high request rate that doesn't reflect production patterns
Use test-mode payment tokens — always use Stripe's tok_visa or equivalent test tokens; never run load tests against real payment processors
Run against staging, not production — load tests consume resources and can degrade service for real customers
Profile at 1.5×, 2×, and 3× expected peak — run multiple tests at different load levels to find your system's inflection point before the actual sale
Monitor the database and cache during tests — watch for connection pool exhaustion, Redis evictions, and lock wait times in your DB; application-tier throughput can look fine while the database is saturated
Tag test orders for easy cleanup — use a consistent test email domain (@test-load.invalid) so you can bulk-delete test data after runs: DELETE FROM orders WHERE email LIKE '%@test-load.invalid'

Common Pitfalls

Problem	Solution
Checkout scenario fails because products are sold out	Reserve test products with unlimited inventory; use a separate `is_load_test_product` flag and filter them from real catalog pages
Loader.io test passes but production still slows down	Staging may not mirror production load — confirm Redis Object Cache is active, MySQL version matches, and the server size is the same
k6 VUs exhausted before reaching target RPS	Use `ramping-arrival-rate` executor (controls RPS) instead of `ramping-vus` (controls concurrent users); increase `preAllocatedVUs` and `maxVUs`
Alert noise during planned load tests	Add a load test flag to your monitoring system (Datadog tag, Grafana annotation) to suppress non-critical alerts during the scheduled test window
Results not reproducible between runs	Use a `SharedArray` with a fixed dataset file instead of Math.random() product generation; fix the test data set before the run

Related Skills

@flash-sale-scaling
@monitoring-alerting-commerce
@database-optimization-commerce
@bot-protection

load-testing-commerce