TTFB (Time to First Byte)

Jeremy Wagner
Barry Pollard

브라우저 지원

  • 43
  • 12
  • 35
  • 11

소스

<ph type="x-smartling-placeholder">

TTFB란 무엇인가요?

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

<ph type="x-smartling-placeholder">
</ph> 네트워크 요청 타이밍을 시각화한 것입니다. 왼쪽부터 오른쪽으로는 리디렉션, Service Worker Init, Service Worker Fetch 이벤트, HTTP Cache, DNS, TCP, Request, Early Hints (103), Response (언로드 프롬프트와 겹침), 프로세싱, 로드가 있습니다. 연결된 타이밍은 리디렉션시작 및 리디렉션 종료, 가져오기 시작, 도메인 조회시작, 도메인 조회종료, 연결 시작, 보안 연결 시작, 연결 종료, 요청시작, 인터임응답 시작, 응답 시작, unloadEventStart, unloadEventEnd, responseEnd, domInteractive, domContentLoadedEventStart, domContentLoadedEventEnd, domComplete, loadEventStart, loadEventEnd입니다. <ph type="x-smartling-placeholder">
</ph> 네트워크 요청 단계 및 관련 타이밍의 다이어그램 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초 이하로 유지하려고 노력해야 합니다.

<ph type="x-smartling-placeholder">
</ph> 양호한 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 값을 반환할 수 있다는 사실도 고려합니다.

<ph type="x-smartling-placeholder">

TTFB 개선 방법

사이트의 TTFB를 개선하는 방법을 알아보려면 TTFB 최적화 심층 가이드를 참고하세요.