TTFB (Time to First Byte)
Definition
TTFB (Time to First Byte) is the time from when a user (or bot) sends an HTTP request until the first byte is received from the server. It reflects server processing speed, network wait time, and physical distance between server and user combined.
TTFB is not an official Core Web Vitals metric, but it is a core component of LCP (Largest Contentful Paint) and the starting point of the page loading pipeline.
Summary
TTFB recommended values: 800ms or below = good / 800–1800ms = needs improvement / above 1800ms = poor. Slow TTFB worsens LCP and lowers crawl efficiency. Improvement priorities: ①CDN adoption ②Server caching ③Hosting upgrade.
Components of TTFB
TTFB is a single value but consists of several internal stages.
DNS Lookup Time
Process of converting domain name (example.com) to IP address. Nearly zero when DNS is cached, but first visits may take tens of milliseconds.
TCP Connection Time
TCP 3-way handshake between client and server. Geographic distance directly affects this. Seoul–Seoul connection: ~1ms; Seoul–US West: ~150ms.
SSL/TLS Negotiation Time
Encryption negotiation in HTTPS connections. TLS 1.3 greatly reduces negotiation time compared to earlier versions.
Server Processing Time
Time from when server receives request until response is generated. Includes database queries, server-side rendering, and cache hit/miss.
First Response Transmission Time
Time for server to send response headers and first byte over the network.
TTFB Recommended Thresholds (Google web.dev)
TTFB thresholds from web.dev:
| Rating | TTFB |
|---|---|
| Good | < 800ms |
| Needs Improvement | 800ms – 1800ms |
| Poor | > 1800ms |
These thresholds are based on real user data (CrUX, Chrome User Experience Report).
Note: TTFB itself is not one of the official three Core Web Vitals (LCP, INP, CLS). However, because LCP includes TTFB, improving TTFB directly improves LCP. See Core Web Vitals for details.
How TTFB Affects SEO
Direct Connection with LCP
LCP is the time until the largest element renders on screen. Breaking down the LCP timeline:
LCP = TTFB + resource loading time + rendering time
Slow TTFB automatically slows LCP. LCP is a core Core Web Vitals metric and directly affects Page Experience ranking signals.
Reduced Crawl Efficiency
Googlebot and AI bots are also affected by TTFB when crawling pages. Slow TTFB causes:
- Increased time per crawl
- Wasted limited crawl budget
- Fewer pages crawlable in the same time
See Crawl Budget for details.
Reduced AI Bot Crawl Frequency
GPTBot, ClaudeBot, and other AI bots also reduce crawl frequency on slow-TTFB sites. Opportunities to be included in AI training data or real-time indexes decrease. See Allowing AI Bots in robots.txt for details.
TTFB Measurement Tools
PageSpeed Insights
Enter a URL at https://pagespeed.web.dev/ for both real user data (CrUX) and lab data. Check TTFB directly in the "Reduce server response times (TTFB)" section.
Chrome DevTools
DevTools → Network tab → click first request → Timing tab → check "Waiting (TTFB)." Useful for local testing but does not reflect real user environments.
GTmetrix
Select server location to measure TTFB from different regions. Select Seoul or Asia server to accurately measure TTFB from Korean user perspective.
WebPageTest
Measurable from locations worldwide. Waterfall chart visualizes full loading timeline including TTFB.
5 Ways to Improve TTFB
1. Adopt CDN
CDN (Content Delivery Network) serves content from edge servers close to users, reducing network delay from physical distance. Static asset caching alone commonly improves TTFB by 50–200ms.
CDNs for Korean users: Cloudflare (Seoul node), AWS CloudFront (Seoul region), Bunny.net.
2. Server Caching
Cache dynamically generated pages to avoid repeating database queries and rendering on every request.
- Redis / Memcached: Cache database query results
- Full page cache: Cache generated HTML in Nginx
- WordPress: W3 Total Cache, WP Rocket
3. Hosting Upgrade
Shared hosting shares server resources among many sites, resulting in high TTFB. Upgrading to VPS or dedicated server reduces server processing time.
For Korean sites: Cafe24 Cloud, AWS Seoul region (ap-northeast-2), NCP (Naver Cloud Platform).
4. Database Optimization
Slow queries are a common TTFB cause. Identify slow queries with MySQL slow query log and add indexes.
5. Migrate to HTTP/2 or HTTP/3
HTTP/2 multiplexes multiple requests over a single connection, reducing connection overhead. HTTP/3 is UDP-based for fast response even with packet loss.
TTFB vs Other Performance Metrics
[COMPARISON_TABLE: TTFB, LCP, INP, CLS comparison]
| Metric | Measurement Target | Area | Core Web Vitals |
|---|---|---|---|
| TTFB | First byte received | Server/network | No (leading indicator) |
| LCP | Largest element render | Server+client | Yes |
| INP | Interaction response | Client (JS) | Yes |
| CLS | Layout shift | Client | Yes |
See INP and CLS for details.
Korea Market Application
TTFB Characteristics by Korean Hosting
- Cafe24/Imweb shared hosting: TTFB 300–800ms (varies with load)
- AWS Seoul region: TTFB 50–200ms (with proper caching)
- Overseas hosting (US servers): TTFB 200–1500ms for Korean users
Sites targeting Korean users must use Korea region servers or CDN nodes with Korea presence to achieve TTFB target (800ms or below).
Naver Search and TTFB
Naver bot (Yeti) is known to reduce crawl frequency on slow-TTFB sites. Check crawl stats in Naver Search Advisor; if crawl speed is abnormally low, inspect TTFB.
TTFB in the AEO Era
AI answer engines (ChatGPT, Perplexity, Google AI Overview) generate answers from real-time web crawling and/or periodic crawl data. Slow-TTFB sites have lower crawl frequency and lower probability of latest content appearing in AI indexes.
GPTBot and ClaudeBot are known to have shorter crawl timeouts than Googlebot. Fast TTFB is the technical foundation for increasing AI citation potential.
Frequently Asked Questions
Q. Is it true that slow TTFB has little ranking impact?
A. TTFB alone is not a direct ranking signal. However, indirect impact exists: TTFB → LCP → Page Experience → rankings. When competing sites have similar content quality, Page Experience differences can affect rankings.
Q. Why does TTFB measured locally differ from PageSpeed Insights data?
A. Chrome DevTools measures lab data in local environment (developer PC). PageSpeed Insights real user data (CrUX) averages measurements from actual users worldwide. Real user distribution, devices, and network environments are reflected, causing differences.
Q. Does CDN always reduce TTFB?
A. Static files (images, CSS, JS) see immediate CDN benefit. However, dynamic pages (server-side rendering) not cached at CDN edge must round-trip to origin server. Improve dynamic page TTFB by combining CDN with server caching.
Q. How does SSG (static site generation) affect TTFB?
A. SSG pre-generates HTML files at build time and deploys to CDN. All requests serve static files directly, yielding lowest TTFB (50–200ms). See Rendering for details.
Q. TTFB is 1000ms — how do I know where most time is spent?
A. Open Timing for the first request in Chrome DevTools Network tab. DNS Lookup, Initial Connection, SSL, and Waiting (TTFB) show separately. Large Waiting time indicates server processing problem; large Initial Connection indicates physical distance problem (no CDN).
Related Sources
- web.dev (2024). Time to First Byte (TTFB). https://web.dev/articles/ttfb
- Google Search Central (2024). Optimize for Core Web Vitals. https://developers.google.com/search/docs/appearance/core-web-vitals
- web.dev (2024). Optimize TTFB. https://web.dev/articles/optimize-ttfb