Performance Testing: Load Testing, Stress Testing, and Website Speed

What Is Performance Testing

Performance testing is the practice of measuring how a system behaves under a defined workload. Instead of asking "does this feature work," which is the job of functional testing, performance testing asks "how fast does it work, for how many people at once, and what happens when demand exceeds capacity." The workload might be a single user loading a page on a slow phone, five hundred concurrent shoppers checking out at once, or a sustained stream of API calls running for twelve hours straight. Each scenario exposes a different class of problem, and a complete performance testing strategy covers all of them.

The practice splits naturally into two halves. Backend performance testing, usually called load testing, uses tools that generate synthetic traffic against servers and APIs. These tools simulate virtual users, each one sending requests the way a real client would, and record how response times, error rates, and throughput change as the number of virtual users grows. Frontend performance testing measures what happens inside the browser: how long until the page shows its main content, how long until it responds to a tap, and how much the layout jumps around while loading. Google formalized the frontend side with Core Web Vitals, three metrics that now feed directly into search rankings.

Both halves matter because they fail independently. A backend that serves API responses in 40 milliseconds can still power a site that takes eight seconds to become interactive because of an oversized JavaScript bundle. A beautifully optimized frontend can still time out when the database behind it hits its connection limit on a busy day. Teams that only test one half consistently get surprised by the other, which is why this guide treats load testing and speed testing as two parts of one discipline.

Why Performance Matters

Performance is a business metric wearing an engineering costume. Amazon famously measured that every 100 milliseconds of added latency cost about 1% in sales. Google found that increasing search results from 400 to 900 milliseconds dropped traffic and ad revenue by 20%. Walmart reported that every 1 second improvement in page load time increased conversions by up to 2%. Numbers vary by industry, but the direction never does: slower sites sell less, retain fewer users, and pay more for the same advertising because quality scores punish slow landing pages.

Search visibility depends on it directly. Since Google's page experience update, Core Web Vitals are a ranking signal, and field data collected from real Chrome users determines whether your pages pass. A site that fails the thresholds is competing with one hand tied behind its back, especially in competitive niches where content quality is roughly equal and tie-breaker signals decide who gets position three versus position eight.

Outages are the expensive way to learn your capacity limits. Ticketing sites crash on tour announcements, retail sites crash on Black Friday, and government portals crash on filing deadlines, all for the same reason: nobody ran a stress test that answered the question "what happens at five times normal traffic." A load test that costs a day of engineering time answers that question safely. A production outage answers it in front of your customers, your executives, and occasionally the press.

Performance also compounds quietly. Each new feature adds a query here and a script there, and no single change feels slow. Without regression testing, a product that launched fast degrades a few percent per sprint until someone important notices it feels sluggish. By then, the slowness is spread across two years of commits and nobody can say where it came from. Continuous performance testing catches each regression while the change that caused it is still fresh in someone's head.

Types of Performance Testing

Performance testing is an umbrella term covering several distinct test types. Each answers a specific question, and mature teams run most of them at different points in the release cycle. The full comparison lives in our load testing vs stress testing guide, but here is the map.

Load Testing

Load testing simulates expected traffic to verify the system meets its performance targets under realistic conditions. If your analytics show 300 concurrent users at peak, a load test ramps up to 300 virtual users running realistic journeys and holds there for 15 to 30 minutes while measuring response times and error rates. Passing means p95 response times stay under your thresholds and errors stay at zero. Load testing is the baseline test type, the one to start with if you have never performance tested at all.

Stress Testing

Stress testing keeps increasing load past expected levels until the system degrades or fails, to find the actual capacity ceiling and observe the failure mode. The output is two numbers and a behavior: the load level where response times start climbing, the level where errors begin, and what failure looks like, whether that is graceful 503 responses with Retry-After headers or cascading timeouts that take down neighboring services. Knowing your ceiling turns capacity planning from guesswork into arithmetic.

Spike Testing

