FE가 알아야 할 브라우저 렌더링 과정 (왜 transform 속성이 유리할까?)

 

브라우저 렌더링 과정-1

의외로 신입이 모르는 것! - 브라우저 렌더링 과정

앞서 전체적인 브라우저 렌더링 과정에 대해서는 간단하게 살펴보았다.

그렇다면 서버 쪽은 잠시 두고, 프론트엔드 개발자로써 알아야 할 브라우저 렌더링 과정에 대해서 이해를 해보자!

 

( 파이어폭스, 사파리, 크롬 각 브라우저 마다 조금씩 차이가 있을 수 있어서 이번에는 Chrome에 국한 된 포스팅을 하고자 한다 )

 

1. 브라우저의 구조

우선 브라우저의 구조에 대해서 전체적으로 살펴보자!

"브라우저 구조" 라고 검색해보면 수 없이 많이 나오는 이미지들 중 하나이다.

각각은 어떤 파트를 담당할까?

• User Interface : 요청 한 페이지를 보여주는 창을 제외한 나머지 모든 부분 ( ex. 주소 표시줄, 이전/다음/새로고침 버튼, 북마크 등 )
• Browser Engine : User Interface와 Rendering Engine을 연결하는 부분
• Rendering Engine : HTML, CSS를 파싱하여 요청한 웹페이지를 표시하는 부분
• Networking : HTTP 요청과 같은 각종 네트워크 요청을 수행하는 부분
• Javascript Interpreter(or Engine) : JS 코드를 해석하고 실행하는 인터프리터 ( 크롬의 경우 V8 엔진 사용)
• Display Backend : 체크박스, 버튼 등 기본적인 위젯을 그려주는 UI 백엔드 파트
• Data Persistance : localStrage나 Cooki 같은 보조기억 장치에 데이터를 저장하는 부분

 

2. 렌더링 엔진

각 웹 브라우저마다 다른 렌더링 엔진을 가지고 있다.

브라우저	렌더링 엔진
Chrome	Blink
Safari	Webkit
FireFox	Gecko
Edge	EdgeHTML, Blink

그러다보니 같은 소스가 브라우저마다 다르게 그려지는 크로스 브라우징 이슈(Cross browsing issue)가 발생하게 되는 경우가 있다.

 

이러한 Rendering Engine의 역할(목표)는 무엇일까? 

크게 두 가지로 구분 할 수 있을 것이다.

1. 웹 페이지에 포함 된 모든 요소들을 화면에 보여줘야 한다.
2. 업데이트가 필요한 경우, 효율적으로 렌더링 할 수 있도록 자료구조를 생성한다. ( *업데이트 : 스크롤, 애니메이션, 비동기 요청으로 인한 데이터 로딩 등 )

Rendering Engine은 이러한 목표를 가지고 있기 때문에 아래와 같은 동작을 거치게 되는데 이를 Critical Rendering Path 라고 한다.

 

3. Critical Rendering Path

우선 전체적인 흐름을 보자면 아래와 같다.

1. 변환(Conversion) : 브라우저에서 사용자가 요청한 페이지의 HTML 원시 바이트(raw bites)를 읽어와 파싱하고, 해당 파일에 지정 된 인코딩(UTF-8 등)에 따라 문자열로 변환한다.
2. 토큰화(Tokenizing) : 파싱 한 문자열을 HTML5 표준에 지정된 고유 토큰으로 변환한다.
3. 렉싱(Lexing) : 토큰을 해당 속성 및 규칙을 정의한 객체(Nodes)로 변환한다.
4. DOME 생성( Dom construction ) : 각 노드가 서로 연관성을 가질 수 있도록 트리를 생성하는데 이를 Dom Tree 라고 한다.

3-1. CSSOM 생성 (CSS Object Model)

DOM Tree를 만들듯이 CSSOM Tree 또한 생성된다.

CSSOM은 DOM이 화면에 어떻게 표시될지 알려주는 역할을 한다.

브라우저는 DOM을 생성하는 동안 외부 CSS를 참조하는 < link > 태그를 만나게 됨녀 브라우저에 리소스를 요청한다.

CSS 원시 바이트(Raw bytes)가 문자열로 변환 된 후 차례로 토큰과 노드로 변환 되고, 마지막으로 CSSOM Tree를 만든다.

 

CSSOM이 Tree 구조를 가지는 이유는 바로 하향식으로 규칙을 적용하기 때문이다.

위의 CSSOM tree를 보면 body tag 안에 있는 span 태그의 font-size는 16px, color는 red 이다.

