구글 SEO
TTFB(첫 바이트 시간)
Time To First Byte 다른 표기: 서버 응답 시간
TTFB(첫 바이트 시간)는 브라우저가 서버에 요청을 보낸 시점부터 첫 번째 응답 바이트를 받기까지 걸리는 시간을 재는 지표입니다.
- TTFB가 정확히 어느 구간의 시간을 재는지
- TTFB 좋음·나쁨 기준이 어떻게 나뉘는지
- TTFB가 느릴 때 어디부터 점검해야 하는지
TTFB는 어디에서 쓰이나요?
페이지가 느린 원인이 서버인지 프런트엔드인지 구분할 때 가장 먼저 봅니다.
- PageSpeed Insights·Lighthouse 리포트를 점검할 때
- 호스팅·서버 응답 속도를 진단할 때
- LCP가 느린 원인이 서버 지연인지 확인할 때
TTFB는 어떻게 측정하나요?
브라우저가 요청을 보낸 시점부터 첫 번째 응답 바이트를 받기까지 걸린 시간을 잽니다.
TTFB = DNS 조회 + 연결 수립 + TLS 협상 + 서버 처리 시간콘텐츠 다운로드·렌더링은 이 시간 이후부터 시작됩니다
이 구간에 포함되는 과정은 네 단계입니다.
- DNS 주소 조회
- 서버와의 연결 수립
- TLS 보안 협상
- 서버가 요청을 처리해 응답을 만드는 시간
TTFB가 왜 중요한가요?
TTFB가 느리면 이후 이어지는 LCP·INP 지표까지 전부 밀립니다.
web.dev는 TTFB가 0.8초 이하면 좋음, 1.8초를 넘으면 나쁨으로 분류합니다.
| TTFB | 판정 |
|---|---|
| 0.8초 이하 | 좋음 |
| 0.8~1.8초 | 개선 필요 |
| 1.8초 초과 | 나쁨 |
TTFB라는 개념은 왜 생겼나요?
로딩 전체 시간만 보면 느린 원인이 서버인지 렌더링인지 구분할 수 없었습니다. TTFB는 콘텐츠 다운로드가 시작되기 전 구간만 따로 떼어 보기 위해 정의됐습니다.
내 상황에 적용하려면?
숫자를 하나 넣어 보면 감이 잡힙니다. 아래는 설명을 위해 가정한 수치입니다.
DNS 조회에 0.1초, 연결과 TLS 협상에 0.2초, 서버 처리에 0.9초가 걸렸다고 하겠습니다. 이 페이지의 TTFB는 합계 1.2초로 개선 필요 구간에 들어갑니다.
- PageSpeed Insights에서 TTFB 값을 따로 확인했습니다
- 서버 처리 시간이 유독 긴지 캐시·쿼리 설정을 점검했습니다
- CDN이 정적 자원에만 적용되는지, 동적 처리에도 도움이 되는지 구분했습니다
- 호스팅 사양이 트래픽 대비 충분한지 확인했습니다
TTFB에 대한 흔한 오해는 무엇인가요?
| 오해 | 실제 |
|---|---|
| TTFB가 느린 건 이미지 용량 때문입니다 | 이미지·CSS가 로드되기 전 시간만 측정하므로 원인은 대부분 서버·호스팅에 있습니다 |
| TTFB만 빠르면 페이지도 빠르입니다 | 전체 로딩의 출발점일 뿐이며 이후 LCP·INP가 따로 나쁠 수 있습니다 |
| CDN을 붙이면 무조건 해결됩니다 | 정적 자원 전송은 빨라지지만 서버의 동적 처리 시간 자체는 줄여주지 않습니다 |
TTFB를 포함한 3가지 핵심 지표는 코어 웹 바이탈에서, TTFB 이후 그려지는 화면 지표는 LCP에서, 서버·코드 구조 전반은 테크니컬 SEO에서 다룹니다.
자주 묻는 질문
TTFB는 코어 웹 바이탈에 포함되나요?
아니요. 공식 3대 지표는 LCP·INP·CLS이며, TTFB는 이 지표들에 영향을 주는 보조 지표로 다뤄집니다.
TTFB는 어떻게 측정하나요?
PageSpeed Insights나 크롬 개발자도구 네트워크 탭에서 요청 시점부터 첫 응답 바이트까지의 간격으로 확인합니다.
TTFB가 느리면 무엇부터 점검해야 하나요?
서버 처리 로직, 데이터베이스 쿼리, 캐시 설정, 호스팅 사양 순으로 점검하는 것이 일반적입니다.
참고 자료
이 페이지가 도움이 되었나요?
10초면 됩니다 · 남겨주신 의견은 다음 개정에 반영됩니다