브라우저 렌더링 과정: 주소 입력 후 화면이 보이기까지 내부에서 일어나는 일

주소를 입력하면 “바로” 화면이 뜨는 것처럼 보이지만, 내부는 여러 단계를 거친다

브라우저 주소창에 URL을 입력하고 엔터를 누르면 웹페이지가 순식간에 나타나는 것처럼 보인다. 그러나 그 짧은 시간 동안 브라우저와 네트워크, 서버, 그리고 브라우저 내부 렌더링 엔진은 여러 단계를 촘촘하게 수행한다. 이 과정 중 어디에서 병목이 생기느냐에 따라 “하얀 화면이 오래 유지된다”, “글자만 먼저 뜬다”, “이미지가 늦게 로딩된다”, “스크롤이 끊긴다” 같은 체감 문제가 달라진다.
이 글은 브라우저 렌더링 과정을 DNS, HTTP/HTTPS, DOM, CSSOM, 렌더 트리(Render Tree)라는 핵심 키워드 중심으로 정리한다. 또한 실제 웹 사용 상황에서 느린 로딩의 원인을 어떻게 분류하고 개선할 수 있는지까지 연결해 설명한다.

---

브라우저 렌더링 과정의 큰 그림과 핵심 용어

1) “렌더링”이란 무엇인가: HTML을 화면 픽셀로 바꾸는 전체 절차다

브라우저 렌더링(rendering)은 단순히 HTML을 표시하는 것이 아니다. 브라우저는 네트워크로 문서를 가져오고, HTML과 CSS, 자바스크립트를 해석한 뒤, 화면에 그리기 위한 내부 자료구조를 만들고, 레이아웃을 계산하고, 최종 픽셀로 그려낸다.
이 과정은 크게 다음 두 덩어리로 나뉜다.

• 네트워크 단계: 서버에서 문서와 리소스를 받아오는 과정(DNS, TCP/TLS, HTTP)
• 렌더링 단계: 받아온 내용을 분석해 화면에 그리는 과정(DOM, CSSOM, Layout, Paint, Composite)

웹페이지가 느릴 때는 이 두 덩어리 중 어디가 병목인지 구분하는 것이 문제 해결의 시작이다.

2) 주소 입력 후 실제로 시작되는 일: DNS → 연결 → 요청/응답

URL을 입력하면 브라우저는 먼저 “이 도메인의 서버 IP가 무엇인지” 알아야 한다. 이때 쓰는 것이 DNS다. DNS가 IP를 알려주면 브라우저는 서버와 연결을 만들고, HTTP 또는 HTTPS로 문서를 요청한다.

• DNS: 도메인 이름을 IP 주소로 바꾸는 시스템이다.
• TCP: 데이터를 신뢰성 있게 주고받기 위한 연결 지향 전송 방식이다(대부분의 웹은 TCP 위에서 동작한다).
• TLS: HTTPS에서 사용하는 암호화 계층이다.
• HTTP/HTTPS: 웹 문서와 리소스를 요청/응답하는 규칙이다.

HTTPS는 TLS 핸드셰이크가 추가되므로 단계가 조금 더 복잡하지만, 보안상 표준이므로 대부분의 웹은 HTTPS를 사용한다.

3) HTML 파싱과 DOM: 웹페이지의 “뼈대”가 만들어진다

서버에서 HTML 문서를 받으면 브라우저는 문서를 위에서 아래로 읽으며 파싱(parsing)을 진행한다. 이때 생성되는 자료구조가 DOM(Document Object Model)이다. DOM은 웹페이지를 트리 구조로 표현한 것이다. 예를 들어 제목, 문단, 이미지, 버튼 같은 요소가 부모-자식 관계로 연결된다.
DOM은 “어떤 요소가 어디에 있는지”를 나타내는 구조이므로, 자바스크립트가 화면 내용을 바꾸거나 이벤트를 붙일 때도 DOM을 대상으로 작업한다.

4) CSS 파싱과 CSSOM: 웹페이지의 “꾸밈 규칙”이 정리된다

