Performance Monitoring
Measure what users actually experience.
A slow website is a broken website. Performance degradation loses conversions, damages SEO rankings, and erodes user trust — often without triggering any availability alert. Performance monitoring tracks response time, time-to-first-byte, and page load duration on a continuous schedule, alerting you the moment latency crosses your acceptable threshold.
Why performance degradation is often invisible
Uptime monitoring tells you when your site is completely unreachable. It tells you nothing about gradual performance degradation — the kind where a database query that took 50ms last month now takes 800ms, or where a CDN misconfiguration added 300ms of latency to every request. These changes don't trigger availability alerts. They just make your site slower, quietly, until users stop converting or Google downgrades your ranking.
Performance problems are also notoriously difficult to reproduce and diagnose after the fact. Without a historical record of response times, answering "when did this start?" is nearly impossible. Was it after the deployment last Thursday? After the CDN configuration change? After the database was migrated to a new host? Without continuous measurement, you're guessing.
Performance also varies by geography. A user on the US East Coast might experience acceptable load times while a user in Singapore sees a 4-second page load due to CDN routing issues. Monitoring from a single location gives you a partial picture. Monitoring from multiple geographies reveals the full picture.
How NetTests measures performance
NetTests sends HTTP requests to your configured URLs on a schedule and records precise timing at each stage of the connection: DNS resolution time, TCP connection time, TLS handshake time, time to first byte (TTFB), and total response time. These metrics are stored for every check, giving you a complete historical record of how performance has changed over time.
Alert thresholds are configurable independently for each metric. You might alert on total response time above 2 seconds for user-facing pages while allowing a higher threshold for API endpoints that perform background processing. TTFB thresholds can identify server-side slowdowns separately from network latency or large response sizes.
Historical charts make it straightforward to correlate performance changes with specific events — a deployment, a configuration change, a traffic spike — so that diagnosing the root cause of a regression becomes a matter of looking at the timeline rather than reconstructing events from logs and memory.
Key features
Time-to-first-byte tracking
Measure TTFB separately from total response time to isolate server-side processing from network and transfer overhead.
Connection phase breakdown
See DNS lookup time, TCP connection time, and TLS handshake time individually — pinpoint exactly where latency originates.
Configurable alert thresholds
Set independent latency thresholds for each monitored URL based on your performance requirements and user expectations.
Historical trend charts
Visualize response time over days, weeks, and months to identify regressions, improvements, and patterns.
Regression detection
Alert when response time increases significantly relative to the recent baseline — not just when it crosses a fixed threshold.
Geographic measurement
Measure performance from multiple geographic locations to surface CDN, routing, or regional infrastructure issues.
Deployment correlation
Annotate the performance timeline with deployment events to immediately identify which change caused a regression.
API endpoint latency
Monitor the response time of your API endpoints alongside user-facing pages — performance affects backend consumers too.
Free performance diagnostic tools
Run a one-off performance check now — then monitor it continuously.
Fetch a URL and report status code, response headers, response size, and total load time.
Measure round-trip latency to a host via ICMP — establish a baseline for network performance.
Combine ping and traceroute to show per-hop latency and packet loss along the full network path.
Send custom HTTP requests and inspect response timing, headers, and body in detail.
Frequently asked questions
What is a good page load time?
Google's Web Vitals guidelines consider a Largest Contentful Paint (LCP) of under 2.5 seconds to be "good." For TTFB, under 800ms is considered acceptable. However, the relevant target depends on your industry and user expectations. Ecommerce research consistently shows that every additional 100ms of load time reduces conversion rates. For API endpoints, response times should be well under 200ms for user-facing calls. The most useful benchmark is your own historical data — track your current baseline and measure improvements relative to it.
What is time-to-first-byte and why does it matter?
Time-to-first-byte (TTFB) measures the time from when a client sends an HTTP request to when it receives the first byte of the response. It reflects server-side processing time, network latency, and the efficiency of your backend stack. A high TTFB typically indicates a slow server-side operation — a slow database query, an overloaded application server, or a cold cache — rather than a network or transfer problem. Monitoring TTFB separately from total response time helps you distinguish between these root causes.
How does performance monitoring affect SEO?
Google uses Core Web Vitals — including LCP, INP (Interaction to Next Paint), and CLS (Cumulative Layout Shift) — as a ranking signal. Slow page load times directly affect LCP scores, which can negatively impact search rankings. Additionally, Google's crawl budget is affected by server response time — a slow server receives fewer crawl requests, which can delay indexing of new or updated content. Continuous performance monitoring helps ensure your site maintains the load times that support strong search performance.
What causes sudden performance regressions?
Common causes of sudden performance regressions include: a deployment that introduced a slow database query, a missing index, or an N+1 query pattern; a CDN configuration change that reduced cache hit rates; an increase in traffic that exposed capacity limits; a third-party script or API call that started taking longer to respond; or infrastructure changes such as a database migration or server resize. Historical performance data correlated with deployment events makes it significantly faster to identify which change caused a regression.
How is performance monitoring different from load testing?
Performance monitoring measures how your application performs under normal production traffic on a continuous basis. Load testing measures how your application performs under artificially elevated concurrent load, typically before a major event or release. Performance monitoring is a continuous production activity; load testing is a periodic assessment. Both are valuable: load testing reveals capacity limits before they're hit, while performance monitoring detects gradual degradation and unexpected regressions in production.
Start tracking performance before it affects users
NetTests measures response time on a schedule, stores historical trends, and alerts you the moment latency crosses your threshold — giving you data to act on, not users to apologize to.
Start monitoring free →