{intro}
<Spacing size="lg" />

## 주요 렌더링 경로란?
 
주요 렌더링 경로(CRP, Critical Rendering Path)는 브라우저가 HTML, CSS, 자바스크립트를 픽셀 데이터로 변경하여 화면을 그려내는 일련의 단계, 즉 **브라우저가 서버로부터 전달받은 데이터를 화면에 그려내는 과정**을 의미합니다.
 
참고로 MDN은 중요 렌더링 경로로 번역되어 있는데, 다른 책들을 보면 주요 렌더링 경로라고 하더라고요. 주요 렌더링 경로가 더 적절한 표현이라고 생각되어 저도 주요 렌더링 경로라고 하겠습니다.
 
## 주요 렌더링 경로 알아보기
 
그럼 주요 렌더링 경로 단계를 자세히 살펴보겠습니다.
 
<PostImage src="https://res.cloudinary.com/yun-log/image/upload/v1738486631/19.CRP/sz9pygr42p7ozroisjsh.png" alt="주요 렌더링 경로 Tree" caption="주요 렌더링 경로 단계" width="1097" height="80"/>
 
브라우저가 화면을 렌더링 할 때 요청/응답, 로딩, 스크립팅, 렌더링, 레이아웃, 페인팅 단계를 거칩니다.
 
### 1. 요청 / 응답 (Request / Response)
 
브라우저가 요청을 보내면 서버가 HTML 데이터를 응답합니다.
 
### 2. 로딩 (Loading)
 
<PostImage src="https://res.cloudinary.com/yun-log/image/upload/v1738486642/19.CRP/mwh4jpcgw3bxndfkm3sw.jpg" alt="DOM Tree" caption="HTML을 파싱하여 생성된 DOM Tree \n 이미지 출처 : https://developer.mozilla.org/ko/docs/Web/Performance/How_browsers_work" width="754" height="689"/>
 
- 브라우저가 HTML을 파싱하여 DOM Tree를 생성합니다. 이때 파싱은 HTML과 같은 데이터를 브라우저가 이해할 수 있는 객체(DOM)로 변환하는 작업을 의미합니다.
- HTML 파싱 중에 발견된 CSS, 자바스크립트, 이미지 등 외부 자원을 요청합니다.
- CSS 파일을 파싱하면서 DOM과 CSS를 결합한 CSSOM(CSS Object Model)을 생성합니다.
- 이 때 CSS, 자바스크립트를 파싱하기 위해 HTML 파일 파싱이 중단됩니다. CSS, 자바스크립트 파싱이 완료된 후 HTML 파싱이 재개됩니다.
 
### 3. 스크립팅 (Scripting)
 
자바스크립트를 파싱하는 단계로, 자바스크립트가 DOM과 스타일을 변경할 수 있기 때문에 자바스크립트 파싱과 실행이 완료되기 전까지 HTML 파싱이 중단됩니다.
 
### 4. 렌더링 (Rendering)
 
<PostImage src="https://res.cloudinary.com/yun-log/image/upload/v1738489533/19.CRP/gumwiwtfwlps4hd65mlv.jpg" alt="Render Tree" caption="DOM과 CSSOM이 결합하여 생성된 Render Tree \n 이미지 출처 : https://web.dev/articles/critical-rendering-path/render-tree-construction?hl=ko" width="1150" height="537"/>
 
DOM과 CSSOM을 결합하여 화면에 렌더링 될 Render Tree를 생성합니다. 이때 Render Tree는 **최종적으로 화면에 보이는 요소만을 포함**합니다. HTML의 HEAD 태그, CSS에서 display:none이 적용된 요소와 같이 화면에 보이지 않는 요소는 Render Tree에 포함되지 않습니다.
 
### 5. 레이아웃 (Layout)
 
Render Tree의 요소들이 페이지에서 배치되는 위치와 크기, 그리고 서로 관련된 위치를 결정합니다. 이때 레이아웃 성능은 DOM의 영향을 받습니다. DOM 요소의 수가 많아질수록 레이아웃 단계에서 소요되는 시간이 길어지게 됩니다.
 
### 6. 페인팅
 