CSS는 요소의 색, 크기, 위치, 글꼴 등 스타일을 정의한다. 브라우저는 CSS를 파싱해 CSSOM(CSS Object Model)을 만든다. CSSOM은 “이 요소에는 어떤 스타일 규칙이 적용되는가”를 계산 가능한 형태로 정리한 결과다.
DOM이 뼈대라면, CSSOM은 옷과 장식 규칙이다. 둘이 결합되어야 화면에 실제로 그릴 준비가 된다.

 

브라우저 렌더링 파이프라인 개요(DNS→HTTP→DOM/CSSOM→Layout→Paint→Composite)

5) 렌더 트리(Render Tree), 레이아웃(Layout), 페인트(Paint), 컴포지트(Composite)

브라우저는 DOM과 CSSOM을 결합해 렌더 트리를 만든다. 렌더 트리는 “화면에 실제로 그릴 대상”만 포함한다. 예를 들어 display:none 요소는 DOM에는 있어도 렌더 트리에는 포함되지 않는다.

• 레이아웃(Layout, Reflow): 각 요소의 위치와 크기를 계산하는 단계다. 화면 폭, 폰트 크기, 박스 모델 등이 반영된다.
• 페인트(Paint): 계산된 요소들을 픽셀로 그려내는 단계다. 배경색, 글자, 테두리, 그림자 등이 그려진다.
• 컴포지트(Composite): 여러 레이어를 합성해 최종 화면을 만든다. 애니메이션이나 스크롤 성능과도 연관이 있다.

사용자가 “스크롤이 끊긴다”라고 느끼는 문제는 레이아웃이나 페인트가 자주 발생하거나, 컴포지팅 부담이 커진 경우가 많다.

6) 자바스크립트의 위치: 렌더링 흐름을 멈추기도 하고 바꾸기도 한다

자바스크립트는 페이지를 동적으로 만들지만, 렌더링 관점에서는 주의해야 할 점이 있다. HTML 파싱 중에 동기 방식의 자바스크립트가 실행되면, 브라우저는 파싱을 잠시 멈추고 스크립트를 실행한다. 스크립트가 DOM을 수정하면 레이아웃/페인트가 다시 발생할 수 있다.
따라서 스크립트 로딩 방식(defer/async), 실행 타이밍, DOM 조작 빈도는 체감 성능에 직접 영향을 준다.

---

실제 사례로 보는 병목 지점과 문제 해결 방법

1) “하얀 화면이 오래 보인다”: 네트워크 또는 초기 렌더링 병목

주소 입력 후 오랫동안 하얀 화면만 보인다면 크게 두 가지를 의심할 수 있다.

• 네트워크 병목: DNS가 느리거나, 서버 연결(TCP/TLS)이 지연되거나, 첫 HTML 응답이 늦는 경우다.
• 초기 렌더링 병목: HTML은 받았지만 CSS/JS가 렌더링을 막고 있거나, 큰 CSS/JS 파일로 인해 DOM/CSSOM 생성이 지연되는 경우다.

실무에서는 첫 바이트가 늦다면 서버/네트워크, 첫 화면이 늦다면 렌더링 리소스 문제일 가능성이 커진다.

2) “텍스트만 먼저 뜨고 이미지가 늦게 뜬다”: 리소스 로딩 우선순위 문제

텍스트가 먼저 뜨고 이미지가 늦게 뜨는 것은 흔한 현상이다. 이유는 HTML이 먼저 도착해 DOM이 어느 정도 만들어지고, 이미지 파일은 별도 요청으로 내려받기 때문이다.
이미지가 유난히 늦다면 다음을 의심한다.

• 이미지 용량이 크다(해상도 과다, 압축 부족).
• 이미지 서버 또는 CDN 응답이 느리다.
• 동시에 많은 이미지 요청이 발생해 병목이 생긴다.
• 네트워크가 불안정하거나 대역폭이 좁다.

사용자 관점에서는 “내 인터넷이 느리다”로 보이지만, 실제로는 페이지 리소스 구성의 문제일 수 있다.

 

