Performance Testing

Performance Testing Overview

A performance test puts a defined number of concurrent users or requests on a website, web application, or API, raises that demand along a planned curve, and records what changes: response times, throughput, error rate, and how much server, database, and network capacity the system used to keep up. The output is a set of numbers compared against a target, not an impression of how fast the site feels.

The target can be a public site, an authenticated journey through a portal or SaaS application, a sequence of API calls, or an internal web application behind a firewall.

The goal is not to make a site fast in general. It is to confirm that its most important pages, workflows, and API calls meet defined requirements at expected traffic levels. A checkout can work normally for one user but slow down or time out when hundreds of customers place orders at once.

Functional testing confirms that a page or transaction works correctly. Performance testing measures whether it remains fast, stable, and reliable as traffic increases.

What Can You Performance Test?

Performance testing commonly covers four HTTP/S targets: websites, web applications, APIs, and internal web applications. Each requires different scripts and measurements.

Why Performance Testing Is Important

The value of a performance test is a specific answer that arrives before users find the problem:

• Bottlenecks show up before release. A slow query or an undersized connection pool appears in a test report instead of a support queue.
• Capacity and scaling plans get verified. Autoscaling rules, CDN cache settings, and instance sizes are assumptions until traffic proves them.
• The journeys that earn revenue stay protected. Login, search, checkout, file upload, and the API calls behind them are the paths to test first.
• Peak events produce fewer slowdowns, errors, and outages. Launches, campaigns, enrollment windows, and seasonal sales often have predictable traffic patterns that can be tested beforehand.
• Regressions get caught. Code, API, database, infrastructure, and external service changes each shift performance a little, and the drift compounds across releases.
• Release decisions and service level objectives get evidence. A p95 number against a target is easier to act on than an opinion that the site “feels slow.”

Types of Performance Testing

Each type applies traffic in a different shape to answer a different question. Most programs combine several.

Endurance testing and soak testing are two names for the same test, not two types. And the line between load and stress testing is the one teams blur most often, so it has its own page: load testing vs. stress testing.

Performance testing is the category. Each type below it changes how much traffic arrives, how fast, and for how long.

Performance Testing vs. Load Testing

Performance testing is the broader practice of evaluating speed, stability, scalability, and resource use under different conditions. Load testing is one type of performance testing focused on expected and peak traffic.

The terms are often used interchangeably because load testing is commonly the first performance test teams run. Other test types are needed to find breaking points, long term degradation, or scaling problems.

For a comparison that also covers stress testing, read performance testing vs. stress testing vs. load testing.

How to Perform Performance Testing

The steps below apply to a landing page, a checkout flow, or an authenticated API sequence.

1. Define the Goal and Acceptance Criteria

State what the test must prove, in numbers. Examples: p95 response time under 2 seconds for checkout at 1,500 concurrent users; error rate below 0.5%; the orders API sustains 400 transactions per second. A test without pass/fail criteria produces data but not a decision.

2. Model Website, Application, or API Traffic

Pull web analytics, access logs, APM data, and business forecasts. Identify the critical pages or journeys, how traffic splits between them, peak concurrency, request rates, think time between steps, the geographic mix, and API calls per session. Page views are not concurrent users: 100,000 daily page views may mean a peak of a few hundred simultaneous sessions, and the model should say which.

3. Prepare a Representative Test Environment

Match the production web stack, application build, database size, CDN and caching behavior, API dependencies, integrations, and scaling rules as closely as practical. Use safe test accounts and payment sandboxes. Where the environment must differ, write the difference down so nobody reads the result as a production guarantee.

4. Choose the Test Type and Testing Method

Pick load, stress, spike, endurance, volume, scalability, or a combination based on the question from step 1. Then choose how to generate traffic. HTTP/S tests send requests directly and are efficient for high request volume against pages and APIs. Real browser tests execute JavaScript and follow multistep user behavior, so they measure what a person waits for. Many teams run protocol tests for scale and a smaller group of real browser users for user experience.

5. Establish a Baseline

Run a controlled test at moderate load before changing anything. This confirms the script completes, the test data is valid, and the load generators are not the bottleneck. Record the result and test conditions because differences in caching, test data, or the environment can make later comparisons unreliable.

6. Run the Test and Monitor the Full System

Increase demand along the planned load curve (a steady ramp, a step, or a sudden spike) rather than applying an unexplained number of users at once. Capture web server, application, infrastructure, database, network, and external service data next to the test results. Without data from the server, you will know something slowed down but not what.

7. Analyze Bottlenecks

Compare results with the acceptance criteria first. Then correlate slow transactions or errors with CPU, memory, database, cache, queue, connection pool, network, and dependency behavior in the same time window. Stop when you can name the component and the condition under which it degrades, not when you have an average response time.

