Time to First Byte의 하위 요소인 대기 시간 단축하기

Time to First Byte의 대기 시간 단축하기

이 문서는 Time to First Byte (TTFB) 가이드의 일부입니다. 대기 시간은 TTFB의 첫 번째 하위 요소이며 주로 리디렉션 시간과 브라우저 대기열로 구성됩니다. 대기 시간이 긴 것은 대부분 서버가 실제 요청을 처리하기 전에 왕복 횟수를 늘리는 불필요한 리디렉션 때문입니다.

Time to First Byte (TTFB)는 다음과 같은 하위 요소로 나눌 수 있습니다.

• 대기 + 리디렉션 (또는 대기 시간)
• 워커 + 캐시 (또는 캐시 지속 시간)
• DNS (또는 DNS 소요 시간)
• 연결 (또는 연결 소요 시간)
• 요청 (또는 요청 소요 시간)

Time to First Byte를 최적화하고 싶으신가요? 이 문서에서는 Time to First Byte의 대기 시간에 대해 다룹니다. Time to First Byte를 이해하거나 문제를 해결하고자 하는데 대기 시간이 무엇을 의미하는지 모른다면, 이 문서를 시작하기 전에 Time to First Byte란 무엇인가와 Time to First Byte 문제 식별 및 해결 방법을 읽어보시기 바랍니다.

리디렉션은 브라우저가 서버로부터 데이터의 첫 바이트를 수신하는 데 걸리는 시간에 추가되므로 Time to First Byte (TTFB)에 큰 영향을 미칠 수 있습니다. 리디렉션이 TTFB에 미치는 영향은 다음과 같습니다.

리디렉션은 어떻게 Time to First Byte를 증가시키는가?

리디렉션은 일반적으로 전체 TTFB 측정(파란색 상자 참조)에 포함됩니다. 즉, 모든 리디렉션에 소요된 시간이 전체 TTFB 점수에 반영되어 예상보다 더 높게 나타날 수 있습니다.

페이지가 리디렉션될 때 일반적으로 다음과 같은 단계가 발생합니다.

• 브라우저가 원래 URL로 초기 요청을 보냅니다.
• 서버는 이 요청을 처리하고 리디렉션 상태 코드(예: 301 또는 302)로 응답합니다.
• 그런 다음 브라우저는 리디렉션된 URL로 새로운 요청을 보냅니다.
• 서버는 이 두 번째 요청을 처리하고 실제 콘텐츠를 전송하기 시작합니다.

리디렉션의 종류와 그 영향

모든 리디렉션이 동일한 것은 아닙니다. 다양한 유형을 이해하면 제거해야 할 리디렉션의 우선순위를 정하는 데 도움이 됩니다.

단일 리디렉션은 네트워크 상태와 서버 응답 시간에 따라 일반적으로 TTFB에 50~300밀리초를 추가합니다. 두세 개의 리디렉션이 체인으로 연결되면 그 시간이 누적되어 TTFB가 800ms "양호(good)" 기준치를 훨씬 초과할 수 있습니다.

서버 처리 시간 증가

각 단계마다 서버가 요청을 처리하고 응답하는 데 시간이 필요하므로 이러한 추가 처리는 전체 TTFB를 증가시킵니다.

리디렉션 체인

경우에 따라 최종 목적지에 도달하기 전에 여러 리디렉션이 발생할 수 있습니다. 이는 TTFB를 증가시키는 "리디렉션 체인"을 생성합니다. 체인 내의 각 리디렉션은 고유한 처리 시간을 추가하여 실제 콘텐츠의 첫 바이트가 수신되기 전까지의 지연을 가중시킵니다.

리디렉션 체인의 일반적인 예는 다음과 같습니다.

http://example.com
  -> 301 -> https://example.com
    -> 301 -> https://www.example.com
      -> 301 -> https://www.example.com/en/

이 예에서는 브라우저가 콘텐츠를 수신하기 전에 세 번의 리디렉션이 발생합니다. 첫 번째 리디렉션(HTTP에서 HTTPS로)은 HSTS를 사용하여 제거할 수 있습니다. 두 번째와 세 번째 리디렉션은 내부 링크를 업데이트하여 최종 URL을 직접 가리키도록 함으로써 제거할 수 있습니다.

네트워크 지연

리디렉션에는 종종 클라이언트와 서버 간의 추가적인 네트워크 왕복이 수반됩니다. 이로 인해 리디렉션이 다른 도메인이나 서버와 관련이 있는 경우 특히 추가적인 네트워크 지연이 발생합니다. 각 리디렉션에 대한 클라이언트와 서버 사이의 물리적 거리는 TTFB에 더 큰 영향을 미칠 수 있습니다.

