브라우저의 동작 원리

브라우저 동작에 대해서 제대로 이해해두고자 이번 기회에 여러 자료들을 참고하여 다시 한번 정리해봤습니다.

브라우저의 주요 기능

브라우저의 주요 기능은 사용자가 선택한 자원을 서버에 요청하고 다운 받아 렌더링하여 브라우저에 보여주는 것
- 자원은 보통 HTML 문서이지만, PDF나 이미지 또는 다른 형태일 수 도 있다
- 지원의 주소는 URI(Uniform Resource Identifier)에 의해 정해진다
브라우저는 HTML과 CSS 명서에 따라 HTML 파일을 해석해서 표시한다
- 이 명세는 웹 표준화 기구인 W3C(World Wide Web Consortium)에서 정한다
- 최근 대부분의 브라우저가 이 표준 명세를 따른다

브라우저의 기본 구조

1. 사용자 인터페이스 (User Interface)

주소 표시줄, 이전/다음 버튼, 북마트 메뉴 등
웹 페이지를 제외하고 사용자와 상호작용하는 사용자 인터페이스
요청한 페이지를 보여주는 창을 제외한 나머지 모든 부분

2. 브라우저 엔진 (Browser Engine)

사용자 인터페이스와 렌더링 엔진 사이의 동작을 제어
- 예를 들어, 사용자가 새로고침 버튼을 눌렀다면 브라우저 엔진은 이를 이해하고 새로고침 명령을 수행한다
유저 인터페이스와 렌더링 엔진을 연결하는 브라우저 엔진

3. 렌더링 엔진 (Rendering Engine)

요청한 콘텐츠를 표시
HTML을 요청하면 HTML과 CSS를 파싱하여 화면에 표시
웹 브라우저마다 렌더링 엔진이 조금씩 다르다
- Safari: Webkit
- Firefox: Gecko
- Chrome: Blink

4. 통신 (Networking)

각종 네트워크 요청을 수행하는 네트워킹 파트
HTTP/HTTPS 요청과 같은 네트워크 호출에 사용됨
- 웹 브라우저(Client)는 해당 URL(예: yahoo.co.jp)로 웹페이지를 요청
- 웹 서버는 요청한 URL에 대한 응답을 반환 (리소스 다운로드)

※ chrome dev tool > network 탭에서 상세 확인 가능
- 다운로드 요청 개수 (requests)
- 수신한 데이터 크기 (transferred)
- 웹 페이지 총 크기 (resources)
- 다운로드 소요 시간 (Finishi)
- HTML 로드 시간 (DOMContentLoaed)
- 웹페이지 렌더링 완료시간 (Load)

※ 수신한 데이터 크기 (transferred) 와 웹 페이지 총 크기 (resources) 의 크기가 다른 이유
- 웹 브라우저가 압축된 리소스를 다운받았기 때문.
- Response Headers > content-encoding: gzip

이것은 플랫폼 독립적인 인터페이스이고 각 플랫폼 하부에서 실행됨

5. UI 백엔드

콤보 박스와 창 같은 기본적인 장치를 그린다
- 체크박스나 버튼과 같은 기본적인 위젯을 그려주는 UI백엔드 파트
플랫폼에서 명시하지 않은 일반적인 인터페이스로서, OS사용자 인터페이스 체계를 사용

6. 자바스크립트 해석기 (JavaScript Interpreter)

자바스크립트 코드를 해석하고 실행
가장 유명한 엔진으로 Chrome에 탑재된 구글의 V8이 있다

7. 자료 저장소 (Data Persistence)

이 부분은 자료를 저장하는 계층
- localStorage나 Cookie 와 같이 보조 기억장치에 데이터를 저장하는 파트
쿠키를 저장하는 것과 같이 모든 종류의 자원을 하드디스크에 저장할 필요가 있음
HTML5 명세서에는 브라우저가 원하는 웹 데이터베이스 가 정의 되어 있음.

렌더링 엔진 (Rendering Engine)의 동작 과정

위 브라우저 기본 구조에서 “렌더링 엔진” 에 대해서 조금 더 자세하게 살펴보자

렌더링 엔진은 HTML을 요청하면 HTML과 CSS를 파싱하여 화면에 표시하는 역할을 한다

웹 브라우저마다 렌더링 엔진이 조금씩 다르다

Safari: Webkit
Firefox: Gecko
Chrome: Blink

렌더링 엔진의 목표

HTML, CSS, JS, Image 등 웹 페이지에 포함된 모든 요소들을 화면에 보여준다
업데이트가 필요할 때, 효율적으로 렌더링할 수 있도록 자료구조를 생성한다
- 사용자 동작으로 인한 입력 발생
- 스크롤 발생이나 애니메이션 동작
- 비동기 요청으로 인한 데이터 로딩 등

Critial Rendering Path

Critial Rendering Path 이란, 브라우저는 렌더링을 위해 위의 과정을 거치게 되는데, 이 것을 Critical Rendering Path라고 한다

1. HTML 파싱 후 DOM 트리 생성

브라우저에서 사용자가 요청한 웹페이지를 불러오고 파싱을 한다
렌더링 엔진은 우선 네트워크 레이어를 통해 전달받은 HTML 문서를 파싱하여 각 요소들을 DOM 트리의 각 DOM 노드 들로 변환한다
DOM이란 Document Object Model의 준말로 마크업 형태의 HTML문서를 오브젝트 모델의 형태로 바꿔놓은 것을 말함
HTML문서의 각 마크업과 DOM의 각 요소는 1:1로 매칭된다

