TTFB란 무엇인가

TTFB(Time to First Byte, 첫 바이트 시간)는 브라우저가 페이지 요청을 시작한 시점부터 서버 응답의 첫 바이트가 도착하기 시작한 시점까지 걸린 시간으로, 서버 응답 속도와 연결 설정 시간을 함께 나타내는 웹 성능 지표다.

구글 web.dev는 TTFB를 “페이지 탐색을 시작한 시점과 응답의 첫 바이트가 도착하기 시작한 시점 사이의 시간을 재는 지표”로 정의한다 (web.dev, Time to First Byte (TTFB)). MDN은 같은 구간을 responseStart - navigationStart라는 식으로 적는다 (MDN, Time to first byte).

코어 웹 바이탈 세 지표에는 들어가지 않지만, LCP와 FCP보다 앞에 오는 기초 지표라서 TTFB가 느리면 뒤의 모든 렌더링 지표가 같이 밀린다.

TTFB에는 어떤 단계가 포함되는가?

TTFB는 서버 처리 시간만이 아니라 리디렉션, DNS 조회, 연결과 TLS 협상까지 요청 앞단의 모든 대기를 합친 값이다. web.dev는 포함 구간을 다섯으로 나눈다 (web.dev, Time to First Byte (TTFB)).

단계내용주로 늘리는 원인
리디렉션 시간301, 302로 다른 URL로 넘어가는 시간http에서 https로 가는 리디렉션, 슬래시 유무 리디렉션 체인
서비스 워커 시작서비스 워커가 등록된 사이트에서만 발생무거운 서비스 워커 초기화
DNS 조회도메인을 IP 주소로 바꾸는 시간느린 DNS 제공자, 낮은 TTL
연결과 TLS 협상TCP 연결과 HTTPS 암호화 설정먼 서버, HTTP/1.1, 긴 인증서 체인
요청에서 첫 바이트까지서버가 HTML을 만들어 보내기 시작할 때까지느린 DB 쿼리, 캐시 미사용, 부족한 서버 자원

그래서 서버 코드가 빨라도 사용자가 다른 대륙에 있거나 리디렉션이 두 번 걸리면 TTFB는 나쁘게 나온다. 어느 단계가 문제인지는 뒤의 측정 절에서 나오는 브라우저 개발자 도구의 타이밍 분해로 확인한다.

TTFB는 몇 초 이하여야 좋은가?

구글 기준으로 0.8초(800ms) 이하가 양호, 1.8초 초과가 나쁨이고, 그 사이는 개선 필요다. 이 기준은 사이트 방문의 75번째 백분위수에 적용한다 (web.dev, Time to First Byte (TTFB)).

판정TTFB비고
양호0.8초 이하방문의 75%가 이 안에 들어야 함
개선 필요0.8초 초과 1.8초 이하
나쁨1.8초 초과

실험실 도구는 더 엄격하다. Lighthouse의 “초기 서버 응답 시간 단축” 감사는 메인 문서 요청에 대한 서버 응답 대기가 600ms를 넘으면 실패로 표시한다 (Chrome for Developers, Reduce server response times).

이 기준을 넘는 사이트는 절반이 안 된다. HTTP Archive의 2024년 조사에서 모바일 웹사이트의 42%만 양호 TTFB였고 40%는 개선 필요, 19%는 나쁨이었으며, 양호 비율은 2021년 41%에서 거의 움직이지 않았다 (HTTP Archive, Web Almanac 2024 Performance).

web.dev는 TTFB가 코어 웹 바이탈이 아니므로 모든 사이트가 반드시 양호 기준을 맞춰야 하는 것은 아니라고 덧붙인다. 다만 아래 이유 때문에 실무에서는 LCP를 관리하는 사이트라면 TTFB를 먼저 본다.

TTFB가 왜 중요한가?

TTFB는 LCP를 구성하는 하위 구간 가운데 가장 큰 몫을 차지하고, 구글 크롤러가 사이트를 얼마나 크롤링할지에도 영향을 준다.

