Website Performance Monitoring: Beyond Uptime Checks

Uptime vs. performance: what's the difference?

Uptime monitoring asks: Is the server responding? If it returns any HTTP 200, the check passes. That's essential but incomplete.

Performance monitoring asks: How well is it responding? It measures how long requests take, whether responses are consistent across time and geography, and what the experience is like for a real user loading the full page — HTML, CSS, JavaScript, images, and all.

You need both. Uptime tells you about binary failures (site is down). Performance tells you about degradation (site is slow, checkout is sluggish, API latency is creeping up).

---

Response time: the most important metric you're probably not watching

Every uptime monitor records response time alongside its up/down check. Response time is the duration between sending the HTTP request and receiving the full response. It's measured in milliseconds.

Why it matters: users have a short patience window. Research from Google and Amazon consistently shows:

• Under 200ms: feels instant
• 200ms–1s: noticeable but acceptable
• 1s–3s: user attention starts wandering; bounce rates rise
• Over 3s: significant abandonment, especially on mobile

PingBase tracks response time for every check and shows it on a time-series chart. This lets you spot trends: a gradual increase in response time often precedes a full outage, and catching the trend early gives you time to investigate before users notice.

---

What to alert on for performance

Don't alert on every spike — transient spikes are normal. Instead, alert when performance degrades consistently:

• Response time exceeds threshold for N consecutive checks — e.g., alert if response time is over 2s for 3 checks in a row. This filters out noise from occasional slow responses.
• Response time increases by X% compared to the weekly baseline — a 50% increase in your API's P95 latency is worth investigating even if you're still under a hard threshold.
• Apdex score drops below threshold — Apdex is a standard metric that combines responses into "satisfied / tolerating / frustrated" buckets based on configurable thresholds.

PingBase alerts when your response time exceeds a custom threshold, so you can define what "slow" means for your specific service.

---

Core Web Vitals: Google's performance benchmark

Core Web Vitals (CWVs) are a set of metrics Google uses to measure user experience, and they're a ranking signal in search. There are three main metrics:

CWVs are measured from real user data (field data, via Chrome User Experience Report) and from lab tests (tools like Lighthouse, PageSpeed Insights, and WebPageTest). Track both: field data shows what real users experience; lab data gives you a controlled environment to test changes.

---

Synthetic monitoring: scheduled performance tests

Synthetic monitoring runs scripted tests against your site on a schedule, from multiple locations. Unlike real-user monitoring (RUM), which captures data from actual visitors, synthetic monitoring gives you consistent, repeatable measurements even when traffic is low.

What you can do with synthetic monitoring:

• Run a full browser render of your homepage every 5 minutes and capture Core Web Vitals
• Script a multi-step user flow (login → view dashboard → complete checkout) and measure how long each step takes
• Test from multiple geographic regions to catch regional slowdowns before they become regional outages
• Compare performance between deploys to catch regressions before they reach users

Tools: Checkly, Playwright-based synthetic tests, WebPageTest (for on-demand) combined with PingBase for continuous HTTP-level monitoring.

---

Multi-location monitoring and perceived performance

Your server might be fast in Virginia but slow in Singapore. If you're targeting a global audience, performance monitoring from a single location gives you a false picture.

PingBase runs checks from multiple locations simultaneously. Beyond catching regional outages (a check that fails in one region but not others), this also gives you a clearer picture of geographic performance distribution — which matters if you're deciding where to add a CDN edge or database read replica.

---

Setting performance baselines

You can't know if performance has degraded without a baseline. The first thing to do when you add a new endpoint to your monitoring stack is record its typical response time and variation. Then set alerts relative to that baseline:

1. Monitor for 1–2 weeks to establish a typical range
2. Set a "slow" alert threshold at 2x the P95 response time
3. Set a "very slow" threshold at 5x — this almost always indicates something is wrong
4. Review baselines after major infrastructure changes (new server, CDN configuration, database migration)

PingBase shows response time history in charts, making it easy to see the trend over time and establish what "normal" looks like for your service.