느린 DNS 조회를 수정하는 방법

느린 DNS 조회는 브라우저가 웹페이지를 로드하기 시작하기 전에 불필요한 지연을 추가합니다. 일반적인 DNS 해석은 20–120 ms가 걸리지만, 잘못 구성되거나 성능이 떨어지는 DNS는 이를 100 ms 이상으로 밀어낼 수 있습니다. DNS 조회 시간은 Time to First Byte (TTFB), 즉 Core Web Vitals 메트릭에 직접적인 영향을 미칩니다. Google의 연구에 따르면 페이지 로드 시간이 3초에서 5초로 증가할 때 이탈 확률이 32%에서 90%로 뛰어오릅니다. 좋은 소식은 대부분의 원인이 진단하고 수정하기가 간단하다는 것입니다.

목차

1. 느린 DNS의 원인
2. 단계 1: 문제 진단
3. 단계 2: 하드웨어 재시작
4. 단계 3: 더 빠른 DNS 제공자로 전환
5. 단계 4: DNS 캐시 플러시
6. 단계 5: IPv6 폴백 지연 수정
7. 단계 6: VPN, 안티바이러스 및 유령 어댑터 확인
8. 단계 7: DNS over HTTPS (DoH) 구성
9. 단계 8: 로컬 DNS 캐시 서버 실행
10. 단계 9: 브라우저별 DNS 문제 수정
11. 단계 10: DNS 레코드 최적화 (웹사이트 소유자)
12. 단계 11: 서드파티 도메인 줄이기 (웹사이트 소유자)
13. 단계 12: DNS 프리패칭 구현 (웹 개발자)
14. 빠른 참조 문제 해결 표

느린 DNS의 원인

여러 요인이 DNS 지연에 기여합니다:

• 느린 ISP 제공 DNS 서버 — ISP의 기본 해석기는 종종 공공 대안보다 상당히 느립니다. GoDaddy 및 Namecheap과 같은 등록기관의 무료 DNS도 일반적으로 느립니다.
• 지리적 거리 — DNS 서버가 멀리 있을수록 왕복 시간이 길어집니다.
• IPv6 폴백 지연 — 현대 운영 체제는 IPv6 (AAAA) 조회를 우선시합니다. ISP가 IPv6 지원이 부족하면 장치가 IPv4로 폴백하기 전에 최대 5초 동안 대기합니다.
• 과도한 DNS 레코드 — 사용하지 않거나 오래된 A, CNAME, TXT 레코드는 조회에 오버헤드를 추가합니다.
• CNAME 체이닝 — 여러 번의 리디렉션 (CNAME → CNAME → A 레코드)은 지연을 쌓는 순차적 조회를 강제합니다.
• DNS 캐싱 없음 — 캐싱이 없으면 동일한 DNS 쿼리가 매 페이지 로드마다 반복됩니다.
• 과부하된 네임서버 — 네임서버가 부족한 호스팅 제공자는 지연을 초래합니다.
• 네트워크 혼잡 및 비최적 경로 — 가까운 서버라도 경로가 혼잡하면 느릴 수 있습니다.
• VPN 및 프록시 간섭 — VPN은 DNS를 자체 서버를 통해 라우팅하여 느려질 수 있습니다. 일부는 터널 외부로 DNS 쿼리를 누출합니다.
• 유령 네트워크 어댑터 — VPN 소프트웨어, 가상 머신 또는 Docker의 유령 어댑터가 오래된 DNS 구성을 보유하여 해석을 방해합니다.
• 안티바이러스/방화벽 DNS 필터링 — 일부 보안 소프트웨어 (Norton, Kaspersky, Bitdefender)는 DNS 쿼리를 가로채 지연을 추가합니다.
• 브라우저 수준 DNS 오버라이드 — Chrome, Firefox, Edge는 자체 내장 DNS over HTTPS (DoH) 구성으로 OS DNS 설정을 조용히 오버라이드할 수 있습니다.
• 너무 많은 서드파티 도메인 — 웹사이트가 로드하는 각 고유 도메인은 총 페이지 로드 시간에 추가되는 별도의 DNS 조회가 필요합니다.
• 보조 DNS 미구성 — 폴백 DNS 서버가 없으면 기본 서버가 다운되거나 느릴 때 시스템이 타임아웃을 기다리며 멈춥니다.

단계 1: 문제 진단

무엇이든 수정하기 전에 DNS가 실제로 병목인지 확인하십시오.

dig 사용 (Linux/macOS)

