- Today
- Total
빵 입니다.
Object Model 구성 본문
브라우저가 페이지를 렌더링하려면 DOM tree와 CSSOM tree가 필요하다.
결과적으로 우리는 가능한 빨리 브라우저에 HTML과 CSS를 전달해야 한다.
📌 TL;DR
- Bytes -> characters -> tokens -> nodes -> object model.
- HTML 마크업은 DOM으로 변환된다.
- CSS 는 CSSOM으로 변환된다.
- DOM, CSSOM은 독립적인 데이터 구조
- Chrome DevTools Timeline을 사용하면 DOM과 CSSOM의 구성과 처리 비용을 캡처하고 검사할 수 있다.
📌 Document Object Model (DOM)
<!DOCTYPE html>
<html>
<head>
<meta name="viewport" content="width=device-width,initial-scale=1" />
<link href="style.css" rel="stylesheet" />
<title>Critical Path</title>
</head>
<body>
<p>Hello <span>web performance</span> students!</p>
<div><img src="awesome-photo.jpg" /></div>
</body>
</html>약간의 텍스트와 이미지 하나가 있는 plain HTML이 있다.
브라우저는 이 페이지를 어떻게 처리 할까?
1. Bytes -> Characters (Conversion: 변환)
브라우저는 디스크나 네트워크에서 HTML의 원시 바이트(Bytes)를 읽고, 지정된 파일 인코딩(ex: UTF-8)에 기반한 개별 문자로 해석한다.
(= HTML 원시 바이트(Bytes)를 HTML 문서 내 정의된 인코딩(Encoding, UTF-8 등) 방식으로 문자 인코딩)
2. Characters -> Tokes (Tokenzing: 토큰화)
브라우저는 인코딩된 문자열을 <html>, <body>같은 꺽쇠 괄호 안의 문자열 같이 W3C HTML5 표준에 명시된 고유의 토큰으로 변환한다. 각 토큰에는 특별한 의미와 고유한 규칙이 있다.
(= 변환 과정에서 인코딩 된 문자열을 W3C 표준에 따라 고유 토큰으로 변환)
3. Tokens -> Nodes (Lexing)
토큰은 속성과 규칙을 정의하는 Node 객체로 변환된다.
* 렉싱 : 토큰을 분리하고, 각각의 토큰에 의미를 부여하는 작업
(= 토큰을 해당 속성 및 규칙을 정의하는 객체(node)로 변환)
4. DOM tree 생성
마지막으로 HTML 마크업은 서로 다른 태그 간의 관계를 정의한다. (일부 태그는 다른 태그 내에 포함)
생성된 객체는 원래 마크업에 정의된 상-하위 관계도 캡처하고, 트리 데이터 구조에 연결된다.
HTML 객체는 body 객체의 부모이고, body 객체는 paragraph 객체의 부모이다.
(= 렉싱 과정을 통해 생성된 노드를 트리 구조로 변환)
* 위 과정은 파싱 이라고 한다.
전체 프로세스의 최종 output은 브라우저가 페이지의 모든 프로세스에 사용하는 간단한 페이지의 Document Object Model (DOM)이다.
브라우저가 HTML 마크업을 처리할 때마다, 위의 모든 단계를 거친다.
문자 인코딩, 토큰 식별, 토큰을 노드로 변환, DOM tree 생성까지!
전체 프로세스는 시간이 걸릴 수도 있다. 특히 처리할 HTML의 양이 많을 수록.
Chrome DevTools를 열고 페이지가 로드되는 동안 Timeline을 기록하면, 각 단계를 수행하는 데 걸리는 실제 시간을 볼 수 있다.
위의 예시 화면을 보면 HTLM 코드를 DOM tree로 변환하는데 ~0.5ms가 걸렸다.
더 큰 페이지의 경우 이 프로세스가 훨씬 더 오래 걸릴 수 있다.
브라우저가 많은 양의 HTML을 처리해야 하는 경우 이건 쉽게 병목 현상이 될 수 있다.
DOM tree는 document 마크업의 속성과 관게를 캡처한다. 그러나 요소가 렌더링될 때 어떻게 보일지는 알려주지 않는다.
어떻게 보일지 알려주는 것 CSSOM의 몫이다.
📌 CSS Object Model (CSSOM)
브라우저가 간단한 페이지의 DOM을 생성하는 동안, document의 head 섹션에서 외부 CSS 스타일시트(style.css)를 참조하는 link 태그를 마주쳤다. 페이지가 렌더린되는 데 아래의 리소스가 필요하다고 예상하면 즉시 이 리소스에 대한 요청을 전달하고 다음 콘텐츠와 함께 반환된다.
body {
font-size: 16px;
}
p {
font-weight: bold;
}
span {
color: red;
}
p span {
display: none;
}
img {
float: right;
}
HTML 마크업에 인라인으로 직접 스타일을 선언할 수 있었다. 그러나 CSS를 HTML으로부터 독립적으로 유지하면 콘텐츠와 디자인을 별개로 다룰 수 있다.
디자이너는 CSS를 사용하여 작업하고, 개발자는 HTML을 사용하여 작업할 수 있다.
HTML과 마찬가지로 읽어온 CSS 규칙을 브라우저가 이해하고 작업할 수 있는 무언가로 변환해야 한다.
HTML 프로세스를 반복하지만, CSS의 경우엔…
CSS Bytes는 문자열로, tokes로, nodes로 변환된다.
마지막엔 CSS Object Model (CSSOM)이라고 불리는 트리 구조에 연결된다.
* 위 과정은 파싱 이라고 한다.
CSSOM이 트리구조를 갖는 이유는?
페이지의 개체에 대한 최종 스타일 집합을 계산할 때, 브라우저는 해당 노드에 적용할 수 있는 가장 일반적인 규칙으로 시작한다. (ex: body 요소의 자식요소라면, body 요소의 모든 스타일이 적용된다; 상속받는다.)
(노드에 포함될수록, 하위에서) 더 구체적인 규칙을 적용함으로써 계산된 스타일을 재귀적으로 스타일을 필터링한다. 즉, 규칙이 “아래로 상속”된다.
body 요소에 포함된 <span> 태그 내에 포함된 모든 텍스트는 폰트 크기 16px에 빨간색이고, 폰트 크기 지시문은 body 요소에서 span으로 상속되었다.
그러나 p태그의 자식요소인 span 태그의 경우, 상속되지 않았다.
또한, 위의 트리는 완전한 CSSOM tree가 아니고, 스타일시트에서 재정의한 스타일만 보여준다.
모든 브라우저는 “user agent styles”라고 하는 기본 스타일셋을 제공한다.
“user agent styles”는 우리가 스타일을 정의하지 않았을 때, 우리가 사용하는 것이다.
우리가 따로 스타일을 정의한다면, 기본값은 무시된다.
CSS 처리 시간을 알아보려면 Chrome DevTools에서 Timeline을 기록하고, “Recalculate Style” 이벤트를 찾으면 된다.
DOM 파싱과 달리 Timeline에는 별도의 “Parse CSS” 항목이 표시되지 않고, 대신 구문 분석 및 CSSOM tree 구성, 하나의 이벤트 아래에서 계산된 스타일의 재귀적 계산을 캡처한다.
위 이미지를 보면, 사소한 스타일시트를 처리하는데 0.6ms까지 걸리고, 페이지 8개에 영향을 미친다. 적은 양이지만 시간이 소요된다. 8가지 요소는? CSSOM과 DOM은 독립적인 데이터 구조이기 때문에!
+ 파싱 이란
컴퓨터에서 컴파일러 또는 번역기가 원시 부호를 기계어로 번역하는 과정의 한 단계로, 각 문장의 문법적인 구성 또는 구문을 분석하는 과정. 즉 원시 프로그램에서 나타난 토큰(token)의 열을 받아들여 이를 그 언어의 문법에 맞게 구문 분석 트리(parse tree)로 구성해 내는 일이다. 파싱은 크게 하향식 파싱과 상향식 파싱으로 나눌 수 있다.
[출처] 네이버 지식백과
🫰🏻 참고 🫰🏻
https://web.dev/critical-rendering-path-constructing-the-object-model/
'브라우저' 카테고리의 다른 글
| Render Tree 구성, Reflow, Paint(Repaint) (0) | 2022.07.26 |
|---|