그러나 p tag 하위인 span tag는 display: none으로 콘텐츠를 표시하지 않는다.

 

이렇게 DOM tree와 CSSOM tree를 합쳐서 결국 Render Tree를 만들게 되는 것이다.

즉, Render tree는 화면에 표시되어야 하는 모든 노드의 컨텐츠, 스타일 정보를 포함하는 트리라고 할 수 있다.

( 이 때 meta tag, display: none 과 같은 것은 렌더와 관계가 없으므로 Render Tree에 포함시키지 않는다)

 

4. Layout

Render Tree가 만들어진 후에는 Layout 혹은 Reflow 라고 불리는 순서를 거치게 된다.

뷰포트 내에서 요소(Render Tree의 Nodes)들의 정확한 위치와 크기를 계산하는 과정이다.

텍스트나 요소 의 박스가 화면에서 차지하는 영역이나 여백, 그리고 스타일 속성 등이 계산 된다.

만약 em, % 등의 상대적인 값을 사용 한 경우, 뷰포트에 맞춰서 px(픽셀) 단위로 변환된다.

 

5. Paint

Browser Rendering의 마지막 과정으로 Painting(혹은 Rasterizing)을 하게 된다.

즉, 실제로 그리게 되는 것이다.

Render Tree에 포함 된 텍스트, 이미지 등이 실제 픽셀로 나타나게 되는 것이다.

선, 면 등 도형 요소로 구성되는 벡터 그래픽스를 작은 점의 집합으로 표현하는 비트맵 그래픽스로 변환하는 일을 하는 것이다.

이러한 과정을 거쳐서 브라우저 화면에 UI가 나타나게 되는 것이다.

 

---

우리가 겪을 수 있는 UI가 업데이트 되는 상황들이 있다.

 

1. 다시 Layout이 발생하는 경우!

주로 요소의 크기나 위치가 바뀔 때, 혹은 브라우저 창의 크기가 바뀌었을 때 등의 경우 다시 layout이 발생한다.

이 때 Layout 수치를 다시 계산해서 재배치 해야하기 때문에 또 다시 Layout을 거치고, paint를 거쳐서 마지막으로 레이어를 합성하는 과정까지 거쳐야 한다.

 

2. Paint부터 다시 발생 되는 경우!

주로 배경 이미지나 텍스트 색상, 그림자 등 Layout의 수치를 변화시키지 않는 스타일의 변경이 일어났을 때 발생한다.

Layout이 변경 된 것이 아니므로 성능상 이 점을 가지게 된다!

 

3. 레이어의 합성만 다시 발생하는 경우!

레이어는 포토샵의 레이어를 떠올리면 좋다.

쉽게 말해, painting  할 영역을 나눠놓은 것을 의미 한다.

Chrome의 경우, Layout 과정 이후에 정해진 기준이나 필요에 의해서 브라우저가 레이어를 생성한다.

그리고 Render tree에 있는 노드 객체들은 생성 된 레이어에 포함 되게 된다.

 

레이어들은 트리형태로 구성이되며, 렌더링 엔진이 각 레이어를 painting 과정에서 각각 그려준 다음 하나의 비트맵으로 합성(Rasterizing)하여 페이지를 완성하게 된다.

이런 경우 Layout, Painting을 수행하지 않고 레이어 합성만 발생하므로 성능상 가장 큰 이점을 가진다.

 

---

그렇다면 왜 애니메이션을 이용 할 때 transform을 이용하는 것이 유리할까?

사실 초반에 웹프로그래밍을 배울 때는 이런 것은 특별히 생각해보지 않았을 것이다.

우선 구현을 해보고 어떤 기능인지 배우는 것이 우선이었으므로 나 또한 특별히 생각해보지 않았다.

그러나 위와 같은 이러한 브라우저 렌더링에 대해서 알게 된다면 이제 왜 transform을 이용해야하는지 이해가 될 것이다.

 

물론 position을 사용해도 애니메이션은 작동한다!

하지만 개발자 모드에서 performance를 눌러서 확대해보면 Layout, painting, composite까지 매 프레임마다 이런 과정을 계속해서 거쳐야할 것이다.

하지만 transform 속성을 이용하게 되면 composite만 거치면 된다!

즉, 끊김이 덜하고 더 부드러운 애니메이션이 가능하도록 성능이 최적화 된다고 할 수 있다.

 

아래의 사이트를 참고해서 각 브라우저 엔진마다 적용 되는 속성들을 확인해보면 도움이 될 것이다!

CSS Triggers