그리고 디그 명령은 DNS 응답 시간을 측정하는 주요 도구입니다:

# 특정 DNS 서버 쿼리 및 응답 시간 확인
디그 example.com @8.8.8.8

# 각 홉의 지연을 보여주는 전체 반복 추적
디그 example.com +trace

출력에는 쿼리 시간 필드 (예: 34 ms)가 포함됩니다. 이 값이 100 ms를 초과하면 DNS 계층이 성능 문제입니다. 이상적으로는 50 ms 이하를 목표로 하십시오.

nslookup 사용 (Windows)

Windows 사용자에게는, 엔에스룩업 기본 DNS 진단 도구입니다:

# 기본 DNS 조회
엔에스룩업 example.com

# 특정 DNS 서버 쿼리
엔에스룩업 example.com 8.8.8.8

# 도메인의 네임서버 확인
엔에스룩업 -type=ns example.com

만약 엔에스룩업 결과가 빠르게 반환되지만 브라우징이 느리게 느껴진다면, 문제는 브라우저 수준 DNS, IPv6 폴백, 또는 VPN 간섭일 가능성이 높습니다 — DNS 서버 자체가 아닙니다.

ping 및 traceroute 사용

DNS 서버에 대한 원시 네트워크 지연을 테스트하여 네트워크 문제와 DNS 애플리케이션 문제를 분리합니다:

# 리눅스/맥OS
핑 -c 3 8.8.8.8
트레이서루트 8.8.8.8

# 윈도우
핑 8.8.8.8
트레이서트 8.8.8.8

ping이 높은 지연을 보여주지만 디그 동일한 서버에 대한 속도가 비례적으로 느리다면, 문제는 네트워크 거리이지 DNS 서버 자체가 아닙니다.

DNS 벤치마크 도구

• GRC DNS 벤치마크 — 수십 개의 DNS 서버를 테스트하고 속도에 따라 순위를 매기는 Windows 유틸리티입니다. 특정 네트워크에 가장 빠른 해석기를 찾는 데 강력히 추천됩니다.
• 네임벤치 — Google 소유 도구로, 컴퓨터에 사용 가능한 가장 빠른 DNS 서버를 찾아냅니다.
• DNS퍼프 — 부하 상태에서 권위 있는 DNS 서버를 벤치마크하는 오픈 소스 도구입니다.
• dnsdiag (dnsping, dnstraceroute, dnseval) — DNS 측정을 위한 Python 도구 세트입니다. 설치는 pip3 설치 dnsdiag.
• dnsspeedtest.site — 소프트웨어 설치 없이 DNS over HTTPS를 사용하여 20개 이상의 DNS 제공자를 벤치마크하는 브라우저 기반 도구입니다.

단계 2: 하드웨어 재시작

종종 간과되는 가장 간단한 수정입니다. 라우터를 재시작하면 내부 DNS 캐시가 지워지고 라우팅 문제가 해결될 수 있습니다. 많은 ISP 라우터는 시간이 지남에 따라 과부하되거나 오래된 상태가 될 수 있는 내장 DNS 포워더를 가지고 있습니다.

• 라우터의 전원을 30초 동안 뽑았다가 다시 꽂으십시오.
• PC, 전화 또는 태블릿을 재시작하십시오.
• 별도의 모뎀을 사용하는 경우, 그것도 재시작하십시오.

이는 일시적인 결함을 지우고 새로운 DNS 연결을 강제합니다. 다른 수정을 시도하기 전에 이것을 시도하십시오.

단계 3: 더 빠른 DNS 제공자로 전환

대부분의 사용자에게 가장 큰 영향을 미치는 단일 수정입니다. ISP의 기본 DNS를 더 빠른 공공 해석기로 교체하십시오. 항상 기본 및 보조 DNS를 모두 구성하십시오 — 폴백이 없으면 기본 서버가 다운되거나 느릴 때 시스템이 타임아웃을 기다리며 멈춥니다.

Cloudflare와 Google에 대한 참고 사항: ThousandEyes의 연구에 따르면 Cloudflare는 ISP 서버와 동등한 수준으로 DNS 해석을 제공하며 (평균 23.4 ms) Google은 평균 48.8 ms를 기록했습니다. 그러나 Google의 EDNS 클라이언트 서브넷 지원은 CDN 캐시 적중률을 향상시킬 수 있습니다. 우선순위에 따라 선택하십시오: 원시 속도 (Cloudflare) 또는 CDN 최적화 (Google).

