Time to First Byte
Measures how long the server takes to return the first byte of HTML - the single best proxy for backend health and CDN edge proximity.
Measures Time to First Byte (TTFB), total response time, and body size. Grades TTFB as success (≤500ms), warning (≤1000ms), or failure (>1000ms).
Instant audit. No account required.
Three checks, one verdict. Each tile is a primitive your AI agent can read alongside the full JSON payload.
Measures how long the server takes to return the first byte of HTML - the single best proxy for backend health and CDN edge proximity.
Reports the full request-to-last-byte budget so heavy templates and slow upstream APIs cannot hide behind a fast TTFB.
Confirms the response is gzip or brotli compressed and reports the bytes saved versus the identity baseline.
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.
Website speed directly impacts your bottom line. Studies consistently show:
Performance isn't just a developer concern - it's a business metric.
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 🔴 |
End-to-end time from request issued to the full response body consumed. This is the wall-clock latency a browser would observe on the first network round-trip.
The total size of the HTTP response body in bytes. Oversized responses usually indicate missing compression - pair this with our Compression Checker to confirm Gzip/Brotli is on.
For granular DNS resolution timing, see our DNS Checker (reports per-query responseTime). For TLS handshake detail, see the SSL Checker. This performance check focuses on TTFB + total latency; the other tools surface the per-layer breakdown.
## 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.
## Cache static assets for 1 year
location ~* \.(js|css|png|jpg|svg|woff2)$ {
expires 1y;
add_header Cache-Control "public, immutable";
}
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.
<link rel="dns-prefetch" href="//cdn.example.com">Modern HTTP versions multiplex multiple requests over a single connection, dramatically reducing latency for pages with many assets.
| 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 |
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.
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.
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.
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.
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:
Pair the audit you just ran with these checkers - the failure modes tend to travel together.
Sends two requests - one accepting br/gzip, one accepting identity - to detect Gzip, Brotli, or zstd compression and compute the size savings. Also verifies the Vary: Accept-Encoding header.
Measures the size of the initial HTML document and counts declared <script>, <link rel=stylesheet>, <img>, and <iframe> tags. Warns above 500 KB; fails above 2 MB.
Runs Google PageSpeed Insights (Performance, Accessibility, Best Practices, SEO) and layers proprietary audits on top: font self-hosting, SRI, llms.txt readiness, and TTFB classification. Grades on the mobile performance score.
Schedule Performance every minute from 12 regions. Get an AI-drafted remediation prompt the moment a check fails - delivered to your inbox, Slack, or MCP-connected agent.