먼저 LCP다. HTTP Archive는 LCP가 나쁜 사이트가 TTFB에만 2.27초를 쓴다고 밝혔는데, 이 값 하나가 양호 LCP 기준인 2.5초에 거의 맞먹는다 (HTTP Archive, Web Almanac 2024 Performance). 첫 바이트가 2초 넘게 안 오면 이미지 최적화를 아무리 해도 LCP를 2.5초 안에 넣을 수 없다.

다음은 크롤링이다. 구글은 사이트 속도가 느려지거나 응답 시간이 늘면 크롤링 용량 한도를 내려 크롤링을 줄인다고 밝히고, 크롤링 효율을 높이는 방법으로 “서버 응답 시간과 리소스를 최적화하여 페이지 로드 속도를 높입니다”를 적는다 (Google 검색 센터, 대규모 사이트의 크롤링 예산 관리). 페이지가 수만 개인 사이트에서 TTFB는 색인 속도 문제이기도 하다.

마지막은 AI 크롤러다. ChatGPT나 퍼플렉시티의 크롤러도 HTML 첫 바이트를 받은 뒤에야 본문을 읽으므로, 응답이 느린 서버는 AI 크롤러의 수집 빈도에서도 불리하다.

TTFB는 어떻게 측정하는가?

실사용자 데이터는 CrUX와 PageSpeed Insights에서, 실험실 값은 브라우저 개발자 도구와 WebPageTest에서 본다. web.dev가 나열한 측정 경로는 다음과 같다 (web.dev, Time to First Byte (TTFB)).

  1. Chrome 사용자 환경 보고서(CrUX): 실제 크롬 사용자의 TTFB 분포. 전체 페이지 로드에서만 수집하고 bfcache 복원이나 프리렌더 페이지는 제외한다 (Chrome for Developers, CrUX metrics).
  2. PageSpeed Insights: CrUX 필드 데이터와 Lighthouse 실험실 값을 한 화면에서 보여 준다.
  3. 크롬 개발자 도구 네트워크 패널: 문서 요청의 타이밍 탭에서 DNS, 연결, TLS, “서버 응답 대기(Waiting for server response)“가 따로 나온다.
  4. WebPageTest: 여러 지역과 회선에서 재고 워터폴로 단계별 시간을 본다.
  5. web-vitals 라이브러리: 페이지에 아래 코드를 넣으면 실사용자 TTFB를 직접 수집한다.
import {onTTFB} from 'web-vitals';
onTTFB(console.log);

터미널에서 curl로 재는 방법도 있다. curl -o /dev/null -w "%{time_starttransfer}\n" https://example.com/이 첫 바이트까지의 초 단위 시간을 찍는다.

2026년 10월 1일 서울의 맥미니에서 이 위키 페이지 하나(/wiki/lcp/)를 curl로 5회 잰 자체 실측값은 다음과 같다. 브라우저 렌더링이 없는 단일 지점 측정이라 CrUX 값과 직접 비교할 수는 없고, 단계별 분해가 어떻게 나오는지 보여 주는 예시다.

회차DNS연결TLS 완료TTFB
1회(첫 연결)0.019초0.060초0.110초0.365초
2회0.003초0.043초0.092초0.152초
3회0.003초0.044초0.095초0.156초
4회0.004초0.043초0.091초0.151초
5회0.003초0.043초0.096초0.161초

첫 회차는 DNS 캐시가 비어 있고 CDN 엣지 캐시도 식은 상태라 0.365초가 나왔고, 캐시가 채워진 뒤로는 0.15초 안팎으로 떨어졌다. TTFB 0.15초 가운데 0.09초가 연결과 TLS 설정이라 정적 페이지에서는 서버 처리보다 연결 단계가 더 큰 몫이라는 점이 보인다.

TTFB를 어떻게 줄이는가?

