브라우저의 주요 기능은 사용자가 선택한 자원을 서버에 요청하고 브라우저에 표시하는 것이다.
자원은 보통 HTML 문서지만 PDF나 이미지 또는 다른 형태일 수 있다. 자원의 주소는 URI(Uniform Resource Identifier)에 의해 정해진다.
브라우저는 HTML과 CSS 명세에 따라 HTML 파일을 해석해서 표시하는데 이 명세는 웹 표준화 기구인 W3C(World Wide Web Consortium)에서 정한다.
브라우저의 사용자 인터페이스는 표준 명세가 존재하지 않지만, 일반적으로 다음의 요소들을 포함한다.
브라우저의 주요 구성 요소는 다음과 같다.

사용자 인터페이스 : 주소 표시줄, 이전/다음 버튼, 북마크 메뉴 등. 요청한 페이지를 보여주는 창을 제외한 나머지 모든 부분이다.
브라우저 엔진 : 사용자 인터페이스와 렌더링 엔진 사이의 동작을 제어한다.
렌더링 엔진 : 요청한 콘텐츠를 표시한다. 예를 들어 HTML을 요청하면 HTML과 CSS를 파싱하여 화면에 표시한다.
통신 : HTTP 요청과 같은 네트워크 호출에 사용된다.
자바스크립트 해석기(엔진) : 자바스크립트 코드를 해석하고 실행한다.
UI 백엔드 : 콤보 박스와 창 같은 기본적인 장치를 그린다. 플랫폼에서 명시하지 않은 일반적인 인터페이스로서, OS 사용자 인터페이스 체계를 사용된다.
자료 저장소 : 자료를 저장하는 계층으로, 쿠키 등의 모든 종류의 자원을 저장하는 웹 데이터 베이스이다.
렌더링 엔진은 요청 받은 내용을 브라우저 화면에 표시하는 역할을 하며, HTML 및 XML 문서와 이미지를 표시할 수 있다. (플러그인이나 브라우저 확장 기능을 이용해 PDF와 같은 다른 유형도 표시할 수 있음)
브라우저마다 사용하는 렌더링 엔진이 각각 다르기 때문에, 모든 브라우저가 동일한 소스를 화면에 동일하게 그려주지 않고 엔진마다 읽을 수 있는 코드의 버전도 다르기 때문에 크로스 브라우징 이슈가 발생할 수 있다.
| 브라우저 | 렌더링 엔진 |
|---|---|
| IE | Trident |
| Edge | EdgeHTML, Blink |
| Chrome | Webkit, Blink(버전 28 이후) |
| Safari | Webkit |
| FireFox | Gecko |
렌더링 엔진은 통신으로부터 요청한 문서의 내용을 얻는 것으로 시작하는데 문서의 내용은 보통 8KB 단위로 전송된다.
다음은 렌더링 엔진의 기본적인 동작 과정이다.


