728x90
브러우저의 랜더링 원리
브라우저가 화면에 나타나는 요소를 렌더링할 때, webkit이나 Gecko 등과 같은 렌더링 엔진을 사용한다.
렌더링 엔진이 HTML, CSS, Javascript를 렌더링할 때 CRP(Critical Rendering Path)라는
프로세스를 사용하며 아래의 단계들로 이루어진다.
- 토큰화된 HTML 문자열들을 이용해 DOM(Document Object Model) 트리를 구축
- DOM은 Javascript를 이용해 실제 상호작용할 수 있는 HTML 엘리먼트로 이루어진 객체
- HTML 파서의 특징
- 너그러운 속성
▶ 최상단에 <html>태그, 닫는 태그를 작성하지 않아도 정상적으로 렌더링된다.
(HTML은 대부분의 프로그래밍 어너가 속한 촘스키의 문맥자유문법에 속하지 않기에 그렇다 한다) - 파싱 과정에 중단될 수 있음
▶ <script>나 <link> 같은 외부 태그를 만나면 HTML 파싱을 중단한 뒤 해당 태그의 해석을 실행함
(스크립트의 경우 일부 브라우저에서 예측 파싱 기법을 이용해 별도의 스레드에서
외부 스크립트, 링크, 스타일 등을 불러온다.) - 재시작(Reentrant)
▶ HTML 파싱 과정 중 외부 요일으로 인해 DOM에 변화가 있다면 파싱 과정을 다시 시작한다.
결국 오래걸린 다는 것이다.
- 너그러운 속성
- CSS 파싱 후, CSSOM(CSS Object Model) 트리 구축
- Javascript 실행(DOM 생성시에 일어날 수 있다.)
- 주의!! HTML 중간에 스크립트가 있으면 HTML 파싱이 중단되고 JS 엔진의 동작이 끝나면
중단되었던 부분 부터 HTML DOM 생성을 재개한다.
- 주의!! HTML 중간에 스크립트가 있으면 HTML 파싱이 중단되고 JS 엔진의 동작이 끝나면
- 렌더트리 생성
- 렌더트리는 DOM 트리와 CSSOM 트리를 조합해 만들며, 화면에 나타나는 요소를 결정하는 트리이다.
- <head>, <script> 같은 태그나 display: none 스타일이 적용된 엘리먼트는 제외된다.
- 그러므로 DOM트리와 렌터트리는 1:1 대칭이 안된다.
- Layout / Reflow 단계 ▶ 뷰포트 기반으로 렌더트리의 각 노드가 갖는 정확한 크기와 위치를 계산
- Paint 단계 ▶ 계산한 위치 / 크기를 기반으로 화면에 그림
React에서의 Virtual DOM
Virtual DOM의 등장 이유
React는 대규모 SPA와 다이나믹 UI의 웹페이지를 다루기 때문에
DOM에 담기는 데이터가 커져 직접 DOM 조작이 무거워져서
실제 DOM의 변경사항을 빠르게 파악하고 반영하기 위함이다.
- 기존 DOM은 변경사항이 있을때 마다 잠재적인 레이아웃 단계와 페인트 단계를 반복한다.
10개의 DOM 노드를 For문으로 수정시 각 노드가 변경될 때마다 다시 그려진다. - 메모리에 DOM 객체를 복사해 구현해두고 직접 DOM에 접근을 하지 않는다.
Virtual DOM은 최종적으로 업데이트된 element만 기존 DOM에 업데이트한다. - 결론 : 노드 업데이트가 빠르고 반복이 줄기 때문에 브라우저의 과부하가 줄어든다.
728x90
'FE 이모저모 공부' 카테고리의 다른 글
| 모듈 시스템 : CommonJS, AMD, UMD, ES6 (0) | 2023.08.26 |
|---|---|
| BOM(Browser Object Model)과 DOM(Document Object Model) (0) | 2023.08.17 |
| Javascript 엔진이 코드를 실행하는 과정 (0) | 2023.08.14 |
| CSR(Client Side Rendering)과 SSR(Server Side Rendering) (0) | 2023.08.07 |
| body-parser를 알아보자 (0) | 2022.11.08 |
