TTFB란? 홈페이지 서버가 첫 응답을 보내기까지 걸리는 시간 쉽게 이해하기
TTFB는 요청 후 서버 첫 응답 데이터가 도착하기까지 걸리는 시간입니다. 전체 로딩·LCP와의 차이, CDN·캐시·DB·API·Cold Start·RUM·분산 추적까지 초보 기준으로 정리합니다.
이미지가 뜨기 전부터 시간이 갈 수 있습니다
느림을 느끼면 이미지·디자인을 먼저 의심하기 쉽지만, 브라우저가 서버에 요청한 뒤 첫 데이터가 도착하기까지가 이미 길 수 있습니다. 그 지표가 TTFB(Time to First Byte)입니다. 식당 비유로 하면 「모든 음식이 차려질 때까지」가 아니라 「직원이 주문 접수 첫 반응을 주기까지」에 가깝습니다.
전체 로딩과 무엇이 다른가
TTFB는 화면이 완성될 때까지의 시간이 아닙니다. HTML·CSS·JS·이미지 로딩은 그 이후입니다. TTFB가 0.1초여도 대용량 이미지·무거운 JS면 체감은 느릴 수 있고, 반대로 TTFB가 2초면 이후가 빨라도 출발이 늦습니다. TTFB 빠름 ≠ 홈페이지 전체 빠름입니다.
요청 → (네트워크·서버 처리) → 첫 바이트 도착 ← TTFB
→ HTML → CSS/JS/이미지 → 화면 구성
무엇을 포함할까 · CDN·캐시·DB·API
서버 CPU 처리만의 지표가 아닙니다. 네트워크 거리, 연결, 서버 도착·처리·전송 시작까지가 함께 영향을 줄 수 있고, 도구마다 표시 기준이 달라 숫자를 그대로 비교하면 안 됩니다. 서버가 멀면 왕복이 늘고, CDN Edge 캐시가 맞으면 원본까지 가지 않아 줄일 수 있지만, 매번 Origin을 치면 CDN이 단계만 늘릴 수도 있습니다. 페이지 캐시로 「DB·생성 반복」을 줄이면 큰 도움이 됩니다(캐시 헤더와도 연결됩니다).
느린 DB 쿼리·과도한 조회·외부 API 대기·무거운 애플리케이션 로직은 흔한 원인입니다. 언어 이름(PHP/Node 등)만으로 단정하지 말고, CPU·메모리·부하와 함께 봅니다. 트래픽이 많으면 로드밸런싱·오토스케일을 검토하고, 트래픽이 적은데도 느리면 코드·DB를 먼저 봅니다. 서버만 올려도 외부 API 3초는 그대로입니다.
정적·동적 · SSR/CSR · LCP
정적 HTML은 파일 읽기 위주, 동적 페이지는 프로그램·DB·생성 단계가 더해질 수 있습니다. SSG는 배포 시 HTML을 미리 만들어 초기 응답에 유리할 수 있고, SSR은 요청마다 서버 생성이 길면 TTFB가 늘 수 있습니다. CSR은 초기 HTML 응답은 빨라 보여도 JS 이후 체감은 느릴 수 있습니다. LCP(주요 콘텐츠 표시)는 TTFB 이후 HTML·이미지 등을 거친 단계라, TTFB가 길면 LCP도 늦어질 수 있지만 TTFB가 빨라도 5MB 히어로면 LCP만 나쁠 수 있습니다.
측정 위치 · RUM · Synthetic · Trace
한국에서 한국 서버를 재면 빠르고 미국에서 재면 네트워크만으로도 늘어날 수 있습니다. RUM으로 지역·기기별 실제 TTFB를, 합성 모니터링으로 배포 전후 변화를 보면 좋습니다. 평균만 보지 말고 분포·p75를 봅니다. 원인 분해는 분산 추적으로 앱·DB·API 비중을 좁힙니다. 갑자기 느려지면 배포 시각·트래픽·DB·API·서버 상태를 순서대로 봅니다.
Cold/Warm · Cold Start · 리디렉션
첫 방문만 느리고 이후 빠른 경우는 Cold Cache(캐시 없음→생성)와 Warm Cache(캐시 히트) 차이일 수 있습니다. 서버리스에서는 실행 환경을 새로 켜는 Cold Start가 첫 요청을 늘릴 수 있으나 플랫폼마다 다릅니다. http→https→www→/home처럼 리디렉션 체인이 길면 사용자 체감 시작이 늦어지고, 301과 TTFB는 다른 개념입니다. 이미지·웹폰트는 보통 TTFB 이후 리소스이고, DNS·HTTP/2·3만으로 2초 쿼리는 안 고쳐집니다. 로그인·관리자·API도 동적 처리가 많으면 TTFB가 늘 수 있고, Streaming은 첫 바이트는 빨라도 전체 완료는 길 수 있습니다.
자주 묻는 질문
TTFB란?
Time to First Byte — 요청 후 첫 응답 데이터가 도착하기까지 걸리는 시간입니다.
전체 로딩과 같나요?
아닙니다. 초기 서버 응답 구간이고, 이후 HTML·CSS·JS·이미지가 이어집니다.
빠르면 사이트도 무조건 빠른가요?
아닙니다. 이미지·JS가 무거우면 화면은 여전히 느릴 수 있습니다.
느린 흔한 원인은?
서버 처리·DB·외부 API·부하·캐시 미스·네트워크 거리 등입니다.
CDN·LCP와의 관계는?
Edge 캐시가 맞으면 TTFB에 도움이 될 수 있고, LCP는 주요 콘텐츠 표시로 다른 단계입니다.
서버만 업그레이드하면 되나요?
병목이 API·DB라면 효과가 작습니다. 원인을 먼저 좁힙니다.
정리
TTFB는 요청 후 서버가 첫 응답 데이터를 보내기 시작할 때까지의 시간입니다. 0에 맞출 수는 없고, 불필요한 지연을 줄이는 것이 목표입니다. 성능은 단계로 나눕니다 — TTFB(응답 시작) · LCP(중요 콘텐츠) · INP(반응) · CLS(화면 흔들림). 다음으로 자주 이어지는 주제는, 사용자가 「이제 중요한 내용이 보인다」고 느끼는 시점인 LCP(Largest Contentful Paint)입니다.