웹 브라우저의 동작 원리와 웹 최적화

개요

---

사용자는 빠르고 상호작용이 원활한 컨텐츠로 이루어진 웹 경험을 원한다.

 

따라서 개발자는 이 두가지 목표를 달성해야 한다.

 

브라우저가 어떻게 동작하는지 이해한다면 향후 실제 성능을 향상시키는 고민을 할 때 큰 도움이 될 것이다.

---

웹 성능의 두가지 문제점

---

1. 지연 시간
   웹을 빠르게 로드하는데 있어 지연 시간은 이겨내야할 중요한 문제이다. 네트워크 지연시간은 네트워크를 통해 컴퓨터가 바이트를 전송하는데 걸리는 시간을 의미한다. 웹을 빠르게 로드하기 위해 신경써야 할 것은 최대한 빠른 요청과 CDN을 통한 캐싱 및 지리적 분산, HTTP/2 이상 프로토콜 적용, 로드 밸런싱, 리소스 및 코드 최적화, 브라우저 캐싱, DNS 최적화 등 여러 요소가 있다.
     
2. 브라우저는 싱글 쓰레드로 동작한다.
   대부분의 브라우저는 싱글 쓰레드이다. 원활한 상호작용을 위해서는 부드러운 스크롤부터 매우 기민하게 반응하는 터치까지 모두 성능이 뛰어난 상호 작용을 보장하는 것이다. 브라우저가 싱글 쓰레드로 동작한다는 점을 이해하고 가능한 메인 쓰레드의 책임을 줄여주는 방식으로 웹 성능 향상을 이룰 수 있다. 메인 쓰레드가 요청된 모든 작업을 수행하면서도 유저와의 상호작용에 반응 할 수 있도록 보장하기 위해서는 렌더링 시간이 가장 중요하다.

---

탐색(Navigation)

---

탐색은 웹페이지를 로딩하는 첫 단계이다.

 

사용자가 주소창에 URL을 입력하거나 링크 클릭, form 제출 등의 동작을 통해 요청을 보내면 탐색 단계가 발생한다.

 

웹 최적화의 목표 중 하나는 탐색이 완료될 때 까지의 시간을 최소화 하는 것이다.

 

이상적인 조건에서는 오래 걸리는 작업이 아니지만 지연시간과 대역폭은 지연을 일으키는 적이다.

---

탐색 과정

---

웹 페이지 탐색 과정 [출처]mdn web docs

---

DNS 조회(DNS Lookup)

---

웹 페이지를 탐색하는 첫 단계는 해당 페이지의 자원이 어디에 위치하는지 찾는 것이다.

만약 https://www.naver.com 주소를 탐색한다면 네이버의 HTML 페이지는 125.209.221.141에 위치한다.

 

여기서 naver.com은 도메인이 되고 이걸 ip 주소로 변환해 주는 것은 DNS라고 한다.

 

만약 https://www.naver.com에 한번도 방문한 적이 없다면 DNS 조회가 필요하다.

 

조회 요청은 최종적으로 DNS 서버에 의해 처리되고 IP주소로 응답한다. 최초 요청 이후 IP는 일정 기간 동안 캐시된다.

 

DNS 서버에 다시 요청하는 대신 캐시에서 IP 주소를 검색하여 요청 속도를 높인다.

 

DNS 조회는 보통 호스트 이름 하나당 한 번만 수행된다. 하지만 DNS 조회는 요청된 페이지에서 참조하는 다른 호스트 이름에 대해서는 각각 수행해야 한다.

 

예를 들어 글꼴, 이미지, 스크립트, 광고 그리고 다른 자원들이 서로 다른 호스트 이름을 가지고 있다면, DNS 조회는 각각에 대해 모두 수행되어야 한다.

모바일 환경에서의 DNS 조회 과정 [출처]mdn web docs

이는 모바일 네트워크 환경에서 성능에 문제가 될 수 있다.

 

만약 웹의 많은 자원들이 다른 호스트 이름을 가지고 있다면 각각의 DNS를 조회하기 위해

 

Cell Tower ⇒ 핸드폰 통신사 ⇒ DNS 서버 ⇒ 핸드폰 통신사 ⇒ Cell Tower ⇒ 핸드폰 ⇒ Cell Tower ⇒ 핸드폰 통신사 ⇒ Site ⇒ 핸드폰 통신사 ⇒ Cell Tower ⇒ 핸드폰

 

의 과정을 각각의 DNS에서 모두 수행하여야 한다.

 

때문에 휴대폰과 셀 타워, DNS 서버의 거리에 따라서 상당한 지연시간이 생길 수 있다.

---

TCP 핸드셰이크(TCP Handshake)

---

DNS 조회를 통해 IP 주소를 알고 난 후에, 브라우저는 서버와 TCP 3방향 핸드셰이크를 통해 연결을 설정한다.

 

이는 브라우저와 서버가 서로 통신하기 위함이다.

 

3방향 핸드셰이크를 통해 연결을 설정하는 이유는 기본적인 2방향 핸드셰이크 방식의 TCP 통신은 클라이언트가 서버의 고유 번호를 알 수 없고, 작업 순서가 달라지거나 중복으로 수행될 수 있기 때문이다.

---

TLS 협상(TLS Negotiation)

---

HTTPS를 이용한 연결을 위해서는 또 다른 “핸드셰이크”가 필요하다.

 

이 핸드셰이크는 통신 암호화에 쓰일 암호를 결정, 서버 확인, 실제 데이터 전송 전 안전한 연결이 이루어지도록 한다.

HTTPS TCP 통신 과정 [출처]mdn web docs

3방향 핸드셰이크 연결 과정에 Certificate 과정이 추가된다.

 

