Your users feel every millisecond. A page that takes 1 second to load loses 7% of users; one that takes 3 seconds loses 40%. Web performance monitoring is the practice of measuring how fast your pages actually respond in production and connecting slow transactions back to the code that caused them. Unlike synthetic testing that pings your servers in a lab, real web performance data comes from real browsers hitting your real app — and that's the only measurement that matters to your bottom line.
This guide covers how to monitor real-world web performance with transactions, percentiles, and traces so you can find and fix the slow paths your users experience every day.
Why web performance monitoring matters
Most teams measure performance locally or in staging, then wonder why production feels slow. Local testing can't reproduce real-world bottlenecks: slow networks, old devices, geographic latency, cache misses, and competing requests that only show up under load. A page that renders in 500ms on your M3 MacBook might take 4 seconds on a mid-range Android phone in Mumbai.
Web performance monitoring captures real transaction times from real users. The data tells you:
- How many users experience slow pages
- Which specific endpoints or flows are bottlenecks
- Whether performance is getting better or worse over time
- Which release introduced a regression
This turns performance from a gut feeling into a fact you can act on.
Transactions and how LightTrace measures them
A transaction is a user-facing flow — a page load, an API request, a button click that spawns async work. LightTrace measures the time from start to finish and tags it with metadata: the user, the release, the endpoint, whether it succeeded.
Every transaction gets grouped by name (e.g., GET /api/users) so you can see aggregate performance for that flow. Instead of getting a million individual timings, you see summaries: p50, p75, p95, p99 latencies, throughput, and error rate.
import * as Sentry from "@sentry/node";
Sentry.init({
dsn: "https://<key>@your-lighttrace-host/1",
tracesSampleRate: 1.0,
environment: "production",
release: "web@2.1.0",
});
// For Express, transactions are automatically created for each route
app.get("/api/users", (req, res) => {
// LightTrace measures from request start to response finish
// and reports p50/p75/p95/p99 latencies
res.json(users);
});For frontend transactions, the SDK measures page navigation:
// In @sentry/react or @sentry/browser
Sentry.init({
dsn: "https://<key>@your-lighttrace-host/1",
tracesSampleRate: 1.0,
});
// Page transitions are automatically timed as transactionsTransactions are the building blocks of performance monitoring. They're created automatically by the SDK, but you can also start them manually to measure any flow—checkout flows, background syncs, or long-running operations.
Percentiles: why average is a lie
The average response time hides your worst experiences. If one user gets a 10-second response and 99 users get 100ms, the average is 200ms — a number that tells you nothing about the outliers.
P95 vs P99 latency measures the experience of the slowest users. P95 means 95% of requests finished faster than this time; P99 means 99% finished faster. If your P99 is 8 seconds, then 1 in 100 users waits 8 seconds. Over millions of requests, that's a lot of frustrated users.
LightTrace shows you the full distribution: p50 (median), p75, p95, p99, and the max. If P50 is 200ms but P99 is 5 seconds, your problem isn't typical users — it's rare, catastrophic slowdowns. Now you know to hunt for the edge case.
Throughput and tail latency matter equally
A fast endpoint that processes 10,000 requests a second is more important to optimize than a slow endpoint processing 10 requests a second. LightTrace surfaces both throughput (requests per second) and latency so you prioritize impact.
Similarly, tail latency (P95/P99) usually hurts more than average latency because it's concentrated in specific use cases. A checkout flow hitting P99 every time someone pays will kill conversion even if average is fine.
Connecting slow transactions back to the code
A transaction that takes 5 seconds tells you that something is slow. To find what, you need distributed tracing. LightTrace breaks each transaction into spans — discrete pieces of work like database queries, HTTP calls, or function execution.
When a transaction is slow, you navigate to the span waterfall and see every millisecond accounted for: 200ms on the database query, 500ms on the external API call, 100ms on serialization. Now you know exactly where the time went and what to optimize.
GET /api/product/123 — 1250ms total
├─ Parse request — 5ms
├─ Query database (SELECT * FROM products WHERE id = 123) — 800ms ← SLOW
├─ Fetch recommendations from external API — 300ms
├─ Serialize JSON — 50ms
└─ Send response — 95ms
If the database query is the bottleneck, you check your indexes or look for N+1 query problems. If it's an external API, you consider caching or timeouts. The spans turn a mystery "slow endpoint" into actionable data.
Enable source maps for JavaScript so spans in browser transactions resolve to your actual component names and function calls, not minified code. The exact source location makes debugging 10x faster.
Correlate performance with releases
Performance regressions often ship silently. A new feature, dependency upgrade, or database schema change can double latency without triggering an alert. That's why every transaction must be tagged with a release.
LightTrace compares P95 latencies across releases so you spot when a deploy introduced a slowdown. If release web@2.0.5 had P95 of 800ms and web@2.0.6 jumped to 2000ms, you've found the culprit. Rollback or fix the regression immediately.
Building the intuition for normal
Your baseline matters. What's "slow" depends on what users expect. A search API should respond in under 200ms; a batch export can take 30 seconds. Set threshold-based alerts so you're notified when P95 for a critical flow spikes beyond normal.
The best practice is to define error budgets — a tolerance for slowness (similar to error budgets for reliability). If your SLO says checkout should be under 2 seconds for 95% of requests, every request slower than that burns budget. Once budget is exhausted, you stop shipping features and focus on performance.
Getting started with LightTrace
Add the Sentry SDK to any app and point it at LightTrace. Transactions start flowing immediately. In the dashboard, you'll see latency percentiles, throughput, and a breakdown of which endpoints are slowest. Click into a slow transaction to see the span waterfall and trace it across services if you're running multiple backends.
For production JavaScript apps, make sure you're uploading source maps so client-side transactions resolve to your real code. Then set alert rules to page you if P95 on a critical flow spikes.
Start tracking errors in minutes
Start monitoring real-world web performance with LightTrace — capture transaction percentiles and trace every slow page back to the code behind it.
Performance monitoring is the difference between shipping fast and shipping right. You can't fix what you don't measure, and you can't measure what doesn't happen in production. The data is there — you just have to look.