JavaScript 리디렉션 vs 서버 측 리디렉션: 서버 측 리디렉션(30x 리디렉션 헤더와 함께 작동)만 Time to First Byte에 추가됩니다. JavaScript 리디렉션은 서버에서 이미 완전한 응답(200)을 보냈기 때문에 Time to First Byte에 추가되지 않습니다.

JavaScript 리디렉션이 Time to First Byte를 늘리지 않기 때문에 더 낫다고 생각할 수도 있습니다. 안타깝게도 JavaScript 리디렉션은 실제 사용자에게 훨씬 더 느리며 나쁜 User Experience를 초래합니다.

User Experience (및 SEO)에 미치는 영향

리디렉션이 때로는 필요하지만 TTFB에 미치는 영향은 더 광범위한 결과를 낳을 수 있습니다.

• User Experience: 리디렉션으로 인한 느린 TTFB는 페이지의 초기 렌더링을 지연시켜 사용자를 좌절시킬 수 있습니다.
• SEO: TTFB가 직접적인 순위 지정 요소는 아니지만 검색 엔진이 고려하는 Core Web Vitals 중 하나인 Largest Contentful Paint (LCP)와 같은 다른 지표에 영향을 줍니다.
• 크롤링 예산: 검색 엔진 크롤러는 리디렉션을 따라가므로 각 리디렉션은 추가 크롤링 예산을 소비합니다. 대규모 웹사이트의 경우 새로운 콘텐츠나 업데이트된 콘텐츠의 발견 속도를 늦출 수 있습니다.

리디렉션으로 인한 TTFB 문제를 측정하는 방법

리디렉션이 실제 사용자에게 미치는 영향을 파악하려면 CoreDash와 같은 RUM 도구를 사용해야 합니다. Real User Monitoring (RUM)을 사용하면 Core Web Vitals를 매우 자세히 추적할 수 있습니다.

CoreDash에서는 "redirect count(리디렉션 수)"를 클릭하기만 하면 리디렉션 수별로 분류된 데이터를 시각화할 수 있습니다. 그런 다음, 예를 들어 "1 redirect" 세그먼트를 클릭하여 RUM 데이터를 "1 redirect"로 필터링하고 영향을 받는 모든 URL을 확인합니다.

사이트의 리디렉션을 감사하는 방법

체계적인 리디렉션 감사에는 다음 3단계가 포함됩니다.

1단계: 사이트 크롤링

크롤링 도구(MarketingTracer, Screaming Frog 또는 Sitebulb 등)를 사용하여 전체 웹사이트를 크롤링합니다. 크롤러는 3xx 상태 코드로 응답하는 모든 내부 URL을 보고합니다. 목록을 내보내고 각 리디렉션된 URL을 가리키는 내부 수신 링크 수를 기준으로 정렬합니다.

2단계: 리디렉션 체인 식별

다른 곳으로 리디렉션되는 URL로 리디렉션되는 모든 URL을 크롤링 결과에서 필터링합니다. 이러한 체인은 TTFB 페널티를 배가시키므로 가장 먼저 수정해야 합니다.

3단계: 수정 및 확인

내부 링크를 업데이트하여 최종 목적지 URL을 직접 가리키도록 합니다. 링크를 업데이트한 후 다시 크롤링하여 내부 탐색에서 더 이상 리디렉션이 트리거되지 않는지 확인합니다. 다음 JavaScript 스니펫을 사용하여 브라우저에서 리디렉션을 감지하세요.

new PerformanceObserver((entryList) => {
  const [nav] = entryList.getEntriesByType('navigation');
  if (nav.redirectCount > 0) {
    console.warn('Redirect detected!', {
      redirectCount: nav.redirectCount,
      redirectTime: nav.redirectEnd - nav.redirectStart,
      finalUrl: nav.name
    });
  }
}).observe({
  type: 'navigation',
  buffered: true
});

리디렉션 영향을 최소화하는 방법

리디렉션 문제를 방지하기 위한 일반적인 규칙으로 다음 3가지 간단한 단계를 따르세요.

• 가능한 한 리디렉션 사용을 최소화하세요.
• 링크를 업데이트하여 최종 목적지 URL을 직접 가리키게 하여 리디렉션 체인을 피하세요.
• 가능하면 클라이언트 측 리디렉션 대신 서버 측 리디렉션을 사용하세요. 일반적으로 더 빠릅니다.

동일 출처(Same origin) 리디렉션. 동일 출처 리디렉션은 사용자의 자체 웹사이트에 있는 링크에서 발생합니다. 이러한 링크를 완전히 제어할 수 있어야 하며 Time to First Byte 작업을 수행할 때 이 링크들을 우선적으로 수정해야 합니다. 이러한 내부 리디렉션을 찾는 일반적인 방법은 전체 웹사이트에서 리디렉션을 확인할 수 있는 사용 가능한 도구 중 하나를 사용하는 것입니다.

