Time to First Byte (TTFB)란 무엇이며 어떻게 개선하는가

Time to First Byte (TTFB)는 브라우저가 페이지를 요청한 시점부터 서버 응답의 첫 바이트를 수신하기까지 걸리는 시간(밀리초)을 측정합니다. 75번째 백분위수 기준 800밀리초 이하가 좋은 수준입니다. TTFB는 Core Web Vitals 지표는 아니지만, Largest Contentful Paint (LCP)와 First Contentful Paint (FCP) 모두에 직접적인 영향을 미치므로 매우 중요한 진단 지표입니다.

What is the Time to First Byte

Time to First Byte (TTFB)는 웹페이지 요청이 시작된 시점부터 첫 번째 응답(바이트)을 수신하기까지 경과한 시간(밀리초)을 나타냅니다. 따라서 TTFB는 대기 시간(waiting time)이라고도 부릅니다. TTFB는 웹 서버와 사용자와 해당 서버 간 네트워크 경로의 응답성을 측정하는 지표입니다. TTFB는 기초 지표입니다. 즉, TTFB에 늘어난 시간은 Largest Contentful Paint와 First Contentful Paint에도 그대로 더해집니다. TTFB에서 단축한 1밀리초는 이 두 페인트 지표 모두에서 1밀리초를 단축하는 것과 같습니다.

TTFB는 Core Web Vitals가 아닙니다

분명히 밝혀둘 점이 있습니다. TTFB는 3대 Core Web Vitals에 속하지 않습니다. Core Web Vitals는 Largest Contentful Paint (LCP), Interaction to Next Paint (INP), Cumulative Layout Shift (CLS)로 구성됩니다. Google은 페이지 경험 순위 신호에 TTFB를 직접 반영하지 않습니다.

하지만 TTFB는 진단 지표로 분류됩니다. LCP나 FCP가 왜 느린지 원인을 파악하는 데 유용합니다. 2025 Web Almanac에 따르면, LCP가 나쁜 사이트는 TTFB에만 평균 2.27초를 소비합니다. 브라우저가 페이지를 렌더링하기 시작하기도 전에 LCP 기준치인 2.5초를 거의 다 써버리는 셈입니다. 따라서 TTFB를 개선하는 것은 전반적인 Core Web Vitals 점수를 개선하는 데 가장 효과적인 조치 중 하나입니다.

Time to First Byte가 중요한 이유

Time to First Byte는 Core Web Vitals 지표가 아니며, TTFB 기준을 충족하지 못하더라도 Core Web Vitals를 통과하는 것은 얼마든지 가능합니다. 그렇다고 TTFB가 중요하지 않다는 뜻은 아닙니다. TTFB는 반드시 최적화해야 하는 대단히 중요한 지표이며, TTFB를 개선하면 페이지 속도와 페이지 경험이 크게 향상됩니다.

TTFB가 방문자에게 미치는 영향

Time to First Byte는 다른 모든 페인트 지표보다 앞서 발생합니다. 브라우저는 Time to First Byte를 기다리는 동안 아무것도 할 수 없어 그저 빈 화면만 표시합니다. 즉, Time to First Byte가 늘어나면 '빈 화면' 노출 시간이 늘어나고, Time to First Byte를 줄이면 '빈 화면' 노출 시간도 줄어듭니다.

페이지가 즉각 로딩된다는 인상을 주려면 Time to First Byte가 최대한 빨라야 합니다.

TTFB는 왜 Core Web Vital이 아닙니까? TTFB는 렌더링을 고려하지 않습니다. 브라우저가 웹페이지를 렌더링하는 데 걸리는 시간은 포함하지 않으므로, TTFB가 낮다고 해서 반드시 사용자 경험이 좋다고 볼 수는 없습니다. 모든 바이트를 빠르게 다운로드하더라도 브라우저가 대량의 JavaScript를 처리해야 하거나 복잡한 레이아웃을 렌더링해야 한다면 웹페이지가 화면에 표시되기까지 여전히 오랜 시간이 걸릴 수 있습니다.

좋은 TTFB 점수의 기준

전체 사용자의 75번째 백분위수에서 FCP가 '좋음' 기준치에 도달할 수 있도록 서버가 내비게이션 요청에 충분히 빠르게 응답해야 합니다. 대략적인 기준으로, 대부분의 사이트는 0.8초 이하의 TTFB를 목표로 삼아야 합니다.

• TTFB 800밀리초 미만은 좋은 수준으로 평가됩니다.
• TTFB 800~1800밀리초 사이는 개선이 필요합니다.
• TTFB 1800밀리초 초과는 나쁜 수준으로 평가되며 즉시 개선해야 합니다.

실제 영향: T-Mobile 사례 연구

T-Mobile은 광범위한 성능 최적화 프로젝트의 일환으로 Time to First Byte 단축에 집중 투자했습니다. 결과는 놀라웠습니다. 방문 대비 주문 전환율이 60% 증가했습니다. T-Mobile은 엣지 렌더링 페이지와 공격적인 서버 측 캐싱을 도입하여 사용자가 첫 바이트를 기다리는 시간을 획기적으로 줄였습니다. 이는 LCP 및 FCP 단축으로 이어졌고, 측정 가능한 수준의 사용자 경험 향상을 이끌어냈습니다. 이 사례 연구는 TTFB 최적화가 단순한 기술적 과제가 아니라 비즈니스 성과에 직접적인 영향을 미친다는 사실을 명확히 보여줍니다.