호스팅 용량 확보, CDN, 캐시, 리디렉션 제거가 기본이고, 그다음이 스트리밍 렌더링과 103 Early Hints 같은 프로토콜 수준 기법이다. web.dev의 최적화 가이드가 제시한 순서대로 정리했다 (web.dev, Optimize Time to First Byte).

  1. 호스팅을 먼저 본다. 보내는 트래픽을 감당할 메모리와 CPU가 있는지, 백엔드 스택이 최신인지 확인한다. Lighthouse는 느린 서버 응답의 원인으로 과도한 애플리케이션 로직, 비효율적인 DB 쿼리, 부족한 서버 하드웨어, 클라이언트와 서버 사이의 네트워크 지연 네 가지를 든다 (Chrome for Developers, Reduce server response times).
  2. CDN을 쓴다. 사용자와 가까운 엣지 서버가 응답하면 DNS 해석, TLS 협상, 압축까지 한 번에 빨라진다. 문서 자체를 엣지에 캐시할 수 있으면 효과가 가장 크다.
  3. 캐시 헤더를 맞춘다. Cache-Control로 엣지와 브라우저 캐시를 지정하고, 배포 때 캐시를 무효화하며, URL 파라미터가 캐시를 우회하지 않게 정리한다.
  4. 리디렉션을 없앤다. 같은 출처 안의 301, 302를 제거하고, http에서 https로 가는 리디렉션은 Strict-Transport-Security 헤더와 HSTS 프리로드로 막는다.
  5. 마크업을 스트리밍한다. 서버가 HTML을 다 만든 뒤 보내지 말고 만드는 대로 흘려보내면 브라우저가 먼저 온 부분부터 처리한다. 서버 사이드 렌더링 프레임워크 대부분이 스트리밍 옵션을 지원한다.
  6. 서비스 워커로 stale-while-revalidate 전략을 쓴다. 캐시된 응답을 먼저 주고 뒤에서 갱신하면 재방문 TTFB가 사실상 0에 가까워진다.
  7. 103 Early Hints를 보낸다. 백엔드가 HTML을 만드는 동안 렌더링에 필요한 CSS와 폰트를 먼저 내려받게 하는 응답 코드다.

원인을 모르면 서버가 Server-Timing 응답 헤더로 DB 시간, 렌더 시간 같은 백엔드 단계를 내려보내게 하고, 필드 데이터에서 어느 단계가 긴지 확인한 뒤 손댄다. web.dev는 실험실 TTFB와 필드 TTFB가 다를 수 있으니 필드 값을 기준으로 디버깅하라고 권한다.

TTFB에 대해 자주 묻는 질문은 무엇인가?

TTFB는 코어 웹 바이탈에 포함되는가?

포함되지 않는다. 코어 웹 바이탈은 LCP, INP, CLS 세 가지이고, TTFB는 구글이 “기초 지표”로 분류하는 진단용 지표다 (web.dev, Time to First Byte (TTFB)). 다만 LCP의 가장 큰 하위 구간이라 LCP를 고치려면 결국 TTFB부터 본다.

개발자 도구의 “Waiting (TTFB)“는 무엇인가?

크롬 네트워크 패널 타이밍 탭에서 요청을 보낸 뒤 서버의 첫 응답 바이트를 기다린 구간이다. 이 값은 DNS와 연결 시간을 뺀 서버 처리 시간에 가까우므로, web.dev가 정의하는 TTFB(탐색 시작 기준)보다 작게 나온다.

TTFB 속도 개선은 무엇부터 해야 하는가?

먼저 PageSpeed Insights에서 필드 TTFB가 0.8초를 넘는지 확인하고, 넘으면 리디렉션 체인과 CDN 캐시 적중 여부부터 본다. 둘 다 정상인데 느리면 Server-Timing 헤더로 백엔드 단계를 분해해 DB 쿼리나 렌더링 시간을 줄인다.

TTFB 뜻이 정확히 무엇인가?

Time to First Byte의 약자로, 첫 바이트까지의 시간이다. 사용자가 페이지로 이동을 시작한 순간부터 서버 응답의 첫 번째 바이트가 브라우저에 도착하기 시작한 순간까지를 잰다.

참고 자료

이 글은 GEO 컨설팅 회사 서치폴라리스가 작성했습니다. 회사소개

우리 브랜드는 AI 답변에 나오고 있을까?

서치폴라리스가 AI 검색 가시성을 진단하고 GEO 실행까지 대행합니다.

GEO 최적화 서비스 보기