TTFB (Time to First Byte)

정의

TTFB(Time to First Byte)는 사용자(또는 봇)가 HTTP 요청을 보낸 시점부터 서버에서 첫 번째 바이트를 수신하는 시점까지의 시간이다. 서버 자체의 처리 속도, 네트워크 대기 시간, 서버와 사용자 간의 물리적 거리가 복합적으로 반영된다.

TTFB는 Core Web Vitals의 공식 지표는 아니지만, LCP(Largest Contentful Paint)의 핵심 구성 요소이며 페이지 로딩 파이프라인의 출발점이다.

요약

TTFB 권장값: 800ms 이하 = 좋음 / 800–1800ms = 개선 필요 / 1800ms 초과 = 나쁨. 느린 TTFB는 LCP를 나쁘게 만들고 크롤 효율을 낮춘다. 개선 우선순위: ①CDN 도입 ②서버 캐싱 ③호스팅 업그레이드.

TTFB의 구성 요소

TTFB는 단일 값이지만 내부적으로 여러 단계로 구성된다.

DNS 조회 시간

도메인 이름(example.com)을 IP 주소로 변환하는 과정. DNS 캐싱이 되어 있으면 거의 0에 가깝지만, 첫 방문 시 수십ms가 소요된다.

TCP 연결 시간

클라이언트와 서버 간 TCP 3-way handshake. 서버와의 지리적 거리가 직접 영향을 준다. 서울-서울 연결: ~1ms, 서울-미국 서부: ~150ms.

SSL/TLS 협상 시간

HTTPS 연결에서 암호화 협상 과정. TLS 1.3은 이전 버전보다 협상 시간을 대폭 단축한다.

서버 처리 시간

서버가 요청을 받은 후 응답을 생성하기까지의 시간. 데이터베이스 쿼리, 서버 사이드 렌더링, 캐시 히트/미스가 여기에 포함된다.

첫 응답 전송 시간

서버가 응답 헤더와 첫 바이트를 네트워크로 내보내는 시간.

TTFB 권장 기준 (Google web.dev)

Google이 web.dev에서 제시하는 TTFB 기준:

등급	TTFB
좋음 (Good)	< 800ms
개선 필요 (Needs Improvement)	800ms – 1800ms
나쁨 (Poor)	> 1800ms

이 기준은 실제 사용자 데이터(CrUX, Chrome User Experience Report)를 기반으로 한다.

주의: TTFB 자체는 Core Web Vitals의 공식 3개(LCP, INP, CLS) 중 하나가 아니다. 그러나 LCP가 TTFB를 포함하기 때문에 TTFB 개선이 LCP 개선으로 직결된다. 자세히는 Core Web Vitals 항목 참조.

TTFB가 SEO에 미치는 영향

LCP와의 직접 연결

LCP(Largest Contentful Paint)는 가장 큰 요소가 화면에 렌더링되기까지의 시간이다. LCP의 타임라인을 분해하면:

LCP = TTFB + 리소스 로딩 시간 + 렌더링 시간

TTFB가 느리면 LCP가 자동으로 느려진다. LCP는 Core Web Vitals의 핵심 지표이므로 페이지 경험 랭킹 시그널에 직접 영향을 준다.

크롤 효율 저하

Googlebot과 AI 봇이 페이지를 크롤할 때도 TTFB의 영향을 받는다. TTFB가 느리면:

크롤당 소요 시간 증가
제한된 크롤 버짓 낭비
동일 시간 내 크롤 가능한 페이지 수 감소

자세히는 크롤 버짓 항목 참조.

AI 봇 크롤 빈도 감소

GPTBot, ClaudeBot 등 AI 봇도 TTFB가 느린 사이트는 크롤 빈도를 줄인다. AI 학습 데이터나 실시간 인덱스에 포함될 기회가 감소한다. 자세히는 robots.txt에 AI 봇 허용 항목 참조.

TTFB 측정 도구

PageSpeed Insights

https://pagespeed.web.dev/에서 URL을 입력하면 실제 사용자 데이터(CrUX)와 실험실 데이터를 모두 제공한다. "서버 응답 시간 단축(TTFB)" 항목에서 TTFB를 직접 확인할 수 있다.

Chrome DevTools

DevTools → Network 탭 → 첫 번째 요청 클릭 → Timing 탭에서 "Waiting (TTFB)" 항목으로 확인한다. 로컬 테스트 용도로는 유용하지만 실제 사용자 환경을 반영하지 않는다.

GTmetrix

서버 위치를 선택해 서로 다른 지역에서 TTFB를 측정할 수 있다. 한국 사용자 관점의 TTFB를 정확히 측정하려면 서울 또는 아시아 서버를 선택한다.

WebPageTest

전 세계 여러 위치에서 측정 가능. Waterfall 차트에서 TTFB를 포함한 전체 로딩 타임라인을 시각화한다.

TTFB 개선 5가지 방법

1. CDN 도입

CDN(Content Delivery Network)은 사용자와 가까운 엣지 서버에서 콘텐츠를 제공해 물리적 거리로 인한 네트워크 지연을 줄인다. 정적 자산 캐싱만으로도 TTFB가 50–200ms 개선되는 경우가 일반적이다.

한국 사용자를 위한 CDN: Cloudflare(서울 노드 있음), AWS CloudFront(서울 리전), Bunny.net.

