RTT란 무엇이며 왜 중요한가요?
왕복 시간(RTT)은 신호가 통신 상대에게 갔다가 돌아오는 데 걸리는 시간입니다. 전체 응답 시간과는 다르며 DNS, 연결 설정, 서버 처리, 데이터 전송 시간이 추가될 수 있습니다. 병렬 요청 수만큼 RTT가 순서대로 더해지는 것은 아닙니다.
RTT가 Web Vitals에 미치는 영향
- LCP: HTML이나 중요한 리소스의 지연이 주요 콘텐츠 표시를 늦출 수 있습니다.
- INP: 동작부터 다음 화면 표시까지를 측정하며 비동기 요청의 완료 시간은 아닙니다. INP가 좋아도 검색 결과는 늦을 수 있으므로 둘 다 측정하세요.
- TTFB: RTT 외에 연결 설정과 서버 처리 등도 포함합니다. TTFB 자체는 Core Web Vital이 아닙니다.
- CLS: 공간을 미리 확보하지 않은 리소스가 늦게 도착하면 레이아웃이 움직일 수 있습니다. RTT가 높다는 이유만으로 이동이 발생하는 것은 아닙니다.
RTT가 커지는 주요 원인
- 멀리 있는 오리진 서버 또는 CDN과 백엔드 사이의 추가 경로
- 서로 의존하는 요청과 리디렉션 체인
- 재사용할 수 있는데도 새로 만드는 연결
- 늦게 발견되는 중요한 외부 리소스
- 전체 응답 시간만 보면 네트워크 문제로 오인할 수 있는 느린 서버 처리
실제로 RTT를 줄이는 방법
- 지역을 비교하고 사용자 가까이의 CDN이나 서버 처리를 검토하세요. 실제로 엣지에서 제공되는 응답을 확인합니다.
- 지원되는 HTTP/2와 HTTP/3를 비교하세요. 물리적 거리는 없어지지 않으며 HTTP/2에는 TCP 수준의 블로킹이 남습니다.
- 버전이 지정된 정적 리소스를 캐시하세요. HTML과 API에는 정보의 최신성과 기밀성을 고려합니다.
<link rel="preconnect">,dns-prefetch, 폰트 preload는 중요성이 확인된 리소스에만 사용하세요. 물리적 RTT를 줄이지는 않습니다.- 불필요한 요청을 없애고 비핵심 JavaScript를 늦추세요. 지연 로딩은 첫 화면 아래의 적절한 콘텐츠에 쓰고 LCP 이미지에는 쓰지 않습니다.
- 리디렉션을 줄이고 연결이나 TLS 세션을 재사용하세요. 0-RTT와 인증서 최적화는 실제 환경에 맞게 확인합니다.
Milten 결과로 RTT 조사하기
- 검사 조건을 기준으로 네트워크 진단의 RTT, 서버 지연, 오리진별 전송 성능을 비교합니다.
- 리소스 힌트와 워터폴, 특히 LCP/FCP 이전 요청을 확인합니다. 힌트가 없다는 것은 조사할 후보이지 반드시 추가해야 한다는 뜻은 아닙니다.
- 서버 처리와 전송 지연을 구분합니다.
- 배포 뒤 다시 검사합니다. 지역 비교 시에는 사용 가능한 설정을 확인하고 조건을 맞추세요.
빠른 점검 목록
- 느린 오리진과 중요한 요청 체인을 찾습니다.
- 브라우저–엣지 및 필요한 경우 엣지–오리진 구간의 실제 프로토콜을 확인합니다.
- 유용한 연결·미리 로딩 힌트만 추가합니다.
- 올바른 최종 URL을 유지하면서 불필요한 리디렉션을 줄입니다.
- 캐시나 stale-while-revalidate에서 최신성과 기밀성을 지킵니다.
- 같은 조건의 여러 검사와 실제 방문 데이터를 비교합니다.
측정부터 시작하기
milten.io의 Speed Scanner에서 네트워크 결과를 살펴보고 확인된 병목 하나를 선택하세요. 초기 결과와 조건을 저장한 뒤 한 가지 변경을 적용하고 같은 조건에서 비교합니다.