요청부터 응답까지의 TTFB 과정

브라우저에서 서버까지: 요청 단계

브라우저 요청 시간은 사용자 브라우저가 HTTP 요청을 보낸 시점부터 해당 요청이 웹사이트 호스팅 서버에 도달하기까지 경과한 시간입니다. 이 구간의 TTFB는 웹사이트가 직접 제어하기 어려우며, 주로 다음 요인에 좌우됩니다.

• 사용자의 인터넷 속도
• 네트워크 인프라의 품질
• 사용자와 서버 간의 물리적 거리

이 단계에서는 DNS 조회, 브라우저 시작 시간, 브라우저 캐시 조회, 서버 연결 협상(TCP 및 TLS)이 모두 일정 시간을 소모합니다.

서버 내부: 처리 및 응답 준비

서버가 요청을 수신하면 응답 생성을 위한 작업이 시작되면서 시간이 흘러갑니다. 대부분의 개발자가 집중하는 단계이며, 최적화 작업을 통해 가장 큰 효과를 거둘 수 있는 구간이기도 합니다. 고려해야 할 요소는 다음과 같습니다.

• 서버 성능: 강력한 하드웨어(CPU, RAM), 효율적인 소프트웨어(웹 서버, 데이터베이스), 최적화된 설정이 모두 중요합니다.
• 데이터베이스 소요 시간: 요청 처리 시 데이터베이스에서 데이터를 가져와야 한다면, 느린 쿼리가 심각한 병목 지점이 될 수 있습니다.
• 코드 최적화: 비효율적인 스크립트 등 부실하게 작성된 서버 측 코드는 처리 시간을 지연시킵니다.
• 캐싱 전략: 효과적인 캐싱(서버 측 캐싱이나 CDN 활용)은 반복 요청에 대한 처리 부담을 대폭 줄여줍니다.

브라우저로 반환: 첫 바이트 전송

처리가 완료되면 서버는 첫 바이트를 시작으로 사용자 브라우저에 응답을 전송합니다.

• 첫 번째 단계와 마찬가지로 네트워크 상태와 물리적 거리가 영향을 미칩니다.
• CDN은 사용자 가까운 곳에 콘텐츠를 캐시하여 전송 시간을 최소화하므로 이 단계에서 특히 유용합니다.
• 이 시점에 리다이렉트가 반환되면 전체 과정이 다시 반복되면서 추가 지연이 발생합니다.

Time to First Byte의 기술적 단계

브라우저의 '요청부터 응답까지의 경로'와 마찬가지로, 내비게이션 요청의 Time To First Byte는 Navigation Timing API로 측정할 수 있으며 5개의 세부 단계로 나뉩니다.

1. 리다이렉트 시간: 리소스가 새 위치로 이동되면 리다이렉트 시간이 해당 리소스의 TTFB에 더해집니다.
2. 워커 및 캐시 시간: 인터넷에서 리소스를 가져오기 전에 브라우저는 자체 캐시나 워커(설정된 경우)에서 리소스를 먼저 조회합니다.
3. DNS 조회 시간: 다음으로 브라우저는 도메인 이름(www.example.com)을 IP 주소로 변환하기 위해 DNS 조회를 수행해야 할 수 있습니다.
4. TCP 연결 시간: 이후 브라우저가 서버에 연결하고 몇 가지 확인 절차를 진행합니다.
5. SSL 핸드셰이크: 브라우저와 서버가 통신 데이터를 암호화합니다.
6. 서버 응답: 마지막으로 서버가 HTML을 전송합니다. 전송하기 전에 HTML을 먼저 동적으로 생성해야 할 수도 있습니다.

Time To First Byte(TTFB) 측정 방법

PageSpeed TIP: 모든 리소스에는 각자의 Time to First Byte가 있습니다. 하지만 본 문서에서는 메인 페이지의 Time to First Byte를 다룹니다.

Time to First Byte는 기기와 접속 지역이 다른 사용자마다 편차가 매우 큽니다. 데스크톱 컴퓨터에서 Time to First Byte를 직접 측정하는 것이 좋은 방법이 아닌 이유가 바로 여기에 있습니다. 같은 이유로 Pingdom이나 GTMetrix 같은 도구를 사용하는 것도 신뢰하기 어렵습니다.

Time To First Byte를 측정하는 가장 좋은 방법은 방문자로부터 RUM(Real User Metrics) 데이터를 수집하는 것입니다. 아래 코드로 직접 구현하거나 CoreDash 같은 RUM 도구를 사용할 수 있습니다.

신세틱 도구로 TTFB 측정

RUM 트래킹으로 TTFB 측정

CrUX 데이터로 TTFB 측정

