브라우저 랜더링 2(랜더링엔진, 최적화)

저번 글에 이어 브라우저랜더링에 대해 알아보겠습니다 

중요랜더링경로

중요 랜더린 경로는 브라우저가  HTML CSS Javascript를 화면에 픽셀로 변환하는 일련의 단계이며 

이를 최적화 하는 것이 랜더링 성능향상에 영향을 줍니다 

 

출처: https://velog.io/@eommoonjoo/JavaScript-Critical-Rendering-Path

 

위의  그림에 해당하는 단계를 중요 랜더링 경로라고하며

간단하게 4단계로 나누어져있다 생각하고 이해하면 편할 것 같습니다

 

1) DOM Tree 구축을 위한 파싱

 -  HTML 문서를 파싱해서 Parse Tree를 생성하고 브라우저가 DOM node(태그)로 구성된 트리 DOM 을 생성하게 됩니다 

 -  HTML을 파싱하는 도중에 CSS 파싱 역시 실행됩니다

 - CSS 파서는 HTML과 달리 전체파일을 모두 다운로드 할때까지 시작할 수 없습니다

 - CSSOM(CSS Object Model)트리를 생성하게 되고

 

2) 랜더트리 생성

 - DOM Tree 가 완성되는 중간중간 Render Tree 가 배치되고 그려진다

 

3) 레이아웃 or 리플로우

- Render Tree 에서는 계산되지않았던 노드들의 크기와 위치 레이어간의 순서정보를 계산하여 화면의 왼쪽위 부터 좌표에 나타냄

 

 - 전역적 레이아웃과 증분적 레이아웃이 존재 

 전역적:

    화면 전체의 레이아웃 계산 새로운 폰트나  뷰포트 변경등 전체 레이아웃 다시계산 

    노드가 많아질수록 속도가 느려져 브라우저 자체적으로 더티 비트 시스템(처음부터 탐색하면서 레이아웃계산하는게아닌 특정부분만 표시 ,다시계산하여 재귀적인 작업시 리소스 최적화 )이 있다 

 

증분적 : 

    더티 비트 시스템을 활용함

    레이아웃의 변경이 발생하야하는 요소들을 만나면 스케줄러를 통해 비동기로 일괄작업을 진행하여 연산횟수 줄임

    복잡한 레이아웃의 경우 프론트 개발자도 연산을 최소화하거나 묶어서 사용하는 등 인지가 필요

 

4) 페인트 

 - Render Tree 탐색 후 render object의 paint 메소드 호출 

 

 

그렇다면 React의 사용이유에 대해 더 깊게 생각 해 볼수 있는 기회인 것 같습니다

이전 글에서 리액트같은 라이브러리를 쓰는 이유를 가상돔의 사용으로 동적인 페이지구성에 강하구나 였는데 

 

틀릴 수 도있지만 아래와 같이 이해하고 있습니다.

 

이제 기존에는 레이아웃 단계에서 전역적 , 증분적 레이아웃이 있었고 DOM 전체를 다시 그리다 보니 비용이 컷다 

그래서 브라우저에서 자체적으러 최적화 하기위해 더티비트시스템이라는 것을 통해 변경되는 부분을 마킹해서 재귀적인 작업 시 리소스를 줄였다

하지만 복잡한 레이아웃의 경우 프론트개발자가 연산을 최소화하거난 묶어서 최적화했고

추가적으로 가상돔이라는 기술로  DOM의 변경된 부분만 업데이트 할 수 있고

리액트의 특성으로 한 스코프 내의 상태 변경에 대해 일괄 처리하기에 연산횟수를 최소화할수있게 되었다

하지만 레이아웃 단계와 페인트 단계에서 변경되어야하는 사항이 많아져 Front-end 개발자는 적절한 컴포넌트 분리를 염두해야한다 

 

CPU 가 레이아웃을 처리하고 레이어를 업데이트 하는데 메인메모리에서 paint라는 과정으로 비디오 메모리로 전달을함 이후 GPU에서 Composite 레이어 작업이 실행됨 

CPU 보다 GPU의 연산능력이 비용이 적다 

따라서 랜더링 성능을 개선하려면 

레이아웃과 페인팅을 최소한으로 발생시키고 되도록이면 composite으로 대체한다 

레이어를 잘 분리하고 불필요한 레이어를 제거한다 

 

다음 글에서 랜더링 최적화에 대해 공부하겠습니다