Performance Checker
Instantly audit any website – no account required.
UpMonitor's Website Performance Test measures your website's Time to First Byte (TTFB), TLS handshake time, and total response latency from multiple global regions. It helps identify performance bottlenecks and server response issues. Results are delivered in under 3 seconds. Free to use — no signup or login required.
Measure your website's response speed and identify performance bottlenecks — instantly, for free.
Why Performance Monitoring Matters
Website speed directly impacts your bottom line. Studies consistently show:
- 53% of mobile users abandon a site that takes longer than 3 seconds to load.
- A 100ms improvement in page load time can increase conversion rates by 1%.
- Google uses page speed as a ranking factor in both desktop and mobile search results.
- Slow sites cause higher bounce rates, lower ad revenue, and reduced customer trust.
Performance isn't just a developer concern — it's a business metric.
What We Measure
⚡ Time to First Byte (TTFB)
What it is: The time elapsed from the moment a browser sends an HTTP request to the moment it receives the first byte of the server response.
Why it matters: TTFB reflects your server's processing speed — including database queries, server-side rendering, and backend logic. It's the most accurate single metric for measuring raw server performance.
| TTFB | Rating |
|---|---|
< 200ms |
Excellent 🟢 |
200–500ms |
Good 🟡 |
500ms–1s |
Needs Improvement 🟠 |
> 1s |
Poor 🔴 |
⚡ DNS Resolution Time
The time taken to resolve your domain name to an IP address. Fast DNS is critical because it's the first step in every website request. Premium DNS providers (Cloudflare, AWS Route 53) typically resolve in under 10ms.
⚡ TCP Connection Time
Time to establish the TCP connection to your server. High TCP times indicate network latency between your server and the check location.
⚡ TLS Handshake Time
Time to complete the SSL/TLS handshake. If enabled, TLS 1.3 significantly reduces handshake overhead compared to TLS 1.2.
⚡ Total Response Time
End-to-end time from request to complete response received. This is the full page load time as seen from the network perspective.
⚡ Response Size
The total size of the HTTP response body in kilobytes. Oversized responses indicate missing compression (gzip/Brotli).
⚡ Compression Detection
We check whether your server applies gzip or Brotli compression to the response. Text-based responses (HTML, CSS, JS) can be compressed by 60–90%, dramatically reducing transfer size.
Performance Optimisation Guide
Enable Compression
## Nginx — enable gzip
gzip on;
gzip_types text/plain text/css application/javascript application/json;
gzip_min_length 256;
Brotli (smaller than gzip, supported by all modern browsers) requires the ngx_brotli module.
Implement Caching
## Cache static assets for 1 year
location ~* \.(js|css|png|jpg|svg|woff2)$ {
expires 1y;
add_header Cache-Control "public, immutable";
}
Use a CDN (Content Delivery Network)
A CDN serves your static assets from edge nodes close to your users. This alone can reduce global TTFB by 60–80%. Popular options: Cloudflare, AWS CloudFront, Fastly.
Reduce Server Response Time
- Cache database query results (Redis, Memcached)
- Enable server-side HTTP response caching
- Optimise slow database queries with indexes
- Use connection pooling for database connections
Minimise DNS Lookup Chain
- Reduce the number of unique domains your page loads resources from
- Use DNS prefetching for critical third-party resources:
<link rel="dns-prefetch" href="//cdn.example.com">
Upgrade to HTTP/2 or HTTP/3
Modern HTTP versions multiplex multiple requests over a single connection, dramatically reducing latency for pages with many assets.
Interpreting Your Results
| Metric | Target | Action Needed If Exceeded |
|---|---|---|
| DNS Resolution | < 50ms | Switch to faster DNS provider |
| TCP Connection | < 100ms | Consider CDN or closer server region |
| TLS Handshake | < 100ms | Enable TLS 1.3, use session resumption |
| TTFB | < 200ms | Enable caching, optimise backend code |
| Total Response | < 500ms | Reduce response body size, enable compression |
| Response Size | < 100KB | Enable gzip/Brotli compression |
Frequently Asked Questions
What is a good TTFB for a website?
A TTFB under 200ms is considered excellent. Between 200ms and 500ms is good, while anything over 1 second is poor and should be optimized by checking server logic or database performance.
Does a CDN improve server response time?
Yes. A CDN (Content Delivery Network) caches your content on edge servers closer to your users, which significantly reduces network latency and can lower your TTFB for global visitors.
How does TLS 1.3 improve performance?
TLS 1.3 reduces the encryption handshake from two round-trips to just one. This can save up to 100ms of latency during the initial connection setup compared to older TLS versions.
Why is my site slow in only some regions?
Regional slowness is usually caused by physical distance from your origin server or network congestion in a specific area. Using a CDN or deploying your app to multiple regions can solve this.
Track Performance Over Time
A single measurement is a snapshot. Performance degrades gradually — a poorly optimised code deploy, a growing database, a traffic spike. You need continuous measurement.
With UpMonitor, you can:
- ✅ Track TTFB and response time trends over days, weeks, and months
- ✅ Get alerted when TTFB exceeds your defined threshold
- ✅ Compare performance across multiple global monitoring regions
- ✅ Correlate performance changes with deployments