
Reflow를 공부하는 과정에서 예상과 다른 동작을 발견하게 되었고, 이를 검증하기 위해 직접 테스트를 진행해 보았다. 그러나 테스트 결과는 내가 기대했던 것과 달랐고, 이를 통해 Reflow에 대해 충분히 이해하지 못하고 있다는 사실을 깨달았다. 이후 관련 자료를 심층적으로 조사하면서, 그동안 Reflow에 대해 단편적으로만 알고 있었다는 점을 명확히 인식하게 되었다. 이번 아티클에서는 Reflow의 개념을 자세히 파헤치고, 공부 과정에서 생긴 의문과 예상과 다른 결과의 원인을 체계적으로 분석해 보려 한다.

## Reflow

우선 용어를 정리하자면, Reflow는 Firefox에서 주로 사용되는 용어이며, Chrome과 Safari에서는 Layout이라는 표현을 사용한다. 이러한 차이는 브라우저 개발자 도구를 통해 쉽게 확인할 수 있다. 즉 Reflow, Layout 같은 말이다. 여기서는 Reflow라고 말을 하겠다. Reflow란 **렌더 트리를 기준으로 요소의 레이아웃(크기, 위치, 관계)을 다시 계산하는 과정**을 의미한다. 특히 현대 웹 개발에서 자바스크립트를 사용해 DOM을 조작할 때 Reflow에 신경 써야 한다. Reflow는 `성능 저하`와 `병목 현상`을 초래할 수 있기 때문이다.

> Reflow가 아니더라도 브라우저 렌더링 과정에 대한 것들은 모두 신경써야 한다.

## 우리가 알고있는 Reflow는 생각보다 다르다.

Reflow에 대한 기본적인 지식을 배웠으니, 다음 코드는 Reflow가 몇번 발생하는지 생각해보자.

```ts
const button = document.querySelector("button")! as HTMLButtonElement
const paragraph = document.querySelector("p")! as HTMLParagraphElement

button.addEventListener("click", (event) => {
  for (let i = 1; i <= 10_000; i++) {
    paragraph.innerHTML = String(i)
  }
})
```

대부분의 사람들은(실제 주변 동료들에게 질문한 결과) "반복 횟수만큼 Reflow가 발생한다"라고 답변했다. 하지만 실제로는 Reflow는 한 번만 발생하고 있었다. 위 코드를 Performance로 분석한 결과는 다음과 같다.

![성능 분석 결과](/posts/JavaScript/reflow/no-optimization.png)

지금은 innerHTML을 추가한 것이지만, 위 코드에서 `createElement`를 사용해 `appendChild`로 DOM 추가를 하더라도 Reflow는 한 번만 발생하게 된다. 이러한 이유를 알려면, Asynchronous Reflow와 Synchronous Reflow를 알아야 한다.

### Asynchronous Reflow(비동기식 리플로우)

Asynchronous Reflow란 브라우저가 DOM 변경에 따른 레이아웃 재계산 작업을 지연하거나 최적화하는 과정을 말한다. 비동기식 Reflow는 페인트가 일어나기 전에 실행된다. 위에 이미지를 보면 pre-paint 이전에 Layout이 일어나는 것을 볼 수 있다. 마치 React의 batch와 같이 DOM 업데이트를 모아서 처리한다고 볼 수 있다. 따라서 위 코드와 같이 반복적으로 DOM 업데이트를 시도한다고해서 매번 Reflow가 발생하는건 아니다.

### Synchronous Reflow(동기식, 강제 리플로우)

Synchronous Reflow는 Forced Reflow 라고도 부른다. 이 개념은 우리가 알고있는 Reflow와 같다. 위 코드에서 `paragraph.innerHTML = String(i)`밑에서 `console.log(Reflow를_일으키는_속성_및_메서드)`를 사용하면 이 때 Forced Reflow가 일어나게 된다. 이 과정을 Performance로 분석하면 다음과 같다.

![동기식 Reflow](/posts/JavaScript/reflow/force-reflow.png)

위 그림에서 보라색으로 표시된 부분이 Layout, 즉 Reflow를 의미한다. Reflow는 브라우저가 DOM의 레이아웃을 다시 계산하는 과정으로, 이 작업은 매우 계산 비용이 크다. 특히, 매번 Reflow를 계산하게 되면 병목 현상이 발생하여 성능이 크게 저하되는 모습을 볼 수 있다. 이렇게 단일 작업 및 프레임에서 Reflow가 여러번 발생하는 것을 `레이아웃 쓰레싱(Layout Thrashing)`이라고 한다.

