브라우저 동작 원리(쉽게 알아보기) - Main flow/CSSOM/렌더 트리(4)

이 글은 이스라엘 개발자 탈리 가르시엘(Tali Garsiel)이 html5rocks.com에 게시한

"How Browsers Work: Behind the scenes of modern web browsers"를 인용하고 있습니다.

아무것도 모르는 초보자의 시선에서

하나하나 모르는 용어는 용어대로 찾아가면서

정리해보는 글입니다.

 

저와같이 아무것도 모르는 초보자를 기준으로 글을 작성했습니다.

 

부디 이 글에 마지막에는

글을 쓰고 있는 저도, 독자도 어렴풋이라도

브라우저가 어떻게 동작하는지 이해할 수 있었으면 좋겠습니다. 🙏

 

이 글은 브라우저 동작 원리 4편입니다.

다른 편은 아래 링크나 블로그에서 참조해주세요!

• 브라우저 동작 원리 1편
• 브라우저 동작 원리 2편
• 브라우저 동작 원리 3편

 

---

The main flow(메인 흐름)

---

전문

The rendering engine will start getting the contents of the requested document from the networking layer. This will usually be done in 8kB chunks.

After that, this is the basic flow of the rendering engine:

Figure : Rendering engine basic flow

The rendering engine will start parsing the HTML document and convert elements to DOM nodes in a tree called the "content tree". The engine will parse the style data, both in external CSS files and in style elements. Styling information together with visual instructions in the HTML will be used to create another tree: the render tree.

The render tree contains rectangles with visual attributes like color and dimensions. The rectangles are in the right order to be displayed on the screen.

After the construction of the render tree it goes through a "layout" process. This means giving each node the exact coordinates where it should appear on the screen. The next stage is painting–the render tree will be traversed and each node will be painted using the UI backend layer.

It's important to understand that this is a gradual process. For better user experience, the rendering engine will try to display contents on the screen as soon as possible. It will not wait until all HTML is parsed before starting to build and layout the render tree. Parts of the content will be parsed and displayed, while the process continues with the rest of the contents that keeps coming from the network.

Main flow examples

Figure : WebKit main flow

Figure : Mozilla's Gecko rendering engine main flow (3.6)

From figures 3 and 4 you can see that although WebKit and Gecko use slightly different terminology, the flow is basically the same.

Gecko calls the tree of visually formatted elements a "Frame tree". Each element is a frame. WebKit uses the term "Render Tree" and it consists of "Render Objects". WebKit uses the term "layout" for the placing of elements, while Gecko calls it "Reflow". "Attachment" is WebKit's term for connecting DOM nodes and visual information to create the render tree. A minor non-semantic difference is that Gecko has an extra layer between the HTML and the DOM tree. It is called the "content sink" and is a factory for making DOM elements. We will talk about each part of the flow:

The rendering engine will start getting the contents of the requested document from the networking layer. This will usually be done in 8kB chunks.

After that, this is the basic flow of the rendering engine:

Figure : Rendering engine basic flow

The rendering engine will start parsing the HTML document and convert elements to DOM nodes in a tree called the "content tree". The engine will parse the style data, both in external CSS files and in style elements. Styling information together with visual instructions in the HTML will be used to create another tree: the render tree.

The render tree contains rectangles with visual attributes like color and dimensions. The rectangles are in the right order to be displayed on the screen.

After the construction of the render tree it goes through a "layout" process. This means giving each node the exact coordinates where it should appear on the screen. The next stage is painting–the render tree will be traversed and each node will be painted using the UI backend layer.

It's important to understand that this is a gradual process. For better user experience, the rendering engine will try to display contents on the screen as soon as possible. It will not wait until all HTML is parsed before starting to build and layout the render tree. Parts of the content will be parsed and displayed, while the process continues with the rest of the contents that keeps coming from the network.

Main flow examples

Figure : WebKit main flow

Figure : Mozilla's Gecko rendering engine main flow (3.6)

From figures 3 and 4 you can see that although WebKit and Gecko use slightly different terminology, the flow is basically the same.

Gecko calls the tree of visually formatted elements a "Frame tree". Each element is a frame. WebKit uses the term "Render Tree" and it consists of "Render Objects". WebKit uses the term "layout" for the placing of elements, while Gecko calls it "Reflow". "Attachment" is WebKit's term for connecting DOM nodes and visual information to create the render tree. A minor non-semantic difference is that Gecko has an extra layer between the HTML and the DOM tree. It is called the "content sink" and is a factory for making DOM elements. We will talk about each part of the flow:

저번 글에서 메인 흐름을 설명하다 DOM과 노드, 트리에 대해 설명하였습니다.

이번 시간에는 이어서 뒷부분의 내용을 해석하고

모르는 개념에 대해 짚고 넘어가겠습니다.

 

 

렌더링 엔진의 기본 흐름

렌더링 엔진은 HTML 문서에 대한 파싱을 시작합니다.

즉, 요청한 문서에 대해서 원하는 정보를 추출하고 가공하는 작업을 시작합니다.

이후 '콘텐츠 트리'라고 불리는 트리안에서 HTML 문서는 DOM 노드로 전환됩니다.

 

렌더링 엔진은 외부 CSS 파일과 스타일 요소를 파싱합니다.
스타일 정보와 HTML의 시각적 요소들은
'렌더트리'라고 하는또 다른 트리를 생성합니다.

 

렌더트리는 무엇일까요?
렌더트리는 색상이나 면적과 같은 시각적 속성이 있는 사각형을 포함합니다.
이 사각형은 순서대로 화면에 표시됩니다.

 

쉽게 말해,

HTML 문서에 대한 파싱이 시작되면 DOM이 생성되고,
이러한 DOM에 CSS 정보,
즉 스타일 정보를 포함하여 만든 트리가 '렌더 트리'입니다.

 