Spike testing jumps from normal load to extreme load almost instantly, simulating a flash sale, a viral post, or a TV mention. It measures whether autoscaling reacts fast enough, whether requests are dropped during the surge, and how long the system takes to recover afterward. Systems that pass gradual stress tests often fail spike tests because scaling takes minutes while spikes take seconds.

Soak Testing

Soak testing, also called endurance testing, runs moderate sustained load for hours or days. It catches slow failures that short tests cannot see: memory leaks, connection pool exhaustion, log files filling disks, and scheduled jobs colliding with traffic. A service that looks perfect in a 10 minute test can still fall over every night at 3 a.m., and a soak test is how you find out before production does.

Scalability and Volume Testing

Scalability testing measures how performance changes as you add resources: double the servers and see whether capacity actually doubles or gains fall off because of a shared bottleneck like a single database writer. Volume testing focuses on data size rather than request rate, verifying that queries which are instant against ten thousand rows are still acceptable against fifty million. Both matter for systems that expect growth, because they predict what next year looks like instead of just describing today.

Performance Metrics That Matter

Every load testing tool reports a pile of numbers, and misreading them is the most common way performance testing goes wrong. Four metrics carry most of the signal.

Response time percentiles describe what users actually experience. The median (p50) is the typical experience, p95 is the experience of the slowest 1 in 20 requests, and p99 catches the outliers. Averages are actively misleading because a handful of 10 second responses hide easily inside thousands of fast ones. Set your targets on p95 and p99: a common baseline is p95 under 500 milliseconds for page-generating requests and under 200 milliseconds for simple API reads. When a stakeholder asks "is the site fast," the honest answer is a percentile, not an average.

Throughput is the number of requests per second the system processes. Watch how it moves with load: healthy systems show throughput rising in step with virtual users while response times hold flat. When throughput plateaus while load keeps rising, the system is saturated, and response times will start climbing immediately after. That plateau is your effective capacity, and planning to run at 50% to 70% of it leaves room for spikes.

Error rate should be zero under normal load, full stop. Errors that appear as load rises mark the beginning of the end for that configuration, and the pattern matters as much as the number. Clean 503 responses mean the system is shedding load deliberately. Timeouts and connection resets mean it is drowning. Track error rate against the load level where it first moves off zero, because that number is your hard ceiling.

Server resource metrics, meaning CPU, memory, disk I/O, network, connection pools, and thread counts, explain the other three metrics. Response times that spike when CPU hits 90% point to compute as the bottleneck. Errors that appear when the database connection pool empties point somewhere entirely different. Load test results without server metrics tell you that something is slow but not why, so wire up monitoring before the first serious test run.

Load Testing Tools

The load testing tool market has a clear open source core and a commercial layer on top. Our full tool comparison covers the field in depth; this is the short version.

k6, from Grafana Labs, is the modern default for developer teams. Tests are JavaScript files, the engine is a fast Go binary, thresholds turn tests into pass/fail CI gates, and a single laptop can simulate thousands of virtual users. If you are starting from zero and your team can read JavaScript, start here.

Apache JMeter is the veteran, maintained since 1998, with the broadest protocol support in open source: HTTP, JDBC, JMS, LDAP, FTP, SMTP, and more through plugins. Its GUI builds test plans visually, which suits testers who prefer configuration over code, and its distributed mode coordinates load generation across many machines. The costs are JVM resource appetite and XML test plans that version control poorly.

Locust brings load testing to Python. User behavior is a Python class, which means loops, conditionals, data handling, and every Python library are available inside your scenarios. Its web UI shows live charts during runs, and master/worker mode distributes load across machines. For Python shops it is the obvious choice.

Gatling, built on an async event-driven engine, generates very high concurrency per machine and produces the best HTML reports in open source. Scripts use a Scala, Java, or Kotlin DSL. Artillery covers HTTP plus WebSocket and Socket.IO with simple YAML scenarios. On the commercial side, LoadRunner remains the enterprise incumbent, BlazeMeter runs JMeter and other open tools at cloud scale, and Grafana Cloud k6 does the same for k6, adding geographic distribution and hosted dashboards.