서버는 클라이언트에 Clientkey를 요청하고 클라이언트는 ClientKey를 응답한다.

 

이는 3방향 핸드셰이크보다 3단계 더 많은 과정을 거쳐서 지연시간이 증가하지만 보안성 있는 연결은 이를 감수할 만큼 가치가 있다.

 

http와 https의 차이

• http는 보안에 취약하다는 문제가 있기에 https는 ssl 인증서를 추가하여 중간에 공격자가 데이터를 가로채는 intercept 공격을 방지한다.

---

응답(Response)

---

웹서버와 연결되고 난 후, 브라우저는 HTTP(Get) request를 보낸다.

 

웹사이트는 대게 HTML 파일을 요청한다.

 

웹서버는 관련 응답 헤더와 함께 HTML의 내용을 응답한다.

---

구문 분석(Parsing)

---

브라우저가 첫 번째 데이터를 받으면, 수신된 정보를 파싱하기 시작한다.

 

파싱은 브라우저가 웹 서버를 통해 받은 데이터를 DOM이나 CSSOM으로 바꾸는 것이다.

 

이는 렌더러가 화면에 페이지를 그리는데 사용한다.

 

웹 서버는 첫 번째 응답을 보낼 때 최소한 페이지의 템플릿이라도 보내야 한다.

 

왜냐하면 브라우저는 응답받은 데이터로 렌더링을 시도하기 때문이다.

---

DOM 트리 구축(Building the DOM tree)

---

첫 번째로 브라우저는 HTML을 DOM 트리로 파싱한다. HTML 파싱은 토큰화와 트리 생성을 포함한다.

• HTML 토큰화 예시

토큰화 결과:
1. DOCTYPE 토큰: { type: "doctype", name: "html" }
2. 시작 태그 토큰: { type: "startTag", name: "html", attributes: { lang: "en" } }
3. 시작 태그 토큰: { type: "startTag", name: "head" }
4. 시작 태그 토큰: { type: "startTag", name: "title" }
5. 텍스트 토큰: { type: "text", content: "Example" }
6. 종료 태그 토큰: { type: "endTag", name: "title" }
7. 종료 태그 토큰: { type: "endTag", name: "head" }
8. 시작 태그 토큰: { type: "startTag", name: "body" }
9. 시작 태그 토큰: { type: "startTag", name: "h1" }
10. 텍스트 토큰: { type: "text", content: "Hello World!" }
11. 종료 태그 토큰: { type: "endTag", name: "h1" }
12. 종료 태그 토큰: { type: "endTag", name: "body" }
13. 종료 태그 토큰: { type: "endTag", name: "html" }

https://oesnuj.tistory.com/entry/브라우저의-화면-렌더링-원리DOM-CSSOM  출처:[비트로 그리는 성장일기:티스토리]

브라우저 화면 렌더링 원리 – DOM, CSSOM부터 Display까지 총정리

 

구문 분석기는 토큰화된 입력을 분석하여 DOM 트리를 구성한다.

---

프리로드 스캐너(Preload scanner)

---

브라우저가 DOM 트리를 만드는 프로세스는 메인 쓰레드를 차지한다.

 

때문에 프리로드 스캐너는 사용 가능한 컨텐츠를 분석하고 CSS나 Javascript, 웹 폰트와 같은 우선순위가 높은 자원을 요청한다.

 

이 덕에 구문 분석기는 외부 자원에 대한 요청응답을 기다리지 않아도 된다.

 

프리로드 스캐너가 미리 자원을 전송받고 있거나 전송받은 후이기 때문이다.

<link rel="stylesheet" src="styles.css" />
<script src="myscript.js" async></script>
<img src="myimage.jpg" alt="image description" />
<script src="anotherscript.js" async></script>

해당 코드에서 메인 쓰레드가 HTML이나 CSS를 분석하고 있을 때, 프리로드 스캐너는 스크립트와 이미지를 찾아 다운로드한다.

 

스크립트가 프로세스를 막지 않도록 하려면 async 속성이나 defer 속성을 추가하면 된다.

 

css를 다운로드 할 땐 자바스크립트의 실행을 막는다. 자바스크립트는 CSS 속성을 조작할 수 있기 때문이다.

---

CSSOM 구축(Building the CSSOM)

---

렌더링의 두 번째 단계는 CSSOM 트리를 만드는 것이다.

 

CSS 객체는 DOM과 비슷하며 DOM과 CSSOM은 둘 다 트리 구조이다.

 

브라우저는 CSS 규칙을 읽고 트리 노드를 만든다.

 

그리고 CSS 선택자에 기반해서 부모, 자식, 형제 관계의 노드를 만든다.

 

CSSOM을 만드는데 드는 시간은 일반적으로 한 번의 DNS 조회보다도 짧다. 때문에 CSSOM은 웹 성능 향상에 크게 기여하지 않는다.

---

렌더(Render)

---

HTML과 CSS를 파싱한 DOM, CSSOM 트리는 렌더 트리로 합성된다.

 

브라우저는 렌더 트리를 이용하여 요소들의 레이아웃을 계산한다.

 

레이아웃은 렌더 트리에 있는 모든 노드의 너비, 높이, 위치를 결정하는 프로세스이다.

 

그 후 요소들을 화면에 출력한다.

 

화면의 일부분은 CPU 대신 GPU가 그리게 함으로써 메인 쓰레드의 부담을 줄이고 성능을 향상시킬 수 있다.

---

참고문헌

---

본 글은 다음 문헌을 참고하였습니다.

https://developer.mozilla.org/ko/docs/Web/Performance/Guides/How_browsers_work

웹페이지를 표시한다는 것: 브라우저는 어떻게 동작하는가 - 웹 성능 | MDN