Performance Testing Guide: Types, Metrics, and Process
What is Performance Testing?
Performance testing is the practice of measuring how a website, application, or API behaves under realistic and heavy usage. It helps you measure how quickly the system responds, how much traffic it can sustain, and how it degrades or recovers when demand exceeds capacity. Performance testing includes load testing, stress testing, soak testing, spike testing, and several related techniques.
Performance is not just about the response time for a single user. A page that loads in half a second for a single user might take 10 seconds or return an error when hundreds of users are active. Performance testing shows how response times, stability, and throughput change as the load increases.
Performance testing is the testing aspect of performance engineering, which also covers designing for performance, watching production, and tuning. This guide focuses on the testing itself: the types, the metrics, and the process.
Why Performance Test Your Application?
Performance problems are generally easier and less expensive (and less stressful!) to address when you find them in a planned test than when your site fails catastrophically in production.
Peak traffic often arrives during launches, sales, and successful marketing campaigns, which are also times when an outage is highly visible and damaging to your brand. Testing beforehand gives your team time to identify bottlenecks, tune the application, and add capacity before real users encounter the problem.
The test results tell you how much load the system can handle, which component reaches its limit first (the bottleneck), and whether a recent code change improved or degraded performance.
Exactly how much performance testing is worthwhile depends on your traffic and the consequences of an outage (see weighing the costs of load testing).
Types of Performance Testing
There are several types of performance testing, and they depend mainly on the amount, shape, and duration of the load. You can usually reuse the same scripts and tools for several types of performance tests by changing the test scenario.
Load Testing
Load testing simulates a realistic number of concurrent users to verify that the system performs acceptably at your expected traffic level. Assuming you have performance and scalability requirements, a baseline load test is usually the best place to start because it answers the immediate question of whether the application is ready for its projected peak. The load testing guide covers this in depth.
Stress Testing
Stress testing deliberately pushes beyond expected capacity to find the breaking point and observe how the system fails and recovers. For example, after verifying that your site handles the expected 500 concurrent users, you might continue ramping to 900 or more to learn what happens when demand exceeds capacity. See the guide to web application stress testing.
Soak and Endurance Testing
Soak testing, also called stability or endurance testing, subjects your application to sustained load for hours or even days. It can expose problems such as memory leaks, gradual connection pool exhaustion, accumulating temporary files, and other resource issues that develop over time. The endurance testing guide covers this technique in detail.
Spike Testing
Spike testing simulates a sudden burst of traffic, such as the surge following a scheduled announcement or viral post. It measures both how the system behaves during the spike and whether performance returns to normal afterwards. The load testing guide covers spike tests alongside the other load shapes.
Front-End Performance Testing
The techniques above mainly focus on server-side capacity because that’s where most load-related bottlenecks are. However, users also experience slowness from rendering pages, executing JavaScript, and loading assets in the browser. The guide to front-end versus back-end performance explains this distinction. Real browser load testing can measure browser-side timing while the back end is under load, giving you a more complete picture of how a website or web application really performs than protocol-level load testing.
Performance Testing Metrics That Matter
Four key measurements are especially useful when interpreting a performance test.
Response time is how long each request or page takes. Pay attention to response time percentiles in addition to the average. A 90th or 95th percentile can reveal slow outliers that the average hides.
Throughput is the amount of work the system completes per second, measured in requests, pages, transactions, or bytes. As long as the system has enough capacity, throughput should generally increase with the load. When throughput levels off while the number of users continues to rise, the system has probably reached a bottleneck. You might also see elevated response times and error rates.
Error rate is the percentage of requests that fail. Error rates might increase when a system is pushed to its breaking point. Under load, you might see errors such as timeouts, connection resets, or HTTP 500 responses from an exhausted database pool. The pages and load levels where errors appear can help identify a scalability bottleneck.
Concurrency is the number of users active at the same time. In most performance tests, concurrency is the input you control (in the form of concurrent bots or virtual users) while response time, throughput, and error rate are the outputs you measure.
Compare the relationship between these metrics to understand how the system’s performance changes as demand increases.
The Performance Testing Process
The basic process is quite similar for most types of performance tests:
- Plan. Decide what traffic to simulate based on analytics or projections, and define concrete acceptance criteria such as a p90 response time and maximum error rate.
- Script. Build scripts that represent important user behavior, including realistic wait times between actions.
- Run. Start with a small validation test, then run the full scenario with an appropriate ramp and duration.
- Analyze. Compare the results with your criteria and identify which measurement or component degraded first.
- Tune and repeat. Fix the current bottleneck and rerun the same test to measure the improvement.
For a detailed guide to the performance testing process, see how to load test a website, which follows the whole process step by step.
Performance Testing Tools
Performance testing tools make up a broad category, but most of the tools differ in two main ways.
Real browser versus protocol-level. Protocol-level tools simulate users by sending HTTP requests directly. This is efficient and well suited to APIs and large test volumes. Real browser tools run complete browsers, which require more resources but also execute JavaScript, load page assets, and capture front-end behavior that protocol-level tests don’t. Loadster supports both approaches with Protocol Bots, Browser Bots, and Playwright.
Open source versus cloud platform. Open source tools like JMeter, k6, Gatling, and Locust are free and flexible, but leave the load generation infrastructure, reporting, and maintenance to you. Cloud platforms handle those pieces at a subscription or usage cost.
We maintain a fact-based rundown of the leading options in our load testing tools comparison, including where each one fits and some tradeoffs to consider.
Continuous Performance Testing in CI/CD
Performance testing is most useful when you run it regularly instead of once a year.
A common continuous approach is to run a short load test against a staging environment for each release candidate, with response time and error-rate criteria acting as a pass/fail gate. If a regression appears, the team can investigate it while the recent changes are still easy to identify. Loadster supports this through its CLI and CI integrations.
Keep the results over time as well. A trend can reveal gradual performance degradation even when every individual test still passes its threshold.
Testing continuously in a staging environment is no substitute for proper load testing and capacity planning in a production-like environment, but it can help you quickly spot performance regressions and deal with them before they impact your real users.
Start Performance Testing
A good first performance test can be fairly simple: write a script for one important user journey, model a gradual ramp to your expected peak concurrency, and evaluate the results with clear response time and error-rate criteria. Use what you learn to improve the scripts and expand coverage in the next test.
If you’d like to try performance testing with Loadster, the free trial fuel is enough to run several tests with no credit card required.