Time to First Byte의 DNS Duration 하위 구성요소 최소화하기
DNS duration은 브라우저의 DNS 조회를 측정합니다. 빠른 DNS 제공업체를 선택하고, TTL 설정을 최적화하며, dns-prefetch를 사용하고, DNS over HTTPS를 이해하여 TTFB를 줄이는 방법을 알아보세요.
Time to First Byte의 DNS Duration 하위 구성요소 최소화하기
이 문서는 Time to First Byte (TTFB) 가이드의 일부입니다. DNS duration은 TTFB의 세 번째 하위 구성요소로, 브라우저가 도메인 이름을 IP 주소로 확인하는 데 걸리는 시간을 나타냅니다. 캐시된 DNS 레코드가 없는 신규 방문자의 경우, DNS 조회는 DNS 제공업체, 사용자의 지리적 위치 및 DNS 레코드의 TTL 설정에 따라 TTFB에 20에서 200밀리초를 추가할 수 있습니다.
Time to First Byte (TTFB)는 다음 하위 구성요소로 나눌 수 있습니다:
- Waiting + Redirect (또는 waiting duration)
- Worker + Cache (또는 cache duration)
- DNS (또는 DNS duration)
- Connection (또는 connection duration)
- Request (또는 request duration)
Time to First Byte를 최적화하고 싶으신가요? 이 문서는 Time to First Byte의 DNS duration 부분을 다룹니다. Time to First Byte를 이해하거나 문제를 해결하고 싶지만 DNS duration이 무엇을 의미하는지 모른다면, 이 문서를 시작하기 전에 Time to First Byte란 무엇인가 및 Time to First Byte 문제 수정 및 식별을 읽어보세요.
DNS 빠른 해결책: Time to First Byte에서 DNS 지연이 발생하고 있다면, 프리미엄 DNS 제공업체로 변경하고 TTL 설정을 업데이트하세요!
Time to First Byte의 DNS Duration 부분은 브라우저가 사이트의 인터넷 (IP) 주소를 조회하는 시간으로 구성됩니다. 컴퓨터는 서로 통신하기 위해 숫자 형태의 IP 주소가 필요한 반면 우리 인간은 "www.example.com"과 같은 도메인 이름을 더 쉽게 기억하기 때문에 DNS 조회가 필요합니다.
Table of Contents!
DNS는 어떻게 작동하나요?
DNS 요청은 TTFB 측정에 포함됩니다. 즉, DNS 요청이 완료되는 데 걸리는 시간이 전체 TTFB 점수에 반영된다는 의미입니다.
페이지가 요청될 때 브라우저가 도메인 이름을 IP 주소로 변환하기 위해 수행하는 단계는 다음과 같습니다:
- 브라우저의 DNS 캐시 확인: DNS 쿼리를 수행하기 전에 브라우저는 먼저 자체 DNS 캐시를 확인하여 요청된 도메인의 IP 주소가 이미 있는지 확인합니다. 최신 브라우저는 반복적인 DNS 조회의 필요성을 줄여 성능을 향상시키기 위해 정해진 기간 동안 DNS 레코드를 캐시합니다. 브라우저 캐시에서 레코드를 찾으면 브라우저는 추가 쿼리 없이 즉시 해당 레코드를 사용할 수 있습니다.
- OS 시스템 캐시 확인: 브라우저 캐시에 필요한 DNS 레코드가 없는 경우 요청은 "스텁 리졸버(stub resolver)"라고도 불리는 운영 체제의 DNS 리졸버로 전달됩니다. OS 역시 DNS 캐시를 유지하며 네트워크 요청을 보내기 전에 이를 확인합니다.
- DNS 쿼리: 브라우저 또는 OS 캐시에서 DNS 레코드를 찾지 못한 경우 재귀적 DNS 쿼리가 DNS 리졸버(일반적으로 사용자의 인터넷 서비스 제공업체(ISP)에서 제공)로 전송됩니다. 이 리졸버는 중개자 역할을 하여 다른 DNS 서버에 쿼리하여 IP 주소를 찾는 과정을 처리합니다.
- 루트 네임 서버(Root Name Servers): 리졸버는 먼저 루트 네임 서버에 연락하며, 이 서버는 도메인 확장자(".com", ".org" 등)에 기반하여 적절한 최상위 도메인(TLD) 서버로 안내합니다.
- TLD 네임 서버(TLD Name Servers): TLD 서버는 리졸버를 특정 도메인의 권한 있는 네임 서버(Authoritative Name Server)로 안내합니다.
- 권한 있는 네임 서버(Authoritative Name Server): 이 서버는 도메인의 DNS 레코드를 보유하고 있으며 리졸버에게 IP 주소를 제공합니다.
- IP 주소 반환: DNS 리졸버가 권한 있는 서버로부터 IP 주소를 획득하면 이 정보를 브라우저로 반환합니다. 그런 다음 브라우저는 IP 주소를 사용하여 서버에 대한 연결을 시작하고 요청된 웹페이지를 로드할 수 있습니다.
DNS가 Time to First Byte에 미치는 영향
재방문자의 경우 DNS 조회는 일반적으로 브라우저나 OS에 캐시되므로 DNS duration이 거의 0으로 줄어듭니다. 그러나 신규 방문자의 경우 브라우저가 TCP 연결 단계로 넘어가기 전에 전체 재귀적 DNS 조회가 완료되어야 합니다. 이것이 신규 방문자의 TTFB가 재방문자에 비해 눈에 띄게 나쁜 경우가 많은 이유입니다.
서드파티 도메인에 dns-prefetch 및 preconnect 사용하기
페이지가 서드파티 도메인(예: 분석, 글꼴 또는 CDN 하위 도메인)에서 리소스를 로드하는 경우 브라우저는 각 도메인에 대해 개별적으로 DNS를 확인해야 합니다. dns-prefetch 리소스 힌트를 사용하여 브라우저가 DNS 확인을 일찍 시작하도록 지시할 수 있습니다:
<!-- 서드파티 도메인을 위한 DNS prefetch --> <link rel="dns-prefetch" href="https://fonts.googleapis.com"> <link rel="dns-prefetch" href="https://cdn.example.com"> <link rel="dns-prefetch" href="https://analytics.example.com">
TCP 및 TLS 연결도 설정해야 할 중요한 서드파티 출처의 경우 DNS 확인 및 연결 핸드셰이크가 포함된 preconnect를 대신 사용하세요:
<link rel="preconnect" href="https://fonts.googleapis.com"> <link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>
preconnect를 지원하지 않는 브라우저를 위한 대체 수단으로 dns-prefetch를 사용하세요:
<link rel="preconnect" href="https://fonts.googleapis.com"> <link rel="dns-prefetch" href="https://fonts.googleapis.com">
이 힌트들은 HTML의 <head> 안에 가능한 한 일찍 배치하세요. 페이지가 실제로 사용하는 도메인에 대한 힌트만 추가하세요. 사용하지 않는 도메인에 대한 힌트를 추가하면 브라우저 리소스가 낭비됩니다. 리소스 로드와 관련된 더 많은 최적화 기법에 대해서는 103 Early Hints 가이드를 참조하세요.
TTFB에 미치는 DNS 영향을 최소화하는 방법
빠른 DNS 제공업체 사용하기
일부 DNS 제공업체는 다른 곳보다 더 빠릅니다. 빠르고 안정적인 DNS 제공업체를 선택하는 것은 DNS 지연을 줄이는 가장 쉬운 방법 중 하나입니다. Cloudflare, Amazon Route 53, Google Cloud DNS와 같은 프리미엄 DNS 제공업체는 전 세계 수백 곳의 위치에서 서버를 운영합니다. DNS 서버가 사용자에게 가까울수록 조회가 더 빨라집니다.
다음은 인기 있는 DNS 제공업체와 일반적인 응답 시간에 대한 비교입니다:
| DNS 제공업체 | 일반적인 응답 시간 | 글로벌 PoPs | 주요 기능 |
|---|---|---|---|
| Cloudflare DNS | ~11ms | 300+ | 무료 티어 제공, DNSSEC, CNAME flattening |
| Amazon Route 53 | ~20ms | 100+ | 상태 확인, 지연 시간 기반 라우팅, 지리적 위치 |
| Google Cloud DNS | ~15ms | Anycast global | 100% 가동 시간 SLA, DNSSEC |
| NS1 | ~15ms | 25+ | 필터 체인, 지능형 DNS 라우팅 |
| 일반적인 ISP/등록대행자 DNS | ~50 to 100ms | 제한적 | 기본 기능만 제공 |
프리미엄 DNS 제공업체와 기본 등록대행자 DNS 간의 차이는 조회당 40~90밀리초가 될 수 있습니다(출처: DNSPerf 벤치마크). 신규 방문자에게 이는 더 빠른 TTFB로 직접 변환됩니다. Cloudflare를 DNS 및 CDN 제공업체로 설정하는 방법을 알아보려면 성능을 위한 Cloudflare 구성 가이드를 읽어보세요.
DNS 캐시 Time to Live(TTL) 최적화하기
DNS 캐싱은 DNS 쿼리 결과를 로컬에 저장하여 반복적인 조회의 필요성을 줄입니다. DNS 레코드에 대해 "최적의" Time-To-Live (TTL) 값을 설정함으로써, 이러한 레코드가 캐시되는 기간을 제어할 수 있습니다.
낮은 TTL 값은 레코드가 더 빨리 만료됨을 의미하며, 이는 더 잦은 DNS 조회를 유발합니다. 높은 TTL 값은 레코드가 더 오래 캐시됨을 의미하며, 이는 DNS 조회는 줄이지만 DNS 변경 사항의 전파 속도를 늦춥니다. 올바른 TTL은 DNS 레코드를 얼마나 자주 변경하는지, 그리고 DNS 조회 속도와 유연성 중 어느 것을 더 중시하는지에 따라 달라집니다.
최적의 DNS TTL 설정이란 무엇인가요?
DNS 마이그레이션이나 서버 변경을 계획할 때, 변경을 수행하기 최소 24시간 전에 임시로 TTL을 5분(300초)으로 낮추세요. 이렇게 하면 변경 후 사용자가 새 IP 주소를 신속하게 가져올 수 있습니다. 마이그레이션이 완료되고 확인되면 TTL을 다시 높은 값으로 늘려 DNS 조회 빈도를 줄이세요.
팁(TIP): CNAME 레코드를 사용하는 경우 CNAME flattening 구현을 고려하세요. CNAME flattening은 루트(최상위) 도메인 수준에서 CNAME 레코드를 사용하여 DNS 표준을 위반하지 않고 사실상 이를 IP 주소로 확인하도록 하는 기술입니다. 이렇게 하면 CNAME을 대상으로 확인한 다음, 대상을 다시 IP 주소로 확인하는 데 필요한 추가 DNS 조회가 제거됩니다.
DNS over HTTPS (DoH) 및 DNS over TLS (DoT)
기존의 DNS 쿼리는 UDP를 통해 일반 텍스트로 전송되므로 중개자(예: ISP 또는 네트워크 운영자)에 의해 가로채이거나 수정되거나 차단될 수 있습니다. DNS over HTTPS (DoH) 및 DNS over TLS (DoT)는 DNS 쿼리를 암호화하여 개인 정보 보호 및 보안을 모두 향상시킵니다.
DoH 및 DoT는 주로 보안 및 개인 정보 보호 문제를 다루지만 DNS 확인 성능에도 영향을 미칠 수 있습니다:
- 지연 시간 영향: 암호화 오버헤드는 초기 DNS 연결(TLS 핸드셰이크)에 약간의 지연 시간을 추가합니다. 그러나 DoH/DoT 연결은 지속적이고 재사용되므로 동일한 연결에 대한 후속 쿼리는 기존 DNS보다 빠른 경우가 많습니다.
- ISP 간섭: 일부 ISP는 자체 DNS 응답을 주입하거나 비고객의 DNS 쿼리 속도를 늦춥니다. DoH는 이러한 간섭을 완전히 우회하므로 영향을 받는 사용자의 DNS 확인 시간을 실제로 단축할 수 있습니다.
- 브라우저 지원: 최신 브라우저(Chrome, Firefox, Edge, Safari)는 모두 DoH를 지원합니다. 대부분의 경우 브라우저의 기본 DNS 제공업체는 사용 가능할 때 이미 DoH를 사용합니다.
웹사이트 소유자의 경우 방문자가 DoH 또는 DoT를 사용할지 여부를 제어할 수 없습니다(이는 브라우저 및 OS 수준 설정입니다). 그러나 권한 있는 DNS 제공업체가 DNSSEC를 지원하는지 확인할 수 있으며, 이는 전송 암호화와 관계없이 DNS 응답에 대한 보완적인 확인 계층을 제공합니다.
JavaScript로 DNS Duration 측정하기
Navigation Timing API를 사용하여 브라우저에서 직접 TTFB의 DNS duration 하위 구성요소를 측정할 수 있습니다:
new PerformanceObserver((entryList) => {
const [nav] = entryList.getEntriesByType('navigation');
const dnsDuration = nav.domainLookupEnd - nav.domainLookupStart;
console.log('DNS Duration:', dnsDuration.toFixed(0), 'ms');
if (dnsDuration > 50) {
console.warn('High DNS duration detected. Consider:');
console.warn('1. Switching to a premium DNS provider');
console.warn('2. Increasing DNS TTL values');
console.warn('3. Using dns-prefetch for third-party domains');
}
}).observe({
type: 'navigation',
buffered: true
});
RUM 데이터에서 DNS duration이 0ms인 것은 일반적으로 DNS 조회가 브라우저나 OS 캐시에서 제공되었음을 나타냅니다(재방문자 시나리오). 50ms를 초과하는 값은 사용자가 전체 재귀적 DNS 조회를 수행해야 했음을 시사하며, 이는 신규 방문자에게 일반적입니다.
느린 DNS 조회로 인해 발생하는 TTFB 문제 측정 방법
DNS 지연으로 인해 실제 사용자가 겪는 영향을 확인하려면 CoreDash와 같은 RUM 도구를 사용해야 합니다. Real User Monitoring을 사용하면 28일의 Google 지연 없이 Core Web Vitals를 더 자세히 추적할 수 있습니다.
CoreDash에서 "Time to First Byte breakdown"을 클릭하여 Time to First Byte의 DNS 부분을 시각화하세요.
추가 읽을거리: 최적화 가이드
관련 가이드:
- 103 Early Hints: 전체 응답이 준비되기 전에 리소스 힌트를 전송하여 브라우저가 중요한 리소스에 대한 DNS 확인 및 연결을 더 일찍 시작할 수 있도록 합니다.
- 성능을 위한 Cloudflare 구성: Cloudflare를 DNS 제공업체이자 CDN으로 사용하여 빠른 DNS 확인을 엣지 캐싱 및 HTTP/3 지원과 결합하세요.
TTFB 하위 구성요소: 전체 가이드
DNS duration은 TTFB의 다섯 가지 하위 구성요소 중 하나입니다. 전체적인 그림을 이해하려면 다른 하위 구성요소를 살펴보세요:
- TTFB 문제 수정 및 식별: 모든 TTFB 최적화를 위한 진단의 출발점입니다.
- Waiting Duration: 리디렉션, 브라우저 대기열(queuing) 및 HSTS 최적화.
- Cache Duration: 서비스 워커 성능, 브라우저 캐시 조회 및 bfcache.
- Connection Duration: TCP 핸드셰이크, TLS 최적화, HTTP/3 및 preconnect.
- Request Duration: 서버 처리 시간, 데이터베이스 쿼리 및 백엔드 최적화.