1-1. DOM 트리 생성

토큰화(Tokenizing)
어휘 분석을 통해 HTML5표준에 지정된 고유한 토근으로 변환됨
문자열을 W3C HTML5 표준에 따라 고유 토큰(, 등, 꺽쇠괄호로 묶인 문자열)으로 변환한다
- 각 토큰은 특별한 의미와 고유한 규칙을 가짐

<html>
  <head>
    <title>브라우저 동작 원리</title>
    <link rel="stylesheet" href="style.css" />
    <meta charset="utf-8" />
  </head>
  <body>
    <h1>브라우저 렌더링 과정</h1>
  </body>
</html>

토큰화 후 아래와 같이 변환됨

Start Tag html
  Start Tag head
    ...
  End Tag head
  Start Tag Body
    Start Tag H1
      Text 브라우저 렌더링
    End Tag H1
  End Tag Body
End Tag html

렉싱(Lexing)
- 토큰을 해당 속성 및 규칙을 정의한 노드 객체로 변환
DOM 생성 (Dom Construction)
- HTML은 상위-하위 관계로 정의할 수 있어 트리 구조로 나타낼 수 있다
- 렉싱 과정을 거쳐 생성된 노드들을 트리구조로 변환한다

1-2. CSSOM 트리 생성

HTML을 DOM 트리로 만드는 과정과 비슷하게 CSS도 CSSOM 이라는 트리가 만들어진다
CSSOM은 DOM 이 어떻게 화면에 표시되어질지 알려주는 역할을 한다
CSS도 위에서 아래로 스타일 규칙이 정해지므로 트리 구조를 가지고 있다

2. Render 트리 생성

하면에 표시되어야 할 모든 노드의 컨텐츠, 스타일 정보를 포함하는 트리

Render 트리 생성 과정

Document 객체부터 각 노드를 순회하면서 각각에 맞는 CSSOM을 찾아서 규칙을 적용하면서
Render 와 관련된 요소들은 Render 트리에 포함시키게 된다
- 이 때, meta태그나, display: none; 같은 속성을 가진 요소들은 Render와 관계가 없으므로 Render 트리에 포함되지 않는다

3. Render 트리 배치 - Layout(Reflow)

Render 트리가 생성되었다면 Layout 과정을 거친다
뷰포트내에서 요소들의 정확한 위치나 크기를 계산하는 과정
Text나 요소의 Box가 화면에서 차지하는 영역이나 여백 그리고 스타일 속성이 계산된다
- 이 때, CSS에서 상대적인 단위 (%, em 등)를 사용했을 경우, 디바이스의 뷰포트에 맞춰 픽셀 단위로 변환된다

4. Render 트리 그리기 - Paint(Repaint)

③과정에서 렌더링 엔진이 각 요소들이 어떻게 생겼으며 어떻게 표시해야할지 알게되면 마지막으로 화면에 실제 픽셀로 그려주는 과정을 거치게되는데, 이 것을 Paint과정이라고 한다
여기까지가 Critical Rendering Path의 과정이며, 이 과정까지의 소요되는 시간을 줄이게 되면 브라우저가 웹 페이지를 보여주는데 소요되는 시간도 줄일 수 있다

UI가 업데이트 되는 3가지 상황

브라우저 렌더링 후, 사용자 동작으로 JavaScript가 실행되어서 CSS가 변경되거나 애니메이션 재생이 일어날 경우, 브라우저는 어떻게 동작할까? 이 때는 크게 3가지 경우로 동작한다.

1. 다시 Layout이 발생하는 경우

주로 요소의 크기나 위치가 바뀔 때, 혹은 브라우저 창의 크기가 바뀌었을 때 다시 발생
JavaScript -> Style -> Layout -> Paint -> Composite
이 때, Layout의 수치를 다시 계산하여 배치해야하기 때문에 Layout 과정이 다시 발생하고
이에 맞춰 다시 Paint 되고
마지막으로 레이러를 다시 합성하는 과정(Composite)도 거치게 된다

2. Paint 부터 다시 발생되는 경우

주로 배경 이미지나 텍스트 색상, 그림자 등 레이아웃의 수치를 변화시키지 않는 스타일의 변경이 일어났을 때 발생
JavaScript -> Style -> Paint -> Composite
이 경우 Layout 과정이 발생하지 않기 때문에, 성능상으로 이점을 가진다

3. 레이어의 합성만 다시 발생하는 경우

레이어는 포토샵의 레이어와 비슷하게 페인팅할 영역을 나누어 놓은 것을 의미한다
- Chrome의 경우 Layout 과정 이후에 정해진 기준이나 필요에 의해서 브라우저가 레이어를 생성한다
- 그리고 Render 트리에 있는 노드 객체들은 이 생성된 레이어가 포함되게 된다
- 이 레이어들은 트리의 형태로 구성이 된다
- 그리고 렌더링 엔진이 레이어를 페인팅 과정에서 각 각 그려준 다음 , 하나의 비트맵으로 합성해서 페이지를 완성한다
JavaScript -> Style -> Composite
이 경우, Layout과 Paint를 수행하지 않고 레이어의 합성만 발생하므로 성능상으로 가장 큰 이점을 가진다
CSS 속성이 변경되었을 때, 앞서 설명한 3가지 경우 중 어떤 경우로 업데이트 되는지는 CSS Triggers를 참고하면 알 수 있다 (CSS 속성마다 렌더링 엔진 별로 어떻게 업데이트 되는지 알 수 있음)

lighthouse.log