CrUX (Chrome User Experience Report)는 웹사이트의 실제 성능 데이터를 수집한 Google의 공개 데이터 세트입니다. Google은 사이트의 Core Web Vitals 통과 여부를 판단할 때 CrUX 데이터 세트를 활용합니다.

CrUX 데이터 세트는 PageSpeed Insights, CrUX API, Looker Studio, Google BigQuery 등의 도구를 통해 접근할 수 있습니다. 이러한 도구를 사용해 사이트의 TTFB를 확인하십시오.

JavaScript로 TTFB 측정

JavaScript로 Time to First Byte (TTFB)를 측정하려면 Navigation Timing API를 사용하면 됩니다. 내비게이션 엔트리를 감지하고 responseStart 속성을 콘솔에 출력하는 PerformanceObserver를 생성할 수 있습니다. responseStart 속성은 응답의 첫 번째 바이트를 수신한 시점의 타임스탬프를 나타냅니다. web-vitals JavaScript library의 onTTFB 함수를 사용하면 브라우저에서 훨씬 간단하게 TTFB를 측정할 수 있습니다.

아래 코드를 사용하여 Time To First Byte (TTFB)를 측정할 수 있습니다:

const formatTime = (time) => {

//round by 2 decimals, use Math.round() for integer
return Math.round(time * 100) / 100;
};

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

// timing start times are relative
const activationStart = pageNav.activationStart || 0;
const workerStart = Math.max(pageNav.workerStart - activationStart, activationStart);
const dnsStart = Math.max(pageNav.domainLookupStart - activationStart, workerStart);
const tcpStart = Math.max(pageNav.connectStart - activationStart, dnsStart);
const sslStart = Math.max(pageNav.secureConnectionStart - activationStart, tcpStart);
const requestStart = Math.max(pageNav.requestStart - activationStart, sslStart);
const responseStart = Math.max(pageNav.responseStart - activationStart, requestStart);

// attribution based on https://www.w3.org/TR/navigation-timing-2/#processing-model
// use associative array to log the results more readable
let attributionArray = [];
attributionArray['Redirect Time'] = { 'time in ms': formatTime(workerStart - activationStart) };
attributionArray['Worker and Cache Time'] = { 'time in ms': formatTime(dnsStart - workerStart) };
attributionArray['DNS Time'] = { 'time in ms': formatTime(tcpStart - dnsStart) };
attributionArray['TCP Time'] = { 'time in ms': formatTime(sslStart - tcpStart) };
attributionArray['SSL Time'] = { 'time in ms': formatTime(requestStart - sslStart) };
attributionArray['Request Time'] = { 'time in ms': formatTime(responseStart - requestStart) };
attributionArray['Total TTFB'] = { 'time in ms': formatTime(responseStart - activationStart) };

// log the results
console.log('%cTime to First Byte (' + formatTime(responseStart - activationStart) + 'ms)', 'color: blue; font-weight: bold;');
console.table(attributionArray);

console.log('%cOrigininal navigation entry', 'color: blue; font-weight: bold;');
console.log(pageNav);

}).observe({
type: 'navigation',
buffered: true
});

Server-Timing API로 병목 지점 찾기

Server-Timing API는 백엔드 서버의 성능 측정값을 브라우저로 전송하는 표준화된 방법을 제공합니다. 개발자는 Server-Timing 헤더를 활용해 TTFB에 영향을 주는 서버 측 요소를 효과적으로 측정하고 분석할 수 있으며, 이를 통해 최적화가 필요한 부분을 찾아내 전반적인 웹사이트 성능을 개선할 수 있습니다.

Server-Timing 헤더에는 쉼표로 구분하여 여러 지표의 측정값을 담을 수 있습니다. 각 항목은 다음으로 구성됩니다:

• 지표의 짧은 이름(예: database, processing)
• 밀리초 단위의 소요 시간(예: dur=123)
• 선택적 설명(예: desc="My Description")

Server-Timing: database;dur=123;desc="DB Query", processing;dur=234;desc="Template Render", cache;dur=0;desc="Cache HIT"

Chrome DevTools에서 Server-Timing 확인하기

Chrome DevTools는 Network 패널에 Server-Timing 항목을 직접 표시합니다. DevTools를 열고 Network 탭에서 document 요청을 선택한 뒤, Timing 탭의 'Server Timing' 섹션으로 스크롤을 내립니다. Server-Timing 헤더로 전송한 각 지표가 이름, 설명, 소요 시간과 함께 나타납니다. 이를 통해 데이터베이스, 템플릿 렌더링, 캐싱 계층 중 어디에서 병목이 발생하는지 쉽게 파악할 수 있습니다.

또한 Server-Timing 헤더를 프로그래밍 방식으로 읽어 CoreDash 같은 RUM 도구로 전송하면 장기적인 추적과 알림 설정에 활용할 수도 있습니다.

103 Early Hints로 TTFB 단축하기

103 Early Hints는 최종 응답이 준비되기 전에 서버가 예비 응답 헤더를 브라우저에 먼저 전송할 수 있도록 지원하는 HTTP 상태 코드입니다. 서버가 요청을 처리(데이터베이스 쿼리 실행, 템플릿 렌더링)하는 동안 브라우저는 스타일시트, 폰트, LCP 이미지와 같은 핵심 리소스를 미리 로드하기 시작할 수 있습니다.

