Time To First Byte(TTFB)란 무엇이며 어떻게 개선할 수 있을까

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

Time to First Byte란 무엇인가

Time to First Byte(TTFB)는 웹페이지의 요청이 시작된 시점부터 첫 번째 응답(바이트)을 수신할 때까지 경과한 시간(밀리초)을 나타냅니다. 따라서 TTFB는 대기 시간이라고도 합니다. TTFB는 웹 서버의 반응성과 사용자와 해당 서버 간의 네트워크 경로를 측정하는 방법입니다. TTFB는 기초 지표입니다. 즉, TTFB에 추가된 시간은 Largest Contentful Paint와 First Contentful Paint에도 추가됩니다. TTFB에서 절약한 1밀리초는 이 두 가지 페인트 지표 모두에서 절약한 1밀리초가 됩니다.

TTFB는 Core Web Vitals가 아닙니다

이 점을 명확히 하는 것이 중요합니다. TTFB는 세 가지 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초를 소비하며, 이는 브라우저가 페이지 렌더링을 시작하기도 전에 2.5초의 LCP 임계값을 거의 모두 소진하는 것입니다. 따라서 TTFB를 수정하는 것은 전반적인 Core Web Vitals 점수를 위해 할 수 있는 가장 영향력 있는 일 중 하나입니다.

Time to First Byte가 중요한 이유

Time to First Byte는 Core Web Vitals가 아니며, TTFB 지표에 실패하더라도 Core Web Vitals를 통과하는 것이 매우 가능합니다. 그렇다고 해서 TTFB가 중요하지 않다는 의미는 아닙니다. TTFB는 최적화해야 할 매우 중요한 지표이며, TTFB를 수정하면 페이지 속도와 사용자 경험(UX)이 크게 향상됩니다.

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

Time to First Byte는 다른 모든 페인트 지표에 선행합니다. 브라우저가 Time to First Byte를 기다리는 동안에는 아무것도 할 수 없으며 빈 화면만 표시됩니다. 즉, Time to First Byte가 증가하면 "빈 화면" 시간이 늘어나고 Time to First Byte가 감소하면 "빈 화면" 시간이 줄어듭니다.

페이지가 즉시 로드되는 느낌을 받으려면 Time to First Byte가 가능한 한 빨라야 합니다.

TTFB가 Core Web Vitals가 아닌 이유는 무엇인가요? TTFB는 렌더링을 고려하지 않습니다. TTFB가 낮다고 해서 브라우저가 웹페이지를 렌더링하는 데 걸리는 시간을 고려하지 않기 때문에 반드시 좋은 사용자 경험(UX)을 의미하는 것은 아닙니다. 모든 바이트가 빠르게 다운로드되더라도 브라우저가 많은 JavaScript를 처리하거나 복잡한 레이아웃을 렌더링해야 하는 경우 웹페이지를 표시하는 데 여전히 오랜 시간이 걸릴 수 있습니다.

좋은 TTFB 점수란 무엇일까요?

75백분위수의 사용자가 "좋음" 임계값 내에서 FCP를 경험할 수 있도록 서버가 내비게이션 요청에 충분히 빠르게 응답하는 것이 권장됩니다. 대략적인 지침으로 대부분의 사이트는 TTFB를 0.8초 이하로 유지하기 위해 노력해야 합니다.

• 800밀리초 미만의 TTFB는 좋은 것으로 간주됩니다.
• 800밀리초에서 1800밀리초 사이의 TTFB는 개선이 필요합니다.
• 1800밀리초를 초과하는 TTFB는 나쁜 것으로 간주되며 즉시 개선해야 합니다.

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

T-Mobile은 광범위한 성능 최적화 이니셔티브의 일환으로 Time to First Byte를 줄이는 데 막대한 투자를 했습니다. 결과는 놀라웠습니다. 방문 대비 주문 전환율이 60% 증가했습니다. 엣지 렌더링 페이지와 공격적인 서버 측 캐싱으로 전환함으로써 T-Mobile은 사용자가 첫 번째 바이트를 기다리는 시간을 크게 줄였고, 이는 더 빠른 LCP, 더 빠른 FCP, 눈에 띄게 더 나은 사용자 경험(UX)으로 이어졌습니다. 이 사례 연구는 TTFB 최적화가 단순한 기술적 연습이 아니라 비즈니스 결과에 직접적인 영향을 미친다는 것을 보여줍니다.