따라서, Forced Reflow는 최대한 사용하지 않는 것이 중요하다. DOM이나 스타일 변경 작업을 효율적으로 설계하고, Reflow를 최소화하는 방법을 고려해야 한다. 예를 들어, 레이아웃 정보를 읽고 쓰는 작업을 분리하거나, `requestAnimationFrame`을 활용하여 렌더링 타이밍에 맞춰 작업을 수행하는 것이 성능 최적화에 도움을 줄 수 있다.

### 레이아웃 쓰레싱의 의문

브라우저는 HTML 파일을 파싱하여 DOM 트리를 생성하고, link 태그를 만나면 CSSOM을 생성한다. 자바스크립트가 DOM을 조작하면, 브라우저는 DOM 트리 생성을 중단하고 자바스크립트 실행을 완료한 후 DOM 트리 생성을 재개한다. 이후, DOM과 CSSOM을 결합하여 Render Tree를 만든다.

이 과정을 살펴보면, `레이아웃 쓰레싱이 어떻게 발생하는지 이해하기 어렵다`. 왜냐하면 Render Tree가 생성된 이후에야 레이아웃 계산(Reflow)이 일어나기 때문이다.

하지만 Render Tree가 완성되기 이전에도 레이아웃 쓰레싱이 발생할 수 있는 이유는 자바스크립트 실행 중에 Forced Reflow가 발생하기 때문이다. Forced Reflow가 발생하면 브라우저는 Recalculate Style 단계를 실행하여 DOM과 CSSOM을 기반으로 Render Tree를 업데이트한다.

따라서, Render Tree는 자바스크립트가 실행되는 동안에도 동적으로 생성되거나 갱신될 수 있으며, 이 과정에서 반복적인 DOM 읽기/쓰기 작업이 강제 Reflow를 유발하면 레이아웃 쓰레싱이 발생할 수 있다.

![Recalculate style](/posts/JavaScript/reflow/layout-thrashing.png)

### 동기식 Reflow에서는 매번 Rendering이 진행될까?

브라우저 렌더링 과정에서 Reflow가 발생하면 Paint, Compositing 단계를 거쳐 DOM에 Commit 된다는 것은 모두 알고 있을 것이다. 하지만 동기식 Reflow에서는 Paint, Commit 단계를 진행하지 않는다. 이러한 점을 보았을 때 Reflow가 된다고해서 반드시 DOM에 Commit되지 않는다는 것을 알 수 있다. 만약 Commit 단계까지 갔다면, 숫자가 카운트되면서 올라가는 애니메이션이 진행되어야하는데, 실제로는 그렇지 않다는것을 알 수 있다.

추가적으로, 자바스크립트가 실행 중일 때 브라우저는 렌더링 작업이 차단된다. 즉, 반복문에서 Reflow를 유발하더라도 자바스크립트 실행이 끝나기 전까지 브라우저는 화면을 렌더링하지 않는다. 이는 브라우저가 싱글 스레드로 동작하며, 자바스크립트와 렌더링 작업을 병렬로 처리하지 않기 때문이다. 따라서, Reflow가 발생하더라도 실제 렌더링은 자바스크립트 실행이 완료된 후에 이루어진다.

만약 자바스크립트가 렌더링을 차단하지 않도록 하기 위해 긴 작업을 작은 단위로 나누고, `setTimeout`이나 `requestAnimationFrame`을 사용해 비동기적으로 작업을 분리하면 브라우저가 렌더링과 자바스크립트 실행을 병행할 수 있다. 이러한 방법은 React에서 긴 동기 작업으로 인해 UI가 멈추는 문제를 해결하기 위해 비동기적으로 동작하는것과 비슷하다.

### 그렇다면 Reflow 최적화를 할 필요가 없을까?

성능 최적화에 관심이 많은 분들은 위 코드(비동기 Reflow)를 최적화하기 위해 다음과 같은 방식을 사용하는 경우를 볼 수 있다

```ts
let text = ""

button.addEventListener("click", () => {
  for (let i = 1; i <= 10000; i++) {
    text = String(i)
  }

  paragraph.innerHTML = text
})
```

비동기식 Reflow를 활용한 코드에서도 Reflow는 한 번만 발생하고, 위 코드에서도 Reflow는 한 번만 발생한다. 따라서 Reflow 측면에서는 결과가 동일하다.