103 Early Hints의 작동 원리

기존 요청 흐름에서는 서버가 처리 작업을 진행하는 동안 브라우저가 아무 작업도 하지 않고 유휴 상태로 대기합니다. 반면 103 Early Hints를 사용하면 서버는 요청을 수신하자마자 부분 응답을 즉시 보냅니다. 이 부분 응답에는 브라우저에 어떤 리소스를 미리 로드(preload)하거나 사전 연결(preconnect)해야 하는지 알려주는 Link 헤더가 포함됩니다. 브라우저는 전체 200 응답을 기다리는 동안 이 힌트를 바탕으로 리소스를 즉시 불러옵니다.

이를 통해 무의미하게 버려지던 대기 시간을 생산적인 로딩 시간으로 전환할 수 있습니다. 103 Early Hints가 문서 자체의 TTFB를 단축하는 것은 아니지만, 브라우저가 리소스를 훨씬 일찍 발견하도록 함으로써 LCP나 FCP 같은 후속 지표에 미치는 TTFB의 체감 영향을 줄여줍니다.

103 Early Hints 서버 설정 예시

현재 많은 CDN과 웹 서버가 103 Early Hints를 지원합니다. HTML에서 발견된 Link 헤더와 preload/preconnect 태그를 바탕으로 103 Early Hints를 자동 생성하는 Cloudflare 설정 예시는 다음과 같습니다:

HTTP/1.1 103 Early Hints
Link: </style.css>; rel=preload; as=style
Link: </static/img/hero.webp>; rel=preload; as=image
Link: <https://fonts.googleapis.com>; rel=preconnect

HTTP/1.1 200 OK
Content-Type: text/html
...

Nginx의 경우 응답에 Link 헤더를 추가하고 HTTP/2 또는 HTTP/3 push를 활성화하여 Early Hints를 구성할 수 있습니다. Apache는 H2EarlyHints 지시자를 통해 103 Early Hints를 지원합니다. 단계별 설정 방법은 103 Early Hints 구현 상세 가이드를 확인하십시오.

Speculation Rules API로 TTFB 완전히 제거하기

Speculation Rules API는 향후 발생할 내비게이션의 성능을 향상시키도록 설계되었습니다. 방문자가 페이지에 도달하면 Speculation Rules를 사용해 다음에 방문할 가능성이 높은 페이지를 미리 가져오거나(prefetch 지시어), 완전히 렌더링(prerender 지시어)하도록 브라우저에 명령할 수 있습니다.

Speculation Rules가 TTFB를 제거하는 원리

페이지가 prerender되면 브라우저는 보이지 않는 백그라운드 탭에서 해당 페이지를 완전히 로드하고 렌더링해 둡니다. 사용자가 링크를 클릭하는 순간, 미리 렌더링된 페이지가 즉각적으로 교체 표시됩니다. 그 결과 측정되는 TTFB는 0밀리초입니다. 이는 이론상의 수치가 아닙니다. corewebvitals.io의 CoreDash RUM 데이터에 따르면 Speculation Rules를 통한 prerender 내비게이션의 p75 TTFB는 실제로 0ms로 나타납니다.

Prefetching은 보다 가벼운 대안입니다. 브라우저가 페이지를 완전히 렌더링하는 대신 HTML 문서만 가져와 캐시합니다. 내비게이션 시점에 문서를 파싱하고 렌더링하는 과정은 여전히 필요하지만, TTFB에서 네트워크가 차지하는 시간을 완전히 없앨 수 있습니다.

Speculation Rules JSON 문법

Speculation Rules는 JSON을 포함하는 <script type="speculationrules"> 블록을 사용해 정의합니다. 메뉴 바의 모든 내비게이션 링크를 'moderate' 적극도(마우스 오버나 포인터 다운 시 트리거)로 prerender하는 예시는 다음과 같습니다:

<script type="speculationrules">
{"prerender":
[{
  "source": "document",
  "where": {"selector_matches": "nav a"},
  "eagerness": "moderate"
}]}
</script>

특정 URL에 대해서는 목록(list) 기반 방식을 사용할 수도 있습니다:

<script type="speculationrules">
{"prefetch":
[{
  "source": "list",
  "urls": ["/core-web-vitals/", "/pagespeed/103-early-hints"]
}]}
</script>

Speculation Rules를 지원하는 브라우저는 점차 확대되고 있습니다. Chrome 121 이상에서는 document rules를 포함한 전체 API를 지원합니다. 아직 Speculation Rules를 지원하지 않는 브라우저의 경우 가벼운 스크립트인 quicklink를 fallback으로 사용할 수 있습니다. Speculation Rules Generator를 사용하여 사이트에 적합한 구성을 생성하십시오.

호스팅이 Time to First Byte에 미치는 영향

호스팅은 여러 방면에서 Time to First Byte에 영향을 줍니다. 더 나은 호스팅에 투자하면 다른 요소를 전혀 변경하지 않고도 Time to First Byte를 즉각 개선할 수 있는 경우가 많습니다. 특히 저가형 공유 호스팅에서 올바르게 구성 및 관리되는 가상 서버로 전환할 때 TTFB가 대폭 개선될 수 있습니다.