요청에서 응답까지의 TTFB

브라우저에서 서버로: 요청

브라우저 요청 시간은 사용자의 브라우저가 HTTP 요청을 보낸 순간부터 해당 요청이 웹사이트를 호스팅하는 서버에 도달할 때까지 경과한 시간입니다. 이 부분의 TTFB는 웹사이트가 직접 제어할 수 있는 범위를 크게 벗어나며 다음 사항에 크게 의존합니다.

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

이 단계 내에서 DNS 조회, 브라우저 시작 시간, 브라우저 캐시 조회 및 서버와의 연결 협상(TCP 및 TLS)이 모두 약간의 시간을 차지합니다.

서버에서: 응답 처리 및 준비

서버가 요청을 수신하면 응답을 생성하기 위해 작동함에 따라 시계가 째깍거립니다. 이 단계는 대부분의 개발자가 집중하는 경향이 있으며 최적화 노력이 가장 큰 영향을 미칠 수 있는 부분입니다. 고려해야 할 요소는 다음과 같습니다.

• 서버 기능: 강력한 하드웨어(CPU, RAM), 효율적인 소프트웨어(웹 서버, 데이터베이스) 및 최적화된 구성이 모두 중요합니다.
• 데이터베이스 지속 시간: 요청에 데이터베이스에서 데이터를 가져와야 하는 경우 느린 쿼리가 주요 병목 현상이 될 수 있습니다.
• 코드 최적화: 비효율적인 서버 측 코드(예: 비효율적인 스크립트)는 긴 처리 시간으로 이어질 수 있습니다.
• 캐싱 전략: 효과적인 캐싱(서버 측 캐싱 또는 콘텐츠 전송 네트워크 사용과 같은)은 반복 요청에 대한 처리 부담을 대폭 줄일 수 있습니다.

브라우저로 돌아가기: 첫 번째 바이트 전송

처리 후 서버는 첫 번째 바이트로 시작하는 응답을 사용자 브라우저로 다시 보냅니다.

• 첫 번째 단계와 마찬가지로 네트워크 조건과 거리도 여기서 역할을 합니다.
• 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 팁: 모든 리소스에는 고유한 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 사용자 경험 보고서)는 웹사이트에 대한 실제 성능 데이터를 포함하는 Google에서 공개적으로 사용할 수 있는 데이터세트입니다. Google은 CrUX 데이터세트를 사용하여 Core Web Vitals를 통과하는지 여부를 결정합니다.

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 라이브러리는 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는 네트워크 패널에 직접 Server-Timing 항목을 표시합니다. DevTools를 열고 네트워크 탭에서 문서 요청을 선택한 다음 타이밍 탭의 "서버 타이밍" 섹션으로 아래로 스크롤합니다. Server-Timing 헤더를 통해 보내는 각 지표는 이름, 설명 및 기간과 함께 표시됩니다. 이렇게 하면 데이터베이스, 템플릿 렌더링 또는 캐싱 계층이 병목 현상인지 간단하게 식별할 수 있습니다.

또한 프로그래밍 방식으로 Server-Timing 헤더를 읽고 장기적인 추적 및 경고를 위해 이러한 타이밍을 CoreDash와 같은 즐겨 사용하는 RUM 도구로 보낼 수도 있습니다.

103 Early Hints로 TTFB 속도 높이기

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

103 Early Hints의 작동 방식

기존의 요청 흐름에서 브라우저는 전체 서버 처리 시간 동안 유휴 상태를 유지합니다. 103 Early Hints를 사용하면 서버는 요청을 받은 직후에 부분 응답을 즉시 보냅니다. 이 부분 응답에는 브라우저에 미리 로드하거나 미리 연결할 리소스를 알려주는 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 푸시를 활성화하여 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를 통한 사전 렌더링된 내비게이션이 p75 TTFB 0ms를 보여준다는 것을 확인시켜 줍니다.