Hiring help is reasonable when performance testing is a one-time need rather than an ongoing practice, and freelance engineers on Fiverr will script and run a load test against your staging environment for far less than a consultancy engagement. For teams building the skill in house, Zero to Mastery has project based courses covering the coding and DevOps foundations that load testing sits on.

Frontend Performance and Website Speed

Backend capacity means little if the page itself is slow in the browser, and for most content and commerce sites the frontend is where the user-visible seconds hide. Frontend performance work revolves around a small set of measurements taken two different ways.

Lab data comes from controlled test runs. Lighthouse, built into Chrome DevTools and available from the command line, loads your page under throttled CPU and network conditions and scores it 0 to 100 across weighted metrics. Lab tests are reproducible and diagnostic: they tell you exactly which script, image, or stylesheet is costing time. Website speed test tools like PageSpeed Insights, WebPageTest, and GTmetrix wrap the same engine with different reporting and test locations.

Field data comes from real users. Chrome anonymously reports loading metrics from actual visits into the Chrome User Experience Report, and Google evaluates your Core Web Vitals against the 75th percentile of that data over a trailing 28 day window. The three vitals are Largest Contentful Paint under 2.5 seconds, Interaction to Next Paint under 200 milliseconds, and Cumulative Layout Shift under 0.1. Field data is the ground truth for both user experience and rankings, while lab data is where you diagnose and fix what the field data reveals.

Browser automation closes the gap between the two. Scripting real page loads with Playwright lets you measure navigation timing, capture Web Vitals on any page including ones behind logins, and run those measurements in CI on every deploy. It is the same skill set used across browser automation generally, pointed at performance instead of functionality.

The Performance Testing Process

Effective performance testing follows a repeatable sequence rather than an ad hoc blast of traffic. The steps below work with any toolchain.

First, define targets before touching a tool. Pick concrete numbers: p95 under 400 milliseconds at 200 concurrent users, homepage LCP under 2.5 seconds on mobile, zero errors at twice expected peak. Targets convert test output from trivia into verdicts. Without them, every result reads as "seems okay probably."

Second, model realistic workloads. Pull traffic data from your analytics: which pages get hit, in what ratios, with what think time between actions. A test that hammers one endpoint with identical requests mostly measures your cache. Real user journeys mix reads and writes, spread across endpoints, with pauses between steps, and your virtual users should too.

Third, prepare an environment that resembles production, and be honest about the differences. Testing production-sized load against a staging box with a quarter of the resources produces numbers you must scale mentally, and shared staging databases produce numbers that mean nothing. Where possible, test against production-identical infrastructure, or carefully load test production itself during low-traffic windows with kill switches ready.

Fourth, baseline with a single user before applying load. Single-user response times are your floor. Endpoints that are slow with zero contention have code or query problems that concurrency will only amplify, and fixing them first makes every later test cleaner.

Fifth, run the test matrix in order of increasing violence: load test at expected traffic, stress test to failure, spike test if your traffic pattern includes surges, soak test before major releases. Record everything, including server metrics, because a result you cannot explain is a result you cannot act on.

Sixth, analyze, fix, and rerun. Performance work is iterative: find the narrowest bottleneck, widen it, and test again, because the next bottleneck is usually hiding right behind the one you just removed. Two or three cycles typically produce dramatic improvements. Diminishing returns arrive fast after that, which is when you stop and set up regression monitoring instead.

Performance Testing in CI/CD

The tests above are periodic and heavyweight. The other half of the practice is lightweight checks that run automatically on every change, so performance regressions get caught the day they are introduced rather than the quarter they are noticed.

For backend checks, a short k6 or Locust script running 1 to 3 minutes at modest concurrency, with thresholds on p95 duration and error rate, makes an effective merge gate. The point is not capacity measurement but comparison: if the search endpoint was 150 milliseconds last week and is 700 today, the pipeline flags it while the diff is one pull request instead of fifty. Keep CI load tests against dedicated or containerized environments, because noisy shared runners produce flaky thresholds, and flaky gates get deleted.

