Q. 자바스크립트 엔진 성능은 계속해서 좋아지고 있는데, 왜 DOM은 느려지는 걸까?
A. DOM 조작이 전체 동작을 비효율적으로 만드는게 아니라, 그 이후에 일어나는 일 때문에, 작업이 더뎌지는 것!
브라우저의 Workflow
DOM Tree 생성
브라우저가 HTML 을 전달받으면, 브라우저의 렌더 엔진이 이를 파싱하고 DOM 노드(Node) 로 이뤄진 트리를 만든다.
Render Tree 생성
외부 CSS 파일과 각 엘리먼트의 inline 스타일을 파싱하고, 스타일 정보를 사용하여 DOM 트리에 따라 새로운 트리, 렌더트리를 만든다.
Webkit 에서는 노드의 스타일을 처리하는 과정을 ‘attachment’ 라고 부른다.
DOM 트리의 모든 노드들은 attach 라는 메소드가 있는데, 이 메소드는 스타일 정보를 계산해서 객체형태로 반환한다.
이 과정은 동기적(synchronous) 작업이며, DOM 트리에 새로운 노드가 추가되면 그 노드의 attach 메소드가 실행된다.
렌더 트리를 만드는 과정에선, 각 요소들의 스타일이 계산되고, 또 이 계산되는 과정에서 다른 요소들의 스타일 속성들을 참조한다.
Layout (reflow)
렌더 트리가 다 만들어지고 나면, 레이아웃 과정을 거친다.
각 노드들은 스크린의 좌표가 주어지고, 정확히 어디에 나타나야 할 지 위치가 주어진다.
Painting
렌더링 된 요소들에 색을 입히는 과정.
트리의 각 노드들을 거쳐가면서 paint() 메소드를 호출한다. 이후에 스크린에 원하는 정보가 나타난다.
Virtual DOM
DOM에 변화생기면, 렌더트리를 재생성하고 (모든 요소들의 스타일이 다시 계산) 레이아웃을 만들고 페인팅을 하는 과정이 다시 반복된다.
복잡한 SPA(싱글 페이지 어플리케이션) 에서는 DOM 조작이 많이 발생한다. 그 뜻은 그 변화를 적용하기 위해 브라우저가 많이 연산을 해야한단 소리고, 전체적인 프로세스를 비효율적으로 만든다.
이 이부분에서 Virtual DOM 이 빛을 발합니다!
만약 뷰에 변화가 있다면, 그 변화는 실제 DOM 에 적용되기전에 가상의 DOM 에 먼저 적용시키고 그 최종적인 결과를 실제 DOM 으로 전달해준다. 이로써, 브라우저 내에서 발생하는 연산의 양을 줄이면서 성능이 개선되는 것 이다.
Q. Virtual DOM없이 변화가 있을 때, 그 변화를 묶어서 DOM fragment 에 적용한 다음에 기존 DOM 에 던져주면 되지 않을까? Virtual DOM이 해결 하려고 하는건 무엇인가?
A. DOM fragment를 관리하는 과정을 수동으로 하나하나 작업 할 필요 없이, 자동화하고 추상화하는 것. 그 뿐만 아니라, 만약에 이 작업을 직접 한다면, 기존 값 중 어떤게 바뀌었고 어떤게 바뀌지 않았는지 계속 파악하고 있어야하는데 (그렇지 않으면 수정 할 필요가 없는 DOM 트리도 업데이트를 하게 될 수도 있다), 이 작업을 Virtual DOM 이 이걸 자동으로 해결해준다.
DOM 관리를 Virtual DOM 이 하도록 함으로써, 컴포넌트가 DOM 조작 요청을 할 때 다른 컴포넌트들과 상호작용을 하지 않아도 되고, 특정 DOM 을 조작할 것 이라던지, 이미 조작했다던지에 대한 정보를 공유 할 필요가 없습니다. 즉, 각 변화들의 동기화 작업을 거치지 않으면서도 모든 작업을 하나로 묶어줄 수 있다.
Reference