브라우저는 렌더링 할 문서를 HTML과 CSS로 나눠서 읽게 된다. 이때 HTML과 CSS는 단순한 텍스트이므로 각각 연산과 관리가 가능하도록 HTML Parser와 CSS Parser를 사용해 관리가 가능한 Object Model로 만든다.
렌더링 엔진은 좀 더 나은 사용자 경험을 위해 가능하면 빠르게 내용을 표시하는데 모든 HTML을 파싱할 때까지 기다리지 않고 배치와 그리기 과정을 시작한다. 네트워크로부터 나머지 내용이 전송되기를 기다리는 동시에 받은 내용의 일부를 먼저 화면에 표시하는 것이다.
렌더링 엔진은 HTML 문서를 한 줄씩 순차적으로 파싱하다가 자바스크립트 파일을 로드하는 script 태그를 만나면 DOM 생성을 일시 중단한다.
script 태그의 src에 정의된 자바스크립트 파일을 서버에 요청하여 응답받으면 자바스크립트 코드를 파싱하기 위해 자바스크립트 엔진에게 제어권을 넘긴다.
자바스크립트 파싱이 끝나면 렌더링 엔진으로 다시 제어권을 넘기고 DOM 생성을 이어 나간다.
생성되지 않은 DOM을 조작하면 에러가 발생할 수 있기 때문에, body 요소 아래에 자바스크립트를 위치 시키거나 DOM 생성이 완료된 시점에 자바스크립트가 실행되도록 한다.
CSSOM 트리와 DOM 트리를 결합하여, 표시해야 할 순서로 내용을 그려낼 수 있도록 하기 위해 렌더 트리를 형성한다. 이 과정을 Attachment라고 한다.
렌더 트리는 화면에 표시되는 각 노드의 위치를 계산하는 레이아웃에 사용되고 픽셀을 화면에 그리는 페인트 과정에도 사용된다.
렌더 트리를 생성하려면 브라우저는 대략 3가지 작업을 수행한다.
렌더 트리가 생성된 후, 기기의 뷰포트 내에서 렌더 트리의 노드가 정확한 크기와 위치를 계산한다.
이때 모든 상대적인 값이 픽셀 값으로 변환된다. (%, rem, vh -> px)
렌더 트리의 각 노드를 화면의 실제 픽셀로 나타낼 때 Painting 메서드가 호출된다. Painting 과정 후 브라우저 화면에 UI가 나타나게 된다.
실제로 요소가 stacking contexts에 쌓이는 순서는 아래와 같다. 스택은 뒤에서 앞으로 그려지기 때문에 이 순서는 Painting에 영향을 미친다. 블록 렌더러가 쌓이는 순서는 다음과 같다.
페인트 단계에서 메인 스레드는 페인트 기록(paint record)을 생성하기 위해 레이아웃 트리를 순회한다. 페인트 기록은 '배경 먼저, 다음은 텍스트, 그리고 직사각형'과 같이 페인팅 과정을 기록한 것이다.
브라우저는 변경에 대해 가능한 한 최소한의 동작으로 반응하려고 노력한다. 예를 들어 div 요소 한 개의 색깔이 바뀌면 해당 요소의 리페인팅만 발생한다.
요소의 위치가 바뀌면 요소와 자식 그리고 형제의 리페인팅과 재배치가 발생한다.
DOM 노드를 추가하면 노드의 리페인팅과 재배치가 발생한다. HTML 요소의 글꼴 크기를 변경하는 것과 같은 큰 변경은 캐시를 무효화하고 트리 전체의 배치(Layout)와 리페인팅이 발생한다.
렌더링 과정을 모두 마치면 최종적으로 브라우저에 페이지가 그려진다.
하지만 특정 액션이나 이벤트에 의해 HTML 요소의 크기나 위치 등의 레이아웃 수치가 변하면 해당 요소의 영향을 받는 자식 노드나 부모 노드들을 포함하여 Layout(Reflow) 과정을 다시 수행하게 된다.
이 경우 각 요소들의 크기와 위치를 다시 계산하게 되는데 이 과정을 Reflow, 그리고 Reflow 된 렌더 트리를 다시 화면에 그려주는 과정을 Repaint라고 한다.
렌더 트리와 각 요소들의 크기와 위치를 다시 계산해주는 과정을 Reflow라고 한다.
Reflow가 일어나는 대표적인 경우는 다음과 같다.
이 외에도 화면의 구조가 변경되었다면 Reflow가 발생한다.
화면을 다시 그리는 과정을 Repaint라고 한다.
화면의 구조가 변경되었을 때에는 Reflow 과정을 거쳐 화면 구조를 다시 계산한 후 Repaint 과정을 통해 화면을 다시 그린다. 즉 화면의 구조가 변경되었을 때에는 Reflow와 Repaint 모두 발생한다.
화면의 구조가 변경되지 않았을 경우에는 Repaint만 발생한다. 예를 들면 opacity, background-color, visibility, outline 등의 스타일 변경 시에는 Repaint만 동작한다.
참고 )
https://d2.naver.com/helloworld/59361
https://velog.io/@thyoondev/%EC%9B%B9-%EB%B8%8C%EB%9D%BC%EC%9A%B0%EC%A0%80%EC%9D%98-%EB%8F%99%EC%9E%91%EC%9B%90%EB%A6%AC%EB%A5%BC-%EC%95%8C%EC%95%84%EB%B3%B4%EC%9E%90