브라우저 렌더링엔진의 동작과정과 virtual DOM의 관계

참고 : 

https://d2.naver.com/helloworld/59361

http://mygumi.tistory.com/190

https://12bme.tistory.com/208

 

 

브라우저의 기본 구조

 

1. 사용자 인터페이스 - 주소 표시줄, 이전/다음 버튼, 북마크 메뉴 등. 요청한 페이지를 보여주는 창을 제외한 나머지 모든 부분이다.
2. 브라우저 엔진 - 사용자 인터페이스와 렌더링 엔진 사이의 동작을 제어.
3. 렌더링 엔진 - 요청한 콘텐츠를 표시. 예를 들어 HTML을 요청하면 HTML과 CSS를 파싱하여 화면에 표시함.
4. 통신 - HTTP 요청과 같은 네트워크 호출에 사용됨. 이것은 플랫폼 독립적인 인터페이스이고 각 플랫폼 하부에서 실행됨.
5. UI 백엔드 - 콤보 박스와 창 같은 기본적인 장치를 그림. 플랫폼에서 명시하지 않은 일반적인 인터페이스로서, OS 사용자 인터페이스 체계를 사용.
6. 자바스크립트 해석기 - 자바스크립트 코드를 해석하고 실행.
7. 자료 저장소 - 이 부분은 자료를 저장하는 계층이다. 쿠키를 저장하는 것과 같이 모든 종류의 자원을 하드 디스크에 저장할 필요가 있다. HTML5 명세에는 브라우저가 지원하는 '웹 데이터 베이스'가 정의되어 있다.

 

 

 

 

 

렌더링 엔진

렌더링 엔진의 역할은 요청 받은 내용을 브라우저 화면에 표시하는 일이다.

렌더링 엔진은 HTML 및 XML 문서와 이미지를 표시할 수 있다. 물론 플러그인이나 브라우저 확장 기능을 이용해 PDF와 같은 다른 유형도 표시할 수 있다. 그러나 이 장에서는 HTML과 이미지를 CSS로 표시하는 주된 사용 패턴에 초점을 맞출 것이다.

렌더링 엔진들

이 글에서 다루는 브라우저인 파이어폭스와 크롬, 사파리는 두 종류의 렌더링 엔진으로 제작되었다. 파이어폭스는 모질라에서 직접 만든 게코(Gecko) 엔진을 사용하고 사파리와 크롬은 웹킷(Webkit) 엔진을 사용한다.

웹킷은 최초 리눅스 플랫폼에서 동작하기 위해 제작된 오픈소스 엔진인데 애플이 맥과 윈도우즈에서 사파리 브라우저를 지원하기 위해 수정을 가했다. 더 자세한 내용은 webkit.org를 참조한다.

동작 과정

렌더링 엔진은 통신으로부터 요청한 문서의 내용을 얻는 것으로 시작하는데 문서의 내용은 보통 8KB 단위로 전송된다.

다음은 렌더링 엔진의 기본적인 동작 과정이다.

 

 

 

렌더링 엔진은 HTML 문서를 파싱하고 "콘텐츠 트리" 내부에서 태그를 DOM 노드로 변환한다. 그 다음 외부 CSS 파일과 함께 포함된 스타일 요소도 파싱한다. 스타일 정보와 HTML 표시 규칙은 "렌더 트리"라고 부르는 또 다른 트리를 생성한다.

렌더 트리는 색상 또는 면적과 같은 시각적 속성이 있는 사각형을 포함하고 있는데 정해진 순서대로 화면에 표시된다.

렌더 트리 생성이 끝나면 배치가 시작되는데 이것은 각 노드가 화면의 정확한 위치에 표시되는 것을 의미한다. 다음은 UI 백엔드에서 렌더 트리의 각 노드를 가로지르며 형상을 만들어 내는 그리기 과정이다.

일련의 과정들이 점진적으로 진행된다는 것을 아는 것이 중요하다. 렌더링 엔진은 좀 더 나은 사용자 경험을 위해 가능하면 빠르게 내용을 표시하는데 모든 HTML을 파싱할 때까지 기다리지 않고 배치와 그리기 과정을 시작한다. 네트워크로부터 나머지 내용이 전송되기를 기다리는 동시에 받은 내용의 일부를 먼저 화면에 표시하는 것이다.

 

 

 

 

동작 과정 예

웹킷의 렌더링 엔진 동작 과정

 

 

모질라의 게코 렌더링 엔진 동작 과정

 

웹킷과 게코가 용어를 약간 다르게 사용하고 있지만 동작 과정은 기본적으로 동일하다는 것을 위에서 알 수 있다.