DOM에 CSS 정보를 포함하여 만든 트리를 'CSSOM'이라 하고,
DOM과 CSSOM을 합한 것이 '렌더 트리'입니다.

 

렌더 트리를 만든 후에는 '레이아웃' 프로세스를 거칩니다.
이 프로세스는 각 노드가 화면에 나타나야 하는 정확한 위치를 찾는 것입니다.

 

다음 단계는 '페인팅'입니다.
렌더 트리가 탐색되고 각 노드는 UI Backend layer를 통해 페인팅 됩니다.

 

이러한 단계는 '점진적 과정'이라는 것이 중요합니다.
더 나은 '사용자 경험(User Experience)'을 위해서,

렌더링 엔진은 가능한 빨리 화면에 콘텐츠를 띄우려 합니다.

 

이런한 단계는, 예를 들어, 모든 HTML을 파싱하려고 기다리지 않고,
콘텐츠의 일부를 파싱하고 표시합니다.
이는 네트워크로부터 남은 내용이 전달되기를 기다리면서,
동시에 전달 받은 내용을 먼저 화면에 표시한다는 얘기입니다.

 

 

이러한 메인 흐름을 정리하면 다음과 같습니다.

1. HTML 문서를 파싱하고 DOM 트리를 만듭니다.
2. CSS 문서를 파싱하고 CSSOM 트리를 만듭니다.
3. DOM과 CSSOM을 합해서 렌더 트리를 만듭니다.
4. 레이아웃 프로세스를 통해 노드가 화면에 나타나야 하는 정확한 위치를 탐색합니다.
5. UI Backend layer를 통해 각 노드를 화면에 그립니다.
6. 일련의 과정은 점진적으로 진행됩니다.

 

 

Main flow examples(메인 흐름의 예)

---

전문

Figure : WebKit main flow

Figure : Mozilla's Gecko rendering engine main flow (3.6)

From figures 3 and 4 you can see that although WebKit and Gecko use slightly different terminology, the flow is basically the same.

Gecko calls the tree of visually formatted elements a "Frame tree". Each element is a frame. WebKit uses the term "Render Tree" and it consists of "Render Objects". WebKit uses the term "layout" for the placing of elements, while Gecko calls it "Reflow". "Attachment" is WebKit's term for connecting DOM nodes and visual information to create the render tree. A minor non-semantic difference is that Gecko has an extra layer between the HTML and the DOM tree. It is called the "content sink" and is a factory for making DOM elements. We will talk about each part of the flow:

웹킷의 메인흐름

 

Mozilla의 Gecko 렌더링 엔진 메인흐름

Gecko에서는 DOM트리와 CSSOM을 결합한 요소를 'Frame Tree'라고 말합니다.

또한 각 요소를 'Frame'이라고 부릅니다.

 

Webkit은 앞서 언급드렸던 것처럼 'Render Tree'라는 용어를 사용하고,

렌더 트리는 'Render Objects'로 구성되어 있습니다.

 

Webkit은 요소를 배치하는데 'layout'이라는 용어를 사용하는데 반해

Gecko는 'Reflow'라는 용어를 사용합니다.

 

'Attachment'는 Webkit의 용어인데, DOM 트리와 CSSOM을 결합할 때 사용합니다.

 

Webkit과 Gecko에는 큰 의미없는 사소한 차이점이 존재하는데,

Gecko는 HTML과 DOM 트리 사이에 추가적인 layer가 존재하고,

이를 'Content Sink'라고 부릅니다.

Content Sink는 DOM 요소를 생성하는 과정을 말합니다.

 

 

 

Parsing–general(일반적인 파싱)

---

전문

Since parsing is a very significant process within the rendering engine, we will go into it a little more deeply. Let's begin with a little introduction about parsing.

Parsing a document means translating it to a structure the code can use. The result of parsing is usually a tree of nodes that represent the structure of the document. This is called a parse tree or a syntax tree.

For example, parsing the expression 2 + 3 - 1 could return this tree:

Figure : mathematical expression tree node

파싱은 렌더링 엔진에서 매우 중요한 과정입니다

문서 파싱은 브라우저가 사용할 수 있는 구조의 코드로 변환하는 것을 의미합니다.

파싱의 결과는 보통 문서의 구조를 나타내는 노드 트리의 형태입니다.

이러한 노드 트리를 우리는 'parse tree'나 'syntax tree'라 부릅니다.

 

예를 들어, '2+3-1'이라는 표현은 다음과 같은 트리를 생성합니다.

수학적 노드 트리

 

 

 

 

Grammars(문법)

---

전문

Parsing is based on the syntax rules the document obeys: the language or format it was written in. Every format you can parse must have deterministic grammar consisting of vocabulary and syntax rules. It is called a context free grammar. Human languages are not such languages and therefore cannot be parsed with conventional parsing techniques.

 

파싱은 문서가 지키는 구문 규칙을 기반으로 합니다.(문서가 작성된 언어 또는 형식)

파싱할 수 있는 모든 형식은 반드시 어휘 및 구문 규칙으로 작성된 결정론적 문법이 있어야 합니다.

 

쉽게 말해, 파싱을 하기 위해서는 반드시 어휘 및 구문에 관한 문법이 있어야 한다는 의미입니다.

이를 'Context Free Grammar(문맥 자유 문법)'이라 부릅니다.

 

인간의 언어는 이런 문법과 체계가 다르기 때문에 기계적인 파싱이 불가능합니다.

 

---

오늘은 Main flow와 CSSOM, 렌더 트리와

기본적인 브라우저 동작 원리에 대해 학습해 봤는데요,

다음 글에서는 'Parser-Lexer combination'에

관한 내용 부터 설명하도록 하겠습니다.