Windows에서 DNS 변경 방법

설정 열기 → 네트워크 및 인터넷 → 이더넷 (또는 Wi-Fi). DNS 서버 할당 옆의 편집 클릭. 수동으로 전환하고, IPv4를 활성화하고, 선호하는 DNS 주소를 입력하십시오.

또는 명령 프롬프트를 통해:

netsh 인터페이스 ip 추가 dns 이름=”이더넷” 주소=1.1.1.1 인덱스=1
netsh 인터페이스 ip 추가 dns 이름=”이더넷” 주소=1.0.0.1 인덱스=2

macOS/Linux에서 DNS 변경 방법

macOS에서는 시스템 설정 → 네트워크 → 연결 → DNS로 이동하여 해석기 IP를 추가하십시오. Linux에서는 /etc/resolv.conf 를 편집하거나 네트워크 관리자를 통해 구성하십시오:

# Linux: /etc/resolv.conf 편집
sudo nano /etc/resolv.conf

# 다음 줄 추가:
네임서버 1.1.1.1
네임서버 1.0.0.1

라우터에서 DNS 변경

네트워크 전체 변경을 위해 라우터의 관리자 패널 (일반적으로 192.168.1.1 또는 192.168.0.1)에서 DNS 설정을 업데이트하십시오. 이는 네트워크의 모든 장치에 영향을 미치며, 각 장치에서 설정할 필요가 없습니다.

단계 4: DNS 캐시 플러시

오래되거나 손상된 캐시 항목은 해석 실패를 초래하거나 잘못된 IP로 리디렉션할 수 있습니다. 플러시는 새로운 조회를 강제합니다:

브라우저 수준 캐시를 잊지 마십시오. Chrome에서는 chrome://net-internals/#dns 로 이동하여 “호스트 캐시 지우기”를 클릭하십시오. Firefox에서는 브라우저를 재시작하거나 about:networking#dns.

단계 5: IPv6 폴백 지연 수정

를 통해 DNS 캐시를 지울 수 있습니다.

표준 가이드에서 무시하는 느린 DNS의 가장 일반적인 숨겨진 원인 중 하나입니다. 현대 운영 체제는 IPv4보다 IPv6 (AAAA) 조회를 우선시합니다. ISP가 IPv6 지원이 부족하거나 없으면 장치가 IPv4로 폴백하기 전에 최대 5초 동안 IPv6 응답을 기다립니다. 이는 새로운 연결마다 발생합니다.

진단 방법
# IPv6 연결성 테스트

ping -6 google.com
# 이 시간이 초과되거나 몇 초가 걸리면, IPv6가 문제입니다
# IPv4와 비교:

ping -4 google.com

수정 방법 옵션 1: 네트워크 어댑터에서 IPv6 비활성화

• (ISP가 지원하지 않는 경우)“
• Windows: 네트워크 어댑터 속성 → “인터넷 프로토콜 버전 6 (TCP/IPv6)” 체크 해제 Linux: 다음을 추가 net.ipv6.conf.all.disable_ipv6 = 1 /etc/sysctl.conf
• macOS: 시스템 설정 → 네트워크 → 연결 → TCP/IP → IPv6 구성 → 링크 로컬만

옵션 2: IPv4 우선 IPv6를 완전히 비활성화하지 않고 — Linux에서는 /etc/gai.conf 를 편집하고 선호도 ::ffff:0:0/96 100.

단계 6: VPN, 안티바이러스 및 유령 어댑터 확인

를 주석 해제하십시오.

VPN 및 프록시 DNS 간섭

• VPN은 종종 DNS를 자체 서버를 통해 라우팅하여 로컬 해석기보다 느릴 수 있습니다. 일부 VPN은 터널 외부로 DNS 쿼리를 누출하여 일관되지 않은 동작을 초래합니다. 진단하려면: VPN에 연결된 상태에서 dnsleaktest.com.
• 을 방문하여 DNS 누출을 확인하십시오.
• VPN을 일시적으로 연결 해제하고 DNS 속도를 테스트하십시오. VPN 없이 더 빠르면, VPN의 DNS가 병목입니다.

많은 VPN은 사용자 정의 DNS 서버를 구성할 수 있습니다 — VPN 제공자의 DNS 대신 Cloudflare 또는 Google을 사용하십시오.

안티바이러스 / 방화벽 DNS 필터링

