Technical Performance Testing SOP

A technical performance testing SOP measures how fast and how stable your product is when real numbers of people use it at once, and it fixes the slowest part before customers find it. Setup takes about a week; test and fix rounds take one to three more. Launch day is the worst moment to discover that checkout slows to 8 seconds at 300 users. This SOP replaces "it feels fast on my laptop" with numbers measured under the load you expect, and then some.

What is technical performance testing and when should you use it?

Performance testing sends simulated users through your product and measures response times, errors and resource use. Three kinds of test cover most startup needs:

• Load test: expected peak traffic, held for 15 to 60 minutes. Does it stay inside budget?
• Stress test: traffic rising until something breaks. Where is the breaking point, and how does it fail?
• Soak test: normal traffic for several hours. Do memory or database connections leak over time?

Use this SOP:

• Before a launch, campaign or press feature that could bring a spike.
• Before a B2B customer rolls your product out to their whole team.
• After a major change to the database, hosting or a heavy feature.
• When users complain about slowness and you need facts instead of guesses.

This page tests speed and stability at the traffic you expect soon. Whether your architecture can grow to 10 or 100 times that is the job of the technical scalability assessment SOP, and behaviour across phones and browsers belongs to the device compatibility testing SOP.

What do you need before you start?

• A working product with the features customers will use at launch.
• A test environment that mirrors production: same server sizes, same database engine, realistic data volume.
• A traffic estimate: expected visitors at peak, such as the first 10 minutes after a newsletter goes out.
• A load testing tool: Grafana k6, Apache JMeter or Locust are free and well documented.
• Monitoring on servers and database (Datadog, New Relic or Grafana) so you can see what strains during the test.

How do you run it, step by step?

1. Set performance budgets

Write numeric targets before testing. Jakob Nielsen's three response time limits give a human baseline: 0.1 seconds feels instant, 1 second keeps the flow of thought, 10 seconds loses attention. For web pages, Google's Web Vitals set "good" at Largest Contentful Paint within 2.5 seconds, Interaction to Next Paint within 200 milliseconds and Cumulative Layout Shift below 0.1. Add server budgets such as p95 response time (95% of requests are faster than this) and an error rate below 1%.

2. Script the journeys that matter

Pick 3 to 5 journeys tied to revenue or first impressions: landing page, sign-up, search, checkout, dashboard load. Script each as a sequence of requests with realistic pauses ("think time") between steps. Mix them in the proportions real users follow, such as 70% browsing and 10% buying.

3. Measure a single-user baseline

Run each journey with one user and record response times, plus a Lighthouse report for the main pages. If a page is slow with one user, more users won't help it. Fix obvious problems (huge images, missing database indexes) before load testing.

4. Run the load test at twice expected peak

Ramp up virtual users gradually to your expected peak, then to twice that, and hold for 15 to 60 minutes. Record p95 and p99 response times, error rate and requests per second, along with CPU, memory and database connections. Twice the expected peak covers a traffic estimate that turns out too low, which is the expensive way to be wrong.

5. Run a stress test and a soak test

Keep adding users until the error rate passes 5% or response times explode; note the breaking point and what failed first. Then run normal load for 2 to 8 hours and watch memory and connections. A graph that climbs steadily during a soak test means a leak that will crash the product on a quiet Sunday.

6. Find and fix the slowest part

Use monitoring and profiling to find where time goes: a slow query, a missing cache, too few database connections, a third-party API call in the request path. Fix the biggest contributor first and rerun the same test, changing one thing at a time so you know what worked.

7. Report and repeat before each release

Write a one-page report: budgets, results per journey, breaking point, fixes made and remaining risks. Save the scripts and add a short load test to your release checklist, so the next feature doesn't quietly undo the work.

Template you can copy

PERFORMANCE TEST PLAN

Expected peak: ____ concurrent users / ____ requests per second (source: ________)
Test target: 2x peak = ____

