리디렉션 지연 시간 측정

리디렉션 하나는 온전한 추가 요청 한 번입니다. 브라우저는 페이지 자체를 요청하기 전에 다음 호스트를 조회하고, 연결을 열고, 새 도메인이라면 TLS 협상을 하고, 서버 응답을 기다려야 합니다. 같은 호스트 안의 홉 하나는 수십 밀리초 정도 걸릴 수 있지만, 단축 서비스, 추적 도메인, HTTP에서 HTTPS로 가는 규칙을 거치는 체인은 특히 모바일 네트워크에서 0.5초 이상을 쉽게 더할 수 있습니다.

리디렉션 시간은 다른 모든 것보다 먼저 발생하므로 Time to First Byte(TTFB)와 Largest Contentful Paint(LCP)에 그대로 더해집니다. Lighthouse와 PageSpeed Insights가 기본 문서의 리디렉션을 지적하는 것도 이 때문입니다.

TrueURL은 홉마다 요청을 보낸 시점부터 응답 헤더가 도착할 때까지의 시간을 측정합니다. 새 연결이 필요한 경우의 DNS 조회와 TCP·TLS 연결 설정, 그리고 서버의 처리 시간이 포함되지만, 페이지 본문 다운로드 시간은 포함되지 않습니다. 워터폴은 홉을 순서대로 보여 주므로 가장 느린 홉이 바로 눈에 띕니다.

측정은 사용자의 기기가 아니라 검사를 실행하는 Cloudflare 데이터 센터(대개 사용자와 가장 가까운 곳)에서 이루어집니다. 따라서 각 서버가 얼마나 빨리 응답하는지는 알 수 있지만, 실제 방문자에게는 홉마다 각자의 네트워크 지연 시간이 더해집니다. 측정값의 편차를 줄이려면 여러 번 실행하세요. 첫 실행에는 비어 있는 DNS 캐시와 새 연결에 드는 시간이 포함될 수 있으며, 이후 실행이 대개 평상시 상태에 더 가깝습니다.

대략적인 기준이며, TrueURL이 각 홉의 시간에 색을 입힐 때 사용하는 기준이기도 합니다.

• 홉당 200 ms 미만: 빠름. CDN 엣지나 간단한 웹 서버 규칙이 응답하는 리디렉션에서 흔합니다.
• 200~600 ms: 무난함. 애플리케이션 서버나, 새 TLS 연결이 필요한 다른 도메인으로의 리디렉션에서 흔합니다.
• 600 ms 이상: 느림. 간단한 규칙이 아니라 플러그인을 불러오거나 데이터베이스를 조회하는 CMS처럼 무거운 애플리케이션이 리디렉션을 생성하고 있을 가능성이 높습니다.

가장 좋은 최적화는 홉을 아예 없애는 것입니다. 그다음으로는 방문자와 최대한 가까운 곳에서 리디렉션에 응답하세요. CDN이나 엣지 규칙은 301 하나를 보내려고 구동되어야 하는 애플리케이션보다 훨씬 빠르게 응답합니다.

• 사이트 내부는 물론 이메일, 광고, SNS 프로필에서도 최종 URL로 바로 링크해 대부분의 방문자가 리디렉션을 거치지 않게 하세요.
• HTTP에서 HTTPS로 가는 규칙, 호스트 규칙, 슬래시 규칙을 하나의 홉으로 합치세요. 이미 합쳐져 있는지는 HTTPS 리디렉션 검사에서 확인할 수 있습니다.
• 리디렉션은 애플리케이션이 아니라 CDN, 로드 밸런서, 웹 서버 설정에서 처리하세요.
• HSTS 헤더를 보내 재방문자가 HTTP에서 HTTPS로 가는 리디렉션을 완전히 건너뛰게 하세요.
• 링크 단축 서비스와 추적용 리디렉션을 여러 겹으로 쌓지 마세요.