TTFB
ttfb
뜻과 개념
요청 후 응답의 첫 바이트를 받기까지 걸리는 시간입니다.
어떻게 작동하나요?
TTFB는 요청을 시작한 뒤 응답의 첫 바이트가 도착하기까지 걸린 시간을 가리킵니다. 측정 방식에 따라 리다이렉트, DNS 조회, 연결과 TLS 협상, 서버 처리 대기가 포함될 수 있습니다. 단순히 PHP 코드가 실행된 시간만을 뜻하지 않으므로 값이 느리다고 곧바로 서버 CPU만 탓하면 원인을 놓칠 수 있습니다.
왜 알아야 하나요?
첫 응답이 늦으면 뒤에 이어지는 콘텐츠 다운로드와 화면 표시도 늦어질 수 있습니다. web.dev는 대략적인 가이드로 0.8초 이하를 제시하지만 TTFB 자체는 Core Web Vitals의 구성 지표가 아닙니다. 서버가 빨리 빈 HTML을 보내도 주요 내용이 늦게 생성되면 사용자는 여전히 느리게 느낄 수 있습니다.
실무에서 적용하는 방법
네트워크 도구로 연결과 서버 대기 시간을 나눠 확인합니다. 반복 측정과 다른 지역·기기 조건을 비교하고 캐시 적중 여부를 기록합니다. 불필요한 이동, 느린 데이터베이스 조회, 외부 API 대기, 원본 서버와의 거리 중 병목을 찾습니다. 수정 뒤에는 TTFB뿐 아니라 FCP와 LCP도 함께 측정해 실제 표시가 빨라졌는지 확인하세요.
실무에서는 이렇게 봅니다
블로그 상세가 외부 통계 API의 응답을 기다린 뒤 HTML을 보내면 통계 서비스 지연이 본문 표시까지 늦출 수 있습니다. 통계가 첫 화면에 필수인지 검토해 캐시나 별도 로딩을 고려할 수 있습니다. 반면 해외 접속만 느리다면 앱 코드보다 전달 경로와 캐시 위치를 먼저 조사해야 할 수 있습니다.
주의할 점
개발 PC에서 한 번 측정한 값은 모든 방문자의 경험을 대표하지 않습니다. 최초 연결과 재사용 연결, 캐시가 비었을 때와 채워졌을 때를 구분해야 합니다. 조기 응답 헤더 같은 구현도 측정에 영향을 줄 수 있으므로 다른 도구의 값을 비교할 때 정의를 확인하세요.
자주 묻는 질문
TTFB가 낮으면 사이트는 빠른가요?
필요한 조건 중 하나일 수 있지만 충분하지 않습니다. 이후의 큰 이미지, 렌더링 차단 스크립트와 상호작용 지연도 사용자 경험에 영향을 줍니다.
호스팅을 바꾸면 해결되나요?
서버 자원이 병목이면 도움이 될 수 있지만 리다이렉트나 느린 외부 요청이 원인이라면 그대로 남습니다. 측정으로 원인을 좁힌 뒤 변경해야 비용을 낭비하지 않습니다.