For frontend checks, Lighthouse CI runs audits on every build, compares scores and metric values against budgets you commit to the repo, and fails builds that blow the budget. Performance budgets work best as absolute metric limits, for example LCP under 2.5 seconds on a throttled mobile profile, rather than score thresholds, because scores bounce a few points run to run while metric regressions of 20% are unambiguous.

Alongside CI gates, synthetic monitoring runs small performance checks against production on a schedule, catching regressions from infrastructure changes, third-party script updates, and data growth that no pre-deploy test can see. This overlaps with uptime monitoring, covered fully in our website monitoring guide, and pairs naturally with CI/CD test automation for the functional side.

Common Bottlenecks and How to Fix Them

Most performance problems fall into a small number of recurring patterns. Knowing them turns test results into fixes faster.

Database queries dominate backend slowness. The usual suspects are missing indexes, which turn millisecond lookups into full table scans, and N+1 query patterns, where an ORM fires one query per list item instead of one query for the list. Both hide comfortably at development data sizes and explode under production volume. Query logging under load, or an APM tool that traces requests down to queries, finds them quickly, and the fixes, adding an index or batching the queries, are usually small.

Connection pool exhaustion produces a distinctive signature: the system is fine, then abruptly all requests hang or fail together. Every service has pools, database connections, HTTP client connections, worker threads, and the smallest one caps your whole system. Soak and stress tests exist largely to find these limits before customers do. Fixes are sizing the pool correctly, ensuring connections are returned promptly, and adding backpressure so overflow degrades gracefully.

Missing caching makes systems redo identical work millions of times. The fix ladder runs from HTTP caching headers, which let browsers and CDNs absorb repeat traffic, through page and fragment caches, down to application-level caches like Redis for hot query results. Cache the read-heavy, rarely changing data first, because that is where a one line change can remove half your database load.

On the frontend, oversized JavaScript is the top offender: every kilobyte must download, parse, and execute before the page settles, and main thread time is what pushes INP over its threshold. Unoptimized images are second, fixed by modern formats, responsive sizing, and lazy loading everything below the fold except the LCP element itself. Layout shift comes from images without dimensions, injected banners, and late-loading fonts, all cheap to fix once identified. A Lighthouse audit points at all of these by name.

Infrastructure limits arrive last: when code and queries are efficient and the machine is still saturated, you scale vertically with bigger instances or horizontally behind a load balancer. Scaling first and optimizing never is the expensive order of operations, because inefficient code scales its costs right along with its capacity.

Performance Testing Best Practices

Test before you need to. The right time to load test is before launch, before the marketing campaign, and before the seasonal peak, with enough calendar room to fix what you find. Teams that test two days before Black Friday discover their capacity ceiling with no time to raise it.

Change one variable per run. A test after a code change, an instance resize, and a config tweak tells you the combination helped or hurt, but not which part. Disciplined single-variable runs cost more wall clock time and save more debugging time than any other habit in this list.

Watch percentiles, not averages, and keep an eye on error rates even when latency looks fine. A test where p50 improved while p99 tripled is a regression for your unluckiest users, and those are the users who write the reviews.

Correlate load metrics with server metrics on one timeline. The moment response times bend upward should line up with something, CPU, memory, pool usage, disk queue, and that alignment is your diagnosis. Modern stacks make this easy: k6 streams to Grafana, JMeter to InfluxDB, Locust to Prometheus.

Make results comparable over time. Store each run's summary, keep workload models versioned alongside code, and rerun the same scenarios after meaningful changes. A library of comparable results turns "is it getting slower" from a debate into a lookup.

Finally, treat performance as a feature with an owner, a budget, and regression tests, not as a fire drill after complaints. The teams that stay fast are not the ones with heroic optimization sprints, they are the ones where a 20% latency regression fails a build the same day it is written.

Explore Performance Testing