호스팅 TIP: 더 나은 호스팅이란 더 빠른 처리 속도, 향상된 네트워크 속도, 더 크고 빠른 서버 메모리를 의미합니다. 비싼 호스팅이 항상 더 나은 호스팅을 의미하지는 않습니다. 공유 호스팅 업그레이드 중 상당수는 CPU 성능이 아니라 저장 공간만 늘려줄 뿐입니다.

TTFB 문제의 근본 원인을 파악하지 않고 무작정 호스팅을 바꾸는 것은 권장하지 않습니다. 먼저 RUM 트래킹을 구축하고 Server-Timing 헤더를 추가하십시오.

호스팅을 업그레이드할 때는 일반적으로 다음 세 가지 개선 사항 중 최소 하나 이상을 확인해야 합니다:

• 더 많은 리소스 확보(CPU + RAM): 특히 서버가 동적 HTML을 생성하는 데 너무 오랜 시간이 걸릴 때 필수적입니다.
• 더 빠른 DNS: 많은 저가형 호스팅 업체는 열악한 DNS 성능으로 악명이 높습니다.
• 최적화된 설정: 더 빠른 SSL 암호화 스위트(cipher), HTTP/3, Brotli 압축 지원 여부와 웹 서버 설정을 직접 수정하여 불필요한 모듈을 비활성화할 수 있는지 등을 확인하십시오.

TTFB 개선 방법: 초기 연결 속도 단축

Time to First Byte가 높은 데에는 여러 원인이 있을 수 있습니다. 하지만 DNS, TCP, SSL은 모든 TTFB에 예외 없이 영향을 줍니다. 따라서 여기서부터 시작하십시오. 이 세 가지를 최적화한다고 해서 가장 극적인 결과가 나오지는 않더라도, 모든 단일 TTFB를 빠짐없이 개선할 수 있습니다.

DNS 속도 향상

PageSpeed TIP: DNS, TCP, SSL은 저가형 호스팅을 사용하거나 CDN 없이 글로벌 사용자를 대상으로 서비스할 때 특히 큰 문제가 됩니다. RUM 트래킹을 활용해 글로벌 TTFB를 확인하고 이를 세부 단계로 분석하십시오.

빠른 DNS 공급업체를 사용하십시오. 모든 DNS 공급업체의 속도가 동일하지는 않습니다. 일부 (무료) DNS 공급업체는 다른 (무료) DNS 공급업체보다 현저히 느립니다. 예를 들어 Cloudflare를 이용하면 세계에서 가장 빠른 수준의 DNS를 무료로 이용할 수 있습니다.

DNS TTL 늘리기. 또 다른 방법은 TTL(Time to Live) 값을 늘리는 것입니다. TTL은 조회 결과를 캐시할 기간을 결정하는 설정입니다. TTL이 높을수록 브라우저가 DNS 조회를 다시 수행해야 할 가능성이 줄어듭니다. ISP 역시 DNS를 캐시한다는 점을 기억하십시오.

TCP 속도 향상

TTFB의 'TCP 구간'은 웹 서버와의 초기 연결 단계를 의미합니다. 연결 시 브라우저와 서버는 데이터 교환 방식에 대한 정보를 공유합니다. 사용자와 지리적으로 가까운 서버에 연결하고 서버에 충분한 여유 리소스를 확보하면 TCP 속도를 높일 수 있습니다. 때로는 NGINX와 같은 가벼운 웹 서버로 교체하는 것만으로도 TTFB의 TCP 구간 속도를 높일 수 있습니다. 대부분의 경우 CDN을 사용하면 TCP 연결 속도가 대폭 향상됩니다.

SSL/TLS 속도 향상

TCP 연결이 수립되면 브라우저와 서버는 암호화를 통해 보안 연결을 설정해야 합니다. 더 빠르고 최신이며 가벼운 프로토콜(SSL 암호화 스위트)을 사용하고, 웹 서버와의 지리적 거리를 좁히면 이 속도를 단축할 수 있습니다(TLS 협상에는 여러 번의 왕복 통신이 필요하기 때문입니다). CDN은 전 세계에 분산 서버를 갖추고 매우 정밀하게 최적화되어 있으므로, CDN을 사용하면 대부분 SSL 연결 시간을 크게 줄일 수 있습니다. 특히 TLS 1.3은 TLS 협상 과정을 최대한 단축하도록 설계되었습니다.

TTFB 개선 방법: 서버 측 속도 향상

페이지 캐싱

Time to First Byte를 단축하는 가장 효율적인 방법은 서버 캐시에서 HTML을 제공하는 것입니다. 전체 페이지 캐싱(full page caching)을 구현하는 방법에는 여러 가지가 있습니다. 가장 효과적인 방법은 NGINX 캐싱 모듈을 사용하거나 Varnish를 리버스 캐싱 프록시로 사용하는 등 웹 서버 레벨에서 직접 처리하는 것입니다.

