브라우저의 로딩 시간은 요청 하나의 시간이 아니라 앞선 응답이 다음 리소스를 발견하고 메인 스레드가 실행한 결과로 표시까지 이어지는 의존 경로의 시간입니다. 캐시·연결·TLS 재사용은 일부 단계를 줄일 뿐이며, 네트워크 완료와 화면 표시·입력 응답을 같은 지표로 취급하지 않아야 합니다.
페이지 로딩의 다단계 요청·실행 경로
HTTPS 주소를 입력하면 브라우저는 URL을 해석하고 필요한 주소·연결을 준비한 뒤 HTML을 받습니다. HTML에서 CSS·스크립트·이미지·폰트를 발견하면 추가 요청이 이어집니다. 네트워크가 끝난 뒤에도 스크립트와 레이아웃 때문에 화면이 늦게 나타날 수 있습니다.
가장 긴 다운로드 하나를 줄이는 것보다 중요한 콘텐츠가 표시되기 위해 앞서 끝나야 하는 경로를 찾는 것이 먼저입니다. 캐시와 기존 연결이 있으면 여러 단계가 생략되므로 첫 방문과 재방문의 시간표는 다릅니다.
URL 구성 요소와 전송 계층 경계
URL의 scheme·host·port·path·query·fragment는 역할이 다릅니다. fragment는 일반적으로 HTTP 요청 대상에 포함되지 않고 문서 내부 위치 등 클라이언트 처리에 사용됩니다. 같은 호스트라도 scheme·port가 다르면 출처가 달라질 수 있습니다.
일반적인 HTTPS over TCP 요청에서는 브라우저가 DNS로 주소를 얻고 TCP 연결 뒤 TLS를 협상합니다. TLS에서는 서버 인증서의 이름·신뢰 체인·유효 기간 등을 확인하므로, DNS 성공은 연결 성공이 아니고 TCP 성공도 의도한 서버를 인증했다는 뜻이 아닙니다. HTTP/3는 QUIC을 사용하므로 이 설명의 TCP handshake 단계를 그대로 적용하지 않습니다.
그림을 글로 읽기
- 이름과 보안 연결 준비: DNS · TCP/TLS 또는 QUIC
- HTML 응답·파싱
- CSS와 폰트 발견
- 스크립트 로드·실행
- 스타일·배치·그리기: 중요 콘텐츠 표시
- 이름과 보안 연결 준비 → HTML 응답·파싱: HTTP 요청
- HTML 응답·파싱 → CSS와 폰트 발견: 리소스 발견
- HTML 응답·파싱 → 스크립트 로드·실행: 실행 의존
- CSS와 폰트 발견 → 스타일·배치·그리기: 표시 규칙
- 스크립트 로드·실행 → 스타일·배치·그리기: DOM 변경 가능
DNS·HTTP 캐시·조건부 304와 연결·TLS 재사용의 생략 범위
| 상태 | 줄어드는 작업 | 남는 작업 |
|---|---|---|
| DNS 캐시 적중 | 이름 질의 | 연결·TLS·HTTP 등 |
| fresh HTTP 캐시 | 원본 요청·본문 전송 가능 | 파싱·렌더링·JS 실행 |
| 조건부 요청 304 | 새 본문 전송 | 네트워크 왕복·서버 검증 |
| 열린 연결 재사용 | 새 연결·TLS 협상 | HTTP 요청과 처리 |
| TLS 세션 재개 | 새 연결의 일부 TLS 비용 | 새 전송 연결·재개 협상 |
예를 들어 이미 열린 연결로 다음 HTTP 요청을 보내는 경우, 여기서 말하는 연결 재사용은 새 연결·TLS 협상을 생략한다는 뜻입니다. TCP keep-alive라는 표현이 소켓이 살아 있는지 확인하는 probe를 뜻할 때와 HTTP에서 연결을 재사용한다는 뜻은 서로 다른 동작입니다. TLS resumption은 티켓 등의 이전 정보를 새 연결에 활용할 뿐 새 TCP 연결 자체를 없애지 않으며, TLS 버전에 따라 절약하는 왕복과 인증 과정이 달라집니다. 0-RTT 허용은 재생 위험이 있는 별도 정책입니다.
DNS TTL이 끝났다고 기존 연결이 새 주소로 이동하지 않습니다. 클라이언트 풀에 남은 연결 수명과 DNS 조회 수명을 따로 다뤄야 합니다. 재개 티켓을 서버가 받지 못하면 전체 handshake로 돌아갈 수 있고 그 비용도 측정에 포함합니다.
Waterfall의 합계와 인과적 의존 경로
예를 들어 HTML이 200ms에 도착하면 그때 발견한 CSS가 100ms 뒤인 300ms에 준비되고, CSS 안의 폰트를 300ms에 발견해 200ms가 걸리면 폰트는 500ms에야 준비됩니다. 이 500ms는 병렬로 내려오는 모든 요청의 시간을 무조건 더한 값이 아니라, 앞 단계가 다음 자료를 발견하게 만드는 의존 경로에서 누적된 시간입니다. 미리 병렬로 발견할 수 있는 자료를 늦게 발견한 것이 병목일 수 있습니다. 반면 중요하지 않은 큰 파일이 뒤에서 계속 내려와도 주요 콘텐츠는 이미 보일 수 있습니다.
redirect는 새 요청을 만들고 새 출처면 DNS·연결도 추가할 수 있습니다. 304는 본문이 없어도 지연이 0이 아닙니다. preload는 발견을 앞당길 수 있지만 불필요한 자료까지 우선시하면 다른 중요한 요청과 대역폭을 경쟁합니다. 실제 사용되는 URL·타입·credentials 설정과 맞아야 중복 요청을 줄일 수 있습니다.
응답 주체와 메인 스레드 실행 지연
Service Worker가 요청을 가로채 자체 응답을 만들면 일반 HTTP 캐시만 보고 원인을 판단하기 어렵습니다. CDN·프록시·브라우저 캐시·원 서버 중 누가 응답했는지 확인합니다. HTML이 빨리 와도 긴 JavaScript가 메인 스레드를 막으면 입력과 렌더링이 지연됩니다.
서버 대기 시간에는 서버 계산뿐 아니라 프록시·네트워크·큐 대기가 섞일 수 있습니다. 브라우저 기록만으로 DB 쿼리가 원인이라고 단정하지 않고 서버 추적과 연결합니다. 콘텐츠 표시 지표, 전체 다운로드 완료, 이벤트 핸들러 준비와 사용자 입력 응답은 별도로 기록합니다.
Cold·Warm 방문 조건과 단계별 지연 비교
예상 결과는 fresh HTTP cache와 열린 연결 재사용을 동시에 가진 warm 방문에서 원본 본문·새 TCP/TLS 단계를 줄이되, 파싱·스크립트·렌더링은 여전히 남을 수 있다는 것입니다. CSS가 늦게 발견되어 폰트가 그 뒤에 시작되는 waterfall이면 가장 큰 파일의 크기보다 발견 의존성을 먼저 줄여야 합니다.
DNS·HTTP 캐시와 연결 재사용을 각각 통제해 cold·warm 조건을 분리합니다. 느린 CSS·폰트·스크립트, redirect, TLS 이름 오류를 넣고 어느 단계에서 멈추는지 확인합니다. 단순히 새로고침했다는 것만으로 모든 캐시가 비었다고 가정하지 않습니다.
실제 원격 IP·프로토콜·캐시 상태·리소스 initiator와 Performance의 긴 작업을 함께 보면 네트워크와 렌더링의 원인을 나눌 수 있습니다. 페이지가 보이는 데 필요한 의존 경로를 줄이는 것이 목적이며 모든 요청의 종료 시간을 동일한 성공 지표로 보지 않습니다.