TTFB

개요

TTFB는 사용자가 페이지로 이동을 시작한 순간(startTime)부터 서버 응답의 첫 바이트가 도착하는 순간(responseStart)까지 경과한 시간을 측정합니다. 즉 브라우저가 실제 콘텐츠를 받기 직전까지의 모든 대기 시간을 포괄하며, 서버가 요청에 얼마나 빠르게 반응하는지를 보여주는 응답성 지표입니다.

TTFB가 중요한 이유는 다른 로딩 지표보다 먼저 발생하기 때문입니다. 첫 바이트가 늦게 도착하면 First Contentful Paint(FCP), Largest Contentful Paint(LCP) 같은 후속 지표도 함께 지연됩니다. 따라서 TTFB는 페이지 로딩 성능의 출발선 역할을 합니다.

기준값과 구성 요소

web.dev는 TTFB의 권장 기준을 다음과 같이 제시합니다. 75번째 백분위수 사용자를 기준으로 0.8초(800ms) 이내면 좋음, 1.8초 초과면 나쁨으로 봅니다. 대부분의 사이트는 0.8초 이하를 목표로 삼는 것이 권장됩니다.

TTFB는 단일 동작이 아니라 여러 단계의 합으로 구성됩니다.

• 리다이렉트: 다른 URL로 우회하는 데 걸리는 시간
• 서비스 워커 시작 시간(해당하는 경우)
• DNS 조회: 도메인 이름을 IP 주소로 변환
• 연결 및 TLS 협상: 서버와의 보안 연결 수립
• 서버 처리 시간: 요청 전송 후 첫 응답 바이트가 생성되기까지의 시간

한 가지 유의할 점은, TTFB가 코어 웹 바이탈에 포함되지 않는 진단 지표라는 사실입니다. 서버 렌더링을 사용해 TTFB가 다소 높더라도 FCP·LCP가 더 우수할 수 있으므로, TTFB 수치는 사이트가 핵심 콘텐츠를 전달하는 방식과 함께 종합적으로 판단하는 것이 바람직합니다.

최적화 방법

web.dev의 TTFB 최적화 가이드는 다음과 같은 접근을 권장합니다.

• 호스팅·서버 인프라: 충분한 메모리와 최신 백엔드 스택을 갖춘 호스팅을 우선 고려합니다.
• CDN 활용: 사용자와 가까운 엣지 서버로 콘텐츠를 분산해 지연을 줄이고, HTTP/2·HTTP/3, 최적화된 TLS 협상, 자동 압축의 이점을 얻습니다.
• 캐싱: 적절한 Cache-Control 헤더로 엣지에 콘텐츠를 캐싱합니다. 트래픽이 많은 사이트는 짧은 캐싱만으로도 TTFB가 크게 개선됩니다.
• 리다이렉트 제거: 잘못된 스킴이나 누락된 슬래시로 인한 동일 출처 리다이렉트를 없애고, HSTS 헤더로 HTTP→HTTPS 리다이렉트를 줄입니다.
• 마크업 스트리밍: 응답을 완성한 뒤 보내는 대신, 서버 렌더링 결과를 청크 단위로 점진 전송합니다.
• 103 Early Hints: 백엔드 처리 중 렌더링에 필요한 리소스를 브라우저에 미리 알립니다.
• 백엔드 모니터링: Server-Timing 헤더로 데이터베이스 쿼리·렌더링·캐시 성능을 실제 환경에서 측정합니다.

근거

본문의 정의, 0.8초·1.8초 기준값, 구성 요소, 코어 웹 바이탈 비포함 여부는 Google의 web.dev 공식 문서 "Time to First Byte (TTFB)"를 따릅니다. 최적화 방법은 web.dev의 "Optimize Time to First Byte" 가이드를 근거로 합니다.

참고·출처

• Time to First Byte (TTFB) — web.dev
• Optimize Time to First Byte — web.dev