브라우저 렌더링 과정

https://velog.io/@soopy368/%EB%B8%8C%EB%9D%BC%EC%9A%B0%EC%A0%80-%EB%A0%8C%EB%8D%94%EB%A7%81-%EC%9B%90%EB%A6%AC

 

1. DOM tree 생성

개발자가 작성한 HTML을 브라우저가 전달받으면, 브라우저의 렌더엔진이 이를 파싱

DOM node로 이루어진 트리 생성

 

2. Render tree 생성

CSS파일과 각 엘리먼트의 inline 스타일을 파싱하고, 스타일 정보를 추가하여 렌더트리 생성

 

3. Layout

각 노드들은 스크린의 좌표가 주어지고 정확히 어디에 위치해야할지 정해짐

 

4. Painting

모든 요소들에 색을 입히는 과정 , UI렌더링

 

 

<가상돔 등장 배경>

 

예전에는 서버에서 데이터와 함께 완전한 페이지를 렌더해주는 SSR(server side rendering) 방식을 많이 사용했음.

 

SPA의 등장과 함께 CSR(client side rendering)방식이 많이 사용되면서 DOM 업데이트가 복잡하게 발생하는 어플리케이션들이 많아졌다.

 

DOM조작을 통해 화면을 렌더링하는 과정의 비효율성을 해결하고, 최적화 할 필요성이 대두

-> 가상돔 등장

 

<가상돔 동작 방식>

최초에 브라우저가 실제 DOM 트리를 생성하고 브라우저 화면에 애플리케이션 UI가 렌더됨.

virtual DOM은 DOM트리를 가벼운 버전으로 복사 (class, style 등의 속성은 있지만, 화면에 변화를 직접 줄 수 있는 DOM api들은 갖고 있지 않음)

DOM 노드에 변화가 생기면 virtual DOM은 다시 새로운 가상의 DOM트리를 생성

가상돔 구현체의 diff 함수에서 매개변수로 이전 상태의 DOM트리와 새롭게 만들어진 DOM트리를 각각 previous와 current로 받아와 변화된 부분 확인

가상돔 구현체에서 patch 함수는 rootNode와 이전 단계에서 diff함수를 통해 얻은 변경된 부분만 담겨있는 patches를 인자로 받는다. 이 함수는 변경된 사항만을 실제 DOM노드에 적용하여 렌더링 과정을 수행.

(즉, 가상돔은 버퍼링 or 캐싱의 역할을 함)

비용이 큰 렌더링 횟수를 줄여 최적화하는 것