그러나 DOM을 한 번만 업데이트하는 것과 여러 번 업데이트하는 것은 성능에서 매우 큰 차이를 가져온다. 이는 브라우저가 DOM 변경 작업을 처리하는 방식 때문으로, Performance 탭을 통해 분석한 결과에서도 이러한 차이가 명확히 드러난다.

#### 여러번의 DOM 업데이트

![여러번의 DOM 업데이트](/posts/JavaScript/reflow/dom-update.png)

여러 번의 DOM 업데이트가 수행된 Performance 결과를 보면, 파란색 막대가 매우 촘촘하게 나타나는 것을 확인할 수 있다. 이 파란색 막대는 parseHTML 과정을 나타내며, 브라우저가 HTML 문자열을 파싱하여 DOM 트리를 생성하는 작업을 의미한다.

DOM을 반복적으로 업데이트하면 브라우저가 계속해서 DOM 트리를 재생성해야 하므로, 긴 태스크 작업 경고창이 표시되었다(위 빨간색 막대) 이 특정 작업에서는 154.47ms의 시간이 소요되었으며, 병목 현상으로 이어지고 있다.

#### DOM 업데이트 최적화

![DOM 업데이트 최적화](/posts/JavaScript/reflow/dom-update-optimization.png)

최적화된 DOM 업데이트의 Performance 결과를 보면, DOM 트리를 생성하는 파란색 막대(parseHTML)가 보이지 않는 것을 확인할 수 있다. 이는 DOM 업데이트 작업이 효율적으로 수행되어 브라우저가 불필요한 parseHTML 작업을 최소화했음을 의미한다. 또한, 태스크 작업 속도가 1.29ms로 매우 짧게 측정되었으며, 이는 성능이 크게 개선되었음을 보여준다. (비록 위 이미지에는 표시되지 않았지만, 작업이 최적화된 결과 29ms밖에 걸리지 않는다는 점이 결정적인 차이로 나타난다.)

#### 결론

즉, Reflow가 한 번만 발생한다고 해서 성능 최적화를 하지 않아도 된다는 뜻은 아니다. 위 예시에서 살펴본 것처럼, 최적화를 수행하지 않으면 DOM 트리를 생성하는 과정에서 병목 현상이 발생할 수 있다.

따라서, 최적화를 진행할 때는 단순히 Reflow 관점에서만 보지 말고, Performance 분석 도구를 활용하여 병목의 원인을 찾아야 한다. 이렇게 하면 문제를 더 직관적이고 명확하게 이해할 수 있으며, 최적화를 더욱 효과적으로 수행할 수 있다.

## 마무리

Reflow에 대해 학습하면서 몇 가지 의문이 들었다. 이를 해결하기 위해 다양한 자료를 찾아보고, 브라우저의 렌더링 과정과 Performance 탭을 활용하여 더욱 깊이 있게 분석해보았다.

- `Reflow 관련 메서드나 프로퍼티를 사용하면 항상 Reflow가 발생하는가?`,
- `Render Tree가 만들어지기 이전에 어떻게 Reflow가 발생하는가?`,
- `Reflow가 발생하면 DOM에 Commit까지 이어지는가?`

이러한 의문과 고민이 없었다면, 다른 사람들에게 잘못된 정보를 전달했을지도 모른다. 이를 통해, 무엇인가를 배울 때는 항상 검증하는 과정이 필요하다는 것을 다시금 느꼈다. 검증을 통해 내용을 확실히 이해할 수 있을 뿐만 아니라, 더 오래 기억에 남게 된다.


Performance 분석을 통한 Reflow Deep Dive

Reflow 딥다이브 (feat. Performance 분석)


자바스크립트는 싱글 스레드 언어다. 하지만 웹에서 일어나는 일들을 보면 동시에 작업을 하는 것처럼 보인다. 이러한 이유는 이벤트 루프 덕분에 가능하다. 이벤트 루프를 알기 전에 다음과 같은 내용들을 알고 있어야 이해하기 쉽다.

- 자바스크립트 특징
- 자바스크립트 엔진
- 자바스크립트의 런타임 환경
- 동기와 비동기

## 자바스크립트의 특징

자바스크립트는 한 번에 한 가지의 일만 처리할 수 있는데, 이것을 `싱글 스레드`라고 부른다. 자바스크립트 엔진은 하나의 콜 스택으로 이루어져 있기 때문에 동시에 처리할 수 있는 능력이 없다.

