TTFB (Time to First Byte)

Jeremy Wagner
Barry Pollard

브라우저 지원

  • Chrome: 43
  • Edge: 12.
  • Firefox: 35.
  • Safari: 11.

소스

TTFB란 무엇인가요?

TTFB는 리소스 요청과 응답의 첫 번째 바이트가 도착하기 시작하는 시점 사이의 시간을 측정하는 측정항목입니다.

네트워크 요청 타이밍의 시각화 왼쪽에서 오른쪽으로의 타이밍은 리디렉션, 서비스 워커 초기화, 서비스 워커 가져오기 이벤트, HTTP 캐시, DNS, TCP, 요청, 조기 힌트 (103), 응답 (로드 취소 메시지와 겹침), 처리, 로드입니다. 관련 타이밍은 redirectStart 및 redirectEnd, fetchStart, domainLookupStart, domainLookupEnd, connectStart, secureConnectionStart, connectEnd, requestStart, interimResponseStart, responseStart, unloadEventStart, unloadEventEnd, responseEnd, domInteractive, domContentLoadedEventStart, domContentLoadedEventEnd, domComplete, loadEventStart, loadEventEnd입니다.
네트워크 요청 단계 및 관련 타이밍을 보여주는 다이어그램 TTFB는 startTime와 responseStart 사이의 경과 시간을 측정합니다.

TTFB는 다음 요청 단계의 합계입니다.

  • 리디렉션 시간
  • 서비스 워커 시작 시간 (해당하는 경우)
  • DNS 조회
  • 연결 및 TLS 협상
  • 응답의 첫 번째 바이트가 도착할 때까지의 요청

연결 설정 시간과 백엔드의 지연 시간을 줄이면 TTFB가 줄어들 수 있습니다.

TTFB의 다른 정의

이전 정의는 기존 정의이지만 초기 힌트가 도입되면서 '첫 번째 바이트'로 간주되는 항목에 대한 논의가 있습니다. firstInterimResponseStart는 이를 구분하기 위해 responseStart에 추가된 새로운 타이밍 항목이지만 Chrome 및 Chromium 기반 브라우저에서만 지원됩니다. 따라서 일부 브라우저 및 도구 (CrUX 포함)는 조기 힌트를 포함하여 첫 번째 바이트가 수신될 때까지 측정합니다.

조기 힌트는 조기에 응답하는 새로운 방법일 뿐입니다. 일부 서버는 기본 본문을 사용할 수 있기 전에 문서 응답을 플러시하도록 허용합니다. HTTP 헤더만 사용하거나 <head> 요소를 사용합니다. 둘 다 조기 힌트와 효과가 비슷하다고 간주될 수 있으므로 TTFB가 측정하는 항목의 정의도 흐리게 만듭니다.

문서에 대한 조치 가능한 데이터의 '첫 번째 바이트'가 브라우저에 수신되는 시점을 측정하는 측면에서 이러한 모든 정의는 유효하다고 간주될 수 있습니다. 전체 응답에 시간이 더 걸릴 경우 데이터를 일찍 다시 전송하는 것이 좋습니다. 가장 중요한 것은 사용 중인 도구가 측정하는 측정항목과 측정 대상 플랫폼의 영향을 받는 방식을 이해하는 것입니다. 따라서 사용하는 기능과 이러한 기능이 사용 중인 TTFB 측정에 미치는 영향에 따라 여러 플랫폼 또는 기술 간의 TTFB를 비교하기는 어렵습니다.

TTFB는 서버 또는 호스트 응답 시간의 지표로 간주되는 경우가 많습니다. 하지만 리디렉션 시간, CDN의 캐시에서 게재되는지 또는 원본 서버로 돌아가는 경로가 더 길어질 수 있는지와 같은 직접적인 제어 외부의 요소의 영향을 받습니다. 이는 현장 데이터에서 특히 두드러집니다. 실험실 테스트는 일반적으로 최종 URL이 테스트되고 캐싱 변경사항이 반복적으로 취소되므로 이러한 요소의 영향을 덜 받습니다. Lighthouse는 이를 더 명확하게 하기 위해 TTFB 대신 서버 응답 시간을 보고하지만 다른 실험실 도구는 그렇지 않을 수 있습니다.

좋은 TTFB 점수는 얼마인가요?

TTFB는 콘텐츠가 포함된 첫 페인트 (FCP) 및 최대 콘텐츠 렌더링 시간 (LCP)과 같은 사용자 중심 측정항목보다 먼저 적용되므로 서버가 탐색 요청에 충분히 빠르게 응답하여 75번째 백분위수의 사용자가 '좋음' 기준점 내에서 FCP를 경험할 수 있도록 하는 것이 좋습니다. 대략적인 가이드라인으로 대부분의 사이트는 TTFB가 0.8초 이하가 되도록 노력해야 합니다.

TTFB 값이 0.8초 이하이면 양호하고 1.8초를 초과하면 좋지 않으며 그 사이의 값이면 개선이 필요합니다.
TTFB 값이 0.8초 이하이면 양호하고 1.8초를 초과하면 좋지 않은 것입니다.

TTFB 측정 방법

TTFB는 다음과 같은 방법으로 실험실 또는 현장에서 측정할 수 있습니다.

현장 도구

실험실 도구

JavaScript에서 TTFB 측정

Navigation Timing API를 사용하여 브라우저에서 탐색 요청의 TTFB를 측정할 수 있습니다. 다음 예에서는 navigation 항목을 리슨하고 콘솔에 로깅하는 PerformanceObserver를 만드는 방법을 보여줍니다.

new PerformanceObserver((entryList) => {
  const [pageNav] = entryList.getEntriesByType('navigation');

  console.log(`TTFB: ${pageNav.responseStart}`);
}).observe({
  type: 'navigation',
  buffered: true
});

web-vitals JavaScript 라이브러리를 사용하면 브라우저에서 TTFB를 더 간결하게 측정할 수도 있습니다.

import {onTTFB} from 'web-vitals';

// Measure and log TTFB as soon as it's available.
onTTFB(console.log);

리소스 요청 측정

TTFB는 탐색 요청뿐만 아니라 모든 요청에 적용됩니다. 특히 교차 출처 서버에 호스팅된 리소스는 이러한 서버에 대한 연결을 설정해야 하므로 지연 시간이 발생할 수 있습니다. 필드의 리소스에 대한 TTFB를 측정하려면 PerformanceObserver 내에서 Resource Timing API를 사용하세요.

new PerformanceObserver((entryList) => {
  const entries = entryList.getEntries();

  for (const entry of entries) {
    // Some resources may have a responseStart value of 0, due
    // to the resource being cached, or a cross-origin resource
    // being served without a Timing-Allow-Origin header set.
    if (entry.responseStart > 0) {
      console.log(`TTFB: ${entry.responseStart}`, entry.name);
    }
  }
}).observe({
  type: 'resource',
  buffered: true
});

이전 코드 스니펫은 탐색 요청의 TTFB를 측정하는 데 사용되는 코드 스니펫과 유사하지만 'navigation' 항목을 쿼리하는 대신 'resource' 항목을 쿼리합니다. 또한 연결이 이미 열려 있거나 리소스가 캐시에서 즉시 검색되므로 기본 출처에서 로드된 일부 리소스가 0 값을 반환할 수 있다는 사실도 고려합니다.

TTFB를 개선하는 방법

사이트의 TTFB를 개선하는 방법에 관한 안내는 TTFB 최적화에 관한 심층 가이드를 참고하세요.