교차 출처(Cross-origin) 리디렉션. 교차 출처 리디렉션은 다른 웹사이트의 링크에서 발생합니다. 사용자는 이에 대한 통제권이 거의 없습니다. 많은 트래픽을 생성하는 영향력이 큰 링크의 경우 해당 사이트의 웹마스터에게 연락하여 연결된 URL을 업데이트하는 것을 고려해 보세요.

리디렉션 체인. 단일 리디렉션이 리소스의 최종 위치로 리디렉션되지 않을 때 다중 리디렉션 또는 리디렉션 체인이 발생합니다. 이러한 유형의 리디렉션은 Time to First Byte에 더 많은 부담을 주므로 무슨 일이 있어도 피해야 합니다. 다시 한번 강조하지만, 이러한 유형의 리디렉션을 찾고 수정하려면 도구를 사용하세요.

HTTP를 HTTPS로 리디렉션 및 HSTS

HTTP를 HTTPS로 리디렉션하는 것은 가장 흔한 리디렉션 유형 중 하나입니다. "https://" 없이 도메인을 입력하거나 오래된 HTTP 링크를 따라오는 모든 방문자는 301 리디렉션을 경험하게 됩니다. Strict-Transport-Security 헤더(HSTS)는 브라우저에게 항상 HTTPS를 사용하도록 지시하여 재방문자에 대한 이 리디렉션을 제거합니다.

HSTS를 활성화하려면 서버 응답에 다음 헤더를 추가하세요.

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

각 지시문의 의미는 다음과 같습니다.

• max-age=31536000: 브라우저는 이 도메인에 대해 1년(31,536,000초) 동안 HTTPS를 사용하도록 기억합니다.
• includeSubDomains: 모든 하위 도메인에도 HTTPS 요구 사항을 적용합니다.
• preload: 브라우저에 내장된 HSTS 프리로드 목록에 도메인이 포함될 수 있도록 허용합니다. 즉, 처음 방문하더라도 리디렉션 없이 HTTPS를 사용하게 됩니다.

HSTS 프리로드 목록에 도메인을 제출하려면 hstspreload.org를 방문하세요. 도메인이 프리로드 목록에 등록되면 브라우저는 해당 도메인에 절대 HTTP 요청을 하지 않으므로 모든 방문자에 대해 HTTP에서 HTTPS로의 리디렉션이 완전히 제거됩니다.

Apache에서는 다음과 같이 HSTS를 추가할 수 있습니다.

Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"

Nginx에서는 다음과 같습니다.

add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;

일반적으로 다음 사항을 권장합니다.

1. 정기적으로 내부 링크를 확인하고 업데이트하세요. 페이지의 위치를 변경할 때마다 해당 페이지에 대한 내부 링크를 업데이트하여 이전 페이지 위치에 대한 참조가 남아 있지 않도록 하세요.
2. 서버 수준에서 리디렉션을 처리하세요. 선호되는 리디렉션 방법은 301 리디렉션입니다. 301 리디렉션은 영구 리디렉션인 반면 302 리디렉션은 임시 리디렉션입니다. 예를 들어 임시 리디렉션은 검색 엔진에서 업데이트되지 않을 수 있습니다.
3. 상대 URL을 사용하세요: 자신의 웹사이트에 있는 페이지에 연결할 때 절대 URL 대신 상대 URL을 사용하세요. 이는 불필요한 리디렉션을 방지하는 데 도움이 됩니다.
4. 표준(canonical) URL을 사용하세요: 내용이 유사한 여러 페이지가 있는 경우 표준 URL을 사용하여 페이지의 기본 버전을 표시하세요. 이는 중복 콘텐츠와 불필요한 리디렉션을 방지하는 데 도움이 됩니다.

추가 읽을거리: 최적화 가이드

관련 가이드:

• 103 Early Hints: 서버가 전체 응답을 처리하는 동안 리소스 힌트를 전송하여 체감되는 TTFB를 줄입니다.
• 성능을 위한 Cloudflare 구성: CDN 구성을 최적화하여 리디렉션 체인을 줄이고 글로벌 TTFB를 향상시킵니다.

TTFB 하위 요소: 전체 가이드

대기 시간은 TTFB의 다섯 가지 하위 요소 중 하나입니다. 전체 그림을 이해하기 위해 다른 하위 요소를 살펴보세요.

• TTFB 문제 식별 및 해결: 모든 TTFB 최적화를 위한 진단의 출발점입니다.
• 캐시 지속 시간(Cache Duration): 서비스 워커 성능, 브라우저 캐시 조회 및 bfcache.
• DNS 소요 시간(DNS Duration): DNS 공급자 선택, TTL 구성 및 dns-prefetch.
• 연결 소요 시간(Connection Duration): TCP 핸드셰이크, TLS 최적화, HTTP/3 및 preconnect.
• 요청 소요 시간(Request Duration): 서버 처리 시간, 데이터베이스 쿼리 및 백엔드 최적화.