게코는 시각적으로 처리되는 렌더 트리를 "형상 트리(frame tree)"라고 부르고 각 요소를 형상(frame)이라고 하는데 웹킷은 "렌더 객체(render object)"로 구성되어 있는 "렌더 트리(render tree)"라는 용어를 사용한다. 웹킷은 요소를 배치하는데 "배치(layout)" 라는 용어를 사용하지만 게코는 "리플로(reflow)" 라고 부른다. "어태치먼트(attachment)"는 웹킷이 렌더 트리를 생성하기 위해 DOM 노드와 시각 정보를 연결하는 과정이다. 게코는 HTML과 DOM 트리 사이에 "콘텐츠 싱크(content sink)"라고 부르는 과정을 두는데 이는 DOM 요소를 생성하는 공정으로 웹킷과 비교하여 의미있는 차이점이라고 보지는 않는다.

 

 

렌더링 엔진의 스레드

렌더링 엔진은 통신을 제외한 거의 모든 경우에 단일 스레드로 동작한다. 파이어폭스와 사파리의 경우 렌더링 엔진의 스레드는 브라우저의 주요한 스레드에 해당한다. 크롬에서는 이것이 탭 프로세스의 주요 스레드이다.

통신은 몇 개의 병렬 스레드에 의해 진행될 수 있는데 병렬 연결의 수는 보통 2개에서 6개로 제한된다(예를 들면 파이어폭스 3은 6개를 사용).

그리기

그리기 단계에서는 화면에 내용을 표시하기 위한 렌더 트리가 탐색되고 렌더러의 "paint" 메서드가 호출된다. 그리기는 UI 기반의 구성 요소를 사용한다.

동적 변경

브라우저는 변경에 대해 가능한 한 최소한의 동작으로 반응하려고 노력한다. 그렇기 때문에 요소의 색깔이 바뀌면 해당 요소의 리페인팅만 발생한다. 요소의 위치가 바뀌면 요소와 자식 그리고 형제의 리페인팅과 재배치가 발생한다. DOM 노드를 추가하면 노드의 리페인팅과 재 배치가 발생한다. "html" 요소의 글꼴 크기를 변경하는 것과 같은 큰 변경은 캐시를 무효화하고 트리 전체의 배치와 리페인팅이 발생한다.

 

 

이렇듯 브라우저에서 화면을 보여줄 때 렌더링 엔진을 통해 그려야 할 트리를 구축하고 브라우저에서 그 트리의 내용을 토대로 그려 화면 상으로 보여주는 것을 알 수 있다.

 

여기에서 만약 DOM의 변경 요청이 생긴다면?

 

브라우저는 해당 변경되는 DOM 노드를 찾은 후 스타일규칙과 DOM트리를 업데이트하여 다시 렌더트리(형상트리)를 구성한다.

그 다음에 해당 트리의 내용을 화면에 적용하여 새롭게 그리는 것이다.

 

DOM의 수정에 대해서 하나, 둘의 요청은 상관 없다.

하지만 100개, 1000개, 더 이상의 요청이 있다면?

 

브라우저는 위의 DOM트리와 스타일 규칙을 다시 최신화하여 렌더트리(형상트리)를 구성하고 그것을 토대로 다시 그려 화면을 업데이트 해야할 것이다. 한마디로 저 위의 과정을 요청이 100번이면 100번, 1000번이면 1000번 다시 한다는 말이다. 

 

이 과정에서 굉장히 많은 비용을 소모한다.

게다가 화면이 복잡하면 복잡할수록, DOM 노드가 많으면 많을수록 비용이 더 많이 소모될 것이다.

이 부분에서 성능저하로 인한 페이지 속도 지연이 발생한다.

위와 같은 처리에 대한 비용이 큰 자세한 이유는 링크를 참고하길 바란다. http://d2.naver.com/helloworld/59361

 

이런 브라우저의 단점을 virtual DOM(가상돔)이 해결해준다.

 

만약 100번의 DOM 수정 요청이 오면, virtual DOM은 브라우저 대신 DOM 변경을 인지하고 (이것이 가능한 이유는 React나 Vue 자신들이 컴포넌트를 가지고 있기 때문이라고 개인적으로 생각) 그 내용을 virtual DOM에 반영한다. 

이 과정이 React나 Vue와 같은 SPA 프레임워크에서 DOM트리와 스타일규칙을 읽어와 변경된 화면의 렌더트리(형상트리)를 구성하는것으로 이해된다. 

이는 Vue나 React들이 가지고 있는 자신들의 컴포넌트가 메모리상에 존재하기 때문에 브라우저가 직접 노드를 일일이 찾아 변경사항을 반영하여 렌더트리(형상트리)를 구성하는것보다 훨씬 빠르다.

 

이렇게 변경사항을 구성해놓은것을 브라우저에게 전달하여 그리게만 하면 브라우저는 렌더링만 하면되고 변경사항에 대한 업데이트는 SPA 프레임워크에서 담당하면 되는것이다.