- 우선 virtual dom을 이해하기 앞서 브라우저의 작동방식을 이해해야한다.
브라우저 workFlow
1. DOM Tree 생성
- 브라우저가 서버로부터 HTML을 전달받으면,
브라우저의렌더 엔진이 이를 파싱하고DOM node로 이루어진 트리를 만든다.
2. Render Tree 생성
- 외부 CSS파일과 각 엘리먼트의 inline 스타일을 파싱한다.
- 스타일 정보를 사용하여 DOM 트리에 따라 새로운 트리, 렌더 트리를 만든다.
- 렌더 트리를 만드는 과정에선, 각 요소의 스타일이 계산되고, 또 이 계산되는 과정에서 다른 요소들의 스타일 속성들을 참조한다.
3. Render Tree 실행 과정
- Webkit에서는 노드의 스타일을 처리하는 과정을
attachment라고 부른다. DOM 트리의 모든 노드들은attach라는 메서드가 있다. 이 메서드는 스타일 정보를 계산해서객체형태로 반환한다. - 이 과정은 동기적(synchronous) 작업이고 DOM 트리에 새로운 노드가 추가되면 그 노드의 attch 메서드가 실행된다.
4. Layout (reflow)
- 렌더 트리가 다 만들어지고 나면, 레이아웃 과정을 거친다.
- 각 노드들은 스크린 좌표가 주어지고, 정확히 어디에 나타나야할 지 위치가 주어진다.
5. Painting
- 렌더링 된 요소들에 색을 입히는 과정이다.
- 트리의 각 노드들을 거쳐가면서 paint() 메서드를 호출하고 그러면 비로소 스키린에 정보가 나타다는 것이다.
Virtual DOM
-
메모리상의 가상 DOM, 이 DOM 트리는 렌더링이 되지 않기 때문에 연산 비용이 적다.
-
"virtual" DOM을 제어하는 API를 직접 호출하지않고 Virtual DOM을 제어하는 것을 React나 Vue같은 프레임워크가 알아서 하도록 추상화했다는 얘기가 사실 더 정확하다.
(실질적인 DOM관리를 Virtual DOM이 한다.) -
브라우저 작동방식은 DOM에 변화가 생기면 렌더트리를 재생성(그러면 모든 요소들의 스타일이 다시 계산 됨)하고 레이아웃을 만들고 페인팅하는 과정이 다시 반복되는 것이다.
-
그러면 복잡한 SPA에서는 DOM 조작이 많이 발생한다. 그 뜻은 그 DOM의 변화를 적용하기위해 브라우저가 많이 연산을 해야한단 소리고, 그것은 전체적인 프로세스를 비효율적으로 만든다.
-
여기서 Virtual DOM이 빛을 바란다. 만약 View에 변화가 있다면, 그 변화는 실제 DOM에 적용되기 전에 가장의 DOM에 먼저 적용을 시키고 그 최종적인 결과를 실제 DOM으로 전달해준다.
이로써, 브라우저 내에서 발생하는 연산의 양을 줄이면서 성능이 개선되는 것이다.
주의사항과 한계
-
0.1초마다 화면에 데이터가 변경된다면? Virtual DOM으로 0.5초씩 모아가지고 렌더링을 적게할 수 있을까? → 안된다. 동시에 변경되는 것에 한해서만 렌더링된다.
-
React나 Vue등을 이용해서 Virtual DOM을 쓰면 무조건 빠른가? → 아니다. 똑같이 최적화를 해야한다. (슬라이드를 옮기거나 무한 스크롤등의 움직임이 있을 때는 Virtual DOM을 이용해서 반복 렌더링을 하지 않도록 해줘야한다.)
Shadow DOM
- Shadow DOM은 주로 웹 구성 요소의 변수 및 CSS 범위 지정을 위해 설계된 브라우저 기술이다.
- virtual DOM은 브라우저 API 위에 JavaScript 라이브러리로 구현된 개념이다.
reference