8. Fix, Retest, and Automate

Change one important variable at a time when you can, rerun the same scenario, and compare it with the baseline. Then add smaller regression tests to CI/CD so critical transactions run on every build, and schedule larger tests before major releases, campaigns, and seasonal peaks.

Key Performance Testing Metrics

Test metrics describe what users would experience. System metrics help explain why. You need both for the same minutes of the test to reach a cause.

Test metrics identify symptoms. Server, database, and observability data locate the cause. LoadView performance reports cover the test side, from summary charts down to a waterfall chart for each session. But the server side has to come from your own monitoring or APM, matched to the test timeline.

How to Read Performance Test Results

A few patterns repeat across most web systems. None proves a root cause on its own, but each indicates where to investigate next.

When throughput levels off and response time begins climbing, the system has likely reached a capacity limit.

When to Run Performance Tests

Performance testing is not a one time task before launch. The useful triggers:

• Early in design, while architecture and the important user journeys are still being decided and changes are cheap.
• After meaningful changes to code, database schema, infrastructure, or integrations, including changes to external scripts and CDN configuration.
• In CI/CD, as short regression checks on the transactions that matter most.
• Before major releases, campaigns, seasonal peaks, and migrations, at the traffic level the event is forecast to produce.
• After a production incident, to confirm the fix holds under the conditions that caused it.
• On a schedule, to catch performance drift that no single release explained.

Performance Testing vs. Website Speed Testing

A website speed test loads one page or one session at one point in time, usually with no other traffic on the site, and reports how long it took. It is useful for front end optimization and for comparing one build with another.

Performance testing applies changing levels of traffic or concurrent users to see how a website, application, or API behaves as demand increases. Both report page or response timing. Performance testing adds what a speed test cannot answer: how many users the system supports, the error rate at peak, where throughput flattens, and how long the system stays stable. And a page that scores well on a speed test can still fail at 500 concurrent sessions.

How to Choose a Performance Testing Tool

Judge a cloud performance and load testing tool against the tests you need to run, not a feature count:

• Supports websites, multistep web applications, and the API protocols you use, including authentication flows.
• Can model realistic traffic: browser journeys, API sequences, think time, data variation, and adjustable load curves.
• Provides enough scale for your peak, from locations that match where your users are.
• Supports protocol testing, real browser testing, or both, depending on what you need to measure.
• Produces usable percentiles, error breakdowns, results for each transaction, and reports you can share with people who did not run the test.
• Integrates with CI/CD and with your monitoring or observability tools for the server side.
• Supports internal web applications when testing behind the firewall is required.
• Is maintainable by the people who will create and rerun the tests.

Performance Testing Best Practices

• Start with a specific business or engineering question, then design the test that answers it.
• Build workloads from analytics, logs, and forecasts rather than guesses.
• Test login, search, and checkout transactions, not just the homepage.
• Use realistic data volumes and environments that match production where possible, and document where they differ.
• Separate problems in the system under test from limits in the load generation setup. Check load generator CPU and network before blaming the application.
• Track percentiles, errors, throughput, and server resources together for the same test window.
• Change one major variable at a time when diagnosing improvements.
• Save baselines and compare the same scenario after every change.
• Include external dependencies and geographic latency when they affect the user journey, since production users do not skip them.

Performance Testing With LoadView

LoadView is a cloud load testing platform for measuring the performance of websites, multistep web applications, and APIs under traffic. Load comes from a managed cloud, so there is no load generation infrastructure to build or maintain.

Where request volume is the question, HTTP/S tests send thousands of concurrent requests and report response times, throughput, and errors per endpoint. Where the user journey is the question, web application load testing runs scripts in real browsers, so JavaScript execution and rendering time are part of the measurement. Scripts are recorded with the EveryStep Web Recorder by clicking through the journey once. API load testing covers REST and SOAP endpoints, including authenticated and multistep call sequences.

Load curves are adjustable: a load step curve gradually changes concurrent users over a defined period, a goal based curve generates a required transaction rate within a fixed interval, and a dynamic adjustable curve lets teams change user load while the test runs. Traffic can come from more than 40 zones on the geographically distributed network, so regional latency and CDN behavior are part of the result.

Reports show the execution plan, transactions per minute, response times, and errors by type, with a waterfall chart for each session for tracing a slow transaction to a specific request. LoadView integrates with Jenkins, Azure DevOps, and CircleCI. Jenkins and CircleCI can use a Failed Sessions Threshold to flag builds when failed sessions exceed the allowed percentage. Internal applications can be tested through whitelisted static IPs or a load injector installed on premises with testing behind the firewall.

Performance Testing FAQ