• 일부 안티바이러스 소프트웨어 (Norton, Kaspersky, Bitdefender)는 DNS 쿼리를 가로채고 필터링하여 지연을 추가합니다. 보안 방화벽은 또한 알 수 없는 서버로의 DNS 트래픽을 차단하거나 제한할 수 있습니다. 테스트하려면:.
• 안티바이러스 웹 보호를 일시적으로 비활성화하고 DNS 속도를 테스트하십시오.
• 방화벽 규칙에서 DNS 관련 차단 (아웃바운드 포트 53 또는 853)을 확인하십시오.

안티바이러스가 비활성화된 상태에서 DNS가 더 빠르면, 선호하는 DNS 서버에 대한 예외를 추가하십시오.

유령 네트워크 어댑터.

VPN 소프트웨어, 가상 머신 (VMware, VirtualBox), Docker의 오래된 또는 유령 네트워크 어댑터는 해석을 방해하는 오래된 DNS 구성을 보유할 수 있습니다. Windows는 특히 이 문제에 취약합니다.

Windows에서 수정하려면:
# 장치 관리자에서 숨겨진 장치 표시
# 관리자 권한으로 CMD 열기:
set devmgr_show_nonpresent_devices=1

devmgmt.msc
# 장치 관리자에서: 보기 → 숨겨진 장치 표시

단계 7: DNS over HTTPS (DoH) 구성

# 네트워크 어댑터 아래에서 회색으로 표시된/유령 어댑터 제거.

DNS over HTTPS (DoH)는 DNS 쿼리를 HTTPS 내에 암호화하여 ISP 스누핑, DNS 스푸핑 및 중간자 공격을 방지합니다. 그러나 잘못 구성되면 문제를 일으킬 수 있습니다.

• 이점.
• DNS 트래픽을 암호화합니다 — ISP 및 네트워크 관리자는 DNS 쿼리를 볼 수 없습니다.
• DNS 스푸핑 및 캐시 중독 공격을 방지합니다.

포트 443 (표준 HTTPS)을 사용하므로 방화벽에 의해 차단되는 경우가 드뭅니다.

• 잠재적 문제 추가 지연:.
• HTTPS/TLS 핸드셰이크는 첫 연결에 오버헤드를 추가합니다. 이후 쿼리는 연결 재사용으로 인해 더 빠릅니다. 로컬 DNS 필터와의 충돌:.
• DoH는 Pi-hole, 로컬 DNS 서버 및 부모 통제를 우회합니다. VPN 충돌:.
• DoH는 올바르게 구성되지 않으면 VPN 터널 외부로 DNS를 라우팅할 수 있습니다. 분할 DNS 문제:.
• 내부 리소스를 위한 내부 DNS를 사용하는 기업 환경은 DoH가 활성화되면 중단될 수 있습니다. 브라우저 오버라이드:.

Chrome, Firefox, Edge는 내장된 DoH로 OS DNS 설정을 조용히 오버라이드할 수 있습니다.

DoH 활성화 방법 Windows 11:“

설정 → 네트워크 → 이더넷/Wi-Fi → DNS → “선호 DNS 암호화”를 “암호화만 (DNS over HTTPS)” 또는 “암호화 선호, 비암호화 허용”으로 설정하십시오. Chrome/Edge:.

설정 → 개인정보 → “보안 DNS 사용” → 제공자 선택 (Cloudflare, Google 등). Firefox:.

DoH 비활성화 방법 (문제 해결 시)

• Windows 11: DNS 암호화를 “암호화되지 않음”으로 되돌리기.”
• Chrome/Edge: “보안 DNS 사용”을 끄기로 전환.
• Firefox: “끄기”로 설정하거나 입력 about:config 및 설정 network.trr.mode = 5.

TLS를 통한 DNS (DoT) vs DoH

DoT는 DNS를 전용 포트(853)에서 암호화하는 대안으로, 포트 443에서 HTTPS 트래픽과 혼합하지 않습니다. DoT는 엔터프라이즈 네트워크에서 식별 및 차단/관리하기 더 쉽습니다. DoH는 일반 웹 트래픽과 혼합되어 필터링이 더 어렵습니다. 가정 사용자에게는 둘 다 작동합니다. 가시성이 필요한 네트워크 관리자에게는 일반적으로 DoT가 선호됩니다.

단계 8: 로컬 DNS 캐시 서버 실행

고급 사용자 및 네트워크 관리자에게는 로컬 캐싱 DNS 리졸버를 실행하면 반복 쿼리에 대한 왕복을 완전히 제거합니다. 매번 원격 DNS 서버를 호출하는 대신 로컬 캐시가 즉시 응답합니다.

