In this guide 6 sections
Pick three journeys that earn or cost you money, such as sign-in, search and checkout. Fix the test data, device and network, then run each journey repeatedly on a staging copy. Record the median and the slow tail. File the results with the build version, so every later change faces the same test.
Choose three journeys, not the whole system
Measuring everything measures nothing well. Be selective. Pick three journeys that staff or customers complain about, or that carry the most orders, such as signing in, searching a catalogue and posting an invoice.
Write each journey as numbered steps a stranger could repeat. Start at the login page, type this search term, open the third result, add it to the cart. Anyone who follows these steps walks the same path and gets timings you can compare with yours, even if they have never opened the application before. Exact steps matter.
- Sign-in and landing screen
- Search or list screen with a filter applied
- Save or submit step such as order, invoice or booking
- A heavy report or export that people avoid
Fix the data, the device and the network
Numbers move when the test moves. Use a staging copy restored from a recent backup, with customer names scrambled, so the invoice and order tables hold realistic row counts. An empty database flatters every query.
Choose one laptop or one cloud runner, one browser build and one throttled connection profile, then write them down. Disable browser extensions. They add noise. Pause the nightly import and the scheduled report job. Both fight the test for the same CPU and disk.
- Staging restored from backup, personal fields masked
- Same test accounts with the same roles every run
- One browser build and one network throttle profile
- Background jobs paused, or noted if they must run
Record the median and the slow tail
An average hides the bad days. Record the median, which is what a typical user sees. Then record the slow tail at the ninety fifth and ninety ninth percentile, which is what your angriest user sees.
Run each journey many times, drop the first warm-up pass and keep every raw timing in a CSV, with error counts and failed requests on the same row. A fast median with timeouts in the tail is a failure. Count them.
Capture the server side too: CPU, memory, disk wait and the slowest database queries. Browser timing says what users feel. Server numbers say where the time went.
Store it where nobody can quietly change it
Save the scripts, the data snapshot reference, the environment notes and the results sheet in version control or a shared folder, with the date. The baseline is a document. Not a memory. It is not how things felt last spring, when the system seemed quicker.
Write down the application version and the commit hash of the build under test; without them a result six months old cannot be reproduced. Every later comparison then turns into an argument about what changed.
- Test script files, such as a JMeter plan, a k6 script or a saved Lighthouse config
- Results CSV with raw timings and error counts
- Environment sheet: server size, database size, browser build
- Commit hash and release tag
Compare every change with the same test
Before you pay for a bigger instance or a tuning engagement, repeat the untouched test and see whether it matches the baseline within its normal wobble. Two runs of one build rarely agree to the millisecond. Learn how far they drift.
After each change, rerun the identical test and place the new column beside the old one, changing a single thing at a time. If two fixes land together, nobody learns which one helped.
Your next step this week: write the three journeys on a single page and run each of them ten times on staging. That page, with its numbers, is the baseline. Start today.
Baseline record sheet
Three blocks on a single worksheet. The first lists each journey as numbered steps with its test account. The second fixes the environment: staging size, data snapshot date, browser build and throttle profile. The third is a table with median, slow tail, error count and server CPU for each run, with a column per change.
Open a blank worksheet to printQuestions owners ask
How many times should I run each journey?
Enough to see the spread. Ten runs after one discarded warm-up pass is a sensible start, and if the results jump around, check for background jobs sharing the server before adding more runs.
Can I take the baseline on the live system?
Only for reading real traffic through monitoring. Scripted tests that create orders or load the database belong on a staging copy, so customers never feel them and test records never reach the books.
Why not just use the average response time?
An average blends fast pages with painful ones. The median shows the typical visit. The slow tail shows the visits that cause complaints. You need both.
What if staging is smaller than production?
Note the difference on the environment sheet and compare only within staging. The baseline serves a before and after comparison on one setup, never a promise of live numbers.