What is TTFB?
TTFB measures how long the browser waits from making a request to receiving the first byte of the server's response. It is the foundation metric that all other load performance sits on — a slow TTFB adds directly to LCP and every subsequent paint.
Google's TTFB thresholds
Good
≤ 800ms
Needs improvement
800ms – 1.8s
Poor
> 1.8s
What Time to First Byte (TTFB) means
Time to First Byte (TTFB) measures server responsiveness. It captures the time from when the browser initiates a navigation request to when the first byte of the HTML response arrives. This single number encompasses DNS lookup, TCP handshake, TLS negotiation, and server processing time — everything that happens before any content can reach the user.
TTFB is often overlooked in favour of LCP and INP, but it is the ceiling for all other metrics. If your server takes 1.2 seconds to respond, your LCP cannot possibly be under 1.2 seconds — regardless of how well you optimise images, fonts, and JavaScript. Every millisecond saved in TTFB flows directly into every subsequent metric on the page.
For Next.js applications on Vercel, TTFB performance depends heavily on where the request is processed. A Server Component that runs in a single AWS region far from the user, or one that blocks on a slow database query before streaming any HTML, can easily produce 600–1200ms TTFB. The solution is a combination of edge deployment, aggressive caching, and streaming HTML delivery.
Common causes of poor TTFB
- Server running in a single region far from the user
- Slow database queries that block the response before any HTML is sent
- No edge caching — every request hits the origin
- Cold starts on serverless functions with large bundle sizes
- Missing or misconfigured Cache-Control headers
- Synchronous middleware that adds latency to every request
How to improve TTFB
- Deploy to Edge Runtime (export const runtime = 'edge') for mostly-static pages
- Add revalidate or fetch cache options to cache responses at the Vercel edge
- Use stale-while-revalidate to serve cached HTML while revalidating in background
- Move product/content data to an edge-native database (Neon, PlanetScale, Turso)
- Stream HTML with Suspense so the shell sends before data queries complete
- Add a Redis/KV cache layer for frequently-read, rarely-changed data
Frequently asked questions about TTFB
What is a good TTFB score?
Google considers a TTFB of 800ms or less as 'Good'. However, for competitive performance on Vercel Edge with proper caching, teams regularly achieve under 50ms for static or edge-cached pages. Target under 200ms for dynamic server-rendered pages.
How does TTFB affect LCP?
TTFB sets the floor for LCP. The browser cannot begin parsing HTML, discovering images, or loading fonts until the first byte arrives. A 600ms TTFB means at minimum 600ms of your LCP score is pure server wait — irrelevant of how optimised your frontend is.
How do I reduce TTFB on a Next.js app?
The most impactful changes are: use Edge Runtime for marketing pages, add revalidate caching to avoid hitting the origin on every request, move slow data fetches behind Suspense boundaries so HTML streams immediately, and use a globally distributed database for dynamic data.
Why does my TTFB vary so much between users?
TTFB varies by geographic distance to your server, network conditions, and whether the request hits a cached edge response or the origin. Users in regions far from your server's AWS region will see significantly higher TTFB than users in the same region — which is why edge deployment matters.
How does AuditJet track TTFB over time?
AuditJet measures TTFB on every scheduled Lighthouse audit from a fixed test region, giving you a consistent trend line rather than a one-off snapshot. When TTFB degrades — due to a slow deploy, a new database query, or a caching misconfiguration — AuditJet flags the regression alongside Google PageSpeed Insights field data for comparison.
Monitor TTFB continuously.
AuditJet tracks TTFB across all your pages on a scheduled basis and alerts your team the moment it regresses.