인기 있는 옵션

• 언바운드 — 검증, 재귀, 캐싱 DNS 리졸버. 모든 기록을 단일 공용 DNS 서버가 갖지 않도록 방지합니다. 업스트림 암호화를 위한 DoT를 지원합니다.
• dnsmasq — 경량 DNS 포워더 및 DHCP 서버. Linux 라우터에서 쉽게 설정할 수 있습니다.
• 파이-홀 — 네트워크 전체 광고 차단기로 DNS 캐시 역할도 합니다. DNS 수준에서 광고 및 추적기를 차단하여 모든 장치에 대한 타사 DNS 조회를 줄입니다.

빠른 설정: Linux에서 Unbound

# Unbound 설치
sudo apt 설치 unbound

# 기본 구성: /etc/unbound/unbound.conf
서버:
    인터페이스: 127.0.0.1
    포트: 53
    액세스 제어: 127.0.0.0/8 허용
    캐시 최소 TTL: 300
    캐시 최대 TTL: 86400
    사전 가져오기: 예

# Cloudflare로 TLS를 통해 포워드
포워드 존:
    이름: “.”
    포워드 TLS 업스트림: 예
    포워드 주소: 1.1.1.1@853
    포워드 주소: 1.0.0.1@853

# 시작 및 활성화
sudo systemctl 활성화 unbound
sudo systemctl 시작 unbound

# 시스템을 로컬 리졸버로 설정
# /etc/resolv.conf 편집:
네임서버 127.0.0.1

AI CRM 사전 가져오기: 예, Unbound는 자주 액세스되는 기록을 만료 전에 새로 고치므로 거의 콜드 캐시 미스를 경험하지 않습니다.

단계 9: 브라우저별 DNS 문제 수정

브라우저는 OS 설정을 무시할 수 있는 자체 DNS 동작을 가지고 있습니다:

크롬 / 엣지

• 내장 “보안 DNS” (DoH)는 OS 수준 DNS를 무시할 수 있습니다. 확인: 설정 → 개인정보 → “보안 DNS 사용.”
• Chrome은 자체 DNS 캐시를 유지합니다. 다음에서 지우십시오 chrome://net-internals/#dns → “호스트 캐시 지우기.”
• 소켓 풀도 지우십시오: chrome://net-internals/#sockets → “소켓 풀 플러시.”

파이어폭스

• Firefox는 미국 사용자에게 기본적으로 Cloudflare DoH를 사용하는 자체 신뢰할 수 있는 재귀 리졸버 (TRR)를 가지고 있습니다. 이는 OS DNS 설정을 완전히 우회합니다.
• 상태 확인: about:networking#dns 캐시된 DNS 항목과 활성 리졸버를 확인합니다.
• TRR 비활성화: 설정 → 개인정보 및 보안 → HTTPS를 통한 DNS → 끄기.
• 설정을 통해 강제 비활성화: about:config → 설정 network.trr.mode net.ipv6.conf.all.disable_ipv6 = 1 5.

모든 브라우저

• 확장 프로그램 (광고 차단기, 개인정보 도구)은 DNS를 가로채고 리디렉션할 수 있습니다. 확장 프로그램을 비활성화한 상태에서 시크릿/프라이빗 모드에서 테스트하십시오.
• DNS가 작동하지만 디그 또는 엔에스룩업 브라우저가 느리다면 문제는 시스템 DNS가 아닌 브라우저 수준입니다.

단계 10: DNS 레코드 최적화 (웹사이트 소유자)

웹사이트를 관리하고 방문자에게 DNS가 느리다면 다음 최적화가 적용됩니다:

기록 줄이기 및 정리

사용하지 않는 A, CNAME, TXT, MX 기록을 제거하십시오. 모든 추가 기록은 해석 시 오버헤드를 추가합니다. 분기별로 DNS 존 파일을 감사하십시오.

CNAME 체인 제거

CNAME → CNAME → A 기록 대신 도메인을 최종 IP로 직접 A 기록을 통해 지정하십시오. 많은 DNS 제공업체는 또한 CNAME 플래트닝 (ALIAS 기록이라고도 함)을 지원하여 체인을 서버 측에서 해석하고 단일 쿼리로 IP를 반환합니다.

적절한 TTL 값 설정

