Website Performance Monitoring: What to Alert On

Website performance monitoring covers two measurement systems that share one name and almost nothing else. One watches how fast your server delivers bytes. The other watches how fast a browser turns those bytes into something usable. They need different tools, produce different numbers, and only one of them belongs on a pager.

A speed test is not website performance monitoring

The two get confused constantly. Paste a URL into a free tester and you get one page load, from one machine, on one connection, at one moment. That is a diagnostic. It is genuinely useful when you want to know why a page is slow right now, and it tells you nothing about whether it was slow yesterday.

Monitoring is the same measurement repeated on a schedule and retained. The value is in the second derivative: not the number, but the fact that the number moved after Tuesday's deploy. A test cannot tell you that because it has no yesterday to compare against.

Both belong in a working setup. Run the tester when you are investigating. Run the schedule so you know when to investigate.

The two halves nobody separates

Split every performance metric you have by where it is measured, and the confusion clears up immediately.

Half	Metrics	Measured by	Alertable
Delivery	DNS, TCP connect, TLS handshake, TTFB, download	any HTTP client, from anywhere	yes
Rendering	LCP, INP, CLS	a real browser, or a script in your page	no, report only

Delivery is your infrastructure answering. It is deterministic enough to threshold, attributable to a layer you control, and measurable on every single request without a browser.

Rendering depends on the visitor's device, their connection, their extensions and whatever third-party script marketing added last week. The same page scores differently on a flagship phone and a four-year-old Android. Averaging that into an alert produces noise, not signal. Our breakdown of browser monitoring covers the three different things vendors mean by that term.

What are the Core Web Vitals thresholds?

Three metrics with published cutoffs, assessed at the 75th percentile of real visits. Google's definitions set them as follows, and the percentile is not optional garnish. It is part of the definition.

Metric	Good	Needs work	Poor
Largest Contentful Paint	2.5s or less	2.5s to 4.0s	over 4.0s
Interaction to Next Paint	200ms or less	200ms to 500ms	over 500ms
Cumulative Layout Shift	0.1 or less	0.1 to 0.25	over 0.25

Interaction to Next Paint replaced First Input Delay as a Core Web Vital in March 2024, so any guide still listing FID predates that change. Time to First Byte is not one of the three. It is a supporting diagnostic, and web.dev suggests keeping it at 800ms or below.

That 75th-percentile rule is why these numbers cannot drive alerts. A metric defined over a rolling window of many visits has no instantaneous value to compare against a threshold.

Two sources, two different questions

Lab data comes from a scripted load under fixed conditions. Field data comes from real visits, collected by the Chrome UX Report across a 28-day rolling window.

Repeatability is what lab data buys you, which makes it the right tool for comparing two versions of a page. Field data is representative instead, which makes it the thing Google actually assesses. They disagree constantly. When they do, field data is right about your users and lab data is right about your code.

Neither is wrong. A page rendering in 1.8 seconds on a wired connection in a data centre can take five on a commuter train. Both numbers are accurate accounts of what they measured.

A 28-day window has one consequence worth planning around. A regression shipped today is barely visible in field data for a fortnight, and a fix takes just as long to show up. Anything you need to react to inside an hour has to come from the delivery half.

Which number should actually page someone?

Time to First Byte, measured from more than one region, on the routes that matter. It is the only performance number that is server-attributable, available on every request, and stable enough to threshold without generating false alarms.

Everything else is a chart. LCP belongs on a weekly review, CLS belongs in a pre-release check, and a full page-load figure belongs wherever your team argues about images. None of them should wake anybody.

We tested this split on a staging site by deliberately adding 600ms of server-side latency. The delivery metrics moved within one check interval. The field vitals took days, because they were waiting for enough real visits to shift a percentile. That gap is the whole argument.

Setting up the half you can alert on

An http monitor with a response-time threshold covers delivery. Point it at a real route rather than the homepage, because a cached landing page survives a database that has stopped answering.

curl -X POST https://uptimeroom.com/api/v1/monitors \
  -H "Authorization: Bearer urm_live_..." \
  -H "Content-Type: application/json" \
  -d '{
    "name": "product page",
    "type": "http",
    "target": "https://example.com/products/anvil",
    "intervalSec": 60,
    "regions": ["london", "los-angeles", "singapore"],
    "responseTimeThresholdMs": 1200,
    "alertAfterCycles": 2
  }'

Three regions is deliberate. A single vantage point cannot tell a slow origin apart from a slow path to that vantage point. Website performance monitoring from one location has produced more wrong conclusions than any other configuration choice we see. Six regions are available as of September 2026, with egress addresses published on the probe IPs page. Slow-response alerting sits on the paid tiers, while the timing history is recorded on every plan.

Set the threshold from measured behaviour, not intuition. Watch a week, find your p95, and put the line above it. The reasoning behind that placement is worked through in our guide to response time monitoring.

Pick the routes with the same care. Three checks on pages that share a template and a cache tell you one thing three times. A static page, a database-backed page and an authenticated page tell you three different things, and they fail independently.

Routes behind a login need a token or a header rather than a session, which the headers field on a monitor carries. Keep that credential scoped to reading one harmless endpoint.

Reading the waterfall when it goes slow

A single response-time number tells you something changed and not what. The breakdown tells you where, and every HTTP-family check records it in five segments.

Segment	A jump here usually means
DNS	a resolver problem or a recent record change
TCP connect	network path or saturated connection limits
TLS handshake	certificate chain length, or an OCSP lookup stalling
Time to first byte	your application, your database, your cache
Content download	payload size, or bandwidth between probe and origin

Four of those five are outside your application code. That is the practical case for measuring from outside: an engineer looking only at server-side timers will not find a resolver fault or a chain that grew by one certificate. The complementary scripted-journey approach is covered in synthetic monitoring.

Common mistakes

Alerting on Core Web Vitals. The thresholds are defined over a percentile of a 28-day window. A metric with no instantaneous value cannot cross a line at 3am, so the alert will either never fire or fire on noise.

Measuring the homepage and calling it coverage. Homepages are the most cached and least representative page on most sites. Check a product page, a search result and an authenticated route instead.

Treating an average as the experience. An average hides the tail, and the tail is where complaints come from. Keep p95 and p99; the four golden signals make the same argument about latency.

Ignoring the download segment. A fast TTFB with a slow download is a payload problem masquerading as a network problem. The waterfall separates them in one glance.

Treat website performance monitoring as two jobs sharing one label. Put a threshold on the delivery half, measured from several regions, and let that decide when somebody gets woken. Put the rendering half on a dashboard reviewed weekly and paged on never.

Timing history is recorded on every plan. The free tier covers ten routes at a one-minute interval as of September 2026. That is enough to learn what your own p95 looks like before committing to a number.