## Table of Contents

## Introduction

웹 사이트를 서비스하는 것은 굉장히 간단해 보일 수 있다. HTML을 내려주면, 브라우저는 다음에 어떤 리소스를 불러올지 알아낸다. 그런 다음, 브라우저가 페이지를 준비하기 까지 기다리기만 하면 된다. 그러나 사실 이 사이에는 많은 일이 일어난다. 브라우저는 과연 어떤 순서로 에셋을 요청해야 할까?

## 1. 에셋 우선순위란 무엇인가?

모던 브라우저는 streaming parser를 활용하여 HTML 구문을 붆석한다. 즉, 에셋은 다운로드 되기 전에 HTML 마크업 문서 내에서 찾을 수 있다. 브라우저가 에셋을 검색할 때, 미리 결정된 우선순위에 기반하여 네트워크 대기열에 해당 에셋을 추가시켜 둔다.

이러한 우선순위는 Lowest, Low, Medium, High, Highest라고 불리는 다섯단계로 나눠서 결정된다. 여기에서 우선순위를 할당하면, 브라우저는 페이지를 빠르게 로드하는데 필요한 가장 중요한 요청을 쉽게 구별할 수 있다.

![chrome-network-priority](./images/chrome-network-priority.png)

## 2. 크롬은 어떻게 우선순위를 결정하는가?

리소스는 어떻게 나타나는지, 그리고 어디서 발견되는지 순서에 따라서 네트워크 대기열에 추가된다. 그런 다음 브라우저는 네트워크 작업에서 가장 우선 순위가 높은 리소스를 최대한 빨리 가져오려고 시도한다.

각 리소스 유형에는 우선순위를 지정하는 규칙이 아래와 같이 존재한다.

| 리소스 타입                      | 우선순위                                                   |
| -------------------------------- | ---------------------------------------------------------- |
| HTML                             | Highest                                                    |
| Fonts                            | High                                                       |
| Stylesheets                      | Highest                                                    |
| `@import`로 불러오는 stylesheets | Highest, 스크립트를 블로킹 한 뒤에 로딩 됨                 |
| 이미지                           | 기본 값은 low, 최초 뷰포트에 존재할 경우 Medium으로 올라감 |
| 자바스크립트                     | 하단 표 참조                                               |
| Ajax, XHR, `fetch()` 등          | High                                                       |

### 자바스크립트 리소스의 우선순위

#### `<head>`내 `<script>`

- 로딩 우선순위 (네트워크, 블링크 엔진): Medium/High
- 실행 우선순위: 매우 높음, parser 블로킹
- 어디서 쓸까
  - FMP, FCP에 영향을 미치는 스크립트
  - 다른 스크립트 이전에 반드시 실행되어야 하는 스크립트
- 예제
  - 프레임워크 런타임 (스태틱 렌더링이 아닌 경우)
  - 폴리필
  - 페이지 전체의 DOM 구조에 영향을 미치는 A/B 테스트 등

#### `<link rel=preload>` + `<script async>` 또는 `<script type=module async>`

- 로딩 우선순위 (네트워크, 블링크 엔진): Medium/High
- 실행 우선순위: 높음, parser에 영향을 미침
- 어디서 쓸까
  - 중요한 컨텐츠를 만드는 스크립트 (FMP)
  - 하지만 뷰포트에 영향을 미치는 스크립트는 안됨
  - 컨텐츠의 동적인 삽입을 위한 동적인 네트워크 요청
  - 가져오는 즉시 실행해야하는 스크립트의 경우에는 `<script type=module async>`를 사용
- 예제
  - `<canvas />` 에 그려야 하는 것

#### `<script async />`

- 로딩 우선순위 (네트워크, 블링크 엔진): Lowest/Low
- 실행 우선순위: 높음, parser에 영향을 미침
- 어디서 쓸까
  - 사용할 때 주의 해야 한다. 요즘 들어 중요하지 않은 스크립트를 로딩 할 때 많이 사용하고 있지만, 로딩 우선순위만 낮을 뿐 실행 우선순위는 높다는 것을 기억해야 한다. https://calendar.perfplanet.com/2016/prefer-defer-over-async

#### `<script defer />`

- 로딩 우선순위 (네트워크, 블링크 엔진): Lowest/Low
- 실행 우선순위: 매우 낮음, `<body />` 최하단에 있는 `<script />`가 실행된 이후에 실행
- 어디서 쓸까:
  - 중요하지 않은 컨텐츠를 만드는 스크립트
  - 페이지 방문자의 50% 이상정도가 사용하는 중요한 상호작용 기능
- 예제
  - 광고

#### `<body />` 최하단에 있는 `<script />`

- 로딩 우선순위 (네트워크, 블링크 엔진): Medium/High
- 실행 우선순위: 낮음, 파서가 끝난 뒤에 실행됨
- 어디서 쓸까
  - 이 방법은 생각만큼 낮은 우선순위로 실행되지 않는다는 것을 명심해야 한다.

#### `<body />` 최하단에 있는 `<script defer />`

- 로딩 우선순위 (네트워크, 블링크 엔진): Lowest/Low, 큐 맨 마지막
- 실행 우선순위: 매우 낮음. `<body />` 최하단에 있는 `<script />` 가 끝나면 실행됨
- 어디서 쓸까
  - 사용자들이 가끔 사용하는 상호작용 기능
- 예제
  - '연관된 기사들' 같은 컨텐츠 (중요도가 낮은)
  - '피드백을 주세요' 같은 기능들 (역시 중요도가 낮은)

#### `<link rel=prefetch />` + `<script/>`

- 로딩 우선순위 (네트워크, 블링크 엔진): Idle/Lowest
- 실행 우선순위: 스크립트가 어떻게 작동 하느냐에 따라 다름.
- 어디서 쓸까
  - 다음 라우팅을 위한 자바스크립트 번들
- 예제
  - 다음 라우팅을 위한 자바스크립트 번들

> 브라우저 별로 동작이 통일되어 있지 않으므로 사용할 때 한번 더 확인이 필요하다. (위 자료는 크롬 기준)
> https://addyosmani.com/blog/script-priorities/

## 3. Critical Request란 무엇인가?

Critical Request란 초기 뷰포트에 표시되어야 하는 리소스를 의미한다.

여기에 포함되는 리소스들은 [Core Web Vital](/2021/08/core-web-vital)의 Largest Contentful Paint, First Contentful Paint에 영향을 미친다.

여기에 포함될 수 있는 리소스들은 아래와 같다.

- HTML
- CSS
- webfont
- images
- logo

이러한 애셋들은 (자바스크립트는 없다) 최초 뷰포트를 보여주는데 필수적인 요소들이기 때문에, 가장 먼저 로딩되어야 한다. 이러한 페이지를 위해서는 아래와 같은 항목을 챙기는 것을 추천한다.

- 최초 페이지 로딩시에 보여주어야 하는 요소들에 대한 성능 측정 (above-the-fold)
- 최초 HTTP 요청은 위 요소들이어야 함
- Critical Request는 리다이렉트 되어선 안됨
- Critical Request는 최적화되고, 압축되어야 하며, 캐싱 및 올바른 HTTP 헤더와 함께 제공되어야 함.

## 4. Lighthouse, Critical Request 체이닝을 피해야 한다.

구글의 라이트하우스는 Critical Request가 체이닝 되어 여러 요청이 호출되는 것을 막도록 권장하고 있다.

![critical-requests-chaining](./images/critical-requests-chaining.png)

가장 흔히 저지르는 critical request chaining은 바로 스타일 시트에서 폰트를 불러올 때 발생한다.

```css
@font-face {
  font-family: 'Calibre';
  font-weight: 400;
  font-display: swap;
  src: url('/Calibre-Regular.woff2') format('woff2'), url('/Calibre-Regular.woff')
      format('woff');
}

.carousel-bg {
  background-image: url('/images/main-masthead-bg.png');
}
```

이러한 요청의 체이닝의 수를 줄이면 LCP의 속도가 빨라지고, 사용자의 웹사이트 경험이 향상된다.이러한 체이닝 수를 줄이기 위해서 아래와 같은 항목을 점검하자.