다양한 CMS 시스템에도 전체 페이지를 캐시해 주는 수많은 플러그인이 있으며, Next.js 같은 여러 SPA 프레임워크 역시 다양한 무효화 전략과 함께 자체적인 전체 페이지 캐싱 구현 방식을 제공합니다.

자체 캐싱을 구현하려는 경우 기본 개념은 단순합니다. 클라이언트가 페이지를 요청하면 캐시 폴더에 해당 파일이 있는지 확인합니다. 존재하지 않는다면 페이지를 생성하여 캐시에 기록하고 일반적인 방식으로 페이지를 전달합니다. 이후 해당 페이지에 요청이 들어오면 캐시 파일이 이미 존재하므로 캐시에서 직접 페이지를 제공할 수 있습니다.

부분 캐싱

부분 캐싱은 빠르게 조회할 수 있도록 페이지나 리소스 중 자주 사용되거나 느리거나 비용이 많이 드는 부분(API 호출, 데이터베이스 조회 결과 등)을 캐시하는 기법입니다. 이를 통해 페이지 생성 시의 병목을 없앨 수 있습니다. 이러한 최적화에 관심이 있다면 Memory Cache, Object Cache, Database Cache, Object-Relational Mapping (ORM) Cache, Content Fragment Cache, Opcode Cache 개념을 살펴보십시오.

애플리케이션 코드 최적화

캐시 파일이 존재하지 않거나, 페이지의 상당 부분이 동적이거나, 기타 문제로 인해 (부분) 캐시에서 페이지를 제공할 수 없는 경우가 있습니다. 그렇기 때문에 애플리케이션 코드를 최적화해야 합니다. 구체적인 방법은 애플리케이션에 따라 완전히 다르지만, 본질은 코드에서 느린 부분을 다시 작성하고 최적화하는 데 있습니다.

데이터베이스 쿼리 최적화

Time to First Byte가 느린 원인은 비효율적인 데이터베이스 쿼리인 경우가 대부분입니다. 먼저 '슬로우 쿼리(slow queries)'와 '인덱스를 사용하지 않는 쿼리'를 디스크에 기록하는 것부터 시작하십시오. 이를 분석하여 인덱스를 추가하거나 전문가에게 데이터베이스 튜닝을 의뢰해 문제를 해결하십시오. 자세한 내용은 MongoDB Performance Advisor 및 MySQL Slow Query Log 문서를 참고하십시오.

내부 네트워크 지연 시간 단축

현장에서 생각보다 자주 마주치는 나쁜 사례 중 하나는 웹 애플리케이션과 데이터 스토리지 간의 느린 통신으로 인해 발생하는 Time to First Byte 지연입니다. 이는 주로 데이터 스토리지를 외부 클라우드 API로 분리한 대규모 사이트에서 발생합니다.

TTFB 개선 방법: 클라이언트 측 속도 향상

클라이언트 측 캐싱

클라이언트 측 캐싱은 사용자의 브라우저가 이미지, 스크립트 등 이미 접근한 리소스를 저장해 두는 방식입니다. 사용자가 웹사이트를 재방문할 때 브라우저는 리소스를 다시 다운로드하지 않고 캐시된 리소스를 빠르게 불러옵니다. 이를 통해 서버로 향하는 요청 수를 크게 줄일 수 있으며, 결과적으로 TTFB 단축으로 이어집니다.

클라이언트 측 캐싱을 구현하려면 HTTP Cache-Control 헤더를 사용합니다. 이 헤더를 통해 브라우저가 특정 리소스를 캐시해야 하는 기간을 지정할 수 있습니다.

페이지의 HTML 자체를 클라이언트 측에 완전히 캐시하는 방안도 고려할 수 있습니다. 서버 요청이 발생하지 않으므로 TTFB를 획기적으로 줄일 수 있습니다. 단점은 페이지가 브라우저 캐시에 저장되면 캐시가 만료되기 전까지 사용자가 실제 페이지의 업데이트 내용을 볼 수 없다는 것입니다.

서비스 워커

서비스 워커는 사용자 브라우저의 백그라운드에서 실행되며 브라우저가 발생시키는 네트워크 요청을 가로챌 수 있는 스크립트입니다. 즉, 서비스 워커가 HTML, 이미지, 스크립트, 스타일시트 등의 리소스를 캐시해 두면, 사용자가 웹사이트를 재방문할 때 다시 다운로드할 필요 없이 캐시된 리소스를 즉시 불러올 수 있습니다.

페이지 Prefetching

제한적인 브라우저 지원 현황 때문에 Speculation Rules API를 사용하기 꺼려진다면 quicklink라는 경량 스크립트를 사용할 수 있습니다. 이 스크립트는 현재 화면에 보이는 viewport 내 모든 링크를 prefetch하여 해당 링크의 Time To First Byte를 사실상 완전히 제거해 줍니다.

quicklink의 단점은 더 많은 브라우저 리소스를 소모한다는 점이지만, 브라우저 지원 범위 측면에서는 당분간 Speculation Rules API보다 우위에 있습니다.

TTFB 개선 방법: CDN 활용