프리패칭(Prefetching)은 더 가벼운 대안입니다. 페이지를 완전히 렌더링하는 대신 브라우저는 HTML 문서만 가져와서 캐시합니다. 이렇게 하면 TTFB의 네트워크 부분이 제거되지만 탐색 시 여전히 브라우저가 문서를 구문 분석하고 렌더링해야 합니다.

Speculation Rules JSON 구문

Speculation Rules는 JSON을 포함하는 <script type="speculationrules"> 블록을 사용하여 정의됩니다. 다음은 "moderate" 한 신속함(마우스를 올리거나 포인터를 누를 때 트리거됨)으로 메뉴 표시줄의 모든 내비게이션 링크를 미리 렌더링하는 예입니다.

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

특정 URL에 목록 기반 접근 방식을 사용할 수도 있습니다.

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

Speculation Rules에 대한 브라우저 지원이 증가하고 있습니다. Chrome 121 이상은 문서 규칙을 포함한 전체 API를 지원합니다. 아직 Speculation Rules를 지원하지 않는 브라우저의 경우 폴백(fallback)으로 quicklink와 같은 가벼운 스크립트를 사용할 수 있습니다. Speculation Rules 생성기를 사용하여 사이트에 맞는 구성을 만드세요.

호스팅이 Time to First Byte에 어떤 영향을 미치나요?

호스팅은 여러 가지 방식으로 Time to First Byte에 영향을 미칩니다. 더 나은 호스팅에 투자함으로써 일반적으로 아무것도 변경하지 않고도 Time to First Byte를 즉시 개선할 수 있습니다. 특히 저예산 공유 호스팅에서 제대로 구성되고 관리되는 가상 서버로 전환할 때 TTFB가 크게 향상될 수 있습니다.

호스팅 팁: 더 나은 호스팅에는 더 빠른 처리, 더 나은 네트워크 속도 및 더 많고 더 빠른 서버 메모리가 포함됩니다. 비싼 호스팅이 항상 더 나은 호스팅을 의미하는 것은 아닙니다. 공유 호스팅 서비스의 많은 업그레이드는 더 많은 CPU 성능이 아니라 더 많은 스토리지만을 제공합니다.

TTFB 문제의 근본 원인을 알지 못한 채 호스팅을 변경하는 것은 권장하지 않습니다. RUM 추적을 설정하고 Server-Timing 헤더를 추가하는 것이 좋습니다.

호스팅을 업그레이드할 때는 일반적으로 다음 세 가지 개선 사항 중 적어도 하나를 찾아야 합니다.

• 더 많은 리소스(CPU + RAM) 확보: 특히 서버에서 동적 HTML을 생성하는 데 너무 오래 걸리는 경우.
• 더 빠른 DNS: 많은 저예산 호스팅 제공 업체는 DNS 성능이 좋지 않기로 악명이 높습니다.
• 더 나은 구성: 더 빠른 SSL 암호, HTTP/3, Brotli 압축, 웹 서버 구성에 대한 액세스(불필요한 모듈 비활성화) 등을 찾아보세요.

TTFB를 개선하는 방법: 초기 연결 속도 향상

높은 Time to First Byte에는 여러 가지 원인이 있을 수 있습니다. 그러나 DNS, TCP 및 SSL은 모든 Time to First Byte에 영향을 미칩니다. 그러니 거기서부터 시작합시다. 이 세 가지를 최적화한다고 해서 가장 큰 결과를 얻지 못할 수도 있지만, 이들을 최적화하면 모든 단일 TTFB가 최적화됩니다.

DNS 속도 향상

PageSpeed 팁: DNS, TCP 및 SSL은 일반적으로 저렴한 호스트를 사용하거나 CDN을 사용하지 않으면서 글로벌 사용자에게 서비스할 때 더 큰 문제입니다. RUM 추적을 사용하여 글로벌 TTFB를 확인하고 TTFB를 하위 부분으로 나눕니다.

