A website can remain available while becoming too slow to use. Detect that condition by monitoring server response time and TTFB from outside your network, Core Web Vitals from real browsers, and task-level latency for critical journeys.
Do not turn generic performance anecdotes into a revenue forecast. Establish your own baseline, segment by page and region, correlate speed with conversions or completion rates, and alert when a sustained regression threatens a defined performance SLO.
The Difference Between "Up" and "Fast"
Traditional uptime monitoring answers one question: Is my site responding?
But that's a low bar.
A site can return a 200 OK status code while taking 8 seconds to load. Technically, it's "up." In reality? Users have already bounced.
Response time monitoring answers the more important question: Is my site responding quickly enough to keep users engaged?
Google's current Core Web Vitals guidance defines "good" field performance at the 75th percentile as LCP at or below 2.5 seconds, INP at or below 200 milliseconds, and CLS at or below 0.1. Those are user-experience thresholds, not universal conversion formulas. Measure whether your own key outcomes change as performance changes.
Why Slow Performance Stays Hidden
Unlike downtime, slow performance is sneaky:
1. No obvious error to trigger an alert
Your monitoring might only alert when a site is down. A response time spike from 200ms to 4 seconds? No alert. No awareness. Just frustrated users.
2. It's gradual, not sudden
Performance often degrades slowly. Database queries get heavier. Traffic increases. Third-party scripts pile up. By the time someone notices, you've lost months of potential conversions.
3. You're not the one experiencing it
You test your site from your office with a fast connection. But users on mobile networks in different regions see something completely different. Without monitoring from multiple locations, you're blind to their experience.
4. Analytics don't show you what users didn't do
Google Analytics shows bounce rate, but it doesn't show the user who waited 5 seconds, got frustrated, and never clicked anything. That interaction just... doesn't exist in your data.
Quantify the Cost with Your Own Data
Generic claims such as "one second costs 7% of conversions" are not reliable inputs for your business case. Device mix, user intent, page type, cache state, geography, and the changed metric all matter.
Build an evidence-based estimate:
- Capture field performance and business events using a stable anonymous session or experiment identifier.
- Group page views into latency or Core Web Vitals bands.
- Compare completion rate for the same page type, device class, country, and acquisition channel.
- Exclude outages, campaigns, and product changes that would confound the comparison.
- Multiply the observed change by eligible sessions and contribution margin—not gross traffic.
- Validate with a controlled performance improvement when possible.
For APIs and SaaS workflows, use task completion, timeout rate, retries, support contacts, and churn-risk signals rather than page bounce alone. The latency percentile guide explains why p95 and p99 expose slow-user experience that averages hide.
What Response Time Actually Measures
When we talk about response time, we're measuring the time from when a request is sent to when the server returns a response.
This includes:
- DNS lookup — Resolving your domain to an IP address
- TCP connection — Establishing the connection
- TLS handshake — Securing the connection (HTTPS)
- Time to First Byte (TTFB) — Server processing time
- Content transfer — Downloading the response
Each of these can be a bottleneck. Effective monitoring tracks them all.
Why TTFB matters most
Time to First Byte is often the best indicator of server-side performance. High TTFB usually means:
- Slow database queries
- Overloaded application servers
- Poor caching strategy
- Suboptimal backend code
Treat TTFB as a decomposition signal, not a universal pass/fail threshold. Compare it with your own baseline and hosting architecture; redirects, connection setup, edge caching, server processing, and streaming behavior all affect the measurement. See the dedicated TTFB monitoring guide.
Common Causes of Slow Response Times
If you're seeing slow performance, here are the usual suspects:
1. Database bottlenecks
Unoptimized queries, missing indexes, or too many database calls per request. This is the #1 cause of slow backends.
2. No caching (or broken caching)
Every request hitting your database and running the same computations. Implementing proper caching can cut response times by 10x or more.
3. Third-party scripts
Analytics, chat widgets, advertising pixels — each one adds latency. Some are worse than others. Monitor which ones are slowing you down.
4. Large payloads
Sending too much data. Uncompressed responses. Oversized images. Every byte takes time.
5. Geographic distance
Your servers are in Virginia. Your users are in Sydney. Physics is undefeated — you need a CDN or regional infrastructure.
6. Traffic spikes
Your normal load is fine, but traffic spikes (marketing campaigns, Product Hunt launch, going viral) expose infrastructure limits.
How to Monitor Response Time Effectively
Here's what separates amateur monitoring from professional monitoring:
1. Check from multiple locations
Your server might respond in 100ms from the same data center. But what about users in Europe? Asia? Africa?
Monitor from multiple geographic regions to see what your actual users experience.
2. Set service-specific thresholds
Do not copy one threshold across every endpoint. Set a target per critical path using its historical percentile and user expectation, then alert on sustained breaches—for example, p95 checkout latency above its SLO for 10 minutes. Keep an absolute ceiling for clearly unusable behavior and a baseline-relative alert for regressions.
3. Track trends, not just current values
A response time that creeps from 200ms to 400ms over six months is a problem — even if it never crosses your alert threshold. Look at historical trends weekly.
4. Monitor your critical paths
Not all pages are equal. Prioritize:
- Homepage and landing pages
- Sign up / login flows
- Checkout / payment pages
- Core API endpoints
These are where slowdowns hurt most.
5. Check at realistic intervals
Once-per-hour checks miss most issues. Check every 1-5 minutes to catch problems quickly.
Response Time Monitoring with Webalert
Webalert tracks response time for every monitor automatically:
See the full features list and compare plans on pricing.
- Per-check response time — See exactly how fast (or slow) each check was
- Historical graphs — View response time trends over days, weeks, and months
- Performance alerts — Set thresholds and get notified when response times degrade
- Multi-region monitoring — Check from global locations to catch regional issues
- Status page integration — Display response time data publicly so customers can see your performance
Whether you're monitoring a marketing site, a SaaS app, or an API, you'll always know how fast you're responding — and when something slows down.
Quick Response Time Audit
Ask yourself:
- Do you know your average response time right now?
- How about last week? Last month?
- Do you get alerts when response time degrades (not just when sites go down)?
- Are you monitoring from the same regions as your users?
- Have you set specific response time targets for your most important pages?
If you answered "no" to any of these, you're flying partially blind.
Response Time Monitoring Checklist
- Track p50, p95, and p99 response time per critical endpoint.
- Separate DNS, TCP, TLS, TTFB, and transfer time where the tool supports it.
- Collect Core Web Vitals field data at the 75th percentile, split by mobile and desktop.
- Monitor from the regions where users are concentrated.
- Correlate releases and infrastructure changes with regressions.
- Define performance SLOs and alert on sustained violations.
- Connect performance bands to your own task-completion and commercial metrics.
- Keep synthetic and real-user monitoring together: one is controlled and continuous; the other captures real devices and networks.
For broader browser metrics, continue with Core Web Vitals monitoring.
Primary Sources
- web.dev: Web Vitals — current LCP, INP, and CLS thresholds and 75th-percentile evaluation.
- web.dev: Time to First Byte — TTFB definition, interpretation, and caveats.
- W3C: Navigation Timing Level 2 — normative browser navigation timing model.
- Google Search Central: Page experience — current guidance on page experience and search systems without overstating a single ranking factor.
Ready to monitor more than just uptime?
Start tracking response times free with Webalert →
Explore features or see pricing.
3 monitors. Response time tracking. Performance alerts. Free forever.