Github actions가 나오면서 cron job을 실행하기가 더 편해졌습니다. 굳이 내 컴퓨터를 24시간 돌리고 있을 필요도 없고, 비싼 돈 주며 어디 이상한 compute를 쓸 필요도 없어졌습니다. [물론 공짜로 쓸 수 있는 Cron 서비스](https://www.easycron.com/)도 있지만 아무래도 github 과 연동할 수 있다는 점이 큰 장점인 거 같네요.

## cron 설정

```yaml
name: cron

on:
  schedule:
    # 실제 스케쥴 작업이 시작될 cron을 등록하면 됩니다.
    # 크론은 https://crontab.guru/ 여기서 확인하면 좋을 것 같습니다.
    # 이 크론은 평일 5시 (한국시간 14시)에 실행됩니다.
    - cron: '0 5 * * 1-5'

jobs:
  cron:
    runs-on: ubuntu-latest
    # 빌드 매트릭스는 여러가지 환경에서 실행될 수 있게 끔 도움을 줍니다.
    # 어차피 저는 테스트가 필요한 것이 아니고, 일반적인 node환경 만 필요하므로 이렇게만 설정해두겠습니다.
    # https://docs.github.com/en/actions/configuring-and-managing-workflows/configuring-a-workflow#configuring-a-build-matrix
    strategy:
      matrix:
        node-version: [12.x]

    # 현재 레파지토리를 체크아웃합니다.
    # https://github.com/actions/checkout
    steps:
      - uses: actions/checkout@v2

      # Nodejs를 셋업합니다.
      - name: Use Node.js ${{ matrix.node-version }}
        uses: actions/setup-node@v2.1.0
        with:
          node-version: ${{ matrix.node-version }}

      # 캐시된 노드모듈이 있다면 그것을 쓰도록 합니다.
      # https://docs.github.com/en/actions/configuring-and-managing-workflows/caching-dependencies-to-speed-up-workflows#using-the-cache-action 를 참고했습니다.
      # key: key를 활용해서 cache를 만들어 저장합니다.
      # path: 캐시될 파일의 위치입니다.
      # OS와 package-lock.json을 기준으로 node_modules의 캐시를 만듭니다.
      - name: Cache node modules
        uses: actions/cache@v2.0.0
        env:
          cache-name: cache-node-modules
        with:
          path: node_modules
          key: ${{ runner.OS }}-build-${{ hashFiles('package-lock.json') }}
          restore-keys: |
            ${{ runner.OS }}-build-${{ env.cache-name }}-
            ${{ runner.OS }}-build-

      # 일반적인 ci를 실행합니다.
      - name: CI
        run: |
          npm ci

      # cron job을 실행합니다.
      - name: Run Cron
        run: |
          npm run something
```


Github actions가 나오면서 cron job을 실행하기가 더 편해졌습니다. 굳이 내 컴퓨터를 24시간 돌리고 있을 필요도 없고, 비싼 돈 주며 어디 이상한 compute를 쓸 필요도 없어졌습니다. [물론 공짜로 쓸 수 있는 Cron 서비스](https://www.easycron.com/)도 있지만 아무래도 github 과 연동할 수 있다는 점이 큰...

Github 액션으로 스케쥴링 작업하기

Github actions가 나오면서 cron job을 실행하기가 더 편해졌습니다. 굳이 내 컴퓨터를 24시간 돌리고 있을 필요도 없고, 비싼 돈 주며 어디 이상한 compute를 쓸 필요도 없어졌습니다. <a href="https://www.easycron.com/">물론 공짜로 쓸 수 있는 Cron 서비스</a>도 있지만 아무래도 github 과 연동할 수 있다는 점이 큰 장점인 거 같네요.
<h2 id="cron-설정">cron 설정</h2>
<pre class="language-yaml"><code class="language-yaml">name: cron

on:
 schedule:
 # 실제 스케쥴 작업이 시작될 cron을 등록하면 됩니다.
 # 크론은 https://crontab.guru/ 여기서 확인하면 좋을 것 같습니다.
 # 이 크론은 평일 5시 (한국시간 14시)에 실행됩니다.
 - cron: '0 5 * * 1-5'

jobs:
 cron:
 runs-on: ubuntu-latest
 # 빌드 매트릭스는 여러가지 환경에서 실행될 수 있게 끔 도움을 줍니다.
 # 어차피 저는 테스트가 필요한 것이 아니고, 일반적인 node환경 만 필요하므로 이렇게만 설정해두겠습니다.
 # https://docs.github.com/en/actions/configuring-and-managing-workflows/configuring-a-workflow#configuring-a-build-matrix
 strategy:
 matrix:
 node-version: [12.x]

 # 현재 레파지토리를 체크아웃합니다.
 # https://github.com/actions/checkout
 steps:
 - uses: actions/checkout@v2

 # Nodejs를 셋업합니다.
 - name: Use Node.js ${{ matrix.node-version }}
 uses: actions/setup-node@v2.1.0
 with:
 node-version: ${{ matrix.node-version }}

 # 캐시된 노드모듈이 있다면 그것을 쓰도록 합니다.
 # https://docs.github.com/en/actions/configuring-and-managing-workflows/caching-dependencies-to-speed-up-workflows#using-the-cache-action 를 참고했습니다.
 # key: key를 활용해서 cache를 만들어 저장합니다.
 # path: 캐시될 파일의 위치입니다.
 # OS와 package-lock.json을 기준으로 node_modules의 캐시를 만듭니다.
 - name: Cache node modules
 uses: actions/cache@v2.0.0
 env:
 cache-name: cache-node-modules
 with:
 path: node_modules
 key: ${{ runner.OS }}-build-${{ hashFiles('package-lock.json') }}
 restore-keys: |
 ${{ runner.OS }}-build-${{ env.cache-name }}-
 ${{ runner.OS }}-build-

 # 일반적인 ci를 실행합니다.
 - name: CI
 run: |
 npm ci

 # cron job을 실행합니다.
 - name: Run Cron
 run: |
 npm run something
</code></pre>

```toc tight: true, from-heading: 2 to-heading: 3 ``` [4 Types of Memory Leaks in JavaScript and How to Get Rid Of Them](https://auth0.com/blog/four-types-of-leaks-in-your-javascript-code-and-how-to-...

자바스크립트 메모리 누수와 해결 방법

[The cost of JavaScript in 2019](https://v8.dev/blog/cost-of-javascript-2019)을 번역 요약한 글입니다.

## Table of Contents

<iframe width="640px" height="360px" src="https://www.youtube.com/embed/X9eRLElSW1c" frameborder="0" allow="autoplay; encrypted-media" allowfullscreen></iframe>

2019년 들어서 자바스크립트를 처리하는데 드는 주요 비용은 다운로드와 CPU 실행 시간이다. 유저 인터랙션은 브라우저의 메인쓰레드가 자바스크립트를 실행하는라 바쁘다면 약간 지연 될 수 있다. 따라서 스크립스 실행 시간 및 네트워크 병목현상을 최적화 하는 것이 효과적이다.

## 실행가능한 고오급 지침

이것이 웹 개발자들에게 의미하는 것이 무엇이냐? 파싱과 컴파일에 드는 시간이 더이상 생각만큼 느리지 않다는 것이다. 자바스크립트 번들에 필요한 세가지 사항은 아래와 같다.

### 다운로드 소요시간을 향상 시켜라

- 자바스크립트 번들사이즈를, 특히 모바일 기기를 위해 작게 만들어라. 작을 수록 다운로드 속도는 향생되고, 메모리 사용량도 줄어들며, CPU 도 부담이 적다.
- 하나의 큰 번들을 만드는 것을 피하라. 먼들이 50~100kb를 넘는다면, 이를 작은 번들로 쪼갤 필요가 있다. ([HTTP/2의 multiplexing](https://stackoverflow.com/questions/36517829/what-does-multiplexing-mean-in-http-2)을 활용한다면 여러 응답과 요청을 동시에 전송할 수 있어 추가적인 요청의 오버헤드를 줄일 수 있다. )
- 모바일에서는 네트워크 속도로 인해 훨씬 더 적은 리소스를 유지하고, 메모리 사용량도 낮게 유지해야 한다.

### 실행 시간 최적화

- 메인쓰레드에 부담을 주는 [Long Tasks](https://w3c.github.io/longtasks/)를 피하고, 페이지를 최대한 빠르게 작동가능하게 (interactive) 만들어라. 다운로드 이후 스크립트 시간은 속도에 있어 이제 중요한 척도(비용)가 되었다.

### 1kb 이상의 큰 인라인 스크립트를 피하라

- 만약 스크립트가 1kb가 넘는다면, 인라인으로 사용하는 것을 피하라. 큰 인라인 스크립트는 메인 쓰레드에서 파싱되고 컴파일 된다.

> Chrome has a minimum size for code caches, currently set to 1 KiB of source code. This means that smaller scripts are not cached at all, since we consider the overheads to be greater than the benefits.

[참고](https://v8.dev/blog/code-caching-for-devs)

## 왜 다운로드와 실행 속도가 문제인가?

왜 다운로드와 실행 시간을 최적화 해야하는가? 다운로드 시간은 성능이 구린 네트워크 환경에서 치명적이다. 4G와 5G 환경이 전세계적으로 구축되고 있지만, [NetworkInformation.effectiveType](https://developer.mozilla.org/en-US/docs/Web/API/NetworkInformation/effectiveType) 는 많은 요소들로 인해 3G 혹은 더 느린 네트워크 처럼 작동할 수 있다.

> 다른 여러가지 요소로 인해 매번 빠른 속도를 유지해 줄 수 없다는 뜻 같습니다.

자바스크립트의 실행속도는 느린 CPU를 사용하는 스마트폰에서 중요하다. CPU, GPU, 서멀 스로틀링 등의 차이로 인해 고오급 스마트폰과 보급형 스마트폰의 성능 차이가 크다. 이는 실행 시간이 CPU와 연관되어 있기 때문에, 자바스크립트 성능에 있어 중요하다.

사실 크롬과 같은 브라우저에서 전체 페이지 로딩에 걸리는 시간 중 최대 30% 정도는 자바스크립트 실행에 사용될 수 있다. 아래는 일반적인 웹사이트 Reddit.com을 하이엔드 데스크톱에서 접근했을 때 걸리는 시간이다.

![자바스크립트 처리에 전체 페이지 로딩 시간 중 10~30%를 소비하고 있다.](https://v8.dev/_img/cost-of-javascript-2019/reddit-js-processing.svg)

그러나 모바일에서는 이와 상황이 많이 다르다.

![최신형 스마트폰(픽셀)에서는 3~4배의 시간이 소요되었지만, 보급형 스마트폰에서는 6배 이상의 시간이 소요된다.](https://v8.dev/_img/cost-of-javascript-2019/reddit-js-processing-devices.svg)

자바스크립트 실행 시간을 최적화 할때는, UI스레드를 장기간 독점하고 있는 Long Tasks에 주의 하자. 이는 시각적으로 페이지가 준비된 것처럼 보여도, 중요한 태스크 실행을 차단하고 있을 수 있다. 이러한 것들은 가능한 작게 나누어야 한다. 코드를 분할하고, 로드 되는 순서에 우선순위를 지정하여 페이지 상호작용을 더 빠르게 할 수 있고, 입력 지연 시간을 줄일 수도 있다.

![메인 쓰레드를 독점하는 작업을 잘게 나누자](https://v8.dev/_img/cost-of-javascript-2019/long-tasks.png)

## 파싱과 컴파일을 향상시키기 위해 V8은 무엇을 했나?

V8의 원시 자바스크립트 구문 분석속도는 크롬 60 이후 2배가량 증가했다. 동시에, 파싱과 컴파일 비용은 이를 병렬화 하는 크롬의 다른 최적화 작업으로 인해 덜 눈에 띄게 되었고, 중요성도 떨어졌다.

V8은 메인 스레드의 파싱 및 컴파일 작업을 평균 40% 감소시켰다(Facebook 46%, 핀터레스트 62%, youtube 80%)

![버전 별 V8파싱 속도](https://v8.dev/_img/cost-of-javascript-2019/chrome-js-parse-times.svg)

또한 V8의 서로 다른 버전에서 이러한 변경점이 CPU 시간에 미치는 영향을 시각화 할수 있다.

![V8 버전별 파싱 속도](https://v8.dev/_img/cost-of-javascript-2019/js-parse-times-websites.svg)

이러한 변화들이 어떻게 이루어졌는지 살펴보자. 요약하자면, 스크립트 리소스는 worker스레드에서 스트리밍 파싱되고, 컴파일 될 수 있는데 이는 다음과 같은 것을 의미한다.

- V8은 메인 스레드를 막지 않고 자바스크립트를 파싱+컴파일 할수 있다.
- 전체 HTML 파서가 `<script/>`태그를 만나면 스트리밍이 시작된다. 파서 블락 스크립트의 경우, HTML파서가 만들어내지만, 다른 `async` 스크립트는 계속해서 진행된다.
- 대부분의 경우, V8 v파서의 속도가 실제 연결 속도 보다는 빠르므로, V8은 마지막 스트립트 바이트가 다운로드 된후 몇 밀리 초 이후에 파싱 + 컴파일된다.

오래된 크롬 버전의 경우, 파싱을 시작하기전에 스크립트를 모두 다운로드 해야 했으므로, 이는 간단한 접근 법인 한편으로 CPU를 충분히 사용하지는 못했다. 41~68사이의 크롬은 다운로드가 시작되자마자 별도의 스레드에서 `async` `deferred` 스크립트 구문을 파싱하기 시작했다.

![스크립트는 여러 chunck로 도착한다.](https://v8.dev/_img/cost-of-javascript-2019/script-streaming-1.svg)

![크롬 71에서는, 스케쥴러가 한번에 여러 `async` `deferred` 스크립트의 신택스를 분석할 수 있는작업기반 설정으로 이동했다. 이러한 변화는 메인 스래드의 파싱 시간이 20% 까지 감소하여 실제 웹사이트에서 측정한 전체적인 TTI/FID가 전체적으로 2%까지 개선되었다.](https://v8.dev/_img/cost-of-javascript-2019/script-streaming-2.svg)

크롬 72에서는, 스트리밍을 파싱을 하는 주요 방법으로 채택했다. 이제는 일반 동기식 스크립트도 동일하게 파싱된다. (인라인은 제외) 또한 메인 스레드에서 필요로 할 경우 이미 수행된 모든 작업을 불필요하게 복제하기 때문에, 작업 기반 구문분석을 취소하는 것을 중단했다.

이전 버전의 크롬은 스트리밍 파싱과 컴파일을 지원했는데, 여기에서 네트워크로 부터 들어오는 스크립트 소스 데이터가 스트리머로 전달되기 전에 크롬의 메인 스레드로 이동해야 했다.

이로 인해 스트리밍 파서는 이미 네트워크에서 도착한 데이터를 기다리는 경우가 많았지만, 메인 스레드의 다른 작업 (HTML파싱, 레이아웃, 또는 자바스크립트 실행 등) 에 의해 차단되서 아직 스트리밍 작업으로 전달되지 않았다.

## 실제 웹사이트에서는 어떤 변화가 일어 났는가?

![](https://v8.dev/_img/cost-of-javascript-2019/reddit-main-thread.svg)

레딧의 경우 100+kb의 번들이 몇개 있는데, 이번들은 외부 다른 함수에 의해 랩핑되어 있어서 메인스레드에 레이지 컴파일을 야기한다.

![](https://v8.dev/_img/cost-of-javascript-2019/facebook-main-thread.svg)

페이스북은 압축된 6mb 정도의 데이터를 최대 292개의 요청으로 부터 가져오는데, 몇개는 비동기로, preloaded로, 혹은 낮은 우선순위로 fetch 된다. 대부분의 스크립트는 작고 세분화되어 있다. 이러한 작은 스크립트는 스트리밍-파싱 / 컴파일을 할 수 있기 때문에 백가라운드 - worker 스레드에서 전체 병렬화에 많은 도움을 준다.

## JSON을 파싱하는데 드는 비용

JSON 문법은 자바스크립트 문법에 비해 간결하므로,JSON을 파싱하는 것이 자바스크립트를 파싱하는 것보다 더욱 효과적이다. 이 사실은 JSON 객체 리터럴을 필요로 하는 웹 앱의 시작 성능 향상에 적용할 수 있다.

```javascript
const data = { foo: 42, bar: 1337 } // 🐌 객체 리터럴이라 느리다.
```

위 형식은 JSON 형식으로 바꿔 쓸 수 있고, 이는 런타임에서 더 빠르게 실행된다.

```javascript
const data = JSON.parse('{"foo":42,"bar":1337}') // 🚀
```

JSON 문자열은 딱 한번 수행되기 때문에, `JSON.parse` 접근은 자바스크립트 객체 리터럴에 비해 훨씬 빠르며, 특히 콜드 로드 시 더 두각을 나타낸다. 경험적으로 보았을때, 10kb 이상의 객체에 이기법을 적용하는 것이 효과적인데, 이를 적용하기 전에 실제로 테스트 해보기를 권한다.

![`JSON.parse`가 훨씬 더 파싱하고, 컴파일하고, 실행하기 빠르다.](https://v8.dev/_img/cost-of-javascript-2019/json.svg)

<iframe width="640px" height="360px" src="https://www.youtube.com/embed/ff4fgQxPaO0" frameborder="0" allow="autoplay; encrypted-media" allowfullscreen></iframe>

## 재 방문시 파싱과 컴파일은 어떻게 이루어 지는가?

V8의 코드 캐싱 최적화가 도움을 줄 수 있다. 스크립트가 처음 요청되면 크롬이 다운로드 하여 V8에 전달하고, 이를 컴파일 한다. 이후 브라우저의 온디스크 캐시에 파일을 저장한다. 만약 JS 파일이 두번째로 요청되면, 크롬은 브라우저에서 캐시된 파일을 가져다가 다시 V8에 전달하여 컴파일 한다. 그러나 이번에는 컴파일된 코드가 직렬화 되어, 캐시된 스크립트 파일에 메타데이터로 첨부된다.

![](https://v8.dev/_img/cost-of-javascript-2019/code-caching.png)

세번째에는, 크롬은 캐시에서 파일과 파일의 메타데이터를 모두가져가서 V8에 넘겨준다.V8은 메타데이터를 역질렬화하여 컴파일을 건너 뛸 수 있다. 처음 두번의 방문이 72시간내에 이루어지면 코드 캐싱이 시작된다. 크롬은 또는 서비스 워커가 스크립트를 캐싱하는데 사용되는 경우 빠른 코드 캐싱을 할 수도 있다.

## 결론

- 다운로드 및 실행 시간은 2019년 스크립트 로딩의 주요 병목 현상이다.
- 화면의 처음 보이는 영역 (above-the-fold-content)와 나머지 페이지를 표현하기 위한 `defered` 스크립트 등을 작은 번들로 만드는 것을 목표로 하라.
- 사용자가 필요할 때 필요한 코드를 넘길 수 있도록 큰 번들을 분해하라.
 - 이는 V8에서 병렬화를 극대화 한다.
- 모바일에서는 느린 CPU, 네트워크, 메모리 소비, 실행시간으로 인해 훨씬 더 적은 스크립트를 제공해야 한다.
- latency와 cahceablility 사이에 가능한 균형을 유지하여, 메인스레드에서 발생할 수 있는 파싱 및 컴파일 작업의 양을 극대화 하라.

[The cost of JavaScript in 2019](https://v8.dev/blog/cost-of-javascript-2019)을 번역 요약한 글입니다. ```toc tight: true, from-heading: 2 to-heading: 3 ``` <iframe src="https://www.youtube.com/embed/X9eRLElSW...

자바스크립트의 비용

<a href="https://v8.dev/blog/cost-of-javascript-2019">The cost of JavaScript in 2019</a>을 번역 요약한 글입니다.
<h2 id="table-of-contents">Table of Contents</h2>
<ul>
<li>
<a href="#%EC%8B%A4%ED%96%89%EA%B0%80%EB%8A%A5%ED%95%9C-%EA%B3%A0%EC%98%A4%EA%B8%89-%EC%A7%80%EC%B9%A8">실행가능한 고오급 지침</a>
<ul>
<li><a href="#%EB%8B%A4%EC%9A%B4%EB%A1%9C%EB%93%9C-%EC%86%8C%EC%9A%94%EC%8B%9C%EA%B0%84%EC%9D%84-%ED%96%A5%EC%83%81-%EC%8B%9C%EC%BC%9C%EB%9D%BC">다운로드 소요시간을 향상 시켜라</a></li>
<li><a href="#%EC%8B%A4%ED%96%89-%EC%8B%9C%EA%B0%84-%EC%B5%9C%EC%A0%81%ED%99%94">실행 시간 최적화</a></li>
<li><a href="#1kb-%EC%9D%B4%EC%83%81%EC%9D%98-%ED%81%B0-%EC%9D%B8%EB%9D%BC%EC%9D%B8-%EC%8A%A4%ED%81%AC%EB%A6%BD%ED%8A%B8%EB%A5%BC-%ED%94%BC%ED%95%98%EB%9D%BC">1kb 이상의 큰 인라인 스크립트를 피하라</a></li>
</ul>
</li>
<li>
<a href="#%EC%99%9C-%EB%8B%A4%EC%9A%B4%EB%A1%9C%EB%93%9C%EC%99%80-%EC%8B%A4%ED%96%89-%EC%86%8D%EB%8F%84%EA%B0%80-%EB%AC%B8%EC%A0%9C%EC%9D%B8%EA%B0%80">왜 다운로드와 실행 속도가 문제인가?</a>
</li>
<li>
<a href="#%ED%8C%8C%EC%8B%B1%EA%B3%BC-%EC%BB%B4%ED%8C%8C%EC%9D%BC%EC%9D%84-%ED%96%A5%EC%83%81%EC%8B%9C%ED%82%A4%EA%B8%B0-%EC%9C%84%ED%95%B4-v8%EC%9D%80-%EB%AC%B4%EC%97%87%EC%9D%84-%ED%96%88%EB%82%98">파싱과 컴파일을 향상시키기 위해 V8은 무엇을 했나?</a>
</li>
<li>
<a href="#%EC%8B%A4%EC%A0%9C-%EC%9B%B9%EC%82%AC%EC%9D%B4%ED%8A%B8%EC%97%90%EC%84%9C%EB%8A%94-%EC%96%B4%EB%96%A4-%EB%B3%80%ED%99%94%EA%B0%80-%EC%9D%BC%EC%96%B4-%EB%82%AC%EB%8A%94%EA%B0%80">실제 웹사이트에서는 어떤 변화가 일어 났는가?</a>
</li>
<li>
<a href="#json%EC%9D%84-%ED%8C%8C%EC%8B%B1%ED%95%98%EB%8A%94%EB%8D%B0-%EB%93%9C%EB%8A%94-%EB%B9%84%EC%9A%A9">JSON을 파싱하는데 드는 비용</a>
</li>
<li>
<a href="#%EC%9E%AC-%EB%B0%A9%EB%AC%B8%EC%8B%9C-%ED%8C%8C%EC%8B%B1%EA%B3%BC-%EC%BB%B4%ED%8C%8C%EC%9D%BC%EC%9D%80-%EC%96%B4%EB%96%BB%EA%B2%8C-%EC%9D%B4%EB%A3%A8%EC%96%B4-%EC%A7%80%EB%8A%94%EA%B0%80">재 방문시 파싱과 컴파일은 어떻게 이루어 지는가?</a>
</li>
<li>
<a href="#%EA%B2%B0%EB%A1%A0">결론</a>
</li>
</ul>
<h2 id="실행가능한-고오급-지침">실행가능한 고오급 지침</h2>
이것이 웹 개발자들에게 의미하는 것이 무엇이냐? 파싱과 컴파일에 드는 시간이 더이상 생각만큼 느리지 않다는 것이다. 자바스크립트 번들에 필요한 세가지 사항은 아래와 같다.
<h3 id="다운로드-소요시간을-향상-시켜라">다운로드 소요시간을 향상 시켜라</h3>
<ul>
<li>자바스크립트 번들사이즈를, 특히 모바일 기기를 위해 작게 만들어라. 작을 수록 다운로드 속도는 향생되고, 메모리 사용량도 줄어들며, CPU 도 부담이 적다.</li>
<li>하나의 큰 번들을 만드는 것을 피하라. 먼들이 50~100kb를 넘는다면, 이를 작은 번들로 쪼갤 필요가 있다. (<a href="https://stackoverflow.com/questions/36517829/what-does-multiplexing-mean-in-http-2">HTTP/2의 multiplexing</a>을 활용한다면 여러 응답과 요청을 동시에 전송할 수 있어 추가적인 요청의 오버헤드를 줄일 수 있다. )</li>
<li>모바일에서는 네트워크 속도로 인해 훨씬 더 적은 리소스를 유지하고, 메모리 사용량도 낮게 유지해야 한다.</li>
</ul>
<h3 id="실행-시간-최적화">실행 시간 최적화</h3>
<ul>
<li>메인쓰레드에 부담을 주는 <a href="https://w3c.github.io/longtasks/">Long Tasks</a>를 피하고, 페이지를 최대한 빠르게 작동가능하게 (interactive) 만들어라. 다운로드 이후 스크립트 시간은 속도에 있어 이제 중요한 척도(비용)가 되었다.</li>
</ul>
<h3 id="1kb-이상의-큰-인라인-스크립트를-피하라">1kb 이상의 큰 인라인 스크립트를 피하라</h3>
<ul>
<li>만약 스크립트가 1kb가 넘는다면, 인라인으로 사용하는 것을 피하라. 큰 인라인 스크립트는 메인 쓰레드에서 파싱되고 컴파일 된다.</li>
</ul>
<blockquote>
Chrome has a minimum size for code caches, currently set to 1 KiB of source code. This means that smaller scripts are not cached at all, since we consider the overheads to be greater than the benefits.
</blockquote>
<a href="https://v8.dev/blog/code-caching-for-devs">참고</a>
<h2 id="왜-다운로드와-실행-속도가-문제인가">왜 다운로드와 실행 속도가 문제인가?</h2>
왜 다운로드와 실행 시간을 최적화 해야하는가? 다운로드 시간은 성능이 구린 네트워크 환경에서 치명적이다. 4G와 5G 환경이 전세계적으로 구축되고 있지만, <a href="https://developer.mozilla.org/en-US/docs/Web/API/NetworkInformation/effectiveType">NetworkInformation.effectiveType</a> 는 많은 요소들로 인해 3G 혹은 더 느린 네트워크 처럼 작동할 수 있다.
<blockquote>
다른 여러가지 요소로 인해 매번 빠른 속도를 유지해 줄 수 없다는 뜻 같습니다.
</blockquote>
자바스크립트의 실행속도는 느린 CPU를 사용하는 스마트폰에서 중요하다. CPU, GPU, 서멀 스로틀링 등의 차이로 인해 고오급 스마트폰과 보급형 스마트폰의 성능 차이가 크다. 이는 실행 시간이 CPU와 연관되어 있기 때문에, 자바스크립트 성능에 있어 중요하다.
사실 크롬과 같은 브라우저에서 전체 페이지 로딩에 걸리는 시간 중 최대 30% 정도는 자바스크립트 실행에 사용될 수 있다. 아래는 일반적인 웹사이트 Reddit.com을 하이엔드 데스크톱에서 접근했을 때 걸리는 시간이다.
<img src="https://v8.dev/_img/cost-of-javascript-2019/reddit-js-processing.svg" alt="자바스크립트 처리에 전체 페이지 로딩 시간 중 10~30%를 소비하고 있다.">
그러나 모바일에서는 이와 상황이 많이 다르다.
<img src="https://v8.dev/_img/cost-of-javascript-2019/reddit-js-processing-devices.svg" alt="최신형 스마트폰(픽셀)에서는 3~4배의 시간이 소요되었지만, 보급형 스마트폰에서는 6배 이상의 시간이 소요된다.">
자바스크립트 실행 시간을 최적화 할때는, UI스레드를 장기간 독점하고 있는 Long Tasks에 주의 하자. 이는 시각적으로 페이지가 준비된 것처럼 보여도, 중요한 태스크 실행을 차단하고 있을 수 있다. 이러한 것들은 가능한 작게 나누어야 한다. 코드를 분할하고, 로드 되는 순서에 우선순위를 지정하여 페이지 상호작용을 더 빠르게 할 수 있고, 입력 지연 시간을 줄일 수도 있다.
<img src="https://v8.dev/_img/cost-of-javascript-2019/long-tasks.png" alt="메인 쓰레드를 독점하는 작업을 잘게 나누자">
<h2 id="파싱과-컴파일을-향상시키기-위해-v8은-무엇을-했나">파싱과 컴파일을 향상시키기 위해 V8은 무엇을 했나?</h2>
V8의 원시 자바스크립트 구문 분석속도는 크롬 60 이후 2배가량 증가했다. 동시에, 파싱과 컴파일 비용은 이를 병렬화 하는 크롬의 다른 최적화 작업으로 인해 덜 눈에 띄게 되었고, 중요성도 떨어졌다.
V8은 메인 스레드의 파싱 및 컴파일 작업을 평균 40% 감소시켰다(Facebook 46%, 핀터레스트 62%, youtube 80%)
<img src="https://v8.dev/_img/cost-of-javascript-2019/chrome-js-parse-times.svg" alt="버전 별 V8파싱 속도">
또한 V8의 서로 다른 버전에서 이러한 변경점이 CPU 시간에 미치는 영향을 시각화 할수 있다.
<img src="https://v8.dev/_img/cost-of-javascript-2019/js-parse-times-websites.svg" alt="V8 버전별 파싱 속도">
이러한 변화들이 어떻게 이루어졌는지 살펴보자. 요약하자면, 스크립트 리소스는 worker스레드에서 스트리밍 파싱되고, 컴파일 될 수 있는데 이는 다음과 같은 것을 의미한다.
<ul>
<li>V8은 메인 스레드를 막지 않고 자바스크립트를 파싱+컴파일 할수 있다.</li>
<li>전체 HTML 파서가 <code>&#x3C;script/></code>태그를 만나면 스트리밍이 시작된다. 파서 블락 스크립트의 경우, HTML파서가 만들어내지만, 다른 <code>async</code> 스크립트는 계속해서 진행된다.</li>
<li>대부분의 경우, V8 v파서의 속도가 실제 연결 속도 보다는 빠르므로, V8은 마지막 스트립트 바이트가 다운로드 된후 몇 밀리 초 이후에 파싱 + 컴파일된다.</li>
</ul>
오래된 크롬 버전의 경우, 파싱을 시작하기전에 스크립트를 모두 다운로드 해야 했으므로, 이는 간단한 접근 법인 한편으로 CPU를 충분히 사용하지는 못했다. 41~68사이의 크롬은 다운로드가 시작되자마자 별도의 스레드에서 <code>async</code> <code>deferred</code> 스크립트 구문을 파싱하기 시작했다.
<img src="https://v8.dev/_img/cost-of-javascript-2019/script-streaming-1.svg" alt="스크립트는 여러 chunck로 도착한다.">
<img src="https://v8.dev/_img/cost-of-javascript-2019/script-streaming-2.svg" alt="크롬 71에서는, 스케쥴러가 한번에 여러 async deferred 스크립트의 신택스를 분석할 수 있는작업기반 설정으로 이동했다. 이러한 변화는 메인 스래드의 파싱 시간이 20% 까지 감소하여 실제 웹사이트에서 측정한 전체적인 TTI/FID가 전체적으로 2%까지 개선되었다.">
크롬 72에서는, 스트리밍을 파싱을 하는 주요 방법으로 채택했다. 이제는 일반 동기식 스크립트도 동일하게 파싱된다. (인라인은 제외) 또한 메인 스레드에서 필요로 할 경우 이미 수행된 모든 작업을 불필요하게 복제하기 때문에, 작업 기반 구문분석을 취소하는 것을 중단했다.
이전 버전의 크롬은 스트리밍 파싱과 컴파일을 지원했는데, 여기에서 네트워크로 부터 들어오는 스크립트 소스 데이터가 스트리머로 전달되기 전에 크롬의 메인 스레드로 이동해야 했다.
이로 인해 스트리밍 파서는 이미 네트워크에서 도착한 데이터를 기다리는 경우가 많았지만, 메인 스레드의 다른 작업 (HTML파싱, 레이아웃, 또는 자바스크립트 실행 등) 에 의해 차단되서 아직 스트리밍 작업으로 전달되지 않았다.
<h2 id="실제-웹사이트에서는-어떤-변화가-일어-났는가">실제 웹사이트에서는 어떤 변화가 일어 났는가?</h2>
<img src="https://v8.dev/_img/cost-of-javascript-2019/reddit-main-thread.svg" alt="">
레딧의 경우 100+kb의 번들이 몇개 있는데, 이번들은 외부 다른 함수에 의해 랩핑되어 있어서 메인스레드에 레이지 컴파일을 야기한다.
<img src="https://v8.dev/_img/cost-of-javascript-2019/facebook-main-thread.svg" alt="">
페이스북은 압축된 6mb 정도의 데이터를 최대 292개의 요청으로 부터 가져오는데, 몇개는 비동기로, preloaded로, 혹은 낮은 우선순위로 fetch 된다. 대부분의 스크립트는 작고 세분화되어 있다. 이러한 작은 스크립트는 스트리밍-파싱 / 컴파일을 할 수 있기 때문에 백가라운드 - worker 스레드에서 전체 병렬화에 많은 도움을 준다.
<h2 id="json을-파싱하는데-드는-비용">JSON을 파싱하는데 드는 비용</h2>
JSON 문법은 자바스크립트 문법에 비해 간결하므로,JSON을 파싱하는 것이 자바스크립트를 파싱하는 것보다 더욱 효과적이다. 이 사실은 JSON 객체 리터럴을 필요로 하는 웹 앱의 시작 성능 향상에 적용할 수 있다.
<pre class="language-javascript"><code class="language-javascript">const data = { foo: 42, bar: 1337 } // 🐌 객체 리터럴이라 느리다.
</code></pre>
위 형식은 JSON 형식으로 바꿔 쓸 수 있고, 이는 런타임에서 더 빠르게 실행된다.
<pre class="language-javascript"><code class="language-javascript">const data = JSON.parse('{"foo":42,"bar":1337}') // 🚀
</code></pre>
JSON 문자열은 딱 한번 수행되기 때문에, <code>JSON.parse</code> 접근은 자바스크립트 객체 리터럴에 비해 훨씬 빠르며, 특히 콜드 로드 시 더 두각을 나타낸다. 경험적으로 보았을때, 10kb 이상의 객체에 이기법을 적용하는 것이 효과적인데, 이를 적용하기 전에 실제로 테스트 해보기를 권한다.
<img src="https://v8.dev/_img/cost-of-javascript-2019/json.svg" alt="JSON.parse가 훨씬 더 파싱하고, 컴파일하고, 실행하기 빠르다.">
<iframe width="640px" height="360px" src="https://www.youtube.com/embed/ff4fgQxPaO0" frameborder="0" allow="autoplay; encrypted-media" allowfullscreen></iframe>
<h2 id="재-방문시-파싱과-컴파일은-어떻게-이루어-지는가">재 방문시 파싱과 컴파일은 어떻게 이루어 지는가?</h2>
V8의 코드 캐싱 최적화가 도움을 줄 수 있다. 스크립트가 처음 요청되면 크롬이 다운로드 하여 V8에 전달하고, 이를 컴파일 한다. 이후 브라우저의 온디스크 캐시에 파일을 저장한다. 만약 JS 파일이 두번째로 요청되면, 크롬은 브라우저에서 캐시된 파일을 가져다가 다시 V8에 전달하여 컴파일 한다. 그러나 이번에는 컴파일된 코드가 직렬화 되어, 캐시된 스크립트 파일에 메타데이터로 첨부된다.
<img src="https://v8.dev/_img/cost-of-javascript-2019/code-caching.png" alt="">
세번째에는, 크롬은 캐시에서 파일과 파일의 메타데이터를 모두가져가서 V8에 넘겨준다.V8은 메타데이터를 역질렬화하여 컴파일을 건너 뛸 수 있다. 처음 두번의 방문이 72시간내에 이루어지면 코드 캐싱이 시작된다. 크롬은 또는 서비스 워커가 스크립트를 캐싱하는데 사용되는 경우 빠른 코드 캐싱을 할 수도 있다.
<h2 id="결론">결론</h2>
<ul>
<li>다운로드 및 실행 시간은 2019년 스크립트 로딩의 주요 병목 현상이다.</li>
<li>화면의 처음 보이는 영역 (above-the-fold-content)와 나머지 페이지를 표현하기 위한 <code>defered</code> 스크립트 등을 작은 번들로 만드는 것을 목표로 하라.</li>
<li>사용자가 필요할 때 필요한 코드를 넘길 수 있도록 큰 번들을 분해하라.
<ul>
<li>이는 V8에서 병렬화를 극대화 한다.</li>
</ul>
</li>
<li>모바일에서는 느린 CPU, 네트워크, 메모리 소비, 실행시간으로 인해 훨씬 더 적은 스크립트를 제공해야 한다.</li>
<li>latency와 cahceablility 사이에 가능한 균형을 유지하여, 메인스레드에서 발생할 수 있는 파싱 및 컴파일 작업의 양을 극대화 하라.</li>
</ul>

[Apply instant loading with the PRPL pattern](https://web.dev/apply-instant-loading-with-prpl/)을 번역한 글입니다.

PRPL은 웹 페이지를 로드하고 인터랙티브 할 수 있게 금 더욱 빠르게 만드는 패턴을 설명하는 약어다.

## 요약

- 중요한 리소스를 미리 로드해라 (Push (or preload) the most important resources.)
- 최초 라우팅을 가능한 빠르게 렌더링해라 (Render the initial route as soon as possible.)
- 나머지 assets을 미리 캐싱해두어라 (Pre-cache remaining assets.)
- 기타 다른 라우팅과 덜 중요한 assets을 레이지 로딩 해라. (Lazy load other routes and non-critical assets.)

## Preload critical resources

[Preload](https://developer.mozilla.org/en-US/docs/Web/HTML/Preloading_content) 속성은 브라우저에 가능한 빨리 리소스를 요청하도록 지시하는 선언적 fetch 요청이다. HTML 헤드에 있는 `<link/>` 태그에 `rel="preload"`를 붙이면 중요한 리소스를 미리 요청할 수 있다.

```html
<link rel="preload" as="style" href="css/style.css">
```

브라우저는 이 선언을 보게 되면, `window.onload` 이벤트를 지연시키지 않는 선에서 해당 리소스에 우선순위를 두고 다운로드를 시도한다.

더욱 자세한 가이드는 [여기](https://web.dev/preload-critical-assets/)를 참고 하라.

## Render the initial route as soon as possible.

First paint를 향상 시키기 위해서는, 가장 중요한 자바스크립트 코드를 인라인으로 작성하고, 나머지를 자바스크립트와 css를 [async](https://developers.google.com/web/fundamentals/performance/critical-rendering-path/adding-interactivity-with-javascript)로 작성해야 한다. 이는 렌더링을 막는 asset을 가져오기위한 서버 라운드 트립을 막음으로서 성능을 향상시킨다. 그러나 인라인 코드는 개발관점에서 유지하기가 어렵고 브라우저에 의해 별도로 캐시될 수 없으니 주의 해야 한다.

가능한 다른 방법으로는 최초 HTML 페이지를 서버사이드 렌더링에 맡기는 것이다. 이는 사용자가 스크립트를 가져오고, 파싱하고, 실행하는 시간동안에 의미있는 정보를 보여줄 수 있다. 그러나 이는 HTML 파일을 가져오는 페이로드를 증가시킬 수 있으며, 이는 [TTI](https://web.dev/interactive/) (사용자가 페이지와 상호작용하는데 걸리는 시간)에 악영향을 미칠 수도 있다. 

First Paint를 향상시킬 수 있는 절대적인 방법은 없다. 따라서 인라인 스타일이나 서버사이드 렌더링을 하는데 있어서 장단점이 무엇인지를 알아야 한다. 

- [CSS 가져오기를 최적화 하기](https://developers.google.com/speed/docs/insights/OptimizeCSSDelivery)
- [서버사이드 렌더링이란 무엇인가](https://www.youtube.com/watch?v=GQzn7XRdzxY)

## Pre-cache assets

![서비스 워커에서의 요청과 응답](https://webdev.imgix.net/apply-instant-loading-with-prpl/service-workers.png)

서비스 워커는 매 방문시 서버에서 필요한 assets을 가져오는 것이 아니라 proxy 처럼 역할하여 assets을 제공한다. 이는 사용자가 오프라인 중에도 애플리케이션을 쓸 수 있게 끔 할 뿐만 아니라, 반복적으로 페이지에 접근했을 때 페이지 로딩을 빠르게 해준다.

일반적인 라이브러리가 제공하는 것 이상으로 복잡한 요구사항이 없다면, 써드 파티 라이브러리로 서비스 워커를 만들어 이 과정을 단순화 하는 것을 고려해봄직하다. 예를 들어 [WorkBox](https://web.dev/workbox)는 asset을 캐싱할 수 있는 서비스 워커를 만들고 유지할 수 있는 다양한 툴을 제공한다. 더 많은 서비스 워커에 대한 정보와 오프라인 상태의 유지에 대해 알고 싶다면, [Service worker guide](https://web.dev/service-workers-cache-storage)를 참고하라.

## Lazy load

웹페이지에는 다양한 asset이 있지만, 특히 구문 분석및 컴파일에 걸리는 시간으로 인해 큰 자바스크립트는 많은 비용을 소모한다. 가능한 자바스크립트를 작게 만들어 최초 페이지 로딩에 필요한 chunk 들만 내보내고, 나머지는 [lazy load](https://web.dev/reduce-javascript-payloads-with-code-splitting/) chunk로 분리하는 것이 좋다.

번들을 나눈 이후에는, 이 chunk들을 `preload` 하는 것이 더욱 중요하다. `Preloading`은 중요한 리소스에 대해서 더 빠르게 다운로드 할 수 있도록 브라우저에 명시한다.

웹 페이지에서 많은 양의 이미지를 로딩한다면, 화면 밖에서 표시되는 이미지에 대해서는 페이지가 로딩 될 때 나중에 로딩되도록 하는 것이 좋다. [lazysizes](https://github.com/aFarkas/lazysizes)라이브러리의 사용을 고려해보는 것도 좋다.

[Apply instant loading with the PRPL pattern](https://web.dev/apply-instant-loading-with-prpl/)을 번역한 글입니다. PRPL은 웹 페이지를 로드하고 인터랙티브 할 수 있게 금 더욱 빠르게 만드는 패턴을 설명하는 약어다.  ## 요약  - 중요한 리소스를 미리 로드해라 (Push (...

빠른 로딩을 위한 PRPL 패턴

[Critical Rendering Path](https://developers.google.com/web/fundamentals/performance/critical-rendering-path?hl=ko)를 요약했습니다. 이글을 보는게 더 나아요 사실

## Table of Contents

성능 최적화를 위해서는 HTML, CSS, 자바스크립트를 바이트 단위로 수신 한 뒤 브라우저에서 렌더링된 픽셀로 변환하기 까지, 어떠한 일들이 있었는지 알아야 한다. 이러한 단계를 바로 `Critical Rendering Path`라고 한다.

![progressive page rendering](https://developers.google.com/web/fundamentals/performance/critical-rendering-path/images/progressive-rendering.png?hl=ko)

## 객체 모델 생성

브랑루저가 페이지를 렌더링하기 위해서는 DOM과 CSSOM 트리를 생성해야 한다. 따라서 최대한 빠르게 이를 생성해서 넘겨야 한다.

먼저 바이트 코드로 넘어온 HTML과 CSS를 어떻게 처리하는지 알아야 한다.

![](https://developers.google.com/web/fundamentals/performance/critical-rendering-path/images/full-process.png?hl=ko)

1. 바이트
2. 문자
3. 토큰
4. 노드
5. 객체모델

HTML은 DOM(Document Object Model)로, CSS는 CSSOM(CSS Object Model)로 변환된다. 이 둘은 독립적인 데이터 구조다.

이 DOM을 기준으로 브라우저는 이후 모든 페이지 처리에 이 DOM을 사용한다.

## 렌더링 트리 생성과 레이아웃 프린트

- DOM과 CSSDOM 이 만들어졌다면, 이 두 트리를 결합하여 렌더링 트리를 생성한다.
- 이 렌더링 트리에는 페이지를 렌더링하는데 필요한 노드만 포함된다. 예를 들어서 `display:none`으로 처리된 것은 렌더링 처리에서 누락된다.
- 레이아웃 단계에서는, 각 객체의 정확한 위치와 크기를 계산한다.
- 마지막으로 페인트 단계를 거치는데, 픽셀을 화면에 렌더링한다.

## 브라우저의 렌더링 단계 요약

1. HTML 을 처리해서 DOM 트리를 만든다
2. CSS 를 처리해서 CSSOM 트리를 만든다.
3. DOM과 CSSOM을 결합하여 렌더링 트리를 만든다
4. 렌더링 트리에서 레이아웃 처리를 통하여 각 객체의 위치와 크기를 계산한다
5. 마지막으로 개별노드를 페인트 한다.

주요 렌더링 경로를 최적화 하는 작업은 위 다섯가지의 단계를 최소화 하는 프로세스다.

## HTML과 CSS는 기본적으로 렌더링을 차단한다.

CSSOM이 생성되기 전까지, 브라우저는 처리되는 모든 컨텐츠를 렌더링하지 않는다. 따라서 가능한 간단하고 빠르게 제공해야 렌더링 차단을 최소화 할 수 있다. HTML도 마찬가지로, 렌더링을 차단하는 리소스다.

하지만 미디어 유형과 미디어 쿼리를 통해서 일부 리소스를 렌더링을 차단하지 않는 리소스로 선언할 수 있다.

```html

<link href="style.css" rel="stylesheet" />

<link href="style.css" rel="stylesheet" media="all" />

<link href="print.css" rel="stylesheet" media="print" />

<link href="other.css" rel="stylesheet" media="(min-width: 40em)" />
```

한 가지 중요한 것은, 위 미디어 쿼리가 있다고 하더라도 해당 리소스에 대해 초기 렌더링을 보류해야 하는지만 나타낸다. 어떤 경우든지, 브라우저는 CSS를 모두 다운받으며, 단지 초기 렌더링을 보류 해야하는지만을 나타낸다.

## 자바스크립트로 상호작용 추가

자바스크립트를 활용하면 페이지 대부분의 측면을 수정할 수 있다. DOM 요소를 추가하고 제거하거나, CSSOM 속성을 수정하는 등 거의 모든 측면에 관여할 수 있다.

이러한 점 때문에, 인라인 스크립트를 실행하면 DOM 생성이 차단되고, 이로 인해 초기 렌더링에도 지연이 발생하게 된다. 자바스크립트로는 DOM, CSSDOM 등에 관여할 수 있기 때문에 렌더링하는데 있어 지연이 발생할 수 있다.

따라서

- 문서의 스크립트 위치는 중요하다. 위치에 따라서 실행이 달라진다.
- 브라우저가 스크립트 태그를 만나면 스크립트가 종료될때까지 DOM 생성이 중단된다.
- 자바스크립트는 CSSOM이 준비될 때까지 일시 중단된다.

따라서 기본적으로, 자바스크립트의 실행은 파서를 차단한다. 그리고 만약 인라인 자바스크립트가 아닌, 스크립트 태그를 통해 포함된 자바스크립트가 있다면, 브라우저가 일시 중단하고, 디스크 / 캐시 / 원격 서버등에서 스크립트를 가져올 때 까지 기다리므로, 추가적인 지연이 더 발생하게 된다.

이를 방지 하기 위해서는 `async` 키워드를 추가하면 된다.

```html
<script src="app.js" async></script>
```

이를 추가하면, 스크립트가 사용가능 해질 때까지 기다리는 동안에도 DOM 생성을 계속해서 하게된다. 이경우 성능이 향상된다.

![](https://kimlog.me/static/7b56046cd820d53017f5fa7124ba2255/44a54/script_load.png)

> 일반적인 `script`는 다운로드하고 실행될 때까지 HTML 파싱을 멈추지만, `async`는 다운로드와 파싱을 동시에 진행한다. `defer`의 경우에는, 마찬가지로 다운로드를 동시에 진행하지만, 스크립트 실행이 맨뒤로 밀리게 된다.

## 주요 렌더링 경로 측정

해당 렌더링 경로를 측정하는 좋은 방법은 `LightHouse`를 이용하는 것이다.

![높은 우선순위를 가지고 로딩되는 리소스를 보여준다.](images/naver-critical-request.png)

또는 [Navigation Timing API](https://developer.mozilla.org/ko/docs/Navigation_timing)를 활용하여 측정할 수도 있다.

```html
<!DOCTYPE html>
<html>
 <head>
 <title>Critical Path: Measure</title>
 <meta name="viewport" content="width=device-width,initial-scale=1" />
 <link href="style.css" rel="stylesheet" />
 <script>
 function measureCRP() {
 var t = window.performance.timing,
 interactive = t.domInteractive - t.domLoading,
 dcl = t.domContentLoadedEventStart - t.domLoading,
 complete = t.domComplete - t.domLoading
 var stats = document.createElement('p')
 stats.textContent =
 'interactive: ' +
 interactive +
 'ms, ' +
 'dcl: ' +
 dcl +
 'ms, complete: ' +
 complete +
 'ms'
 document.body.appendChild(stats)
 }
 </script>
 </head>
 <body onload="measureCRP()">
 Hello web performance students!
 <div><img src="awesome-photo.jpg" /></div>
 </body>
</html>
```

```
interactive: 229ms, dcl: 230ms, complete: 956ms
```

![](https://developers.google.com/web/fundamentals/performance/critical-rendering-path/images/dom-navtiming.png?hl=ko)

- `domLoading`: 전체 프로세스의 시작 타임스탬프. 브라우저가 처음 수신한 HTML 문서 바이트의 파싱 시작.
- `domInteractive`: 브라우저가 파싱을 완료한 시점을 표시. 모든 HTML 및 DOM 생성 작업이 완료됨을 의미.
- `domContentLoaded`: DOM이 준비되고 자바스크립트 실행을 차단하는 스타일시트가 없는 시점을 표시. 즉, 이제 (잠재적으로) 렌더링 트리를 생성할 수 있음. 많은 자바스크립트 프레임워크가 자체 로직을 실행하기 전에 이 이벤트를 기린다. 따라서 브라우저는 EventStart 및 EventEnd 타임스탬프를 캡처하여, 이를 통해 이 실행이 얼마나 오래 걸렸는지 추적할 수 있다.
- `domComplete`: 이름이 의미하는 바와 같이, 모든 처리가 완료되고 페이지의 모든 리소스(이미지 등) 다운로드가 완료되었음을 의미.
- `loadEvent`: 각 페이지 로드의 최종 단계로, 브라우저가 추가 애플리케이션 로직을 트리거할 수 있는 `onload` 이벤트를 트리거함.

## 주요 렌더링 경로 성능 분석

[예제 페이지](https://googlesamples.github.io/web-fundamentals/fundamentals/performance/critical-rendering-path/basic_dom_nostyle.html)를 통해 분석을 시작해보자.

![example1.png](images/example.png)

`DOMContentLoaded`가 호출되는데 약 300ms 정도가 소요되었다. 그리고 이는 파란색 수직선으로 체크 되었다. 이미지 로딩은 이에 영향을 받지 않았다. 주요 렌더링 경로에는 HTML, CSS, 자바스크립트만 포함된다.

하지만 `load`이벤트는 이미지에서 차단되었다. `onload`는 따라서 모든 리소스가 다운로드 된 후에 호출된다는 것을 알 수 있다.

[이제 여기에 자바스크립트와 CSS를 추가해보자.](https://googlesamples.github.io/web-fundamentals/fundamentals/performance/critical-rendering-path/measure_crp_timing.html)

```html
<!DOCTYPE html>
<html>
 <head>
 <title>Critical Path: Measure Script</title>
 <meta name="viewport" content="width=device-width,initial-scale=1" />
 <link href="style.css" rel="stylesheet" />
 </head>
 <body onload="measureCRP()">
 Hello web performance students!
 <div><img src="awesome-photo.jpg" /></div>
 <script src="timing.js"></script>
 </body>
</html>
```

![example2.png](images/example2.png)

`DOMContentLoaded`가 거의 `onload`와 동시에 호출된 것을 알 수 있다. 일반적인 HTML과는 다르게, CSSOM을 생성하기 위해 CSS 파일도 가져와야 한다. 또한 파서 차단 자바스크립트가 포함되어 있어 CSS 파일이 다운로드 될때까지 차단되어 있는 것을 볼 수 있다.

[이번엔 `async` 키워드를 추가해보자.](https://googlesamples.github.io/web-fundamentals/fundamentals/performance/critical-rendering-path/measure_crp_async.html)

![example3.png](images/example3.png)

이번에는 HTML이 파싱된 이후에 `domContentLoaded`가 실행된 것을 볼 수 있다. 브라우저가 자바스크립트를 차단하지 않는다는 것을 알게 되었고, 다른 파서 차단 스크립트가 없으므로 CSSDOM 생성 또한 동시에 처리 가능하다.

만약 이 모든 코드를 인라인으로 때려박게 되면, 위의 예제와 비슷한 성능을 느낄 수 있다. HTML 페이지는 더 커지지만, 페이지 안에 모든 요소가 있으므로 외부 리소스가 올때까지 기다릴 필요가 없기 때문이다.

## 성능 분석

### 순수 HTML

```html
<!DOCTYPE html>
<html>
 <head>
 <meta name="viewport" content="width=device-width,initial-scale=1" />
 <title>Critical Path: No Style</title>
 </head>
 <body>
 Hello web performance students!
 <div><img src="awesome-photo.jpg" /></div>
 </body>
</html>
```

![pure html](https://developers.google.com/web/fundamentals/performance/critical-rendering-path/images/analysis-dom.png?hl=ko)

### CSS 파일 추가

```html
<!DOCTYPE html>
<html>
 <head>
 <meta name="viewport" content="width=device-width,initial-scale=1" />
 <link href="style.css" rel="stylesheet" />
 </head>
 <body>
 Hello web performance students!
 <div><img src="awesome-photo.jpg" /></div>
 </body>
</html>
```

![css](https://developers.google.com/web/fundamentals/performance/critical-rendering-path/images/analysis-dom-css.png?hl=ko)

CSS를 가져오기 위해 한번의 왕복이 더 추가되었고, 그만큼 렌더링도 밀려난 것을 볼 수 있다.

### CSS + 자바스크립트 추가

```html
<!DOCTYPE html>
<html>
 <head>
 <meta name="viewport" content="width=device-width,initial-scale=1" />
 <link href="style.css" rel="stylesheet" />
 </head>
 <body>
 Hello web performance students!
 <div><img src="awesome-photo.jpg" /></div>
 <script src="app.js"></script>
 </body>
</html>
```

![css+javascript](https://developers.google.com/web/fundamentals/performance/critical-rendering-path/images/analysis-dom-css-js.png?hl=ko)

외부 자바스크립트 asset은 파서 차단 리소스 인 것을 명심하자. 자바스크립트 실행을 위해 작업을 차단하고 CSSDOM 이 생성되기 전까지 기다려야 한다.

한가지 눈여겨 봐야 할 점은, CSS와 자바스크립트 리소스 요청이 거의 동시에 이루어진다는 것이다. 두 리소스를 검색한 후 두 요청을 모두 동시에 실행 한다. 이는 CSS와 자바스크립트 전송을 동시에 할 수 있다는 것을 말한다.

### CSS + Async javascript

```html
<!DOCTYPE html>
<html>
 <head>
 <meta name="viewport" content="width=device-width,initial-scale=1" />
 <link href="style.css" rel="stylesheet" />
 </head>
 <body>
 Hello web performance students!
 <div><img src="awesome-photo.jpg" /></div>
 <script src="app.js" async></script>
 </body>
</html>
```

![css+async javascript](https://developers.google.com/web/fundamentals/performance/critical-rendering-path/images/analysis-dom-css-js-async.png?hl=ko)

더이상 스크립트가 파서를 차단하지 않고, 주요 렌더링 경로에도 포함되지 않았다. 또한 주요 스크립트가 없어서 CSS가 `domContentLoaded`이벤트를 차단하지도 않고, 따라서 애플리케이션 로직이 빠르게 실행되었다는 것을 알 수 있다.

## 주요 렌더링 경로 최적화

최초에 렌더링을 빠르게 하려면 다음의 경우를 고려해야 한다.

- 주요 리소스 수: 페이지의 초기 렌더링을 차단하는 리소스의 수. 최대한 적어야 한다.
- 주요 경로 길이 (얼마나 많은 리소스가 엮여 있는가): 주요 리소스와 해당 바이트 크기간의 그래프를 나타낸다. 일부 리소스는 이전 리소스가 다운된 후에만 시작할 수 있으며, 리소스가 클수록 다운로드 하는데 걸리는 왕복 수가 많아진다.
- 주요 바이트 수 (리소스의 크기): 당연히 작아야 한다.

## 페이지 스피드 규칙 및 권장 사항

- 렌더링 차단 스크립트 및 CSS 를 최소화
- 자바스크립트 사용최적화
 - `async` 속성을 적극적으로 활용
 - 중요하지 않은 비필수 자바스크립트 실행 지연
 - 길게 실행되는 자바스크립트 회피
- CSS 사용 최적화
 - CSS는 문서 헤드에 넣기
 - `@import`의 사용을 피하기. 이는 경로에 대한 왕복이 추가된다.
 - 렌더링 차단 CSS를 인라인으로 처리

[Critical Rendering Path](https://developers.google.com/web/fundamentals/performance/critical-rendering-path?hl=ko)를 요약했습니다. 이글을 보는게 더 나아요 사실 ```toc tight: true, from-heading: 2 to-heading: 3 ```   성...

yceffort

Github 액션으로 스케쥴링 작업하기

자바스크립트 메모리 누수와 해결 방법

자바스크립트의 비용

빠른 로딩을 위한 PRPL 패턴

주요 렌더링 경로 - 브라우저의 원리를 이해하고 최적화 하기