각 단계가 왕복(RTT) 을 요구한다는 것이 핵심입니다. DNS, TCP, TLS, HTTP 가 각각 왕복을 쓰므로 왕복 시간이 긴 경로에서는 연결을 세우는 데만 수백 밀리초가 듭니다. 그래서 연결 재사용이 중요합니다.
URL 입력 후 화면까지
브라우저에 URL을 입력하면 화면이 나타나기까지의 전체 과정 (면접 단골 질문!)
전체 흐름
1. URL 파싱
↓
2. DNS 조회 → IP 주소 획득
↓
3. TCP 연결 (3-way handshake)
↓
4. TLS 핸드셰이크 (HTTPS)
↓
5. HTTP 요청 전송
↓
6. 서버 처리 + HTTP 응답
↓
7. HTML 파싱 → DOM 트리
↓
8. CSS 파싱 → CSSOM 트리
↓
9. 렌더 트리 생성
↓
10. 레이아웃 → 페인트 → 화면 표시
상세 과정
1~2. URL 파싱 & DNS 조회
https://www.google.com/search?q=hello
└┬──┘ └──────┬───────┘└──┬──┘└──┬──┘
프로토콜 호스트 경로 쿼리
DNS 조회 순서:
브라우저 캐시 → OS 캐시
→ Local DNS → Root → TLD → Auth
→ IP: 142.250.196.110
3~4. TCP + TLS 연결
Client Server
|--- SYN ----→| TCP
|←- SYN+ACK --|
|--- ACK ----→|
|--- ClientHello →| TLS
|←- ServerHello --|
|--- KeyExchange →|
| 암호화 시작 |
5~6. HTTP 요청/응답
→ GET /search?q=hello HTTP/1.1
Host: www.google.com
Accept: text/html
← HTTP/1.1 200 OK
Content-Type: text/html
<html>...</html>
7~10. 브라우저 렌더링
HTML → DOM Tree
↘
Render Tree → Layout → Paint
↗
CSS → CSSOM Tree
JS → DOM/CSSOM 수정 가능
단계
설명
DOM 생성
HTML 파싱 → 노드 트리
CSSOM 생성
CSS 파싱 → 스타일 트리
렌더 트리
DOM + CSSOM 결합
레이아웃
요소 위치/크기 계산
페인트
픽셀로 화면에 그림
성능 최적화 포인트
단계
최적화
DNS
DNS 프리페치, 캐싱
TCP
Keep-Alive, HTTP/2
TLS
TLS 1.3, 세션 재사용
다운로드
CDN, 압축(gzip)
렌더링
CSS를 head에, JS를 body 끝에
리소스
lazy loading, 코드 스플리팅
면접에서 이렇게 나옵니다
Q.브라우저에 URL을 입력하면 어떤 과정이 일어나나요?
단계
하는 일
1
URL 을 해석한다. 프로토콜, 호스트, 경로
2
DNS 로 호스트의 IP 를 찾는다
3
TCP 연결을 맺는다. HTTPS 면 TLS 협상까지
4
HTTP 요청을 보낸다
5
서버가 처리해 응답한다
6
브라우저가 HTML 을 파싱해 DOM 을 만든다
7
CSS 로 CSSOM 을 만들고 둘을 합쳐 렌더 트리를 만든다
8
배치를 계산하고(레이아웃) 화면에 그린다(페인트)
9
이미지, 스크립트 등 하위 자원을 받아 반영한다
중간에 캐시가 여러 번 끼어듭니다. DNS 캐시, HTTP 캐시, 브라우저 자원 캐시가 각각 단계를 건너뛰게 합니다.
흔한 실수: 6번 이후를 빼고 답하는 것. 이 질문은 네트워크만이 아니라 렌더링까지 아는지 보려는 것이고, 성능 최적화 이야기가 그 위에서 나옵니다.
Q.렌더링 과정에서 DOM과 CSSOM의 역할은?
구조
무엇으로 만드나
담는 것
DOM
HTML
문서의 구조와 내용
CSSOM
CSS
각 요소에 적용될 스타일
렌더 트리
DOM 과 CSSOM 을 합쳐
화면에 그려질 것만
렌더 트리에는 display: none 인 요소가 빠집니다. 반면 visibility: hidden 은 자리를 차지하므로 포함됩니다.
두 구조가 모두 있어야 그릴 수 있으므로 CSS 는 렌더링을 막습니다. 그래서 CSS 는 문서 앞쪽에 두고, 당장 필요 없는 스타일은 나중에 불러옵니다.
스크립트는 반대 성격입니다. 파싱 중에 만나면 DOM 생성이 멈추므로 defer 나 async 로 이 멈춤을 피합니다.
흔한 실수: 렌더 트리를 DOM 과 같은 것으로 설명하는 것. DOM 은 문서 구조이고 렌더 트리는 그릴 대상만 남긴 별도 구조입니다.
Q.리플로우(reflow)와 리페인트(repaint)의 차이는?
크기와 위치를 다시 계산하는지, 색만 다시 칠하는지가 다릅니다.
항목
리플로우
리페인트
다시 하는 일
배치 계산
픽셀 칠하기
비용
크다. 주변 요소까지 영향
상대적으로 작다
유발하는 변경
width, height, margin, font-size, 요소 추가와 삭제
color, background, visibility
리플로우가 나면 리페인트도 따라옵니다. 반대는 아닙니다.
줄이는 방법입니다.
스타일을 여러 번 바꾸지 말고 클래스 하나로 한 번에 바꾼다
DOM 을 반복해 조작할 때는 문서 조각에 모아 한 번에 붙인다
애니메이션은 transform 과 opacity 를 쓴다. 배치와 칠하기를 건너뛴다
읽기와 쓰기를 번갈아 하지 않는다. 강제 동기 배치가 발생한다
흔한 실수: 마지막 항목을 모르는 것. offsetHeight 같은 값을 읽으면 브라우저가 밀린 변경을 즉시 반영해야 해서, 반복문 안에서 읽고 쓰면 매번 리플로우가 납니다.
Q.각 단계별 성능 최적화 방법을 설명해주세요.
단계
최적화
DNS
미리 조회, 연결 사전 수립
연결
연결 재사용, HTTP/2 로 연결 수 줄이기, TLS 세션 재사용
요청과 응답
압축, 캐시 헤더, CDN 으로 거리 단축
서버 처리
느린 쿼리 개선, 캐시, 응답 크기 축소
파싱과 렌더
CSS 는 앞에, 스크립트는 defer, 중요한 스타일만 먼저
이미지
적절한 포맷과 크기, 지연 로딩
무엇부터 할지는 측정으로 정합니다. 편도 지연이 큰 사용자에게는 왕복 수를 줄이는 것이 가장 크고, 서버가 느리면 그쪽이 전부입니다.
환경
연결 수립
서버 처리
먼저 고칠 것
편도 40ms
240ms
12ms
왕복을 줄인다
편도 5ms
30ms
200ms
서버를 고친다
흔한 실수: 이미지 압축부터 시작하는 것. 눈에 띄는 작업이지만 병목이 아닌 경우가 많습니다. 구간별 시간을 먼저 재는 것이 순서입니다.