빠른 DNS 공급자를 사용하세요. 모든 DNS 공급자가 다른 공급자만큼 빠른 것은 아닙니다. 일부(무료) DNS 공급자는 다른(무료) DNS 공급자보다 느립니다. 예를 들어 Cloudflare는 세계에서 가장 빠른 DNS 공급자 중 하나를 무료로 제공합니다.

DNS TTL 늘리기. 또 다른 방법은 Time to Live(TTL) 값을 늘리는 것입니다. 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을 제공하는 것입니다. 전체 페이지 캐싱을 구현하는 방법에는 여러 가지가 있습니다. 가장 효과적인 방법은 예를 들어 NGINX 캐싱 모듈을 사용하거나 Varnish를 역방향 캐싱 프록시로 사용하여 웹 서버 수준에서 직접 이 작업을 수행하는 것입니다.

또한 전체 페이지를 캐시하는 다양한 CMS 시스템용 플러그인이 많이 있으며 Next.js와 같은 많은 SPA 프레임워크에는 다양한 무효화 전략과 함께 전체 페이지 캐싱의 자체 구현이 있습니다.

고유한 캐싱을 구현하려는 경우 기본 아이디어는 간단합니다. 클라이언트가 페이지를 요청하면 캐시 폴더에 페이지가 있는지 확인합니다. 존재하지 않는 경우 페이지를 만들고 캐시에 쓴 다음 평소처럼 페이지를 표시합니다. 페이지에 대한 다음 요청 시 캐시 파일이 존재하며 캐시에서 직접 페이지를 제공할 수 있습니다.

부분 캐싱

부분 캐싱을 사용하면 자주 사용되거나 느리거나 비용이 많이 드는 페이지의 일부 또는 리소스(예: API 호출, 데이터베이스 결과)를 빠른 검색을 위해 캐시하는 것입니다. 이렇게 하면 페이지를 생성할 때 병목 현상이 제거됩니다. 이러한 유형의 최적화에 관심이 있다면 다음 개념을 찾아보아야 합니다: 메모리 캐시, 객체 캐시, 데이터베이스 캐시, ORM(Object-Relational Mapping) 캐시, 콘텐츠 조각 캐시 및 Opcode 캐시.

애플리케이션 코드 최적화

캐시 파일이 없거나, 페이지의 많은 부분이 동적이거나, 다른 문제가 발생하여 (부분) 캐시에서 페이지를 제공할 수 없는 경우가 있습니다. 그렇기 때문에 애플리케이션 코드를 최적화해야 합니다. 이것이 수행되는 방법은 전적으로 귀하의 애플리케이션에 달려 있습니다. 코드의 느린 부분을 다시 작성하고 최적화하는 데 기반을 두고 있습니다.

데이터베이스 쿼리 최적화

대부분의 경우 비효율적인 데이터베이스 쿼리가 느린 Time to First Byte의 근본 원인입니다. "느린 쿼리"와 "인덱스를 사용하지 않는 쿼리"를 디스크에 로깅하는 것으로 시작하세요. 이를 분석하고, 인덱스를 추가하거나, 전문가에게 데이터베이스 튜닝을 요청하여 이러한 문제를 해결하세요. 자세한 내용은 MongoDB Performance Advisor 및 MySQL 느린 쿼리 로그(Slow Query Log)를 참조하세요.

내부 네트워크 지연 시간 줄이기

제가 자주 접하는 나쁜 관행은 웹 애플리케이션과 데이터 스토리지 간의 통신 속도 저하로 인한 Time to First Byte의 지연입니다. 이는 일반적으로 데이터 스토리지를 클라우드 API에 아웃소싱한 대규모 사이트에서만 발생합니다.

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

클라이언트 측 캐싱

클라이언트 측 캐싱에는 사용자의 브라우저가 이미지 및 스크립트와 같이 이미 액세스한 리소스를 저장하는 작업이 포함됩니다. 따라서 사용자가 웹사이트로 돌아올 때 해당 브라우저는 리소스를 다시 다운로드하는 대신 캐시된 리소스를 빠르게 검색할 수 있습니다. 이렇게 하면 서버에 대한 요청 수를 크게 줄일 수 있으며, 이는 결과적으로 TTFB를 줄일 수 있습니다.

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