> 스레드(thread)는 어떠한 프로그램 내에서, 특히 프로세스 내에서 실행되는 흐름의 단위를 말한다. 일반적으로 한 프로그램은 하나의 스레드를 가지고 있지만, 프로그램 환경에 따라 둘 이상의 스레드를 동시에 실행할 수 있다. 이러한 실행 방식을 멀티스레드(multithread)라고 한다.
> [위키백과](<https://ko.wikipedia.org/wiki/%EC%8A%A4%EB%A0%88%EB%93%9C_(%EC%BB%B4%ED%93%A8%ED%8C%85)>)

## 자바스크립트 엔진과 런타임 환경

자바스크립트는 ECMAScript를 기반으로 만들어진 프로그래밍 언어다. 자바스크립트 엔진은 ECMAScript 엔진이라고 말하는 게 더 정확하지만 일반적으로는 자바스크립트 엔진이라고 말을 한다. 즉 자바스크립트 엔진은 ECMAScript를 구현한 것을 말한다. 자바스크립트 런타임 환경은 자바스크립트가 어느 환경에서 실행되는지에 따라 달라진다. `fetch`, `DOM API`들은 브라우저에서 제공받는다. 따라서 자바스크립트는 ECMAScript + 호스트 객체(자바스크립트가 실행되는 환경에서 제공받는 객체)라고 볼 수 있다.

즉 우리가 말하는 자바스크립트가 런타임 환경을 말하는 것인지 ECMAScript인지 명확하게 구분할 필요가 있다. 앞으로 나올 이벤트 루프는 ECMASCript에 정의되어 있지 않은 내용이다. 자바스크립트 엔진이 아닌 자바스크립트 런타임 환경에서 사용되는 개념이다. 따라서 개념의 혼동이 오면 안 된다.

## 동기와 비동기

![Image](/posts/JavaScript/event-loop/snyc-async.png)
자바스크립트는 한 번에 한 가지의 일만 처리할 수 있기 때문에 요청한 작업에 완료 여부를 따져 순차적으로 처리를 한다. 이것을 동기라고 부른다. 동기는 순서가 보장되지만 요청한 작업이 끝날 때까지 블로킹 된다는 단점이 있다. 비동기는 요청한 작업에 완료 여부랑 상관없이 처리하는 것을 말한다. 즉 순서를 예측할 수 없지만, 작업이 끝날 때까지 기다리지 않고 다음 작업을 이어가기 때문에 동기보다 더 많은 일을 할 수 있다.

## 이벤트 루프

![Image](/posts/JavaScript/event-loop/event-loop.jpg)
자바스크립트는 싱글 스레드 언어이지만, 웹 어플리케이션에서는 많은 일이 동시에 일어나는 것처럼 보인다. 자바스크립트 엔진은 단일 호출 스택(CallStack)을 사용하며 요청이 들어올 때마다 해당 요청을 순차적으로 Call Stack에 담아 처리할 뿐이다. 위 그림에서 볼 수 있듯이 `fetch`, `setTimeout`등 비동기 함수들은 자바스크립트 엔진이 아닌 외부에 있는 Web API에서 처리를 하게 된다. 또한, Event Loop, Callback Queue도 마찬가지로 자바스크립트 엔진 외부에 구현되어 있다.

![Image](/posts/JavaScript/event-loop/nodejs-environment.jpg)

위 그림에서도 브라우저 환경과 비슷한 구조를 볼 수 있다. Node.js는 비동기 IO를 지원하기 위해 `libuv` 라이브러리를 사용하며, 이 라이브러리가 이벤트 루프를 제공한다. 자바스크립트 엔진은 비동기 작업을 위해 Node.js의 API를 호출하며 이때 넘겨진 콜백은 libuv의 이벤트 루프를 통해 스케쥴되고 실행된다.

자바스크립트가 싱글 스레드 기반의 언어라는 말은 ＂자바스크립트 엔진이 하나의 콜 스택을 사용한다＂는 관점에서만 사실이다. 실제 자바스크립트가 실행되는 환경인 브라우저, Node.js에서는 주로 여러 개의 스레드(멀티스레드)를 사용되며, 이러한 실행 환경이 하나의 Call Stack을 사용하는 자바스크립트 엔진과 상호 연동하기 위해 사용하는 장치가 바로 `이벤트 루프`인 것이다.

### CallStack

Call Stack은 자바스크립트 엔진 안에 있고, 함수를 호출하면 새로운 실행 컨텍스트가 생성되어 Call Stack에 추가된다. Call Stack은 먼저 들어온 게 나중에 나가는 FILO의 스택이다. 함수가 값을 반환하면 Call Stack에서 제거된다.

![Image](/posts/JavaScript/event-loop/callstack.gif)

위 gif와 같이 자바스크립트는 한 번에 하나의 작업만 처리할 수 있다. 만약 오래 걸리는 작업을 처리한다고 하면, 다른 작업은 처리할 수 없는 블로킹이 발생하게 된다.

### Web API

![Image](/posts/JavaScript/event-loop/web-api.gif)
Web APIs는 브라우저에서 제공하는 API 모음이라고 볼 수 있다. Web APIs의 일부분은 비동기적으로 실행되는 작업들을 처리한다. 대표적으로 `setTimeout`, `fetch`등이 있고, 콜백 함수 방식과 Promise 기반의 방식을 사용한다.

> 여기서 중요한 건 Web APIs가 모든 것을 비동기적으로 처리하지 않는다. `document.querySelector()` 또는 `console.log()`와 같은 메서드들은 동기적으로 처리된다.

### Callback Queue (Task Queue)

![Image](/posts/JavaScript/event-loop/callback-queue.gif)
`Callback Queue`는 Web APIs에서 처리된 콜백 함수를 대기하는 공간이고, 먼저 들어온 게 먼저 나가는 FIFO 구조다. Callback Queue에는 Task Queue와 Micro task Queue가 있다. 둘의 차이점은 우선순위에 따라 처리되는 순서가 달라진다는 점이다. 위 gif에서는 Geo location API를 다루고 있지만, Web APIs에서 처리된 콜백 함수들은 Callback Queue라는 공간에 대기한다고 볼 수 있다.

### Event Loop

![Image](/posts/JavaScript/event-loop/event-loop.gif)

Event Loop은 Call Stack이 비어있는 상태인지 지속해서 확인하고 비어있는 상태라면 Callback Queue에 있는 함수를 Call Stack으로 옮기고 실행시키는 역할을 한다.

위 gif에서는 `setTimeout`에 대한 예제다. 동작 과정을 설명해보자면 다음과 같다.

1. `setTimeout(() => console.log('2000ms'), 2000)`이 호출되면 CallStack에 푸시된다.
2. setTimeout의 콜백 함수는 Web APIs로 이동해 타이머를 시작한다. 이 때 CallStack에 남아있는 setTimeout 함수는 제거된다.
3. 비동기이기 때문에 바로 다음 함수인`setTimeout(() => console.log('100ms'), 100)`을 호출하고 CallStack에 푸시된다.
4. 2번과 마찬가지로 콜백 함수는 Web APIs로 이동해 타이머를 시작하고 CallStack에 남아있는 setTiemout 함수는 제거된다
5. `console.log('End of Script!')`가 실행되고 콘솔에 출력한다. (동기)
6. 100ms가 지나면 `() => console.log('100ms')` 콜백 함수가 Callback Queue 대기열에 추가된다.
7. 이벤트 루프가 CallStack이 비어있는 상태라는걸 감지한 후 `() => console.log('100ms')`함수를 CallStack에 옮기고 실행한다. console.log("100ms")가 출력된다.
8. 2000ms가 지나면 `() => console.log('2000ms')`콜백 함수가 Callback Queue 대기열에 추가된다.
9. CallStack이 비어있어, Callback Queue에 대기중인 `() => console.log('2000ms')` 콜백 함수를 CallStack에 옮기고 실행해 console.log("200ms")가 출력된다.

자바스크립트가 싱글 스레드 언어임에도 동시에 실행하는 것처럼 보였던 이유는 자바스크립트 엔진과 런타임 환경의 Web APIs와 Callback Queue 이 3가지를 이벤트 루프가 관리를 하고 있기 때문이다.

## Reference

- [자바스크립트와 이벤트 루프](https://meetup.nhncloud.com/posts/89)
- [Event Loop와 비동기](https://pozafly.github.io/javascript/event-loop-and-async/)
- [JavaScript Visualized: Event Loop, Web APIs, (Micro)task Queue](https://www.lydiahallie.com/blog/event-loop)

| 2024-08-10 Promise 내용은 추후에 추가됩니다.


자바스크립트는 한 번에 하나의 작업만 처리하는데, 동시에 처리되는 것처럼 보이는 이유는 무엇일까?