• 안정적인 기록: 캐싱 이점을 극대화하기 위해 더 높은 TTL (3600–86400초)을 사용하십시오.
• 자주 변경되는 기록: 300–600초 (5–10분)의 TTL을 사용하십시오.
• 기록이 절대 변경되지 않는 경우가 아니라면 TTL을 86400 (24시간)으로 설정하지 마십시오. 이는 업데이트 전파를 지연시킵니다.

DNSSEC 고려사항

DNSSEC는 DNS 응답에 암호화 서명 검증을 추가하여 캐시 중독 및 스푸핑을 방지합니다. 그러나 각 조회에 처리 시간을 추가합니다. 보안이 우선이라면 DNSSEC를 활성화하십시오; 이는 특히 느린 권위 있는 네임서버에서 해석 시간을 약간 증가시킬 수 있습니다.

프리미엄 DNS 제공업체 / CDN 사용

도메인 등록 기관의 무료 DNS는 일반적으로 느립니다. 프리미엄 DNS 제공업체 (Cloudflare, AWS Route 53, Dyn, DNS Made Easy)는 저지연 응답을 위해 설계된 대규모, 전 세계적으로 분산된 애니캐스트 인프라를 가지고 있습니다. Cloudflare 또는 Akamai와 같은 CDN은 자체 DNS 인프라를 가지고 있으며 전 세계적으로 분산된 접속 지점을 가지고 있어 전 세계 사용자에 대한 조회 시간을 단축합니다.

단계 11: 서드파티 도메인 줄이기 (웹사이트 소유자)

웹사이트가 로드하는 각 고유한 타사 도메인은 별도의 DNS 조회가 필요합니다. 이는 빠르게 누적됩니다 — 7개의 외부 도메인에서 리소스를 로드하는 사이트는 DNS 시간만으로 1초 이상을 누적할 수 있습니다.

줄이는 방법

• 외부 리소스 감사: 브라우저 개발자 도구 (네트워크 탭) 또는 WebPageTest를 사용하여 사이트가 호출하는 모든 고유한 도메인을 식별하십시오.
• 가능한 경우 자체 호스팅: 타사 글꼴, 스크립트, 자산을 다운로드하여 원본 서버 또는 CDN에 호스팅하십시오. 이는 해당 DNS 조회를 완전히 제거합니다.
• CDN 도메인 통합: 여러 외부 호스트 대신 단일 CDN 하위 도메인을 사용하십시오.
• 사용하지 않는 플러그인 및 추적기 제거: 외부 JavaScript를 로드하는 각 플러그인은 적어도 하나의 DNS 조회와 스크립트 자체를 추가합니다.

비필수 JavaScript 지연

타사 JavaScript는 종종 추가 외부 도메인을 로드합니다. 비필수 JS를 지연하면 이러한 DNS 조회가 메인 페이지 렌더링 후로 지연됩니다:

<!– Defer non-critical third-party scripts –>
<script src=”https://analytics.example.com/tracker.js” defer></script>

<!– Async for scripts that don’t depend on page load order –>
<script src=”https://ads.example.com/ad.js” async></script>

사용 디퍼 또는 어싱크 이러한 스크립트가 메인 페이지 렌더링을 차단하지 않으면서 로드되도록 합니다. 이러한 도메인에 대한 DNS 조회는 여전히 발생하지만 사용자가 콘텐츠를 보는 것을 차단하지 않습니다.

단계 12: DNS 프리패칭 구현 (웹 개발자)

최신 브라우저는 지원합니다 dns-프리페치 그리고 프리커넥트 사용자가 필요하기 전에 타사 도메인에 대한 DNS를 해결하는 리소스 힌트:

<!– DNS prefetch for non-critical third-party domains –>
<link rel=”dns-prefetch” href=”https://fonts.googleapis.com”>
<link rel=”dns-prefetch” href=”https://analytics.example.com”>

<!– Preconnect for critical third-party domains (DNS + TCP + TLS) –>
<link rel=”preconnect” href=”https://cdn.example.com”>
<link rel=”preconnect” href=”https://api.example.com”>

사용 프리커넥트 가장 중요한 연결에 대해 (DNS + TCP + TLS를 처리합니다) 및 dns-프리페치 다른 모든 것에 대해. 프리커넥트는 연결당 100–500 ms를 절약할 수 있으며, DNS 프리페치는 20–120 ms를 절약합니다. 프리커넥트를 과도하게 사용하지 마십시오 — 각 연결은 리소스를 소비하는 연결을 엽니다.

빠른 참조 문제 해결 표