클라이언트 측에서 페이지의 HTML을 완전히 캐시하는 것을 고려할 수 있습니다. 서버 요청이 필요하지 않기 때문에 TTFB가 크게 줄어듭니다. 단점은 페이지가 브라우저의 캐시에 있으면 페이지 캐시가 만료될 때까지 사용자가 페이지의 라이브 버전에 대한 업데이트를 볼 수 없다는 것입니다.

서비스 워커(Service Workers)

서비스 워커(Service Workers)는 사용자 브라우저의 백그라운드에서 실행되며 브라우저에서 수행하는 네트워크 요청을 가로챌 수 있는 스크립트입니다. 즉, 서비스 워커는 HTML, 이미지, 스크립트 및 스타일시트와 같은 리소스를 캐시하여 사용자가 웹사이트로 돌아올 때 해당 브라우저가 리소스를 다시 다운로드하는 대신 캐시된 리소스를 빠르게 검색할 수 있습니다.

페이지 프리패칭(Page Prefetching)

제한된 브라우저 지원으로 인해 Speculation Rules API를 사용하지 않으려면 quicklink라는 작은 스크립트를 사용할 수 있습니다. 그러면 보이는 뷰포트에 있는 모든 링크를 미리 가져오고 이러한 링크에 대한 Time To First Byte를 거의 모두 제거합니다.

quicklink의 단점은 더 많은 브라우저 리소스가 필요하다는 것이지만, 당분간은 브라우저 커버리지 측면에서 Speculation Rules API보다 성능이 뛰어납니다.

TTFB를 개선하는 방법: CDN 사용

CDN(콘텐츠 전송 네트워크)은 분산된 서버 네트워크를 사용하여 리소스를 사용자에게 전송합니다. 이러한 서버는 일반적으로 최종 사용자에게 지리적으로 더 가깝고 속도에 고도로 최적화되어 있습니다. Cloudflare를 사용하는 경우 최적의 Core Web Vitals 성능을 위해 Cloudflare를 구성하는 방법에 대한 가이드를 확인하세요.

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)를 사용하는 것입니다. 이 헤더는 출처에 대한 첫 번째 방문 시 HTTPS를 적용한 다음 브라우저에 이후 방문 시 HTTPS 체계를 통해 즉시 출처에 액세스하도록 지시합니다.

사용자가 웹 페이지를 요청할 때 서버는 다른 페이지로의 리디렉션으로 응답할 수 있습니다. 브라우저가 새 페이지에 대해 추가 요청을 해야 하므로 이 리디렉션은 TTFB에 추가 시간을 더할 수 있습니다.

리디렉션을 피하거나 리디렉션의 영향을 최소화하는 방법에는 여러 가지가 있습니다.

1. 내부 링크를 업데이트하세요. 페이지의 위치를 변경할 때마다 해당 페이지에 대한 내부 링크를 업데이트하여 이전 페이지 위치에 대한 참조가 남아 있지 않도록 하세요.
2. 서버 수준에서 리디렉션을 처리하세요.
3. 상대 URL 사용: 자신의 웹사이트에 있는 페이지로 연결할 때 절대 URL 대신 상대 URL을 사용하세요. 이렇게 하면 불필요한 리디렉션을 방지하는 데 도움이 됩니다.
4. 표준(Canonical) URL 사용: 콘텐츠가 비슷한 페이지가 여러 개 있는 경우 표준 URL을 사용하여 선호하는 버전의 페이지를 나타냅니다. 이렇게 하면 중복 콘텐츠와 불필요한 리디렉션을 방지하는 데 도움이 됩니다.
5. 301 리디렉션 사용: 리디렉션을 사용해야 하는 경우 302 리디렉션 대신 301 리디렉션을 사용하세요. 301 리디렉션은 영구 리디렉션인 반면 302 리디렉션은 임시 리디렉션입니다. 301 리디렉션을 사용하면 불필요한 리디렉션을 방지하는 데 도움이 됩니다.