2. 서버 캐싱

동적으로 생성되는 페이지를 캐시해 매 요청마다 데이터베이스 쿼리·렌더링을 반복하지 않는다.

Redis / Memcached: 데이터베이스 쿼리 결과 캐싱
전체 페이지 캐시: Nginx에서 생성된 HTML 캐시
워드프레스: W3 Total Cache, WP Rocket

3. 호스팅 업그레이드

공유 호스팅은 서버 리소스를 다수 사이트가 공유하므로 TTFB가 높다. VPS 또는 전용 서버로 업그레이드하면 서버 처리 시간이 감소한다.

한국 사이트라면: 카페24 클라우드, AWS 서울 리전(ap-northeast-2), NCP(Naver Cloud Platform).

4. 데이터베이스 최적화

느린 쿼리가 TTFB를 높이는 흔한 원인이다. MySQL slow query log로 느린 쿼리를 식별하고 인덱스를 추가한다.

5. HTTP/2 또는 HTTP/3 전환

HTTP/2는 단일 연결로 여러 요청을 동시에 처리(다중화)해 연결 오버헤드를 줄인다. HTTP/3는 UDP 기반으로 패킷 손실에도 빠른 응답이 가능하다.

TTFB와 다른 성능 지표 비교

[COMPARISON_TABLE: TTFB, LCP, INP, CLS 비교]

지표	측정 대상	영역	Core Web Vitals
TTFB	첫 바이트 수신	서버/네트워크	X (사전 지표)
LCP	최대 요소 렌더링	서버+클라이언트	O
INP	상호작용 응답	클라이언트(JS)	O
CLS	레이아웃 변동	클라이언트	O

자세히는 INP, CLS 항목 참조.

한국 시장 적용

한국 호스팅별 TTFB 특성

카페24/아임웹 공유 호스팅: TTFB 300–800ms (부하에 따라 변동)
AWS 서울 리전: TTFB 50–200ms (적절한 캐싱 시)
국외 호스팅(미국 서버): 한국 사용자 TTFB 200–1500ms

한국 사용자 대상 사이트는 반드시 한국 리전 서버 또는 한국 노드 CDN을 사용해야 TTFB 목표치(800ms 이하)를 달성할 수 있다.

네이버 검색과 TTFB

네이버 봇(Yeti)도 TTFB가 느린 사이트의 크롤 빈도를 줄이는 것으로 알려져 있다. 네이버 서치어드바이저에서 크롤 통계를 확인해 크롤 속도가 비정상적으로 낮으면 TTFB를 점검한다.

AEO 시대의 TTFB

AI 답변 엔진(ChatGPT, Perplexity, Google AI Overview)은 실시간 웹 크롤을 포함하거나 정기 크롤 데이터를 기반으로 답변을 생성한다. TTFB가 느린 사이트는 크롤 빈도가 낮아지고 최신 콘텐츠가 AI 인덱스에 반영될 확률이 낮아진다.

특히 GPTBot, ClaudeBot은 크롤 타임아웃이 Googlebot보다 짧은 것으로 알려져 있다. 빠른 TTFB는 AI 인용 가능성을 높이는 기술적 기반이다.

자주 묻는 질문

Q. TTFB가 느려도 순위에 큰 영향이 없다는데 맞나요?
A. TTFB 단독으로는 직접 순위 신호가 아니다. 그러나 TTFB → LCP → 페이지 경험 → 순위로 이어지는 간접 영향이 존재한다. 특히 경쟁 사이트와 콘텐츠 품질이 비슷할 때 페이지 경험 차이가 순위에 영향을 줄 수 있다.

Q. 로컬에서 측정한 TTFB와 PageSpeed Insights 데이터가 왜 다른가요?
A. Chrome DevTools는 로컬 환경(개발자 PC)에서 측정하는 실험실 데이터다. PageSpeed Insights의 실제 사용자 데이터(CrUX)는 전 세계 실제 사용자의 측정값 평균이다. 실제 사용자 분포, 디바이스, 네트워크 환경이 반영되어 다를 수 있다.

Q. CDN을 쓰면 TTFB가 항상 줄어드나요?
A. 정적 파일(이미지, CSS, JS)은 즉시 CDN 효과를 본다. 그러나 동적 페이지(서버 사이드 렌더링)는 CDN 엣지에서 캐시되지 않으면 오리진 서버까지 왕복해야 한다. 동적 페이지 TTFB 개선을 위해서는 CDN과 서버 캐싱을 함께 구성해야 한다.

Q. SSG(정적 사이트 생성) 방식이 TTFB에 어떤 영향을 주나요?
A. SSG는 빌드 시 HTML 파일을 미리 생성해 CDN에 배포한다. 모든 요청이 정적 파일을 직접 서빙하므로 TTFB가 가장 낮다(50–200ms). 자세히는 렌더링 항목 참조.

Q. TTFB 1000ms가 나오는데 어디서 시간이 가장 많이 걸리는지 어떻게 알 수 있나요?
A. Chrome DevTools Network 탭에서 첫 요청의 Timing을 열면 DNS Lookup, Initial Connection, SSL, Waiting(TTFB) 단계별 시간이 분리되어 표시된다. Waiting 시간이 크면 서버 처리 시간이 문제고, Initial Connection이 크면 물리적 거리(CDN 미사용)가 문제다.