2021.05.30, Max Kim

브라우저의 동작 과정과, 브라우저의 동작 과정상의 최적화 방법을 소개합니다.

<aside> 🌍 chrome의 webkit 렌더링 엔진 기준으로 설명합니당. 욕심으로는 JS단에서의 최적화도 설명하고 싶었지만 뭔가 브라우저라는 주제에서는 벗어나는 것 같아 화면 요소 최적화를 통해 브라우저의 부하를 줄이는 방법에 대해서 중점적으로 설명해봤습니다.

</aside>

HTML Critical Rendering Path

HTML을 받은 직후에 브라우저가 취하는 동작입니다.

1. HTML 문서 파싱과 해석

• 렌더링 엔진은 HTML 문서를 파싱하고, 콘텐츠 트리 내부에서 태그들을 DOM 노드로 변환한다. 그 다음 외부 CSS파일과 함께 포함된 스타일 요소도 파싱하여 CSSOM 트리를 만든다. 트리 두개를 각각 따로 만듬

• HTML 파싱 과정

  

  • 변환 : 브라우저가 HTML의 원시 바이트를 디스크나 네트워크에서 읽어와서, 해당 파일에 대해 지정된 인코딩(UTF-8)에 따라 개별 문자로 변환
  • 토큰화 : 브라우저가 문자열을 고유 토큰으로 변환. 태그들의 존재를 파악해냄
    • status machine과 같은 알고리즘 사용 : < 를 만나면 태그 열림, 그다음에 문자를 만나면 StartTag 토큰을 생성하고, >를 만나면 닫힘...
  • 렉싱 : 방출된 토큰은 해당 속성 및 규칙을 정의하는 객체로 변환
  • DOM 생성 : 입력 값은 토큰화되어 만들어지는 일련의 토큰. 계층의 순서대로 파싱이 되기 때문에 토큰을 하나 평가할때마다 계층구조를 인식하여 트리를 생성. (초기 → html 이전 → head 이전 → head 내부 → head 다음 → body 내부 → body 다음....)

• HTML 파싱

  • 파싱 프로세스의 최종 결과물이 바로 페이지의 DOM이며, 브라우저는 이후 모든 페이지 처리에 이 DOM을 사용함.
  • 브라우저는 HTML의 마크업을 처리할 때마다 위의 모든 단계를 수행함. 저렴한 연산은 아니고, 처리해야할 HTML이 많은 경우 시간이 꽤 걸릴 수 있음.
  • JS 등으로 마크업을 변화시킬때도 파싱 과정을 처음부터 다시 수행함 : 매끄러운 애니메이션을 만드려고 시도하는 경우, 브라우저가 대량의 HTML을 처리해야 한다면 쉽게 병목이 발생할 수 있음
  • DOM은 문서 마크업의 속성 및 관계를 포함하지만 요소가 렌더링될 때 어떻게 표시될지는 알려주지 않음. 이것은 CSSOM의 책임

• CSSOM 파싱

  • HTML이 아닌 CSS에 대해서도 비슷한 파싱 프로세스를 반복하여 트리를 만듬
  • CSSOM도 똑같이 트리구조를 가지는데, 페이지에 있는 객체의 최종 스타일을 계산할 때 브라우저는 해당 노드에 적용 가능한 가장 일반적인 규칙(하위 태그에도 적용되는 넓은 범위의 스타일 규칙)으로 시작한 후 더 구체적인 규칙을 적용하는 방식으로, 즉 하향식으로 규칙을 적용하는 방식으로 계산된 스타일을 재귀적으로 세분화

2. Render Tree 생성

• 먼저 브라우저가 DOM과 CSSOM을 렌더링 트리에 결합. 이 트리는 페이지에 표시되는 모든 DOM 콘텐츠와 각 노드에 대한 모든 CSSOM 스타일 정보를 캡처
• 렌더링 트리 생성 과정
  • DOM트리의 루트에서 시작하여 표시되는 노드 각각을 평가 : 표시되지 않는 노드들(메타태그같은) 생략, CSS를 통해 숨겨지는(display:none) 노드 생략(visibility: hidden과의 차이) ⇒ CSS를 실질적으로 고려하기 시작함 - 렌더링 되는 노드들은 DOM 요소에 있기는 하지만 렌더트리와 돔트리는 1:1로 대응하는 관계는 아님을 알 수 있다.
  • 표시된 각 노드에 대해 적절하게 일치하는 CSSOM 규칙을 찾아 적용 : 비슷한 트리를 만들었으니 찾는 것도 쉬움
  • 표시된 노드를 콘텐츠 및 계산된 스타일과 함께 내보냄