느린 웹페이지 원인 분류(네트워크 병목 vs 렌더링 병목 vs 리소스 병목)

3) “스크롤이 끊기고 버벅인다”: 레이아웃/페인트가 자주 발생하는 경우

페이지가 뜬 뒤 스크롤이 끊기는 문제는 로딩 문제가 아니라 렌더링 비용 문제인 경우가 많다. 다음 상황에서 자주 발생한다.

• 스크롤 중에 요소 크기나 위치가 자주 바뀐다(레이아웃 재계산 빈번).
• 그림자, 블러, 큰 배경 이미지처럼 페인트 비용이 큰 스타일이 많다.
• DOM 요소가 지나치게 많다(긴 목록, 무한 스크롤 구현 방식 문제).
• 자바스크립트가 스크롤 이벤트에서 무거운 작업을 수행한다.

웹이 느릴 때 “CPU가 바쁜지”와 “GPU 합성이 부담인지”가 갈린다. 사용자가 직접 정밀 분석을 하기는 어렵지만, 증상만으로도 원인 범위를 줄일 수 있다.

4) 브라우저 캐시와 재방문 속도: 왜 두 번째는 빠른가

같은 사이트를 다시 방문하면 더 빨라지는 경우가 있다. 이는 브라우저 캐시(cache) 때문이다. 캐시는 이미지, CSS, JS 같은 정적 리소스를 저장해두고 다음 요청에서는 재사용하게 해준다.
다만 캐시가 무조건 좋은 것만은 아니다. 캐시가 꼬이거나 오래된 리소스가 남으면 화면이 깨지는 경우도 있다. 그래서 “강력 새로고침”이나 캐시 삭제가 문제 해결에 도움이 될 때가 있다. 이는 원리적으로 “저장된 리소스를 버리고 다시 받아오는 행동”이다.

5) 사용자가 할 수 있는 현실적인 점검 방법 5가지

전문 도구 없이도 다음 점검은 비교적 쉽게 할 수 있다.

1. 다른 사이트들은 정상인데 특정 사이트만 느린지 확인한다(서버/사이트 이슈 분리).
2. 같은 사이트를 모바일 데이터로 접속해 본다(집 와이파이 문제 vs 사이트 문제 분리).
3. 다른 브라우저(크롬/엣지/사파리)에서 증상이 같은지 확인한다(확장 프로그램 영향 분리).
4. 시크릿 모드로 접속해 본다(캐시/쿠키/확장 프로그램 영향 분리).
5. 이미지가 많은 페이지에서 특히 느리면, 화면이 늦게 뜨는지 스크롤이 끊기는지 구분한다(로딩 병목 vs 렌더링 병목 구분).

이 정도만 해도 “인터넷이 느린 것 같다”라는 막연한 문제를 구체적인 증상으로 바꿀 수 있다.

---

렌더링은 네트워크와 브라우저 엔진이 협업하는 과정이며, 병목을 나누면 해결이 쉬워진다

브라우저 렌더링 과정은 주소 입력 후 DNS 조회와 HTTPS 연결, HTTP 요청/응답을 거쳐 HTML과 CSS를 파싱해 DOM과 CSSOM을 만들고, 렌더 트리를 생성한 뒤 레이아웃·페인트·컴포지트 단계로 화면을 완성하는 절차다. 자바스크립트는 이 흐름을 멈추거나 다시 계산하게 만들 수 있어 체감 성능에 큰 영향을 준다.
웹페이지가 느릴 때는 네트워크 병목(DNS/서버 응답), 렌더링 병목(DOM/CSSOM/JS), 리소스 병목(이미지/폰트)을 구분하면 원인을 빠르게 좁힐 수 있다.

다음으로 이어서 보면 좋은 주제는 두 가지다. 첫째, DNS와 CDN이 웹 로딩 속도에 어떤 영향을 주는지에 대한 설명이다. 둘째, 자바스크립트 로딩 전략(defer/async)과 렌더링 차단 리소스가 성능에 미치는 영향에 대한 정리다.