- 요청의 수를 줄이기
- 리소스를 압축하거나 최소화 하여 크기를 줄이기
- 중요하지 않은 스크립트에 `async`
- HTML에 인라인 `@font-face` 선언을 고려
- css `background-image`나 `@import`를 최소화
- `preload`를 사용하여 중요한 리소스를 빨리 가져오기
- [bundlephobia](https://bundlephobia.com/)를 사용하여 더 작은 대체 라이브러리를 찾아보기

## 5. 요청 우선순위를 제어하기

요청 우선순위는 [preload](https://developer.mozilla.org/en-US/docs/Web/HTML/Link_types/preload)의 영향을 받을 수 있다. `Preloaded` 리소스는 높은 우선순위를 보여 받고, 페이지가 로딩될 때 빠르게 불러와진다.

```html
<link
  rel="preconnect"
  href="https://fonts.gstatic.com"
  crossorigin="anonymous"
/>
<link
  rel="stylesheet"
  href="https://fonts.googleapis.com/css2?family=Inter:wght@400;600;700&display=swap"
/>
```

![chrome-font-priority](./images/chrome-font-priority.png)

`Preload`를 사용하면, Critical Request를 최적화 할 수 있지만 너무 많이 사용해서는 안된다. 너무 많은 리소스에 붙이게 되면, 당연하게도 [페이지의 성능이 저하된다.](https://andydavies.me/blog/2019/02/12/preloading-fonts-and-the-puzzle-of-priorities/)

Preloading은 LCP와 CLS(Cumulative Layout Shift)에 영향을 미칠 수 있는데, 일부는 부정적인 영향을 미칠 수 있다. 사용하기 전에 충분히 실험해봐야 한다.

## 6. 이미지 레이지 로딩

기본적으로 브라우저는 사용자가 이미지를 실제로 보는 것과 상관없이 HTML에 있는 모든 이미지를 로드한다. 레이지 로딩을 사용하면 사용자가 이미지에 스크롤을 가까이 할 때만 이미지를 불러오도록 지정할 수 있다. 사용자가 스크롤 하지 않으면 해당 이미지를 브라우저는 불러오지 않는다.

이 접근방식을 사용하면 전반적인 렌더링 속도를 개선하고, 불필요한 데이터 전송을 피할 수 있다. 레이지로딩은 LCP를 개선하는데 매우 효과적이다.

과거 라이브러리나 스크립트를 사용하여 구현했지만, 요즘 브라우저에는 이 기능이 내장되어 있다.

> 물론 지원 가능 여부는 확인해 봐야 한다. https://caniuse.com/loading-lazy-attr

## 7. font-display

[통계에 따르면, 전체 69% 사이트가 웹 폰트를 사용하고 있다.](http://httparchive.org/interesting.php#fonts) 그리고 불행하게도, 이 경우 대부분 수준 이하의 성능을 제공하고 있다. 대부분의 유저들이 폰트가 나타나다가 사라지거나 한다거나, font-weight이 바뀌거나 하는 경험을 해본적이 있다. 이러한 변화는 이제 CLS에 부정적인 영향을 끼치게 된다.

`<link rel= "preload"/>`에서 소개했던 것 처럼, 폰트도 우선순위를 제어하면 렌더링 속도에 큰 영향을 미칠 수 있다. 따라서 대부분의 경우에는 폰트의 요청 우선순위를 결정해야 한다.

CSS font-display를 사용하면 렌더링 속도 향상에 영향을 미칠 수 있다. 이 속성을 사용하면 폰트를 요청하고 로딩되는 동안, 폰트가 표시되는 방식을 제어할 수 있다.

> https://yceffort.kr/2021/06/ways-to-faster-web-fonts 를 참고!

## Critical Request 체크리스트

위에서 살펴본 것들을 바탕으로, 사이트에 중요한 에셋을 선택하고 그에 따른 우선순위를 지정할 수 있다. 우선 순위와 속도를 높이기 위해서 아래의 체크리스트를 한번더 확인해보자.

- 크롬 개발자 도구에서 우선순위를 확인해보기
- 가능한 경우 필요한 요청 수를 줄이기
- 사용자가 완전히 렌더링된 페이지를 보기 전에 해야하는 것들을 정리하기
- `<link rel="preload" />`를 하여 중요 요청의 우선순위를 수정하기
- 다음 페이지에서 사용될 가능성이 있는 에셋에 대해 [link prefetching](https://developer.mozilla.org/en-US/docs/Web/HTTP/Link_prefetching_FAQ)을 사용하기
- [Link Preload HTTP 헤더](https://www.w3.org/TR/preload/)를 사용하여 HTML이 완전히 전송되기전에 사전에 로드될 리소스를 선언하기
- 이미지의 사이즈가 올바른지 확인하기
- 로고나 아이콘에 인라인 svg를 사용하기
- AVIF, Webp와 같은 좋은 이미지 포맷 사용하기
- `font-display: swap`을 사용하여 초기렌더링에 텍스트를 표시하기
- `WOFF2` 와 같은 압축된 폰트 형식 사용하기
- `chrome://net-internals/#events`를 사용하여 크롬 네트워크 이벤트 살펴보기
- _가장 빠른 요청은 요청하지 않는 것_


서순을 정확히하는게 중요하지

Critical Request - request 순서는 웹사이트 속도에 어떤 영향을 미치는가

## Introduction

사파리 15가 나왔다. 애플을 굉장히 좋아하고, 또 다수의 애플 제품을 보유하고 있는 나로서는 매우 즐거운 일이지만, 이번 safari 15는 나에게 몇가지 이슈를 안겨줬다. 무엇이 달라졌고, 어떻게 대응해야 하는지 살펴보자.

## 주소 창 위치의 변화

주소 창 위치가 변화하였다. 종전에 위에 있었지만, 이제는 밑에 주소창이 나타난다. 이로 인해 발생하는 문제에 대해서는 후술한다.

## 버튼 기본 색상 및 radius 변경

먼저 버튼의 기본 색상과 radius가 변경되었다.

![safari14-button](./images/safari14-button.png)

![safari15-button](./images/safari15-button.jpeg)

애플에서 자주 보던 그 파란색이다. 이제 스타일 리셋을 할때 버튼의 색깔까지 클리어 해주어야 한다.

## 사파리 100vh 문제 해결?

모바일 사파리에서는 기존 버전까지 `100vh`가 의도대로 동작하지 않는 문제가 있었다. 요약하자면 모바일 사파리에서는 스크롤시 주소창이 사라지는데, 이 경우 `100vh`가 뷰포트의 100% 높이가 변경되어 버리는 문제가 있다. 즉, `100vh`라는 값이 정적이지 않다는 뜻이다. 문제를 자세히 살펴보자.

먼저 우리가 아는 `vh` 란 viewport 너비의 1%를 말한다.

그리고 모바일 사파리에서 동작하는 `100vh`는 아마도 아래와 같을 것이라고 추측하고 있다.

> 가장 큰 문제는 모바일 브라우저 (크롬, 사파리)가 주소창이 보여지거나 숨겨져서 view port의 크기가 변경될 수 있다는 것이다. 이러한 브라우저는 view port 높이가 변경될때 현재 가시적인 부분으로 100vh를 수정하는 것이 아니라, 브라우저 주소 표시줄이 숨겨진 상태에서 100vh를 설정해둔다는 것이다. 그 결과, 주소표시줄이 다시 보이게 될 때 화면 하단 부분이 잘려나가서, 100vh의 목적을 위반하게 된다.

> https://chanind.github.io/javascript/2019/09/28/avoid-100vh-on-mobile-web.html

![100vh](https://chanind.github.io/assets/100vh_problem.png)

### 테스트

아래 테스트 페이지를 살펴보자. 하단에는 버튼이 있고, 이 모든 요소들은 `100vh`로 감싸져 있다.

![safari14-100vh](./images/safari14-100vh.png)

![safari15-100vh](./images/safari15-100vh.jpeg)

오오 해결된 것 같지만...

![safari15-100vh-floating-address-bar](./images/safari15-100vh-floating-address.jpeg)

> 짜잔 사실 해결되지 않았습니다.

Safari15에서도 `100vh`에는 변화가 없다. 이 쯤 되면 사실상 해결할 생각이 없거나, 혹은 이를 문제라고 보고 있는 것 같지 않다.

이를 해결하기 위해서는 어떻게 해야할까?

시간을 과거로 돌려, 아이폰 X가 처음나왔을때, 노치에 컨텐츠가 가려지는 문제를 해결하기 위하여 애플이 [`env`와 `safe-area-inset`을 소개했던 것](https://webkit.org/blog/7929/designing-websites-for-iphone-x/)을 떠올려보자.

사파리 14에서는, `safe-area-inset-bottom`의 값이 주소 창에 상관없이 0으로 고정되어 있었다. 그러나 사파리 15에서는 주소창이 활성화 되지 않은 상태에서의 `safe-area-inset-bottom`값은 0 이지만, 주소창이 펼쳐졌을 때는 그 값만큼 제공이 된다.

```css
footer {
  padding-bottom: calc(1em + env(safe-area-inset-bottom));
}
```

## Theme color

탭 모음 배경색은 더 이상 흰색 또는 회색으로 고정되어 있지 않고, 현재 페이지의 색 구성표에 맞게 조정된다. 이렇게 하면 화면에 좀더 몰입도를 가져올 수 있다. 기본적으로는 헤더나 바디의 배경색을 사용하여 사파리에서 자동으로 선택되지만, 문서헤더에 메타 태그를 사용하여 설정할 수도 있다.

![safari14-theme-color](./images/safari14-themecolor.png)

![safari15-theme-color](./images/safari15-themecolor.jpeg)

사파리 14, 15에서 내 블로그의 색이 다르게 나오는 것을 볼 수 있는데, 이는 아래 코드처럼 내가 강제로 색을 설정해두었기 때문이다.

```html
<meta name="theme-color" content="#00b7ff" />
```

이 말인 즉슨, 다른 DOM 노드 처럼 자바스크립트를 활용하여 사용자가 특정 작업을 사용하거나 특정 페이지를 방문할 때, `theme-color`를 동적으로 업데이트하여 사용자에게 더 큰 몰입감을 줄 수도 있다.

또한 이는 다크테마도 지원한다. 그래서 나는 아래 처럼 변경해보았다.

```html
<meta
  name="theme-color"
  content="#ffffff"
  media="(prefers-color-scheme: light)"
/>
<meta
  name="theme-color"
  content="#121826"
  media="(prefers-color-scheme: dark)"
/>
```

![safari15-theme-color-light](./images/safari15-theme-color-light.jpeg)

![safari15-theme-color-light](./images/safari15-theme-color-dark.jpeg)

> https://github.com/whatwg/html/issues/6495


웹 개발자가 본 사파리 15의 변화와 대응

## Table of Contents

## Introduction

오늘날의 웹 애플리케이션의 크기는 꽈거에 비해 꽤 커졌다. 특히, 자바스크립트의 비중이 그렇다. [http archive](https://httparchive.org/reports/state-of-javascript#bytesJs)의 자료를 보면, 자바스크립트 크기의 중위값을 본다면 데스크톱은 476.4KB, 모바일의 경우 439.0kb 정도로 무시할 수 있는 수준이 아니다. 그리고 이는 단순히 transfer 기준인 걸 알아야 한다. 일반적으로 네트워크를 오갈 때는 압축된 번들이 온다는 것을 고려해 봤을 때, 실제 압축이 해제된 크기를 본다면 더 클 것이다. 리소스를 처리할 때는 압축이 되지 않은 파일을 기준으로 하기 때문에 우리는 이점을 잘 기억해둬야 한다. 압축된 300kb의 자바스크립트 번들은, 압축 해제시 약 900kb 정도가 될 것이고, 이는 파서와 컴파일러에 900kb 만큼의 부담이 갈 것이다.

그리고 자바스크립트는 처리하는데 많은 비용이 드는 리소스다. 다운로드 후 비교적 가벼운 디코딩 시간만 소요되는 이미지와는 다르게, 자바스크립트는 파싱도 해야하고, 컴파일도 해야하고, 그리고 마지막으로 실행도 되어야 한다. 즉, 다른 리소스에 비해 자바스크립트는 _비싼_ 리소스다. [자바스크립트 엔진의 효율성을 개선하기 위한 작업](https://v8.dev/blog/background-compilation)이 지속적으로 이뤄지고 있지만 자바스크립트의 성능 향상 작업은 어디까지나 개발자의 몫이다.

이를 위해 자바스크립트의 성능을 향상시키는 다양한 기술들이 있다. [Code Splitting](https://webpack.js.org/guides/code-splitting/)과 같이 애플리케이션 자바스크립트를 청크로 분할하고, 이러한 청크를 필요한 애플리케이션 경로에만 제공하여 성능을 향상시킬수도 있다. 이 기술도 제법 괜찮지만, 자바스크립트가 많이 사용되는 애플리케이션의 일반적인 문제, 사용하지 않는 코드가 포함될 수도 있다. 이 문제를 해결하기 위한 것이 바로 트리쉐이킹이다.

## Tree shaking?

[Tree shaking](https://en.wikipedia.org/wiki/Tree_shaking)은 사용되지 않는 코드를 제거하는 기법을 의미한다. 이 용어는 [Rollup](https://github.com/rollup/rollup#tree-shaking) 덕분에 유명세를 타긴했지만, 사용되지 않는 코드를 제거한다는 개념은 원래도 존재하고 있었다. 그리고 이 개념은 [Webpack](https://webpack.js.org/guides/tree-shaking/)에서도 소개되었다.

트리쉐이킹이라는 용어는 애플리케이션을 일종의 나무와 같은 구조로 보는 대에서 유래되었다. 트리의 각 노드는 앱에 고유한 기능을 제공하는 종속성을 나타낸다. 최신 애플리케이션에서는, 다음과 같은 `import`를 활용하여 이러한 디펜던시 (종속성)을 가져온다.

```javascript
// Import all the array utilities!
import arrayUtils from 'array-utils'
```

애플리케이션 초기단계에서는 이러한 디펜던시가 상대적으로 적을 수도 있다. 그리고 처음에는 `import`했을 때 모든 디펜던시를 사용했을 수도 있다. 그러나 애플리케이션이 점점 커질 수록 이 디펜던시도 같이 커지게 된다. 그리고 시간이 지날 수록 사용하지 않는 디펜던시가 제거되지 않는 경우도 생기게 된다. 이러한 문제를 해결하기 위해, 트리쉐이킹은 static import 문을 사용하여 ES6 모듈의 특정 부분만을 가져오는 방법을 사용한다.

```javascript
// Import only some of the utilities!
import { unique, implode, explode } from 'array-utils'
```

위 `import`문과 차이점이라고 한다면, 모든 것을 `import` 하는 이전 코드와는 다르게 여기에서는 딱 필요한 method들만 `import`했다는 것이다. 이 코드가 dev build에서는 어차피 모든 모듈을 가져오기 때문에 실질적으로 변화가 일어나지 않는다. 그러나 프로덕션 빌드에서는 명시적으로 가져오지 않는 es6모듈에 대해 `export`를 `shake` 하도록 웹팩을 구성하여 프로덕션 빌드를 더 작게 만들 수 있다.

### 트리 쉐이킹을 할 수 있는지 확인해보기

[이 예제 저장소](https://github.com/malchata/webpack-tree-shaking-example)로 웹팩에서 어떻게 트리쉐이킹이 일어나는지 확인 해보고자 한다. 이 애플리케이션은 간단한 데이터베이스에서 검색을 하는 기능을 제공하고 있다. 쿼리를 입력하면, 제품목록이 뜬다.

그리고 이 애플리케이션의 자바스크립트 코드는 벤더 코드 (`Preact`, `Emotion`)와 애플리케이션 코드 번들 (청크)로 나눠져 있다.

```bash
                 Asset        Size  Chunks             Chunk Names
js/vendors.a3722bf0.js    37.1 KiB       0  [emitted]  vendors
js/main.951b863a.js       20.8 KiB       1  [emitted]  main
```

번들크기가 21.1kb로 큰 편은 아니다. 그러나 이는 트리쉐이킹이 되지 않았다는 점을 알아야 한다.

애플리케이션 코드의 `FilterablePedalList` 컴포넌트에서 아래와 같은 코드를 확인할 수 있다.

```javascript
import * as utils from '../../utils/utils'
```

아마 이런 코드를 어디에선가 본적이 있을 것이다. 이 같이 `import`하는 것은 주의할 필요가 있다. 이 뜻은 `../../utils/utils`에 있는 것을 모두 `utils` 네임스페이스에 저장하라는 뜻이다. 여기서 중요한 것은 저 모듈에 얼마나 많은 모듈이 있는가이다.

확인해보니 약 1300줄의 코드가 있는 것을 확인해 볼 수 있다. 뭐 물론, 그렇다고 이게 꼭 잘못되었다고만 할 순 없다. 저기에 있는 모든 모듈을 쓰고 있다면 불가피한 선택이었을 수도 있다. 그러나 실제로 저 컴포넌트에서 쓰고 있는 `utils` 모듈은 고작 3개 뿐이다.

물론, 이 예시가 극단적인 케이스이긴 하다. 그러나 이러한 가상 시나리오가 실제 애플리케이션 코드에서 발견할 수 있는 최적화 사례와 유사하다는 사실은 분명하다. 이제 이를 트리쉐이킹 하기 위해서는 어떻게 해야할까?

### 바벨이 es6 모듈을 commonjs module로 변환하지 않도록 하기

Babel은 대부분의 웹 애플리케이션이 필요로 하는 필수 도구다. 그러나 아쉽게도, 트리쉐이킹과 같은 간단한 작업도 이 babel 때문에 어려워 지는 경우가 발생한다. 만약 [babel-preset-env](https://babeljs.io/docs/plugins/preset-env/)를 사용한다면, 이 모듈이 es6를 자동으로 commonjs 변환해준다. 즉, `import`를 `require`로 바꿔주기도 한다. 이는 훌륭한 기능이지만, 트리 쉐이킹 관점에서는 그렇지 못하다.

트리쉐이킹 관점에서 commonjs의 문제점은 웹팩이 어떤 모듈이 사용중인지 아닌지를 판단하여 제거하기가 어렵다는 것이다. 이를 위해 `.babelrc`에서 `commonjs`로 변환하지 못하도록 설정을 추가해 줘야 한다.

```javascript
{
  "presets": [
    ["env", {
      "modules": false
    }]
  ]
}
```

`"modules": false`를 지정하면, babel이 우리가 원하는 대로 동작하게 되어 디펜던시를 분석하고 사용되지 않는 디펜던시를 제거할 수 있다. 또한 웹팩은 코드를 광범위하게 호환되는 형식으로 변환하므로, 이 프로세스는 호환성 문제를 일으키지 않는다.

### `sideEffects` 활용하기

이렇게 트리쉐이킹을 할 때 고려해야할 또다른 측면은 프로젝트의 모듈이 부수효과를 일으키지는 지 여부다.

```javascript
let fruits = ['apple', 'orange', 'pear']

console.log(fruits) // (3) ["apple", "orange", "pear"]

const addFruit = function (fruit) {
  fruits.push(fruit)
}

addFruit('kiwi')

console.log(fruits) // (4) ["apple", "orange", "pear", "kiwi"]
```

`addFruit`은 `fruit` 배열의 마지막에 원소를 추가하지만, 이는 `addFruit`의 범위를 벗어나는 일을 하고 있다.

이러한 부수효과는 es6 모듈에서도 똑같이 적용되며, 이 또한 트리쉐이킹 관점에서 문제가 될 수 있다. 예측 가능한 입력값을 받고, 예측가능한 출력을 내뱉는 모듈을 트리쉐이킹 할 경우, 이를 사용하지 않을 때 트리쉐이킹을 하면 안전하게 처리할 수 있다.

웹팩의 경우 `package.json`에 `sideEffects: false`로 지정하여 패키지와 패키지 사이에 부수효과가 없음을 암시할 수 있다.

```json
{
  "name": "webpack-tree-shaking-example",
  "version": "1.0.0",
  "sideEffects": false
}
```

혹은, 특정 파일에 대해서만 부수효과가 없다고 지정할 수 있다.

```json
{
  "name": "webpack-tree-shaking-example",
  "version": "1.0.0",
  "sideEffects": ["./src/utils/utils.js"]
}
```

후자의 예제의 경우, 여기에서 지정된 파일은 부수효과가 없는 것으로 가정한다. `package.json`에 추가하고 싶지 않으면, [`module.rules`를 활용하여 설정할 수 있다.](https://github.com/webpack/webpack/issues/6065#issuecomment-351060570)

### 필요한 것 만 import 하기

`Babel`의 설정을 es6로 유지하도록 변경했지만, 모듈에서 필요한 함수만 가져오도록 수정해야 한다.

```javascript
import { simpleSort } from '../../utils/utils'
```

이 구문은, `../../utils/utils`에서 `simpleSort`만 가져오도록 지정한다. 전체 유틸리티 모듈이 아닌, 하나의 함수만 가져오므로 기존의 `utils.simpleSort`를 모두 `simpleSort`로 수정해야 한다.

이제 번들 크기를 다시 확인해보자.

```bash
                 Asset        Size  Chunks             Chunk Names
js/vendors.a3722bf0.js    37.1 KiB       0  [emitted]  vendors
   js/main.951b863a.js    20.8 KiB       1  [emitted]  main
```

```bash
                 Asset        Size  Chunks             Chunk Names
js/vendors.b007c500.js    36.9 KiB       0  [emitted]  vendors
   js/main.2b536ea2.js    8.45 KiB       1  [emitted]  main
```

두개 번들 크기 모두 줄었지만, 여기서 가장 큰 해택을 본 것은 `main` 쪽이다. 실제로 사용하지 않는 부분을 제거하여 약 60%의 코드를 날려버릴 수 있었다. 이렇게 하면 스크립트가 다운로드 하는데 걸리는 시간 뿐만 아니라 처리하는데 걸리는 시간도 줄일 수 있다.

### 무엇을 해야할지 감이 오지 않을 때

대부분의 경우 이정도 수정을 거치면 최신버전의 웹팩에서 트리쉐이킹이 동작하지만, 그럼에도 불구하고 제대로 동작하지 않는 경우가 있다. 예를 들어 [Lodash](https://lodash.com/)와 같은 경우가 있다. Lodash의 설계적인 특성상, [Lodash-es](https://www.npmjs.com/package/lodash-es)%20install%20the-,lodash-es,-package%20in%20lieu)를 설치해서 사용해야 한다.

https://yceffort.kr/2020/07/how-commonjs-is-making-your-bundles-larger

```javascript
// This still pulls in all of lodash even if everything is configured right.
import { sortBy } from 'lodash'

// This will only pull in the sortBy routine.
import sortBy from 'lodash-es/sortBy'
```

`import` 구문을 일관되게 유지하고 싶다면, [babel-plugin-lodash](https://www.npmjs.com/package/babel-plugin-lodash)를 설치하여 사용하면 된다.

그럼에도 불구하고 트리 쉐이킹의 적용을 받지 않는 라이브러리가 있다면, es6 구문을 활용하여 메서드를 내보내는지 여부를 확인해야 한다. CommonJS 방식인 `module.exports`를 사용하는 경우 웹팩에서 트리쉐이킹이 불가능하다. 그럼에도, [webpack-common-shake](https://github.com/indutny/webpack-common-shake)와 같은 라이브러리를 사용하면 가능할 수도 있지만, [일부 케이스의 경우 트리쉐이킹이 완벽하게 되지 않는다.](https://github.com/indutny/webpack-common-shake#limitations) 그러므로 안정적인 트리 쉐이킹을 위해서는 es6 모듈을 사용하는 것이 좋다.

## 마치며

트리 쉐이킹에서 어떤일이 발생할지는 애플리케이션과 애플리케이션의 의존성, 아키텍쳐에 달려있다. 지금 바로 해보자. 번들에서 사용하지 않는 코드를 삭제한다면 최적화를 일궈낼 수 있다. 물론, 트레 쉐이킹을 하더라도 이득이 없을 수도 없다. 그러나 프로덕션 빌드에서 이러한 최적화를 활용하도록 빌드 시스템을 구성하고, 애플리케이션에서 필요한 것만 선택적으로 가져오면 애플리케이션을 최소한의 크기로 유지할 수 있다. 이는 성능 측면에서, 그리고 사용자 측면에서 모두 좋다.


트리쉐이킹은 직접 해드세요 제발

트리쉐이킹으로 자바스크립트 사이즈 줄이기

사이트와 애플리케이션에는 실행해야할 스크립트가 잔뜩 쌓여있다. 이러한 자바스크립트가 최대한 빨리 실행되야 하는 것이 좋지만, 그와 동시에 사용자의 방해가 되지 않도록 해야 한다. 사용자가 페이지를 스크롤 할 때 데이터를 보내거나, DOM에 element를 추가해야 하는 경우 웹 애플리케이션이 응답하지 않아 사용자 경험이 저하될 수 있다.

이를 해결하기 위해 [requestIdleCallback](https://developer.mozilla.org/ko/docs/Web/API/Window/requestIdleCallback)이라는 API가 있다. `requestAnimationFrame`을 사용하면 애니메이션을 적절하게 스케쥴링하고, 60fps를 달성하는데 도움을 줄 수 있는 것 처럼, `requestIdleCallback`은 프레임이 끝나는 지점에 있거나, 사용자가 비활성화 상태일 때 작업을 예약할 수 있다.

- https://developer.mozilla.org/ko/docs/Web/API/Window/requestIdleCallback
- https://w3c.github.io/requestidlecallback/
- https://github.com/pladaria/requestidlecallback-polyfill

## 왜 `requestIdleCallback`인가

필수적이지 않은 작업을 스케쥴링해서 처리하는 것은 매우 어렵다. `requestAnimationFrame` 콜백을 실행한 후 스타일 연산, 레이아웃, 페인팅 및 기타 브라우저 내부에서 실행해야하는 작업을 수행하기 때문에, 현재 남은 프레임 시간을 정확히 파악하는 것은 어렵다. 개발자가 여기에서 해볼 수 있는 시도는 많지 않다. 사용자가 어떤 방식으로든 인터랙션을 하지 못하게 하려면, 사용자가 할 수 있는 모든 종류의 인터랙션 (스크롤, 터치, 클릭 등)에 listener를 달아야 한다. 반면 브라우저는 프레임 작업이 끝난 이후에 얼마나 여유가 있는지, 그리고 사용자가 인터랙션 중인지 알 고 있기 때문에 `requestIdleCallback`을 사용해 가능한 효율적으로 이 빈 시간을 활용할 수 있는 api를 쓸 수 있다.

## `requestIdleCallback`

- https://caniuse.com/requestidlecallback

IE에서는 사용이 불가능하고, safari에서는 (여전히) 실험적 기능으로 제공되고 있다.

polyfill

- https://github.com/pladaria/requestidlecallback-polyfill/blob/master/index.js
  - timeout을 이용해서 적용
- https://github.com/aFarkas/requestIdleCallback
  - 말그대로 사용자가 할 수 있는 모든 이벤트에 리스너를 달아둬서 해결

## `requestIdleCallback` 사용해보기

`requestIdleCallback`은 [requestAnimationFrame](https://developer.mozilla.org/ko/docs/Web/API/Window/requestAnimationFrame)과 매우 비슷하다.

```javascript
requestIdleCallback(myNonEssentialWork)
```

`myNonEssentialWork`가 호출되면, 이 작업의 남은시간을 나타내는 함수가 포함된 [deadline](https://developer.mozilla.org/ko/docs/Web/API/IdleDeadline)객체를 넘겨받는다.

```javascript
function myNonEssentialWork(deadline) {
  while (deadline.timeRemaining() > 0) doWorkIfNeeded()
}
```

`timeRemaining`함수를 호출하여 현재 최신 값을 가져올 수도 있다. `timeRemaining`의 값이 0 이면서, 다음 작업이 또 있는 경우에는 `requestIdleCallback`으로 다음 작업을 또 예약할 수도 있다.

```javascript
function myNonEssentialWork(deadline) {
  while (deadline.timeRemaining() > 0 && tasks.length > 0) doWorkIfNeeded()

  if (tasks.length > 0) requestIdleCallback(myNonEssentialWork)
}
```

## 함수 호출을 보장받는 방법

만약 작업이 정말 정말 바쁘면 어떻게 될까? 콜백이 실행되지 않을지 걱정될 수도 있다. `requestIdleCallback`은 `requestAnimationFrame`와 다르게 두번째 인수가 존재한다. 이 인수에서는, timeout을 넘길 수 있는데, 이 설정된 시간이 초과된 경우 idle 상태와 상관없이 그냥 실행해버린다.

```javascript
// 2초는 내가 기다려본다...
requestIdleCallback(processPendingAnalyticsEvents, { timeout: 2000 })
```

이렇게 시간 초과로 인해 콜백이 실행되는 경우 아래 두가지를 확인할 수 있다.

- `timeRemaining()`은 0을 반환
- `didTimeout`이 true가 됨

```javascript
function myNonEssentialWork(deadline) {
  while (
    (deadline.timeRemaining() > 0 || deadline.didTimeout) &&
    tasks.length > 0
  )
    doWorkIfNeeded()

  if (tasks.length > 0) requestIdleCallback(myNonEssentialWork)
}
```

이 timeout으로 인해 사용자 작업이 중단될 수도 있으므로 (작업으로 인해 애플리케이션이 응답하지 않거나 오류가 나거나), 이 인수를 사용할 때는 주의해야 한다.

## 데이터 분석을 위해 `requestIdleCallback`사용하기

`requestIdleCallback`를 사용하는 예제를 살펴보자. 이 경우 메뉴를 클릭하는 것과 같은 이벤트를 추적할 수 있다 그러나 일반적으로 메뉴를 클릭하면 화면에 애니메이션이 함께 표시되므로, google analytics에 이 이벤트를 즉시 보내지 않도록 설정해보자.

```javascript
var eventsToSend = []

function onNavOpenClick() {
  // 메뉴를 여는 이벤트
  menu.classList.add('open')

  // 보낼 이벤트를 저장해둔다.
  eventsToSend.push({
    category: 'button',
    action: 'click',
    label: 'nav',
    value: 'open',
  })

  schedulePendingEvents()
}
```

`requestIdleCallback`를 활용하여 이 이벤트를 실행해보자.

```javascript
function schedulePendingEvents() {
  // isRequestIdleCallbackScheduled 가 있으면 예약하지 않는다.
  if (isRequestIdleCallbackScheduled) return

  // 없으면 작업시작 준비
  isRequestIdleCallbackScheduled = true

  if ('requestIdleCallback' in window) {
    // 최대 2초 대기
    requestIdleCallback(processPendingAnalyticsEvents, { timeout: 2000 })
  } else {
    processPendingAnalyticsEvents()
  }
}
```

이 예제에서는 2초로 설정했지만, 애플리케이션에 따라 이 값이 달라질 수 있다.데이터 분석의 경우, 데이터를 미래의 특정 시점에 리포트 하는 것이 아니라 적절한 시간에 리포팅 해야 한다.

```javascript
function processPendingAnalyticsEvents(deadline) {
  // false 상태로 만들어 다음 작업도 받게함
  isRequestIdleCallbackScheduled = false

  // deadline이 없다면, 바로 실행
  if (typeof deadline === 'undefined')
    deadline = {
      timeRemaining: function () {
        return Number.MAX_VALUE
      },
    }

  // 작업이 남아있고, 여유가 있는 경우 실행
  while (deadline.timeRemaining() > 0 && eventsToSend.length > 0) {
    var evt = eventsToSend.pop()

    ga('send', 'event', evt.category, evt.action, evt.label, evt.value)
  }

  // 해야할 작업이 있다면 다시 예약
  if (eventsToSend.length > 0) schedulePendingEvents()
}
```

이 예제에서는, `requestIdleCallback`가 없으면 바로 전송하도록 해두었다. 그러나 프로덕션 애플리케이션에서는 사용자의 상호작용과 충돌하지 않고 에러가 발송하지 않도록 timeout으로 지연해서 전송하는 것이 좋다.

## `requestIdleCallback`으로 DOM 조작하기

`requestIdleCallback`이 성능에 도움이 될 수 있는 또다른 상황은, 필수적이지 않은 DOM을 변경해야 하는 경우가 있다. 예를 들어, 지속적으로 children 하단에 붙어서 로딩되는 DOM과 같은 것을 들 수 있다.

![](https://developers.google.com/web/updates/images/2015-08-27-using-requestidlecallback/frame.jpg)

먼저, 브라우저가 지속적으로 사용중이어서, 작업을 할 수 있는 여유시간이 없는 경우도 가정해야 한다. 이 경우, 프레임별로 `setImmediate`를 실행해야 한다.

프레임이 끝나는 지점에서 콜백이 실행되면, 현재 프레임이 커밋된 이후에 실행할 수 있도록 스케쥴링 될 것이다. 즉, 스타일 변경사항이 적용되고, 레이아웃이 다시 계산될 것이다. idle callback내에서 DOM을 조작하려면, 레이아웃 계산이 취소될 수 있다. 다음 프레임에서 `getBoundingClientRect`이나 `clientWidth`와 같이 현재 레이아웃을 읽어오는 메소드가 있는 경우, [강제 동기식 레이아웃](https://developers.google.com/web/fundamentals/performance/rendering/avoid-large-complex-layouts-and-layout-thrashing#avoid-forced-synchronous-layouts)을 수행해야 하는데 이 경우 브라우저에서 성능 저하가 일어날 수 있다.

idle callback에서 DOM 조작을 트리거하지 않는 또다른 이유는, DOM 에 걸리는 시간을 예측할 수 없기 때문에, 브라우저에서 제공한 deadline을 쉽게 넘길 수 있기 때문이다.

따라서 가장 좋은 방법은 브라우저가 스스로 스케쥴링할 수 있는 `requestAnimationFrame` 콜백 내부에서 DOM 조작을 하는 것이다. 하나 주의해야할 것은, 만약 가상돔 라이브러리를 사용한다면 `requestIdleCallback`에서 변경작업을 수행하지만, idle callback이 아닌 다음 `requestAnimationFrame`에서 DOM 변경작업을 적용한다.

```javascript
function processPendingElements(deadline) {
  // deadline이 없으면, 바로 실행
  if (typeof deadline === 'undefined')
    deadline = {
      timeRemaining: function () {
        return Number.MAX_VALUE
      },
    }

  if (!documentFragment) documentFragment = document.createDocumentFragment()

  // 작업에 여유가 있고, 작업이 있으면 바로 실행
  while (deadline.timeRemaining() > 0 && elementsToAdd.length > 0) {
    var elToAdd = elementsToAdd.pop()
    var el = document.createElement(elToAdd.tag)
    el.textContent = elToAdd.content

    documentFragment.appendChild(el)

    // 바로 실행하는 것이 아니고, 다음 requestAnimationFrame 까지 대기
    scheduleVisualUpdateIfNeeded()
  }

  if (elementsToAdd.length > 0) scheduleElementCreation()
}
```

```javascript
function scheduleVisualUpdateIfNeeded() {
  if (isVisualUpdateScheduled) return

  isVisualUpdateScheduled = true

  requestAnimationFrame(appendDocumentFragment)
}

function appendDocumentFragment() {
  // Append the fragment and reset.
  document.body.appendChild(documentFragment)
  documentFragment = null
}
```

## 더 읽어보기

- https://developers.google.com/web/updates/2015/08/using-requestidlecallback
- https://engineering.linecorp.com/ko/blog/line-securities-frontend-4/
- https://www.w3.org/TR/requestidlecallback/


requestIdleCallback으로 최적화하기

## Table of Contents

## 이벤트 루프는 정확히 무엇인가?

`이벤트 루프` 사실 일반적인 프로그래밍 패턴을 지칭하는 용어다. 프로그래밍의 이벤트나 메시지를 대기하나가 처리하는 일종의 프로그래밍 구조체라고 볼 수 있다. (https://ko.wikipedia.org/wiki/%EC%9D%B4%EB%B2%A4%ED%8A%B8_%EB%A3%A8%ED%94%84) 자바스크립트와 Nodejs의 이벤트 루프도 별반 다르지 않다. 자바스크립트는 애플리케이션이 실행되면 다양한 이벤트를 발생시키고, 이러한 이벤트는 처리를 위해 이벤트 핸들러 형태로 대기열에 존재한다. 이벤트 루프는 대기중인 이벤트 핸들러를 지속적으로 지켜보다가, 이벤트 핸들러가 존재하면 이를 실행한다.

### HTML5 스펙으로 살펴보는 이벤트 루프

[HTML5의 스펙](https://html.spec.whatwg.org/)은 여러 벤더가 브라우저나 자바스크립트 런타임, 또는 기타 관련한 라이브러리를 개발하는데 사용할 수 있는 표준 가이드라인을 제시한다.

대부분의 브라우저와 자바스크립트 런타임은 이러한 가이드라인을 그대로 따르기 때문에 전세계 웹서비스에 더 나은 호환성을 제공한다. 그러나 사실은 이 단일 소스에서 약간씩 벗어나서 흥미로운 (혹은 짜증나는) 결과를 유발하기도 한다.

여기에서는 이러한 흥미로운 결과, 특히 Nodejs와 브라우저와의 차이에 대해서 알아보려고 한다. 개별 브라우저 구현은 언제든 조금씩 변할 수 있으므로, 자세히 알아보지는 않는다.

### 클라이언트 사이드와 서버사이드 자바스크립트

지난 수년간, 자바스크립트는 브라우저에서 실행되는 웹 애플리케이션에서만 사용되어져 왔다. 그리고 이 후 자바스크립트는 nodejs를 사용하여 서버 사이드 애플리케이션을 만드는데에도 사용할 수 있다. 두 곳 모두 자바스크립트를 사용하지만, 클라이언트와 서버사이드에서의 요구사항은 조금씩 다를 수 있다.

브라우저는 일종의 샌드박스 환경이며, 파일 시스템 작업, 네트워크 작업 등 자바스크립트가 수행할 수 있는 작업에 권한 제한이 있다. 그러나 서버사이드 자바스크립트(Nodejs)는 이벤트루프에서 이러한 것들을 모두 실행할 수 있다.

브라우저와 Nodejs 모두 자바스크립트를 사용하여 비동기 이벤트 기반 패턴을 구현한다. 그러나 브라우저의 맥락에서 봤을 때에 "이벤트"란 웹 페이 지 내에서의 상호작용 (클릭, 마우스 이동, 키보드 이벤트 등..)이지만, Nodejs에서의 맥락에서 이벤트란 파일 I/O, 네트워크 I/O 등이다. 이러한 요구 사항의 차이로 인해 크롬과 Node는 자바스크립트 실행을 위해 모두 V8 엔진을 사용하지만, 이벤트 루프 구현에는 차이가 있다.

'이벤트루프'란 결국 프로그래밍 패턴에 불과하기 때문에, V8은 자바스크립트 런타임과 함께 외부 이벤트 루프 구현을 플러그인 해줄 수 있록 해준다. 이러한 유연성을 바탕으로, 크롬 브라우저는 [libevent](https://libevent.org/)를, nodejs는 [libuv](https://blog.insiderattack.net/javascript-event-loop-vs-node-js-event-loop-aea2b1b85f5c#:~:text=and%20NodeJS%20uses-,libuv,-to%20implement%20the)를 각각 이벤트 루프 구현을 위해 사용한다. 그러므로, 자바스크립트와 Nodejs의 이벤트루프는 기본적으로 다른 라이브러리를 사용하여 약간의 차이가 있을 수 있지만, '이벤트루프'라고 하는 일반적인 프로그래밍 패턴을 구현하고 있다는 것에서 비슷하다.

## 브라우저 vs Nodejs 무엇이 다른가?

### 마이크로, 그리고 매크로 태스크

> 간단히말해, 마이크로 태스크와 매크로 태스크는 서로 다른 비동기 태스크 처리기다. 매크로 태스크에 비해 마이크로 태스크의 우선순위가 더 높다. 마이크로 태스크의 예로는 `Promise`가 있다. `setTimeout은 대표적인 매크로 태스크다.

브라우저와 Nodejs에 눈에 띄는 차이점은 **마이크로 태스크와 매크로 태스크의 우선순위를 어떻게 정하느냐** 이다. Nodejs 11 이상에서는 브라우저의 동작과 일치하지만, 이전 버전은 상당히 다르다. 자, 아래 면접 질문으로 나올 것 만 같은 아래 코드르 보자.

> Nodejs 11이전 버전에서 무슨일이 있는지 살펴보려면 https://blog.insiderattack.net/new-changes-to-timers-and-microtasks-from-node-v11-0-0-and-above-68d112743eb3

```javascript
Promise.resolve().then(() => console.log('promise1 resolved'))
Promise.resolve().then(() => console.log('promise2 resolved'))
setTimeout(() => {
  console.log('set timeout3')
  Promise.resolve().then(() => console.log('inner promise3 resolved'))
}, 0)
setTimeout(() => console.log('set timeout1'), 0)
setTimeout(() => console.log('set timeout2'), 0)
Promise.resolve().then(() => console.log('promise4 resolved'))
Promise.resolve().then(() => {
  console.log('promise5 resolved')
  Promise.resolve().then(() => console.log('inner promise6 resolved'))
})
Promise.resolve().then(() => console.log('promise7 resolved'))
```

> `queueMicrotask`를 사용하여 마이크로 태스크를 스케쥴링 할 수도 있다.

브라우저 (크롬, 파이어폭스, 사파리. IE는 브라우저가 아니므로 제외) + Nodejs 11 이상

```bash
promise1 resolved
promise2 resolved
promise4 resolved
promise5 resolved
promise7 resolved
inner promise6 resolved
set timeout3
inner promise3 resolved
set timeout1
set timeout2
```

Nodejs 11 미만

```bash
promise1 resolved
promise2 resolved
promise4 resolved
promise5 resolved
promise7 resolved
inner promise6 resolved
set timeout3
set timeout1
set timeout2
inner promise3 resolved
```

[HTML5 스펙에 정의된 이벤트 루프 가이드라인](https://html.spec.whatwg.org/multipage/webappapis.html#event-loop-processing-model)에 따르면, 이벤트 루프는 매크로 태스큐에서 하나의 매크로 태스크를 처리하기전에 마이크로 태크스에 있는 모든 것을 처리해야 된다. 이 예제에서는, `set timeout3` 콜백이 실행되면, promise 콜백을 예약한다. HTML5의 스펙에 따라서, 타이머 콜백 큐의 다른 콜백을 처리하기전에, 이벤트 루프가 마이크로태스크 큐가 비어있는지 확인해야 한다. 따라서 새로 추가된 promise callback을 실행하고 처리하여야 한다. 이 작업을 처리하면, 비로소 마이크로 태스크 큐가 비어 이벤트 루프가 남은 `setTimeout1` `setTimeout2`을 실행할 수 있게 된다.

그러나 11 버전 이전의 nodejs에서는, 이벤트 루프의 두 사이 단계에서만 마이크로 태스크열을 비우게 된다. 따라서 `inner promise3`은 모든 `setTimeout3`이 실행되기 전까지 실행될 수가 없게 된다.

### 내부 타이머 동작의 차이

타이머 동작은 Nodejs, 브라우저 간 뿐만아니라 브라우저 벤더간, 버전마다 다르다. 여기서 가장 주목할만한 두가지는 timeout이 0일때와, timeout이 중첩되어 있을 때다. 이 러한 두가지 동작의 차이를 알기 위해 Nodejs v10.19.0, v11.0.0, chrome, firefox, safari에서 아래의 코드를 실행해보자. 이 코드는 timeout이 0 인 중첩타이머 8개를 스케쥴링하고, 각 콜백이 스케쥴링 된이후 실행되기까지의 걸린 시간을 계산한다.

```javascript
const startHrTime = () => {
  if (typeof window !== 'undefined') return performance.now()
  return process.hrtime()
}

const getHrTimeDiff = (start) => {
  if (typeof window !== 'undefined') return performance.now() - start
  const [ts, tns] = process.hrtime(start)
  return ts * 1e3 + tns / 1e6
}

console.log('start')
const start1 = startHrTime()
const outerTimer = setTimeout(() => {
  const start2 = startHrTime()
  console.log(`timer1: ${getHrTimeDiff(start1)}`)
  setTimeout(() => {
    const start3 = startHrTime()
    console.log(`timer2: ${getHrTimeDiff(start2)}`)
    setTimeout(() => {
      const start4 = startHrTime()
      console.log(`timer3: ${getHrTimeDiff(start3)}`)
      setTimeout(() => {
        const start5 = startHrTime()
        console.log(`timer4: ${getHrTimeDiff(start4)}`)
        setTimeout(() => {
          const start6 = startHrTime()
          console.log(`timer5: ${getHrTimeDiff(start5)}`)
          setTimeout(() => {
            const start7 = startHrTime()
            console.log(`timer6: ${getHrTimeDiff(start6)}`)
            setTimeout(() => {
              const start8 = startHrTime()
              console.log(`timer7: ${getHrTimeDiff(start7)}`)
              setTimeout(() => {
                console.log(`timer8: ${getHrTimeDiff(start8)}`)
              })
            })
          })
        })
      })
    })
  })
})
```

`node 10.1.0`

```bash
timer1: 0.650208
timer2: 1.617334
timer3: 1.456791
timer4: 1.417208
timer5: 1.38725
timer6: 1.379334
timer7: 1.374334
timer8: 1.377042
```

`node 14.17.1`

```bash
timer1: 0.990541
timer2: 1.715584
timer3: 1.872625
timer4: 1.55775
timer5: 1.509125
timer6: 1.48125
timer7: 1.474916
timer8: 1.4655
```

`chrome`

```bash
timer1: 1.5999999940395355
timer2: 1.399999976158142
timer3: 1.5
timer4: 1.4000000059604645
timer5: 5.300000011920929 # 4번째 타이머 부터 4ms 이후에 실행됨
timer6: 5.199999988079071
timer7: 4.9000000059604645
timer8: 5.300000011920929
```

`safari`

```bash
timer1: 1
timer2: 1.0000000000004547
timer3: 1.9999999999995453
timer4: 1
timer5: 1.0000000000004547
timer6: 4.999999999999545
timer7: 4
timer8: 5
```

`firefox`

```bash
timer1: 0
timer2: 0
timer3: 0
timer4: 1
timer5: 5
timer6: 6
timer7: 5
timer8: 5
```

살펴본 결과 아래 몇가지 사실을 알 수 있었다.

- 0으로 설정하더라도, Nodejs 타이머는 최소 1ms이후에 실행된다.
- 크롬과 파이어폭스는 처음 4개의 타이머가 1ms 언저리에 실행되었지만, 그 후에는 4ms 이후에 실행되었다.
- 사파리는 크롬/파이어폭스와 비슷하지만, 6번째 타이머부터 4ms 이후에 실행된다.

브라우저에서오는 4ms 의 시간차이는 어디서 만들어진걸까? 이는 앞서 언급했던 [HTML5 스펙](https://html.spec.whatwg.org/multipage/timers-and-user-prompts.html#timers)에 기재되어 있다.

> Timers can be nested; after five such nested timers, however, the interval is forced to be at least four milliseconds.

이 규칙에 따르면, 크롬과 파이어폭스는 기재된 스펙에 맞게 5번째 부터 발생했지만, 사파리는 규칙을 제대로 따르고 있지 않는 것 같다.

브라우저는 잠시 뒤로하고, node는 중첩에 따라 시간 제한을 별도로 두지 않아도 된다는 것을 알 수 있다.

### Nodejs와 Chrome의 최소 타임아웃 시간

NodeJs와 크롬 모두 중첩되지 않은 경우라 할지라도 모든 타이머에 최소 1ms의 시간 지연이 발생한다. 그러나 크롬과 다르게 nodejs는 중첩수준에 상관없이 꾸준히 1ms내외로만 적용된다. 아래 코드를 살펴보면, 모든 타이머에 1ms의 시간이 왜 nodjs에서 적용되는지 알 수 있다.

```javascript
function Timeout(callback, after, args, isRepeat, isRefed) {
  after *= 1 // Coalesce to number or NaN
  if (!(after >= 1 && after <= TIMEOUT_MAX)) {
    if (after > TIMEOUT_MAX) {
      process.emitWarning(
        `${after} does not fit into` +
          ' a 32-bit signed integer.' +
          '\nTimeout duration was set to 1.',
        'TimeoutOverflowWarning',
      )
    }
    after = 1 // Schedule on next tick, follows browser behavior
  }

  // ....redacted
}
```

크롬도 위와 비슷한 작업을 `DOMTimer`에서 한다. 그리고, `maxTimerNestingLevel`에 다다르면 4ms가 적용되는 것도 알 수 있다.

```cpp
DOMTimer::DOMTimer(ExecutionContext* context, PassOwnPtrWillBeRawPtr<ScheduledAction> action, int interval, bool singleShot, int timeoutID)
    : SuspendableTimer(context)
    , m_timeoutID(timeoutID)
    , m_nestingLevel(context->timers()->timerNestingLevel() + 1)
    , m_action(action)
{
    // ... redacted ...
    double intervalMilliseconds = std::max(oneMillisecond, interval * oneMillisecond);
    if (intervalMilliseconds < minimumInterval && m_nestingLevel >= maxTimerNestingLevel)
        intervalMilliseconds = minimumInterval;
    if (singleShot)
        startOneShot(intervalMilliseconds, FROM_HERE);
    else
        startRepeating(intervalMilliseconds, FROM_HERE);
}
```

위에서 알 수 있듯, 자바스크립트 런타임에는 타이머와 중첩된 타이머가 0으로 설정되었을 때 실행되는 방법에 대한 독특한 구현이 있다. 따라서 자바스크립트 애플리케이션이나 라이브러리를 개발 할 때, 호환성을 높이기 위해 런타임 별 동작에 크게 의존하지 않는 것이 좋다.

### `process.nextTick`, `setImmediate`

또다른 브라우저와 nodejs의 차이점은 `process.nextTick`과 `setImmediate`이다.

`process.nextTick`은 NodeJS에만 있는 api이며 브라우저에는 이와 비슷한 동작을 하는 api는 없다. `nextTick`이 nodejs의 libuv 이벤트 루프의 일부는 아니지만, `nextTick`은 이벤트 루프 동안 nodejs가 C++과 JS 경계를 넘어가는 과정에서 실행된다. 그래서, 어떤 측면에서는 이벤트 루프와 관련있다고 볼 수도 있다.

`setImmediate`또한 Nodejs 전용 api다. [MDN](https://developer.mozilla.org/en-US/docs/Web/API/Window/setImmediate)과 [caniuse.com](https://caniuse.com/?search=setImmediate)에 따르면, 놀랍게도 IE10, 11, 그리고 초기 엣지 버전에서 사용이 가능한 api다. 그외에 다른 브라우저 에서는 사용이 불가능하다.

둘의 차이를 알기 위해서는, 이벤트 루프의 과정에 대해 알필요가 있다.

![pahse of event loop](https://jinoantony.com/static/624c9768d8888b109a4649298c0cb091/29492/event-loop.png)

1. Timer: `setTimeout`의 시간이 다된 타이머, `setInterval`로 추가된 인터벌 함수가 실행됨
2. Pending Callback: 다음 루프로 지연된 I/O 콜백을 실행
3. Idle handler: 내부적으로 사용되는 libuv 내부 작업을 수행
4. Prepare Handler: 내부적으로 사용되는 I/O를 폴링하기전에 몇가지 사전작업 수행
5. I/O poll: 새 I/O 이벤트를 검색하고, I/O 관련 콜백을 실행
6. Check Handler: `setImmediate`가 실행
7. Close callback: 클로즈 핸들러 실행

`setImmediate()`

```javascript
console.log('Start')
setImmediate(() => console.log('Queued using setImmediate'))
console.log('End')
```

```bash
Start
End
Queued using setImmediate
```

`setImmediate()`는 callback을 인수로 받으며, 이를 이벤트 큐에 추가한다. (immediate queue) 위에서 언급했듯, `setImmediate()`는 `Check Handler`과정에서 수행된다.

`process.nextTick()`

```javascript
console.log('Start')
process.nextTick(() => console.log('Queued using process.nextTick'))
console.log('End')
```

```bash
Start
End
Queued using process.nextTick
```

마찬가지로 callback을 인수로 받지만, `next tick` 큐라고 하는 별도의 큐에 추가한다. 이 `process.nextTick()`로 넘겨받은 callback은 현재 phase가 넘어간 이후에 실행된다. 즉, 이벤트 루프의 각 단계가 넘어갈 때마다 실행된다.

따라서, 차이점을 정리하자면

1. `setTimeout`은 Check handler과정에서 실행되지만, `process.nextTick`은 이벤트 루프의 각 단계 사이에서 실행된다.
2. 1번에 의거하여, `process.nextTick`의 우선순위가 더 높다. (= 먼저 실행된다.)

   ```javascript
   setImmediate(() => console.log('I run immediately'))

   process.nextTick(() => console.log('But I run before that'))
   ```

   ```bash
   But I run before that
   I run immediately
   ```

3. 만약 특정 단계에서 `process.nextTick()`이 호출되면, 이벤트루프를 계속하기전에 모든 콜백이 전달된다. `process.nextTick`이 재귀적으로 호출되면, 이벤트루프가 차단되고 `I/O Starvation`이 생성된다. 아래 예제 코드를 실행해보면, `setImmediate`나 `setTimeout`이 실행되지 않고 `process.nextTick`만 계속 도는 것을 알 수 있다.

   ```javascript
   let count = 0

   const cb = () => {
     console.log(`Processing nextTick cb ${++count}`)
     process.nextTick(cb)
   }

   setImmediate(() => console.log('setImmediate is called'))
   setTimeout(() => console.log('setTimeout executed'), 100)

   process.nextTick(cb)

   console.log('Start')
   ```

   ```bash
   Start
   Processing nextTick cb 1
   Processing nextTick cb 2
   Processing nextTick cb 3
   Processing nextTick cb 4
   Processing nextTick cb 5
   Processing nextTick cb 6
   Processing nextTick cb 7
   Processing nextTick cb 8
   Processing nextTick cb 9
   Processing nextTick cb 10
   # 무한히 안끝나고 nextTick만 계속 돈다
   ```

4. `process.nextTick`과는 다르게, 재귀적으로 `setImmediate`를 호출하면 이벤트루프를 블로킹하지 않는다. 모든 재귀 호출은 다음 이벤트 루프에서 실행된다. 아래 코드를 보면, `setImmediate`가 재귀적으로 호출되지만 이벤트 루프를 블로킹하지 않아 간간히 `setTimeout`이 호출되는 것을 알 수 있다.

   ```javascript
   let count = 0

   const cb = () => {
     console.log(`Processing setImmediate cb ${++count}`)
     setImmediate(cb)
   }

   setImmediate(cb)
   setTimeout(() => console.log('setTimeout executed'), 100)

   console.log('Start')
   ```

   ```bash
   Start
   Processing setImmediate cb 1
   Processing setImmediate cb 2
   Processing setImmediate cb 3
   Processing setImmediate cb 4
   ...
   Processing setImmediate cb 503
   Processing setImmediate cb 504
   setTimeout executed
   Processing setImmediate cb 505
   Processing setImmediate cb 506
   ...
   ```

그럼 각각 언제 써야할까? 문서에 따르면 왠만하면 `setImmediate()`를 사용하라고 되어 있다.

> We recommend developers use setImmediate() in all cases because it's easier to reason about.

그렇다면, `process.nextTick`은 언제 사용하는게 좋을까? 아래 코드를 살펴보자.

```javascript
function readFile(fileName, callback) {
  if (typeof fileName !== 'string') {
    return callback(new TypeError('file name should be string'))
  }

  fs.readFile(fileName, (err, data) => {
    if (err) return callback(err)

    return callback(null, data)
  })
}
```

`readFile()` 함수는 인수가 넘어오는 것에 따라서 동기도 비동기도 될 수 있다. 따라서 이는 예측하지 못한 문제가 발생할 수 있다. 그렇다면 어떻게 100% 비동기로 동작하게 할 수 있을까?

```javascript
function readFile(fileName, callback) {
  if (typeof fileName !== 'string') {
    return process.nextTick(
      callback,
      new TypeError('file name should be string'),
    )
  }

  fs.readFile(fileName, (err, data) => {
    if (err) return callback(err)

    return callback(null, data)
  })
}
```

바로 `process.nextTick`을 사용하면 된다. `filename`이 string이 아니면 `process.nextTick`을 활용하여 적절하게 콜백을 수행할 것이다. 이처럼 `process.nextTick`는 스크립트를 실행한 직후 즉시 콜백을 실행해야 하는 여러 상황에서 유용하다.


Browser 2

Critical Request - request 순서는 웹사이트 속도에 어떤 영향을 미치는가

웹 개발자가 본 사파리 15의 변화와 대응

트리쉐이킹으로 자바스크립트 사이즈 줄이기

requestIdleCallback으로 최적화하기

브라우저와 Nodejs의 이벤트 루프는 무엇이 다를까