6-1. 페인트(Paint) 단계 : Render Tree를 분석한 후 **요소들을 그룹 지어 레이어로 나눕니다.** 그 후 각각의 레이어는 픽셀 데이터로 변환됩니다. 이때 각 레이어는 독립적으로 렌더링 되며 이는 브라우저의 렌더링 성능을 향상 하는데 도움을 줍니다. 레이어는 CSS 속성 (z-index, position, transform, will-change 등)과 canvas, video 태그 등을 기준으로 분리됩니다.
 
<PostImage src="https://res.cloudinary.com/yun-log/image/upload/v1738486630/19.CRP/aehimnnckg4lzqirpte3.png" alt="개발자 도구에서 Layer 확인하기" caption="개발자 도구의 오른쪽 점 세 개 버튼 -> 도구 더 보기 -> 레이어 클릭 시 열리는 레이어 탭에서 레이어를 직접 확인해 볼 수 있습니다." width="778" height="448"/>
 
<PostImage src="https://res.cloudinary.com/yun-log/image/upload/v1738486646/19.CRP/armbgfxsbwjeved8cakz.png" alt="개발자 도구에서 블로그 메인 Layer 확인" caption="블로그 메인 화면 레이어" width="812" height="419"/>
 
<PostImage src="https://res.cloudinary.com/yun-log/image/upload/v1738486633/19.CRP/wkwqaqg2ca6dbnomlxia.png" alt="개발자 도구에서 블로그 PostCard의 image에 will-change 속성을 주었을 때" caption="PostCard의 Image에 will-change 속성을 적용하면 이미지마다 레이어가 생성됨" width="812" height="419"/>
 
시각적으로 레이어를 확인할 수 있으니 더 이해하기 쉽습니다 👍
 
<Callout icon="🤔" title="will-change는 항상 성능에 유리할까요?" >
CSS 속성 중 브라우저에 미리 변경될 CSS를 알려주는 will-change가 있습니다. HTML 요소에 will-change가 적용돼 있다면 브라우저는 해당 요소를 독립적인 레이어로 분리하여 렌더링 최적화를 준비합니다. 하지만 will-change를 남발하여 너무 많은 레이어가 생성된다면 오히려 성능 저하의 원인이 됩니다. 따라서 정말 필요한 경우에만 사용하는 것을 권장합니다. 
</Callout>
 
6-2. 컴포지트 (Composite) 단계: 페인트 단계에서 생성된 레이어를 결합하여 최종적으로 화면에 표시합니다.
 
## 브라우저 렌더링 최적화
 
브라우저는 위와 같은 과정을 통해 HTML 파일을 화면에 렌더링합니다.
그럼, 브라우저에서 렌더링을 최적화하기 위한 방법은 무엇이 있을까요?
 
### 1. 과도한 DOM 요소 사용을 지양할 것
 
지나치게 깊은 DOM Tree나 복잡한 DOM 요소 구조는 렌더링 성능을 저하시킬 수 있으므로 불필요한 div 태그를 사용하는 등 과도한 DOM 요소 사용은 지양하는 것이 좋습니다.
 
### 2. 리플로우와 리페인팅 최소화
 
포스트 초반에 인터랙션을 구현할 때 transform이 width, position 보다 성능상 유리하다는 이야기를 했습니다. 바로 CSS 속성에 따라 거치는 렌더링 단계가 달라지기 때문입니다.
 
<PostImage src="https://res.cloudinary.com/yun-log/image/upload/v1738486627/19.CRP/yhjtzvlsf0xnmckfrpbs.jpg" alt="Reflow" caption="DOM 요소, CSS 변경 등으로 레이아웃 과정이 다시 발생" width="1097" height="80"/>
 
**리플로우(Reflow)** 는 렌더링 과정에서 레이아웃 과정이 다시 일어나는 것을 의미합니다. DOM 요소를 추가, 제거하거나 width, position, margin 등의 CSS 속성 변경으로 인해 HTML 요소들이 재배치되어야 할 때 브라우저는 각 요소의 위치와 크기를 새로 계산하는 리플로우 과정을 거치게 됩니다. 화면 배치를 다시 계산하기 때문에 렌더링 성능 저하를 유발합니다.
 
