The two families of UI performance testing tools
Lab, synthetic
Load a page under controlled conditions and score it.
Repeatable and comparable. Measures a clean environment with clean data.
Field, real users
Collect timings from actual sessions.
Honest about reality. Tells you after it has already happened to somebody.
What falls between them
Lab tools run against a test environment, which means a small dataset. Field tools see real data volumes and only report after a real user has suffered. So a screen that is fast with ten rows and unusable with two thousand passes the lab and shows up in the field, which is the worst possible order.
Closing that gap does not need a new category of tool. It needs a seeded account the size of a large customer, and the same flows exercised against it before release.
Choosing within each family
Lab tools: prefer ones that measure interaction latency, not only initial load. Load is a one-time cost per session, interaction happens constantly.
Field tools: check whether you can segment by account size. An average across all customers hides exactly the customers who are suffering.
Both: compare against your own history rather than an absolute score. Borrowed thresholds rarely transfer between products.
Segmenting field data so it means something
Real-user monitoring is the more honest of the two families and it is easy to make useless by looking at the wrong aggregate.
An average across all users blends a customer with fifty records and one with fifty thousand, and the second one is the entire signal. So does blending devices, blending geographies, and blending your internal users with your customers. The overall number can improve while your largest accounts get steadily worse, which is the failure mode that costs renewals.
Segment by the dimension your product actually varies on, which for most business software is account size rather than device or network. If the tooling cannot segment that way, the number it reports is not measuring the thing you care about.
The prerequisite nobody lists
A screen that renders instantly because the request silently failed will score beautifully in a lab tool. Correctness is the floor under every performance number, and verifying it is cheaper than any of the tooling above.
Terminal
npm install -g @testsprite/testsprite-cli
testsprite setup
The same setup is available in the TestSprite dashboard if you would rather not install anything locally. The rest of the CLI surface is in the CLI repository.
Where each one runs
Lab tools in the pipeline, on every pull request, comparing against your baseline. Field monitoring always on. Functional verification against a realistically sized account, also on every change, because that is the gap the other two leave open.
The trigger matters more than the mechanism. Pointing it at your deployment event means every change is checked without anyone deciding to; the GitHub App does that from the dashboard, and a GitHub Actions step does it from inside your workflow.
Where TestSprite fits between lab and field
In the gap both leave open: exercising real flows against an environment with realistic data, before release. Coverage is generated from your product and runs on every change, so a screen that works with ten rows and breaks with two thousand is caught by behavior rather than by a percentile.
It also supplies the prerequisite neither family checks. A page that renders instantly because the fetch failed is fast and wrong, and a lab score will not tell you.
Lab tooling keeps measuring load and interaction timing, field monitoring keeps reporting what users experienced. The benefit here is that the failure which only appears at your largest customer's data volume gets found before that customer does.
Is TestSprite in this category?
No. It verifies that flows behave correctly, which is the prerequisite for any performance number meaning anything.
Do we need both lab and field tools?
Yes. Lab gives you a repeatable signal before release, field tells you what actually happened. Neither alone is enough.
What about synthetic monitoring?
A lab tool pointed at production on a schedule. Useful for availability, and it still runs against whatever data that account has.
How large should a seeded test account be?
As large as your largest real customer. Anything smaller and you are testing a case that does not exist in production.
Should performance scores block merges?
A large regression against your own baseline, yes. An absolute score threshold, usually not, because it tracks the benchmark rather than your product.
Lab is too clean, field is too late.
UI performance testing tools are lab or field, and both miss degradation with real data volumes. Seed an account the size of a large customer, exercise flows against it before release, and verify correctness first.