웹 페이지가 브라우저에 로드되고 화면에 렌더링되는 과정인 중요 렌더링 경로(Critical Rendering Path) 개념은 굉장히 중요합니다. 웹 프론트엔드 개발자의 개발은 결국 이 구조 위에서 일어나는 변화일 뿐이니까 말입니다. (참고로 이러한 설명들은 브라우저를 만드는 구글의 설명이 가장 정확합니다. 인터넷에 돌아다니는 글들도 거의 그 글을 시작으로 해석을 덧붙인 겁니다.)

I have a DOM Tree… https://web.dev/howbrowserswork/

위 그림은 복잡해보이지만 결국 핵심은 HTML과 CSS로부터 문서의 구조와 스타일을 읽어온 뒤, 하나의 화면으로 그려내는 과정입니다.

HTML과 CSS 파일은 그 자체로는 그냥 문자열일 뿐입니다. 브라우저는 이 문서들을 파서(Parser)로 읽어와 의미 단위로 토큰화(Tokenization)합니다. 그리고 각각 DOM(Document Object Model)과 CSSOM(Cascading Style Sheet Object Model)으로 만듭니다.

그 다음 단계에서는 이 두 트리를 합쳐 실제 화면을 그리기 위한 정보인 렌더 트리(Render Tree)로 변환합니다. 렌더 트리에는 시각적으로 보이는 요소들만 포함됩니다. 예를 들어 head, script, display: none인 요소들은 제외됩니다.

그 후, 브라우저는 렌더 트리를 기반으로 각 요소가 위치할 자리를 계산(Layout)하고, 화면을 그립니다(Painting). 중간중간 렌더 트리에 변화가 생기면 그 변화의 범위에 따라 요소가 그려질 범위를 다시 계산하거나, 화면에 그립니다.

왼쪽은 DOM 트리, 오른쪽이 Render 트리 (https://web.dev/howbrowserswork/)

이 때 앞서 언급한 레이아웃과 페인팅은 여러 레이어로 나뉘어 작업이 이뤄지므로(쌓임 맥락, Stacking Context ex. z-index) 최종적으로 하나의 결과물로 합치는 과정이 필요합니다. 레이어 간 순서를 따져 하나의 화면으로 합성(Composite)하면 모든 과정이 마무리 됩니다.

현재 강의를 작성 중인 노션 페이지를 개발자 도구의 [Layers] 기능을 사용하여 살펴보았습니다

여기까지의 과정은 매우 중요하므로(프론트엔드 개발자들 밥줄임…) 머릿속에 꼭 잘 담아둬야겠습니다.

이해에 도움이 될 것 같아 동영상을 하나 가져왔습니다. 아래 동영상은 화면을 다시 그리는 Layout 과정을 시각화 한 것입니다.

좌측 상단에서 하나의 요소를 완성시키고 알맞은 위치로 이동시키는 작업을 반복하는데, 트리 구조에서 하위 노드를 가진 하나의 노드가 렌더링 되는 과정을 상상해보면 이해하기 좋을 것 같습니다.

https://www.youtube.com/watch?v=9-ezi9pzdj0

여기까지 기본 동작에 대해 알아보았는데요. 굉장히 중요한 사실을 하나 말씀드리겠습니다.

<aside> 💡 브라우저는 변경이 일어난 범위나 속성에 따라 새로 그리는 범위가 달라집니다.

</aside>

앞서 화면을 렌더링 하는 단계를 일종의 파이프라인처럼 순서에 따라 일어나는 것으로 표현했습니다. 모두가 아실 법한 하노이 탑으로 간단한 예시를 들어보겠습니다.

https://ko.khanacademy.org/computing/computer-science/algorithms/towers-of-hanoi/a/towers-of-hanoi

‘하노이 탑’은 A에 쌓여 있는 원반을 한번에 하나씩만 옮겨 최종 목표인 C까지 모두 옮기는 게임입니다. 게임 초반 가장 위에 꽃혀 있는 1번 원반을 옮기는 것은 쉽습니다. 1번 위에 있는 원반은 아무 것도 없으니 다른 원반들에 영향을 주지 않기 때문이죠.

하지만 5번 원반은 어떤가요? 위에 1~4번 원반이 모두 올라가 있기 때문에 5번을 옮기려면 다른 원반들 또한 모두 움직여야 합니다.