CDN(Content Delivery Network)은 분산된 서버 네트워크를 활용해 사용자에게 리소스를 전송합니다. 이러한 서버는 일반적으로 최종 사용자와 지리적으로 더 가까우며 속도에 고도로 최적화되어 있습니다. Cloudflare를 사용하고 있다면 최적의 Core Web Vitals 성능을 위한 Cloudflare 설정 가이드를 확인하십시오.

CDN 및 엣지 캐싱 적용 시의 TTFB

CDN 미적용 시의 TTFB (독일 호스팅)

CDN은 Time to First Byte의 6개 단계 중 5개를 개선하는 데 도움이 됩니다:

• 리다이렉트 시간: 대부분의 CDN은 엣지에서 리다이렉트를 캐시하거나 엣지 워커를 활용해 원본 서버 연결 없이도 리다이렉트를 처리할 수 있습니다.
• DNS 조회 시간: 대부분의 CDN은 현재 사용 중인 DNS 서버보다 뛰어난 초고속 DNS 서버를 제공합니다.
• TCP 연결 및 SSL 핸드셰이크 시간: 대부분의 CDN은 최적화 설정이 매우 잘 되어 있으며, 최종 사용자와의 가까운 물리적 거리 덕분에 연결 및 핸드셰이크 시간을 단축합니다.
• 서버 응답: CDN은 여러 방식으로 서버 응답 시간을 단축합니다. 엣지에 서버 응답을 캐시하는 전체 페이지 엣지 캐싱뿐 아니라 뛰어난 압축(Brotli)과 최신 프로토콜(HTTP/3)을 지원합니다.

TTFB 개선 방법: 리다이렉트 방지

리다이렉트 시간은 Time To First Byte에 그대로 더해집니다. 따라서 기본 원칙으로서 리다이렉트는 가능한 한 피해야 합니다. 리다이렉트는 특정 위치에 있던 리소스가 다른 위치로 이동했을 때 발생합니다. 서버가 리다이렉트 응답 헤더를 반환하면 브라우저는 새 위치로 다시 접속을 시도합니다.

동일 출처 리다이렉트: 사이트 내부 링크에서 비롯되는 리다이렉트입니다. 이러한 링크는 개발자가 완전히 제어할 수 있으므로, Time to First Byte 개선 작업 시 최우선으로 수정해야 합니다. 웹사이트 전체에서 리다이렉트를 검사할 수 있는 도구는 시중에 많이 나와 있습니다.

교차 출처 리다이렉트: 다른 웹사이트의 링크에서 비롯되는 리다이렉트입니다. 이 링크는 직접 제어하기가 사실상 불가능합니다.

다중 리다이렉트: 다중 리다이렉트 또는 리다이렉트 체인은 한 번의 리다이렉트로 리소스의 최종 위치에 도달하지 못할 때 발생합니다. 이러한 리다이렉트는 Time to First Byte에 훨씬 더 큰 부담을 주므로 반드시 피해야 합니다. 점검 도구를 사용해 이러한 리다이렉트를 찾아내어 수정하십시오.

HTTP-HTTPS 리다이렉트: 이를 방지하는 한 가지 방법은 Strict-Transport-Security 헤더(HSTS)를 사용하는 것입니다. HSTS는 오리진 첫 방문 시 HTTPS를 강제하고, 이후 방문부터는 브라우저가 즉시 HTTPS 프로토콜로 직접 접속하도록 지시합니다.

사용자가 웹페이지를 요청했을 때 서버가 다른 페이지로 리다이렉트 응답을 반환할 수 있습니다. 브라우저가 새 페이지로 추가 요청을 보내야 하므로 이 리다이렉트는 TTFB에 불필요한 지연을 더하게 됩니다.

리다이렉트를 방지하거나 리다이렉트의 영향을 최소화하는 방법은 다음과 같습니다:

1. 내부 링크 업데이트: 페이지 위치가 변경되면 해당 페이지로 향하는 내부 링크를 모두 업데이트하여 이전 위치를 참조하는 링크가 남아있지 않도록 합니다.
2. 서버 레벨에서 리다이렉트 처리.
3. 상대 URL 사용: 자체 웹사이트 내 페이지를 연결할 때는 절대 URL 대신 상대 URL을 사용하십시오. 불필요한 리다이렉트를 방지하는 데 도움이 됩니다.
4. 표준(Canonical) URL 사용: 유사한 콘텐츠를 가진 페이지가 여러 개 있다면 canonical URL을 지정하여 대표 페이지를 명시하십시오. 중복 콘텐츠와 불필요한 리다이렉트를 방지할 수 있습니다.
5. 301 리다이렉트 사용: 리다이렉트가 불가피하다면 302 리다이렉트 대신 301 리다이렉트를 사용하십시오. 301은 영구 리다이렉트인 반면 302는 임시 리다이렉트입니다. 301 리다이렉트를 사용하면 불필요한 리다이렉트 반복을 줄일 수 있습니다.

TTFB와 함께 리소스 우선순위 최적화하기