TTFB와 함께 리소스 우선순위 지정 최적화

TTFB를 줄이는 것은 로딩 성능 이야기의 일부일 뿐입니다. 첫 번째 바이트가 도착하면 브라우저는 우선순위를 지정할 리소스를 알아야 합니다. 리소스 우선순위 지정 가이드를 읽고 fetchpriority, preload 및 preconnect 힌트가 빠른 TTFB와 함께 작동하여 가능한 가장 빠른 페이지 로드를 제공하는 방법을 알아보세요. 또한 사용자가 체감하는 TTFB에 추가되는 타사 DNS 조회 및 연결 시간을 없애기 위해 Google Fonts를 자체 호스팅하는 것을 고려하세요.

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

다음 데이터는 CoreDash Real User Monitoring 및 2025 Web Almanac에서 제공합니다.

지리적 편차가 큽니다

TTFB는 사용자와 서버 간의 물리적 거리에 따라 극적으로 다릅니다. corewebvitals.io(유럽에서 호스팅됨)의 CoreDash 데이터는 이를 분명하게 보여줍니다.

서버 근처의 유럽 사용자는 170ms 미만의 TTFB를 보는 반면, 인도 사용자는 3배 더 높은 TTFB를 경험하고 중국 사용자는 만리장성 방화벽(Great Firewall)과 물리적 거리로 인해 거의 10배 더 높은 TTFB(1,468ms)를 봅니다. 이 데이터는 글로벌 오디언스에게 글로벌 엣지 위치를 갖춘 CDN이 필수적인 이유를 보여줍니다.

Speculation Rules 사전 렌더링은 0ms TTFB를 제공합니다

CoreDash 내비게이션 유형 데이터는 Speculation Rules를 통해 미리 렌더링된 페이지가 p75 TTFB 0밀리초를 달성한다는 것을 확인해 줍니다. 표준 탐색은 131ms, 다시 로드는 82ms(웜 연결의 이점 활용), 뒤로/앞으로 탐색은 244ms로 가장 느립니다. 이로 인해 Speculation Rules는 후속 페이지 로드에서 TTFB를 없애는 데 있어 가장 효과적인 단일 기술이 되었습니다.

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

corewebvitals.io에서 모바일 사용자는 데스크톱의 124ms에 비해 316ms의 p75 TTFB를 경험합니다. 이 2.5배의 격차는 서버 차이가 아니라 모바일 네트워크 대기 시간으로 인해 발생합니다. 데스크톱의 96.1%와 비교하여 모바일 페이지 로드의 88.5%만이 "좋은" TTFB 등급을 달성합니다. TTFB를 최적화할 때는 항상 실제 모바일 네트워크에서 테스트하세요.

신규 방문자와 재방문자의 TTFB는 비슷합니다

이 사이트에서 신규 방문자는 p75 TTFB 127ms를 보고 재방문자는 138ms를 봅니다. 유사점은 클라이언트 측 캐시 이점보다는 일관된 서버 측 캐싱이 TTFB 성능의 주요 요인임을 시사합니다. 서버 측 캐싱이 없는 사이트의 경우 신규 방문자와 재방문자 간의 격차가 훨씬 더 클 수 있습니다.

글로벌 TTFB는 5년 동안 정체되어 있습니다

2025 Web Almanac에 따르면 모바일 페이지의 44%만이 전 세계적으로 "좋은" TTFB 점수를 달성했습니다. 이 수치는 2021년 41%에서 거의 변하지 않았으며 TTFB는 웹에서 가장 정체된 성능 지표가 되었습니다. 반면 LCP는 같은 기간 동안 44%에서 59%로, INP는 55%에서 74%로 개선되었습니다. LCP가 좋지 않은 사이트는 TTFB에만 평균 2.27초를 소비하며, 이는 2.5초 LCP 임계값의 거의 전체에 해당합니다.

관련 가이드: 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, 세션 재개 및 preconnect 힌트를 사용하여 TCP 및 TLS 핸드셰이크 시간을 줄입니다.