<PostImage src="https://res.cloudinary.com/yun-log/image/upload/v1738486636/19.CRP/wqfohmpkoyaasn0df33w.jpg" alt="Repainting" caption="레이아웃 변경 없이 CSS가 변경될 때 발생" width="1097" height="80"/>
 
**리페인팅(Repainting)** 은 렌더링 과정에서 페인팅 과정이 다시 일어나는 것을 의미합니다. 레이아웃 변화 없이 CSS가 변경될 때 리페인팅 과정을 거치게 됩니다. 리페인팅의 경우 리플로우보다는 덜 하지만 여전히 성능을 저하시키는 요인입니다. 따라서 인터랙션을 구현할 때 리플로우보다는 리페인팅을, 그 중에서도 특히 컴포지트만 발생시키는 CSS 속성을 사용하는 것이 중요합니다.
 
[CSS Triggers](https://www.lmame-geek.com/css-triggers/)에 들어가 보면 스타일 변경 시 레이아웃, 페인트, 컴포지트를 트리거하는 CSS 속성이 잘 정리되어 있습니다.
 
<PostImage src="https://res.cloudinary.com/yun-log/image/upload/v1738799737/19.CRP/vxwqklfyo3brmwk1fmb9.png" alt="트리거 속성" width={526*0.6} height={86*0.6}/>
 
<PostImage src="https://res.cloudinary.com/yun-log/image/upload/v1738486625/19.CRP/thtjzavhschn9qsp6h9o.png" alt="css triggers transform" width="808" height="57"/>
transform은 컴포지트만 트리거합니다 👍
 
<PostImage src="https://res.cloudinary.com/yun-log/image/upload/v1738486638/19.CRP/yr7kunuligohgemlmo0e.png" alt="css triggers width" width="1097" height="80"/>
<PostImage src="https://res.cloudinary.com/yun-log/image/upload/v1738486623/19.CRP/qj2bp4atuhsffbngmh9m.png" alt="css triggers position" width="1097" height="80"/>
 
하지만 width와 position은 레이아웃을 트리거, 즉 리플로우 단계를 거치는 것을 확인할 수 있습니다. 즉 width, position을 빈번하게 변경시키는 인터랙션이 있다면 그만큼 화면을 계산하는 일이 많아져 브라우저 렌더링 성능이 떨어지며 브라우저 화면 프레임이 뚝뚝 끊길 수도 있습니다. 그렇기에 인터랙션을 구현할 때 리플로우보다는 리페인팅을, 그중에서도 컴포지트만 발생하는 CSS 속성을 사용하는 것이 좋습니다.
 
<Callout title="레이아웃 쉬프트 (Layout Shift)">
혹시 웹사이트가 로딩되며 클릭하려던 요소가 아래로 밀리는 바람에 의도하지 않은 버튼을 눌러 불쾌했던 경험 있으신가요?
그러한 현상을 레이아웃 쉬프트라고 합니다. 말그대로 레이아웃이 이동하는 현상이죠.
레이아웃 쉬프트도 리플로우를 유발하기 때문에 브라우저 렌더링 성능에 좋지 않습니다. 게다가 사용자 경험에도 좋지 않기 때문에 스켈레톤 UI를 사용하여 이를 방지하는 것이 중요합니다.
</Callout>
 
## 포스팅을 마치며
 
오늘은 브라우저의 렌더링 과정 중에서도 HTML 파일이 화면에 그려지게 되는 과정인 주요 렌더링 경로에 대하여 알아보았습니다. 예전에 공부했었지만 시간이 오래되어 자세한 내용은 기억이 살짝 흐릿한 상태였는데 이번에 포스트를 작성하며 해당 내용을 다시 정리할 수 있어 좋았습니다. 처음 주요 렌더링 경로를 알게 되었을 때 '이런 과정을 거쳐 화면이 렌더링 되는 거구나', '이래서 인터랙션 구현할 때 transform을 써야 하는구나' 하고 시야가 넓어진 기분이 들었던 기억이 납니다. 바로 이런 재미에 공부를 하게 되는 것 같습니다 😋 그럼 이번 포스트는 여기서 마무리해 보겠습니다 👋👋

주요 렌더링 경로 알아보기

{intro}
<Spacing size="lg" />

## 자바스크립트 엔진과 런타임 환경
 
<PostImage src="https://res.cloudinary.com/yun-log/image/upload/v1738486502/09.event_loop/oferio6vo4lrltq3phbj.jpg" alt="자바스크립트 런타임 환경" width="992" height="584"/>
 
**자바스크립트 엔진**은 자바스크립트 코드를 해석하고 실행하는 프로그램입니다. 자바스크립트 엔진은 싱글 스레드로 동작하며 **한 번에 하나의 일만 처리**할 수 있습니다. 이는 함수의 실행을 관리하는 **콜 스택이 하나**라는 의미이기도 합니다. 대표적으로 크롬과 Node.js에서 사용하는 V8엔진이 있습니다.
 
**자바스크립트 런타임 환경**은 자바스크립트가 실행되는 환경, 즉 크롬 같은 **브라우저(혹은 Node.js)** 입니다. 브라우저에서 제공하는 Web API들(fetch, setTimeout, EventListener...)을 통해 **비동기 작업**이 가능하며 이벤트 루프를 통해 비동기 작업의 우선 순위를 정하고 처리합니다.
 
### 콜 스택 (Call Stack)
 
**콜 스택**은 자바스크립트 엔진이 **함수의 실행 순서를 관리하기 위해 사용하는 스택(Stack) 자료구조**입니다. 함수가 호출되며 생성된 실행 컨텍스트가 콜 스택에 차곡차곡 쌓이게 되며 가장 나중에 호출된 함수가 가장 먼저 실행되는**LIFO(Last In First Out)** 구조입니다.
 
### 태스크 큐 (Task Queue)
 
**태스크 큐**는 **브라우저에서 태스크(작업)를 관리하는 큐(Queue) 자료구조**입니다. 비동기적으로 처리되는 작업들(event listner의 콜백함수, setTimeOut 함수의 콜백함수 등)을 관리하는 일종의 **대기소 역할**을 합니다. setTimeOut에서 지정한 시간이 됐거나 click 이벤트가 발생한 시점에 작업(콜백함수)을 태스크 큐에 넣어두어 대기시킨 후 콜 스택이 비워졌을 때 가장 먼저 들어온 작업부터 하나씩 콜 스택으로 이동하는 **FIFO(First In First Out)** 구조입니다.
 
### 마이크로태스크 큐 (Microtask Queue)
 
**마이크로태스크 큐**는 브라우저에서 Promise의 상태 변화에 따라 실행되는 then, catch, finally의 콜백 함수와 MutationObserver의 콜백 함수 등을 관리하는 큐(Queue) 자료구조입니다. **태스크 큐 보다 높은 우선 순위**를 가지며 콜 스택이 비워졌을 때 먼저 들어온 작업부터 하나씩 콜 스택으로 이동시켜 실행시킵니다. 태스크 큐와 마이크로태스크 큐가 나누어진 이유는 작업 처리에 우선 순위를 두어 **태스크 큐에 있는 작업에 영향을 받지 않고 마이크로태스크를 동일한 환경에서 처리할 수 있기 때문**이라고 합니다.
 
## 이벤트 루프 (Event Loop)란?
 
**이벤트 루프**는 브라우저에 내장된 **비동기 작업을 처리하는 매커니즘**입니다. 말 그대로 계속 루프를 돌며 콜 스택과 태스크 큐, 마이크로태스크 큐를 관찰하며 처리할 작업(함수)이 있다면 순서대로 처리합니다. 
 
## 이벤트루프를 통한 비동기 작업 순서
 
앞서 본 이미지를 보며 비동기 작업이 어떤 순서로 진행되는지 알아보겠습니다.
 
<PostImage src="https://res.cloudinary.com/yun-log/image/upload/v1738486502/09.event_loop/oferio6vo4lrltq3phbj.jpg" alt="자바스크립트 런타임 환경" width="992" height="584"/>
 
1. 이벤트 루프는 콜 스택이 비워져 있는지 확인합니다.
2. 콜 스택이 비워져 있지 않다면 작업을 콜 스택으로 이동시키지 않습니다. 
3. 콜 스택이 비워져 있다면 마이크로태스크 큐에 있는 작업들을 들어온 순서대로 하나씩 콜 스택으로 이동시킵니다. 앞서 언급했듯 마이크로태스크 큐는 태스크 큐보다 높은 우선 순위를 갖습니다. 
 콜 스택으로 이동한 함수의 실행이 종료된 후 콜 스택이 비워지게 되면 다시 마이크로태스크 큐에 있는 작업을 콜 스택으로 이동시킵니다. 이 과정은 마이크로태스크 큐에 있는 모든 작업이 비워질 때까지 반복됩니다. 만약 콜 스택에서 함수가 실행되고 있는 중간에 마이크로태스크 큐에 새로운 작업이 추가되면, 해당 작업까지 모두 처리한 후 태스크 큐 작업을 처리합니다.
4. 콜 스택이 비워져 있고 마이크로태스크 큐에 작업이 없다면 태스크 큐에서 작업들을 하나씩 들어온 순서대로 처리합니다. 태스크 큐에 있는 모든 작업이 비워질 때 까지 1부터 4까지의 단계를 반복합니다.
 
위와 같은 과정을 통해 이벤트 루프는 비동기 작업의 실행 순서를 정하고 처리합니다.
 
실제로 코드를 통해 이벤트 루프 동작을 살펴볼 겸 한가지 재밌는 실험을 해볼까요?
setTimeOut(()=>{}, 0)이 정말 0ms 후에 실행되는지 알아보겠습니다.
 
```javascript
const runAfterZero = () => {
 const runTime = performance.now();
 console.log("시작!"); // 1번 
 setTimeout(() => {
 const afterTime = performance.now();
 console.log(`실행하는데 걸린 시간 : ${afterTime - runTime}ms`); //2번
 }, 0);
 console.log("끝!"); //3번
 };
runAfterZero();
```
 
<PostImage src="https://res.cloudinary.com/yun-log/image/upload/v1738486505/09.event_loop/bshbzgai8ffxfpqwegkt.png" alt="이벤트 루트 동작 확인" width="982" height="162" caption="setTimeOut 0는 0ms 뒤에 실행 되지...않았습니다...!"/>
 
>1. 전역 컨텍스트가 생성되어 콜 스택에 쌓입니다.
>2. runAfterZero 함수가 호출되며 콜 스택에 runAfterZero 함수의 실행 컨텍스트가 쌓입니다.
>3. 1번 로그가 찍힙니다.
>4. setTimeOut이 호출되며 0ms 후에 태스크 큐에 콜백함수가 들어가게 됩니다.
>5. 2번 로그가 찍힙니다.
>6. 함수의 실행 모두 종료된 후 함수 컨텍스트가 콜 스택에서 제거됩니다.
>7. 전역의 코드가 모두 종료된 후 전역 컨텍스트가 콜 스택에서 제거됩니다.
>8. 콜 스택이 모두 비워진 후 태스크 큐에 있는 setTimeOut의 콜백함수가 실행되며 3번 로그가 찍힙니다. 실행되는데 걸린 시간은 0.5ms이네요.🤓

 
여기서 주목해야 할 점은 콜 스택이 비워져 있어야 남아있는 작업을 처리할 수 있다는 것입니다. 만약 실행되는데 아주 오래 걸리는 코드가 있다면 어떨까요? 그 시간동안 마이크로태스크 큐, 태스크 큐에 등록된 작업들은 그저 대기하고 있을 수 밖에 없습니다. 
 
```javascript
const runAfterZero = () => {
 const runTime = performance.now();
 console.log("시작!"); // 1번 코드
 setTimeout(() => {
 const afterTime = performance.now();
 console.log(`실행하는데 걸린 시간 : ${afterTime - runTime}ms`); //2번 코드
 }, 0);
 console.log("끝!"); //3번 코드
 };
runAfterZero();

const start = Date.now();
const duration = 3000;
while (Date.now() - start < duration) {
 const elapsed = Date.now() - start;
}
```
 
아까와 같은 코드이지만 전역에 3초 동안 실행되는 반복문을 추가해보았습니다. 어떨게 될까요? 두근두근
 

<PostImage
 src="https://res.cloudinary.com/yun-log/image/upload/v1738489141/09.event_loop/rqb1lruixpyqqtyfpcqo.gif" alt="3초 후 실행" width="498" height="86" />
 
3초 동안 반복문이 실행되고 전역 코드가 모두 종료되어 전역 컨텍스트가 제거된 후 setTimeOut의 콜백함수가 실행됩니다.😱
이렇게 되면 성능에도 좋지 않고 사용자가 화면을 클릭 했을 때 등록된 이벤트 리스너 콜백이 바로 실행되지 않는 등 사용성이 굉장히 떨어질 수 밖에 없습니다.
따라서 setTimeOut(()=>{},0)을 사용하여 복잡한 코드를 나누어 태스크 큐에 넣어두는 방식으로 작업을 관리할 수 있습니다. (저는...그렇게까지 코드 관리해 본 적은 없지만요...)
 
그리고 브라우저는 성능 최적화와 안정적인 사용자 환경을 위해 콜 스택에 있는 함수가 모두 실행된 후 화면의 변경을 업데이트합니다. 보통의 경우에는 60fps (약 16ms) 주기로 업데이트 되지만 콜 스택에서 굉장히 오랫동안 실행되는 코드가 있다면 정상젹으로 UI가 업데이트 되지 않는 이슈가 발생할 수 있기 때문에 역시 너무 크고 복잡한 작업을 나누어 관리하는 것이 중요합니다.
 
<PostImage src="https://res.cloudinary.com/yun-log/image/upload/v1738489144/09.event_loop/b91l2i2fbn8cettfwdpo.gif" alt="UI 업데이트 테스트" width="792" height="144" caption="콜 스택에서 함수가 실행될 동안 mouse hover로 인한 UI 업데이트가 되지 않음" />
 

## 포스팅을 마치며
 
오늘은 자바스크립트 런타임 환경에서의 이벤트 루프에 대해 알아보았습니다. 코드를 한줄 한줄 읽어서 실행하는 인터프리어 언어..(하지만 호이스팅!), 싱글 스레드를 가진 동기식 언어..(자, setTimeOut에 코드를 비동기로 싸서 드셔보세요😋) 자바스크립트 당신은 도대체...? 종잡을 수 없지만 알고 보면 다 나름의 이유가 있기 때문에 자바스크립트를 열심히 공부하는 것이 중요하다고 생각됩니다.
 
특히 이번에 이벤트 루프를 정리하며 제가 전역 컨텍스트에 대해서 오해하고 있다는 걸 알게 되었습니다. 저는 전역 컨텍스트가 앱이 실행되는 동안에 계속 콜 스택에 남아 있다고 생각했습니다. 그래서 전역 컨텍스트가 있는데 어떻게 콜 스택이 비워질 수 있지? 하고 고뇌했는데 알고보니 코드 실행이 종료되면 전역 컨텍스트도 사라지게 되는거였습니다. (급하게 실행 컨텍스트 포스트를 수정하러 가는 중 🏃‍♀️🏃‍♀️🏃‍♀️) 이렇게 글로 정리해보며 기존에 잘못 알고 있던 것들도 바로 잡을 수 있어서 블로그를 운영하는 목적을 잘 달성하고 있는 것 같아서 기분이 좋습니다. (하지만 피그마 실력은 도통 나아지질 않습니다... 괴롭...) 
 
뜬금 없지만 내일이 바로 추석입니다. 이 글을 읽으신 분들 모두 즐거운 추석 보내시길(혹은 보내셨길) 바라며 글을 마치겠습니다 🌝👋👋

.css-y59011{position:relative;}.css-y59011::after{content:"";position:absolute;right:0;bottom:0;width:0;height:2px;background-color:var(--color-secondary);-webkit-transition:width 200ms ease-in-out;transition:width 200ms ease-in-out;} 주요 렌더링 경로 알아보기

이벤트루프 알아보기

주요 렌더링 경로 알아보기