BUDGETS
Journey        | p95 response | p99 response | Error rate | Page LCP | INP
Landing page   | ≤ ____ ms    | ≤ ____ ms    | < 1%       | ≤ 2.5 s  | ≤ 200 ms
Sign-up        |              |              |            |          |
Search         |              |              |            |          |
Checkout       |              |              |            |          |

TEST RUNS
Run | Type (baseline/load/stress/soak) | Users | Duration | p95 | p99 | Errors % | Req/s | CPU % | Memory | DB connections | Pass/Fail

FINDINGS
Slowest part found | Evidence | Fix | Result after rerun

REPORT
Breaking point: ____ users / ____ req/s, first failure: ________
Remaining risks: ________
Release checklist test: script ____, run before every release

Worked example: a ticket booking site for local events

This is an illustrative case with invented numbers. A founder sells tickets for small concerts and expects 2,000 visitors in the first 10 minutes when a popular show goes on sale, roughly 300 people choosing seats at once. Budgets: p95 under 800 ms for seat selection, errors below 1%.

The single-user baseline looks fine at 220 ms. At 300 virtual users the picture changes: p95 reaches 2.9 seconds and 4% of seat requests fail. Monitoring shows the database at full load from one query that checks seat availability without an index, and only 10 database connections available to the app.

She adds the index, raises the connection pool to 40 and caches the event page for 30 seconds. Rerun at 600 virtual users (twice peak): p95 is 480 ms and errors are 0.2%. The stress test breaks at around 900 users, when the payment provider's test endpoint starts rate-limiting. A four-hour soak test shows flat memory. She launches with a queue page ready for anything above 800 users.

What should you measure, and when do you stop?

Stop when every journey meets its budget at twice expected peak, the breaking point is known and the soak test is flat. If the breaking point sits below twice peak after two fix rounds, the problem is design-level; take it to the technical architecture review SOP.

Which mistakes should you avoid?

• Testing against production on launch week. Use a copy, or schedule a quiet window and warn your hosting provider.
• Testing with an empty database. Queries that fly on 100 rows crawl on 1 million. Load realistic data first.
• Reading averages. An average of 300 ms can hide 10% of users waiting 5 seconds. Read p95 and p99.
• Hammering one URL. Real users click through journeys with pauses; scripted journeys find the real slow spots.
• Forgetting third parties. Payment, email and map APIs have their own limits; test with their sandbox and read their rate limits.

How can AI speed this up?

AI coding assistants write k6, JMeter or Locust scripts from a description of your journeys, and they read profiler output or slow query logs and suggest likely fixes. Paste a test summary and ask which metric moved and why. Verify every suggested fix with a rerun, since AI advice on database tuning sounds confident and can make things worse. Keep production credentials and customer data out of the prompts.

Where does this SOP fit in your validation plan?

Performance testing comes after the product works end to end and before you send traffic to it.

1. Prove the hard part first with the proof of concept SOP.
2. Check that connected services behave together with the integration testing SOP.
3. Plan for growth beyond the next peak with the technical scalability assessment SOP.
4. Time the launch with the product launch strategy validation SOP.

See all Technical Validation SOPs. Page speed also affects search visibility, so the free digital marketing and SEO module of the F/MS startup school and the 100 SEO methods collection are worth a look once your pages pass.

FAQ

What is the difference between load testing and stress testing?

A load test runs your expected peak traffic to check the product stays inside its budgets. A stress test keeps adding users until something breaks, to find the limit and see how it fails.

What is a good response time for a web app?

Aim for p95 under 1 second for most actions, in line with Nielsen's limit for keeping the user's flow of thought, and under 200 ms for interactions that should feel instant.

Which tools can a startup use for performance testing?

Grafana k6, Apache JMeter and Locust are free load testing tools. Lighthouse and PageSpeed Insights check page speed, and Datadog, New Relic or Grafana show what strains on the server.

How many virtual users should I test with?

Twice your expected peak of simultaneous users for the load test, then keep increasing for the stress test until it breaks.