Key takeaways
- Software performance engineering (SPE) is the practice of setting performance goals, predicting and designing for them, and then checking them in test and production. Performance testing is one activity inside it.
- Set targets from what users and the business need, in percentiles, before the design is fixed.
- The cheapest fixes are design decisions made before the code exists, which is why SPE starts early.
Software performance engineering is a systematic, quantitative approach to building software that meets its performance requirements. It treats speed, throughput and capacity as design goals from the first planning meeting, not as something to check just before release. Performance testing, the part most teams already do, is one activity within it. This guide explains what SPE covers, how it differs from performance testing, and how to start without a dedicated team.
What is software performance engineering?
The field’s reference text is Performance Solutions by Connie U. Smith and Lloyd G. Williams. The overview on Smith’s own site defines software performance engineering as a systematic, quantitative approach to the cost-effective development of software systems that meet performance requirements. The process begins early in the lifecycle, uses simple models of the planned architecture and design to predict where problems will appear, and continues through coding and load testing to track results against the targets (perfeng.com, SPE overview).
In day-to-day terms that means five things: agree numeric goals, estimate the cost of the design before building it, measure early builds, test under load before release, and watch production. The aim is to find a slow design while it is a diagram, not after it has shipped.
What is the difference between performance engineering and performance testing?
Performance testing measures how a system behaves under a defined load and reports the result. Performance engineering decides what the system should achieve, shapes the design to get there, and uses testing and monitoring as evidence. A team can test without engineering, and then learns about problems late.
| Performance testing | Software performance engineering | |
|---|---|---|
| Question | Does this build meet the target under this load? | How do we make sure the system can meet its targets at all? |
| When | Mostly test and pre-release, plus automated runs | From requirements through design, build, test and production |
| Output | Measurements, pass or fail | Targets, design decisions, models, test and monitoring plan, fixes |
| Who | Testers, QA, performance specialists | Architects, developers, testers and operations together |
| Example | A load test of checkout at expected peak | Choosing a cache and a queue for checkout because the peak order rate rules out a synchronous design |
The same split is why the mistakes teams make in performance testing so often start before the first script: no target, no baseline, no realistic traffic.
Why does software performance engineering matter?
Slow software costs money in lost sessions and extra infrastructure, and changing a design late costs far more than changing it early. A frequently quoted figure says a 100 ms delay in page load time can cut retail conversion by 7%. It comes from Akamai’s April 2017 retail performance report, which analysed about 10 billion retail visits across the US, Europe and Asia Pacific, and it is specific to page load time on retail sites; do not apply it to your API without your own data. Measure the link between latency and your own business metric instead, such as abandoned checkouts per response-time band, because that is the number that will justify the work in your company.
Other benefits are plainer and need no statistic: fewer incidents caused by load, less money spent on oversized servers, and fewer emergency rewrites before a launch.
How does the performance engineering lifecycle work?
Treat it as a loop with six stages. Each has a concrete deliverable.
| Stage | What you do | Deliverable |
|---|---|---|
| 1. Plan | Turn user expectations and business goals into numeric targets and non-functional requirements | A one-page list of targets, e.g. checkout p95 under a limit at a stated order rate |
| 2. Design | Estimate load and cost of the architecture, compare options, set performance budgets | A short model or spreadsheet and a decision on caching, queues, data access |
| 3. Build | Profile hot paths, run micro-benchmarks, review queries | Findings fixed before merge |
| 4. Test | Baseline, load, stress and soak tests under realistic traffic | Results compared with the targets |
| 5. Operate | Monitor response time, errors and saturation in production, alert on breaches | Dashboards and alerts tied to the targets |
| 6. Improve and plan capacity | Fix the top bottleneck, re-test, forecast growth | A prioritised backlog and a capacity estimate |
Write targets with the help of sample non-functional requirements and, for web pages, performance budgets.
Which performance metrics should you track?
- Response time as percentiles (p50, p95, p99): averages hide the slow tail, which is where users complain. See why percentiles beat averages.
- Throughput: requests or transactions per second, covered in what is throughput.
- Error rate: the share of failed requests.
- Resource utilisation: CPU, memory, disk and network, to see how close to saturation you are.
- A business metric alongside them, such as completed checkouts, so a change in speed can be tied to an outcome.
Which tools help at each stage?
Name the job first, then the tool. Examples of widely used options:
| Job | Examples |
|---|---|
| Load and stress testing | Apache JMeter, k6, LoadFocus (runs JMeter and k6 tests from 25+ cloud regions) |
| Metrics and dashboards | Prometheus, Grafana |
| Tracing slow requests | OpenTelemetry, Jaeger |
| Profiling code | Your language’s profiler, such as perf on Linux |
| Front-end speed | Lighthouse, or LoadFocus page speed monitoring |
| Production API checks | LoadFocus API monitoring |
No single tool covers the whole lifecycle, and none replaces the targets from stage 1.
How do you start with performance engineering?
- Baseline. Load test your two or three main user flows and record p95 latency, throughput and error rate. The quick baseline guide walks through it. This is your reference for every change.
- Write targets. Even rough ones: “search p95 under 800 ms at 200 requests per second”. A wrong target you can correct beats none.
- Shift checks left. Run a short load test in the CI pipeline and fail the build when a threshold is broken. Most tools can return a non-zero exit code when a limit is exceeded.
- Test before launches. Run a full test at expected peak with a realistic traffic mix and from the regions your users come from, before each major release or campaign.
- Monitor and review. Watch the same metrics in production, and put a performance review on the agenda of design discussions.
Common pitfalls in performance engineering
- Testing only at the end, when design-level problems are too expensive to fix.
- Using averages instead of percentiles, which hides tail latency.
- Ignoring the client side: users feel rendering time, not only server time.
- Testing unrealistic conditions: one fast network, a tiny dataset, no concurrency.
- Optimising code that is rarely used while a busy endpoint stays slow. Look at where users spend their time first.
Frequently Asked Questions
What is the difference between performance testing and performance engineering?
Performance testing measures a system under load and reports results. Performance engineering sets the targets, shapes the design to meet them and uses testing and monitoring as evidence throughout the lifecycle. Testing is one part of engineering.
When should performance engineering start?
At requirements and design, before the architecture is fixed. Even a prototype can have a target and a baseline, and early numbers are cheap to collect.
How do I know if my performance improvements are working?
Compare the same measurements before and after under the same load: response-time percentiles, throughput, error rate and resource use. Then check the business metric the target was meant to protect.
How can I add performance checks to CI/CD?
Run a short load test in the pipeline with pass or fail thresholds, for example a p95 limit and an error-rate limit, and let the tool’s exit code fail the job. Keep long tests for scheduled runs.
Do I need a dedicated performance engineer?
Not to start. A developer who owns the targets, a baseline test and a production dashboard covers most of the value for a small product. Dedicated specialists matter when the system is large or latency-critical.
Sources
- Definition and process of SPE: perfeng.com, Software Performance Engineering overview; Connie U. Smith and Lloyd G. Williams, Performance Solutions, Addison-Wesley (October 2026)
- Conversion and load time: Akamai, “Online Retail Performance Report: Milliseconds Are Critical” press release, April 2017 (the akamai.com newsroom page needs JavaScript, so the wording was checked on a trade-press copy dated 24 April 2017; secondary coverage reports different splits by device, so the figure is quoted as a headline claim only; the report PDF itself was not read) (October 2026)
- LoadFocus capabilities: loadfocus.com/index.md and loadfocus.com/load-testing (October 2026)