TTFB 단축은 로딩 성능 개선의 첫 단계일 뿐입니다. 첫 바이트가 도착한 후에는 브라우저가 어떤 리소스의 우선순위를 높여야 할지 알아야 합니다. 빠른 TTFB와 fetchpriority, preload, preconnect 힌트를 조합하여 가장 빠른 페이지 로딩을 구현하는 방법은 리소스 우선순위 지정 가이드를 참고하십시오. 아울러 제3자(third-party) DNS 조회와 연결 시간으로 인해 사용자의 체감 TTFB가 늘어나는 문제를 없애려면 Google Fonts 자체 호스팅(self-hosting)을 고려하십시오.

실제 TTFB 데이터가 보여주는 현실

다음 데이터는 CoreDash RUM(Real User Monitoring)과 2025 Web Almanac을 바탕으로 합니다.

지리적 위치에 따른 엄청난 편차

TTFB는 사용자와 서버 간의 물리적 거리에 따라 극심하게 달라집니다. 유럽에 호스팅된 corewebvitals.io의 CoreDash 데이터가 이를 명확하게 보여줍니다:

서버와 가까운 유럽 사용자의 TTFB는 170ms 미만인 반면, 인도 사용자는 3배 높은 TTFB를 경험하고, 중국 사용자는 만리방화벽(Great Firewall)과 물리적 거리로 인해 거의 10배에 달하는 TTFB(1,468ms)를 기록합니다. 이 데이터는 글로벌 사용자를 대상으로 할 때 전 세계 엣지 로케이션을 갖춘 CDN이 왜 필수적인지 명확히 보여줍니다.

Speculation Rules prerender로 0ms TTFB 달성

CoreDash의 내비게이션 유형별 데이터에 따르면 Speculation Rules를 통해 prerender된 페이지는 p75 TTFB 0밀리초를 달성한 것으로 확인되었습니다. 일반 내비게이션은 131ms, 새로고침(reload)은 82ms(웜 커넥션 효과), 뒤로 가기/앞으로 가기(back-forward) 내비게이션은 244ms로 가장 느렸습니다. 따라서 Speculation Rules는 후속 페이지 로딩에서 TTFB를 없애는 가장 효과적인 단일 기술입니다.

모바일 TTFB는 데스크톱의 2.5배

corewebvitals.io에서 모바일 사용자의 p75 TTFB는 316ms로, 데스크톱의 124ms에 비해 훨씬 느립니다. 이 2.5배의 격차는 서버 차이가 아니라 모바일 네트워크 지연 시간 때문에 발생합니다. 데스크톱 페이지 로드의 96.1%가 TTFB '좋음' 등급을 달성한 반면, 모바일은 88.5%에 불과합니다. TTFB를 최적화할 때는 항상 실제 모바일 네트워크 환경에서 테스트하십시오.

신규 방문자와 재방문자의 유사한 TTFB

이 사이트의 경우 신규 방문자의 p75 TTFB는 127ms, 재방문자는 138ms를 기록했습니다. 두 수치가 비슷한 것은 클라이언트 측 캐시의 이점보다는 일관된 서버 측 캐싱이 TTFB 성능을 좌우하는 핵심 요인임을 시사합니다. 서버 측 캐싱이 없는 사이트에서는 신규 방문자와 재방문자 간의 격차가 훨씬 더 벌어질 수 있습니다.

5년간 정체된 전 세계 TTFB

2025 Web Almanac에 따르면 전 세계적으로 모바일 페이지 중 TTFB '좋음' 점수를 달성한 비율은 44%에 불과합니다. 이 수치는 2021년의 41%에서 거의 변하지 않아, TTFB는 웹에서 가장 정체된 성능 지표로 남아 있습니다. 같은 기간 동안 LCP는 44%에서 59%로, INP는 55%에서 74%로 개선된 것과 대조적입니다. LCP가 나쁜 사이트는 TTFB에만 평균 2.27초를 소비하는데, 이는 LCP 기준치인 2.5초의 대부분에 해당합니다.

관련 가이드: TTFB 세부 단계별 분석

Time to First Byte의 각 세부 단계마다 고유한 최적화 전략이 있습니다:

• <b>TTFB 문제 진단 및 해결</b>: DevTools, Server-Timing, RUM 데이터를 활용해 느린 TTFB의 근본 원인을 파악하는 단계별 진단 가이드입니다.
• <b>대기 시간 단축</b>: TTFB를 지연시키는 리다이렉트 시간과 서버 처리 지연을 최소화하는 방법입니다.
• <b>캐시 시간 단축</b>: 재방문자의 TTFB를 없애기 위한 브라우저 캐싱, 서비스 워커, 뒤로 가기/앞으로 가기 캐시(bfcache) 활용 전략입니다.
• <b>DNS 소요 시간 최소화</b>: 더 빠른 DNS 공급업체, TTL 값 증가, dns-prefetch 리소스 힌트를 통해 DNS 확인 속도를 높이는 방법입니다.
• <b>연결 시간 최적화 (TCP + TLS)</b>: HTTP/3, TLS 1.3, 세션 재개(session resumption), preconnect 힌트를 활용해 TCP 및 TLS 핸드셰이크 시간을 줄이는 방법입니다.