## Introduction

프론트엔드 엔지니어로 일을 하다 보면, 당연히 많은 오픈소스와 다양한 도구에 도움을 받고 의존하게 된다. VS Code 를 비롯해서 여러가지가 있지만, 최근에 내가 가장 도움을 많이 받은 도구 중 하나는 Github Action 이다. github action을 기반으로 github workflow를 만들고 활용하여 프론트엔드 팀의 CI/CD 파이프라인에 도움을 주는 방법을 살펴보자.

## 좋은 Github CI workflow는 무엇일까

- 최소한의 비용으로 실행해야 한다: github actions은 [빌드 시간 만큼 비용을 청구](https://docs.github.com/en/billing/managing-billing-for-github-actions/about-billing-for-github-actions)하므로 빌드 시간을 최소한으로 낮춰야 한다.
- 효율적으로 동작해야 한다: workflow는 가능한 빨리 수행 되어서 성공 또는 실패 여부를 확인할 수 있어야 한다.
- 잘 설계되어 있어야 한다: 각 모든 step에는 모두 목적이 있으며, 쓸데 없는 step이 없어야 한다.

## Workflow 가 해야 하는 일

workflow에서 처리할 수 있는 일들에는 많지만, 일반적인 프론트엔드 프로젝트를 상상해본다면 아래와 같은 작업들을 처리할 것이다.

- lint
- formatting
- type checking
- unit test
- build
- e2e test (다양한 브라우저 지원)

물론 여유가 있다면 이러한 작업을 별도의 workflow에서 실행하는 것이 가장 간단한 방법이다. 그러나 모든 작업을 별개로 두었을 경우 한 작업이 실패한다면, 다른 작업은 진행할 필요가 없음에도 (모든 워크플로우가 통과하는게 의미 있기 때문에) 다른 작업을 중단하는 것은 불가능하다.

정리하자면, 이러한 방식의 워크플로우는 병렬로 실행되기 때문에 서로 상호 작용할 방법이 없다. 즉, 다른 워크 플로우의 실패를 다른 워크플로우의 중단으로 트리거할 수 없다.

따라서 좋은 방법은 모든 워크플로우를 하나로 결합하는 것이다. 독립적인 워크플로우 였던 모든 태스를 하나의 워크 플로우로 통합한다면 이러한 문제를 해결할 수 있다.

```yaml
jobs:
  lint-format:
    runs-on: ubuntu-latest
    strategy:
      matrix:
      node: [14, 16]
    steps:
      - name: Checkout Commit
      uses: actions/checkout@v2
      - name: Use Node.js ${{ matrix.node }}
      uses: actions/setup-node@v1
      with:
        node-version: ${{ matrix.node }}
      - name: Run lint
      run: |
        npm run lint
      - name: Run prettier
      run: |
        npm run prettier
```

이 job은 원하는 작업을 순차적으로 하거나 또는 병렬로 실행할 수 있다. github에서는 [`needs`라고 하는 키워드를 제공하여](https://docs.github.com/en/actions/learn-github-actions/workflow-syntax-for-github-actions#jobsjob_idneeds) 하나 또는 여러개의 작업을 dependencies로 설정할 수 있으므로, 하나의 작업이 성공적으로 끝나기 전까지는 달느 작업이 시작되지 않게 할 수 있다. 이러한 방법을 활용하면, 빠르게 workflow를 실패하게 만들 수 있고 비싼 작업을 여러번 반복하지 않아도 된다.

```yaml
# 타입체크와 유닛테스트가 병렬로 발생한다
# 빌드는 앞선 두 가지 작업이 성공적으로 발생했을 때만 수행
jobs:
  type-check:
    runs-on: ubuntu-latest
    strategy:
      matrix:
      node: [14, 16]
    steps:
      - name: Checkout Commit
      uses: actions/checkout@v2
      - name: Use Node.js ${{ matrix.node }}
      uses: actions/setup-node@v1
      with:
        node-version: ${{ matrix.node }}
      - name: Check types
      run: |
        tsc -p tsconfig.json --noEmit
  unit-test:
    runs-on: ubuntu-latest
    strategy:
      matrix:
      node: [14, 16]
    steps:
      - name: Checkout Commit
      uses: actions/checkout@v2
      - name: Use Node.js ${{ matrix.node }}
      uses: actions/setup-node@v1
      with:
        node-version: ${{ matrix.node }}
      - name: Run test
      run: |
        npm run test
  build:
    runs-on: ubuntu-latest
    strategy:
      matrix:
      node: [14, 16]
    needs: [type-check, unit-test]
    steps:
      - name: Checkout Commit
      uses: actions/checkout@v2
      - name: Use Node.js ${{ matrix.node }}
      uses: actions/setup-node@v1
      with:
        node-version: ${{ matrix.node }}
      - name: Run build
      run: |
        npm run build
```

무엇을 병렬로 실행할지는 프로젝트의 필요에 따라 달라진다. 예를 들어 유닛테스트와 타입체크는 병렬로 진행하곤 한다. 이 두가지 단계는 빠르게 수행할 수 있고, 비용이 적게 들기 때문에 다른 테스트와 의존해서 실행될 필요가 없다. 따라서 위 작업이 수행된 후에 빌드 작업이 포함되어도 늦지 않다.

모든 워크플로우를 하나로 잘 결합하고, 병렬화할 작업 또는 순차적으로 실행할 작업을 신중하게 선택하여, CI 파이프라인의 작동방식과 각 단계간의 의존성에 대한 가시성을 높일 수 있다.

## 작업 결과 공유하기

모든 CI 단계를 결합했다면, 이제 다음 과제는 CI 과정에서 나온 결과물을 공유하여 CI를 최대한 효율적으로 작동하도록 하는 것이다. github action에서 사용할 수있는 방법은 두가지가 있다.

1. [actions/cache](https://github.com/actions/cache)를 활용한 레버리지 캐싱
2. [actions/upload-artifact](https://github.com/actions/upload-artifact)와 [download-artifact](https://github.com/actions/download-artifact)를 활용한 artifact 관리

첫번째 만으로도 이미 훌륭(?)하지만 npm install과 같이 반복적이고 시간이 지나도 크게 변하지 않는 출력을 가진 작업에만 사용할 수 있다.

> 참고하기: https://docs.github.com/en/actions/advanced-guides/caching-dependencies-to-speed-up-workflows#example-using-the-cache-action

```yaml
jobs:
  # 이 jobs은 이름에서 알 수 있는 것 처럼, 이전 워크플로우 실행에서 캐시되고 변경이 일어나지 않는 경우 npm dependencies를 설치하고 캐시한다.
  install-cache:
    runs-on: ubuntu-latest
    strategy:
      matrix:
        node-version: [14, 16]
    steps:
      - name: Checkout Commit
        uses: actions/checkout@v2
      - name: Use Node.js ${{ matrix.node }}
        uses: actions/setup-node@v1
        with:
          node-version: ${{ matrix.node }}
      - name: Cache npm dependencies
        uses: actions/cache@v2
        id: cache-dependencies
        with:
          path: node_modules
          key: ${{ runner.os }}-npm-${{ hashFiles('**/package-lock.json') }}
          restore-keys: |
            ${{ runner.os }}-npm-
      - name: Install Dependencies
        # 캐시가 있다면 해당 스텝을 넘어가고, 그렇지 않다면 설치
        if: steps.cache-dependencies.outputs.cache-hit != 'true'
        run: |
          npm ci

  # 이전에 캐시로 체크했던 의존성을 사용
  type-check:
    runs-on: ubuntu-latest
    strategy:
      matrix:
        node: [14, 16]
    needs: install-cache
    steps:
      - name: Checkout Commit
        uses: actions/checkout@v2
      - name: Use Node.js ${{ matrix.node }}
        uses: actions/setup-node@v1
        with:
          node-version: ${{ matrix.node }}
      # 여기에서도 actions/cache를 사용하지만, 여기에서는 의존성을 되살리는 용도로만 사용
      # 워크플로우 전단계에서 이미 설치하거나 캐시를 불러왔을 것이기 때문에 install을 하지 않음
      # Here we use actions/cache again but this time only to restore the dependencies
      - name: Restore npm dependencies
        uses: actions/cache@v2
        id: cache-dependencies
        with:
          path: node_modules
          key: ${{ runner.os }}-npm-${{ hashFiles('**/package-lock.json') }}
          restore-keys: |
            ${{ runner.os }}-npm-
      - name: Check types
        run: |
          tsc -p tsconfig.json --noEmit
```

여기에서 artifacts를 사용하면 더 향상시킬 수 있다.

예를 들어, 파이어폭스와 크롬에서 각각 e2e 테스트를 하는 작업이 있다고 가정해보자. 이 경우 빌드를 두번하게 되어 github action에 과금 부담이 증가할 수 있으므로 두번 이상 빌드하지 않는 것이 좋다. 이를 해결하기 위해서는 e2e 테스트를 실행하기전에 빌드 작업을 수행한다음, 이 빌드 결과물을 가지고 두군데에서 공유해서 사용하는 것이다.

이를 위해 사용하는 것이 `actions/upload-artifact` 와 `actions/download-artifact` 다.

- 빌드가 성공적으로 끝나면, `actions/upload-artifact` 로 빌드 결과물을 업로드
- 해당 빌드가 필요한 job에서 `actions/download-artifact`를 사용

이 방법은 동일한 워크플로우 실행중에 업로드된 워크플로우의 아티팩트만 다운로드 할 수 있다. 즉 여러개의 개별 action사이에서는 불가능한 방법이다.

```yaml
jobs:
  build:
    # ...
    steps:
      # ...
      - name: Run build
        run: |
          npm run build
      # This step in the build job will upload the build output generated by the previous step
      # 이전 스텝에서 만든 빌드 결과물을 업로드
      - name: Upload build artifacts
        uses: actions/upload-artifact@v2
        with:
          # 빌드 결과물에 이름을 부여
          name: build-output
          # 업로드할 결과물 path
          path: .next
  e2e-tests-chrome:
    # ...
    needs: build
    steps:
      ...
      # 이전에 업로드 했던 빌드 결과물을 다운로드
      - name: Download build artifacts
        uses: actions/download-artifact@v2
        with:
          name: build-output
          # 아티팩트를 어느 위치에 둘 것인지 설정
          path: .next
      - name: Run cypress
        uses: cypress-io/github-action@v2.10.1
        with:
          start: next start
          browser: chrome
  e2e-tests-firefox:
    # ...
    needs: build
    steps:
      ...
      # 반복
      - name: Download build artifacts
        uses: actions/download-artifact@v2
        with:
          name: build-output
          path: .next
      - name: Run cypress
        uses: cypress-io/github-action@v2.10.1
        with:
          start: next start
          browser: firefox
```

> 물론, artifacts를 업로드해서 저장하는 것도 매월 과금에 추가된다. 따라서 업로드 하기 전에 얼마나 과금이 될지 미리 고민을 해보는 것이 좋다. https://docs.github.com/en/billing/managing-billing-for-github-actions/about-billing-for-github-actions#included-storage-and-minutes

> `retention-days` 옵션을 사용하면, 시간이 경과한 아티팩트를 자동으로 삭제할 수 있다.

## 반복 작업 삭제하기

코드를 PR 올리기로 결정하고, 푸쉬를 하고 PR을 열었다고 가정해보자. PR로 인해 트리거된 워크플로우가 실행될 것이다. 그러나 잠깐 사이에 무언가 빠트린 코드가 생각나 다시 커밋후 푸시를 해보자. 이 경우에는 또다른 워크플로우가 실행 될 것이다.

기본적으로는 실행중인 이전 워크플로우를 중단할 수는 없다. 워크플로우가 완료될 때 까지 계속 실행되므로 과금에 낭비가 일어날 것이다.

이를 해결 하기 위해 github에서 비교적 최근에 [concurrency](https://github.blog/changelog/2021-04-19-github-actions-limit-workflow-run-or-job-concurrency/)라는 개념을 도입했다.

`concurrency`를 사용하면 워크플로우나 job에 대해서 하나의 concurrency group을 만들 수 있다. 이렇게 하면 한 그룹에서 실행중인 워크플로우가 있을 경우, 'pending' 상태로 표시된다. 그리고 새 워크플로우가 대기열에 추가될 때 마다 그룹에서 진행중인 워크플로우를 취소하도록 명령을 내릴 수 있다.

```yaml
name: CI

on:
  pull_request:
    branches:
      - main

concurrency:
  # 그룹을 pr의 head_ref로 정의
  group: ${{ github.head_ref }}
  # 해당 pr에서 새로운 워크플로우가 실행될 경우, 이전에 워크플로우가 있다면 이전 워크플로우를 취소하도록 한다.
  cancel-in-progress: true

jobs:
  install-cache:
  # ...
```

워크플로우 레벨에서 이 작업을 수행하면, 새로운 변경사항을 커밋하여 새로운 워크플로우가 실행 될 때 이전 워크플로우를 취소 시킬 수 있으므로 시간과 비용을 절약할 수 있다.

> 더 많은 `concurrency` 예제 살펴보기: https://docs.github.com/en/actions/learn-github-actions/workflow-syntax-for-github-actions#concurrency


프론트엔드 프로젝트를 위한 github CI workflow

리액트 18에서 변경될 새로운 SSR 아키텍쳐

## 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

## 정규식은 무엇인가

정규식은 string 데이터의 패턴을 설명하는 방식이다. 다양한 언어에서 사용가능하며, 정규식을 사용하면 이메일 주소나, 암호와 같은 일련의 문자에서 패턴을 확인하여 해당 정규식에 정의된 패턴과 일치하는지 확인하고, 실행 가능한 정보를 얻을 수 있다.

## 정규식 만들기

자바스크립트에서 정규식을 만드는 방법은 두가지가 있다. `RegExp` 생성자를 사용하여 만들거나, `/` 를 사용하여 패턴을 감싸는 방법이 있다.

### 정규식 생성자

문법 : `new RegExp(pattern[, flags])`

```javascript
var regexConst = new RegExp('abc')
```

### 정규식 리터럴

문법: `/pattern/flags`

```javascript
var regexLiteral = /abc/
```

- `flags`는 옵셔널한 값인데, 이후에 다룬다.

정규식을 동적으로 만들고 싶은 경우가 있는데, 이 경우에는 정규식 리터럴을 사용할 수 없으므로 정규식 생성자를 사용해야 한다.

둘 중에 어떤 방법을 선택하던지 똑같은 정규식이 된다. 두 정규식 객체 모두 메서드와 속성이 동일하다.

> 슬래시는 패턴을 묶는데 사용되므로, 정규식의 일부로 사용하기 위해서는 `\/`와 같이 백슬래시로 이스케이프 해야 한다.

## 정규식 메소드

정규식 테스트를 위해 주로 사용하는 메소드가 두가지 있다.

### ReExp.prototype.test()

이 메서드는 정규식과 일치하는 항목이 있는지 여부를 테스트하는데 사용된다.

```javascript
var regex = /hello/
var str = 'hello world'
var result = regex.test(str)
console.log(result) // true
```

### RegExp.prototype.exec()

이 메소드는, 일치하는 모든 그룹을 배열로 리턴한다.

```javascript
var regex = /hello/
var str = 'hello world'
var result = regex.exec(str)
console.log(result)
// [ 'hello', index: 0, input: 'hello world', groups: undefined ]
// 'hello' -> 패턴에 일치하는 것
// index: -> 시작 index
// input: -> 실제 넘겨 받은 문자열
```

## 간단한 정규식 패턴

리터럴 텍스트와, 테스트 문자열이 일치하는지 확인하는 가장 간단한 패턴이다.

```javascript
var regex = /hello/
console.log(regex.test('hello world'))
// true
```

## 특수문자

사실 간단한 정규식 패턴은 별로 사용할일이 없다. 복잡한 경우를 다룰 때, 정규 표현식을 어떻게 쓰는지 살펴 보자.

예를 들어, 특정 이메일 주소를 확인하는 것이 아니라 여러 이메일 주소를 확인하고자 한다. 여기에서는 특별한 문자가 등장한다. 정규 표현식을 완전히 이해하기 위해서는 이것들을 어느정도 암기해야 한다.

### Flags

정규 표현식에는 다섯 가지의 옵셔널 플래그, 한정자가 있다. 그 중 가장 유명한 두개는 아래와 같다.

- `g`: 글로벌 검색
- `i`: 대소문자 구별을 안함

플래그와 단일 정규식을 결합할 수 있다.

정규식 리터럴 - `/pattern/flogs`

```javascript
var regexGlobal = /abc/g
console.log(regexGlobal.test('abc abc')) // true
var regexInsensitive = /abc/i
console.log(regexInsensitive.test('Abc')) // true
```

정규식 생성자 - `new RegExp('pattern', 'flags')`

```javascript
var regexGlobal = new RegExp('abc', 'g')
console.log(regexGlobal.test('abc abc')) // true
var regexInsensitive = new RegExp('abc', 'i')
console.log(regexInsensitive.test('Abc')) // true
```

### 문자열 그룹

#### `[xyz]`

특정한 위치에 서로 다른 문자를 일치시키는 방법으로, 괄호안에 있는 문자의 문자열에 있는 모든 단일 문자를 확인한다.

```javascript
var regex = /[bt]ear/
console.log(regex.test('tear'))
// returns true
console.log(regex.test('bear'))
// return true
console.log(regex.test('fear'))
// return false
```

#### `[^xyz]`

괄호안에 있는 것과 일치하지 않는 것만 확인한다.

```javascript
var regex = /[^bt]ear/
console.log(regex.test('tear'))
// returns false
console.log(regex.test('bear'))
// return false
console.log(regex.test('fear'))
// return true
```

#### `[a-z]`

모든 알파벳을 특정 위치에서 일치시키고 싶다면, 모든 문자를 쓰는 대신 이처럼 범위를 쓰면 된다. `[a-h]`는 a~h를 의미한다. `[0-9]`를 사용하여 숫자를 찾거나, `[A-Z]`를 사용하여 대문자만 찾을 수도 있다.

```javascript
var regex = /[a-z]ear/
console.log(regex.test('fear'))
// returns true
console.log(regex.test('tear'))
// returns true
```

#### 메타 문자

특수한 의미를 가진 것들을 의미한다. 매우 다양하지만, 일단 중요한 것은 아래와 같다.

- `\d`: 숫자 (`[0-9]`와 같음)
- `\w`: 글자, 숫자, `_`를 포함. (`[a-zA-Z0–9_]`와 같음)
- `\s`: 공백 문자 (스페이스, 탭)
- `\t`: 탭 문자
- `\b`: 단어의 시작이나 끝에 일치하는 단어를 찾는다. 단어 바운더리 라고도 불리운다.
- `.`: 새 줄(`\n`)을 제외한 모든 문자와 일치
- `\D`: `\d`와 같음
- `\W`: `\w`와 정반대
- `\S`: `\s`와 정반대

#### Quantifiers

Quantifiers는 정규식에서 특별한 의미를 갖는 기호를 의미한다.

- `+`: 이전 식과 1회 이상 일치

  ```javascript
  var regex = /\d+/
  console.log(regex.test('8'))
  // true
  console.log(regex.test('88899'))
  // true
  console.log(regex.test('8888845'))
  // true
  ```

- `*`: 이전 식을 0회 이상 일치

  ```javascript
  var regex = /go*d/
  console.log(regex.test('gd'))
  // true
  console.log(regex.test('god'))
  // true
  console.log(regex.test('good'))
  // true
  console.log(regex.test('goood'))
  // true
  ```

- `?`: 이전식을 0, 1번 일치

  ```javascript
  var regex = /goo?d/
  console.log(regex.test('god'))
  // true
  console.log(regex.test('good'))
  // true
  console.log(regex.test('goood'))
  // false
  ```

- `^`: 문자열의 시작과 일치. 문자열 뒤에 오는 정규식은 테스트 문자열의 시작에 있어야 한다. 즉, `^`은 문자열의 시작과 일치해야 한다.

  ```javascript
  var regex = /^g/
  console.log(regex.test('good'))
  // true
  console.log(regex.test('bad'))
  // false
  console.log(regex.test('tag'))
  // false
  ```

- `$`: 문자열의 끝, 즉 문자열 앞에 와야하는 정규식과 일치한다.

  ```javascript
  var regex = /.com$/
  console.log(regex.test('test@testmail.com'))
  // true
  console.log(regex.test('test@testmail'))
  // false
  ```

- `{N}`: 이전 정규식과 N번 일치

  ```javascript
  var regex = /go{2}d/
  console.log(regex.test('good'))
  // true
  console.log(regex.test('god'))
  // false
  ```

- `{N,}`: 최소 N번 이상 이전 정규식과 일치

  ```javascript
  var regex = /go{2,}d/
  console.log(regex.test('good'))
  // true
  console.log(regex.test('goood'))
  // true
  console.log(regex.test('gooood'))
  // true
  ```

- `{N,M}`: 최소 N번 이상 M번 미만으로 정규식과 일치

  ```javascript
  var regex = /go{1,2}d/
  console.log(regex.test('god'))
  // true
  console.log(regex.test('good'))
  // true
  console.log(regex.test('goood'))
  // false
  ```

- `X|Y`: `X` 또는 `Y`와 일치

  ```javascript
  var regex = /(green|red) apple/
  console.log(regex.test('green apple'))
  // true
  console.log(regex.test('red apple'))
  // true
  console.log(regex.test('blue apple'))
  // false
  ```

  ```javascript
  var regex = /a+b/ // This won't work
  var regex = /a\+b/ // This will work
  console.log(regex.test('a+b')) // true
  ```

#### 고오급

- `(x)`: `x`와 일치하고, 이 일치항목을 기억한다. 이를 캡쳐 그룹이라고 한다. 정규식 내 하위 식을 만드는 데에도 사용된다.

  ```javascript
  var regex = /(foo)bar\1/
  console.log(regex.test('foobarfoo'))
  // true
  console.log(regex.test('foobar'))
  // false
  ```

  `\1`는 괄호안의 첫번째 하위 표현식과 일치하는 항목을 기억하고, 이를 사용한다.

- `(?:x)`: x와 일치하는 것을 찾고, 그리고 이를 기억하지 않는다. 이는 논 캡쳐 그룹이라고 한다. `\1`는 작동하지않지만, `\1`과 일치하게 된다.

  ```javascript
  var regex = /(?:foo)bar\1/
  console.log(regex.test('foobarfoo'))
  // false
  console.log(regex.test('foobar'))
  // false
  console.log(regex.test('foobar\1'))
  // true
  ```

- `x(?=y)`: x가 y뒤에 올 경우 일치시킨다. 이를 positive look ahead라고 도 한다.

  ```javascript
  var regex = /Red(?=Apple)/
  console.log(regex.test('RedApple'))
  // Apple앞에있는 Red만 일치
  // true
  ```

## 실제 사용법

### 숫자 10개와 일치하는 정규식

```javascript
var regex = /^\d{10}$/
console.log(regex.test('9995484545'))
```

위 정규식을 하나씩 파해쳐 보자.

1. 일치 항목이 전체 문자열에 걸쳐서 있어야 한다면 (= 전체 문자열과 같아야 한다면) `^`, `$`를 사용하면 된다.
2. `\d`는 숫자만 허용한다
3. `{10}`은 이전 표현식을 10번 일치하는 것을 의미하므로, 여기서는 숫자 10개 일치를 의미한다.

### 날짜 `DD-MM-YYYY`또는 `DD-MM-YY`

```javascript
var regex = /^(\d{1,2}-){2}\d{2}(\d{2})?$/
console.log(regex.test('01-01-1990'))
// true
console.log(regex.test('01-01-90'))
// true
console.log(regex.test('01-01-190'))
// false
```

위 정규식을 하나씩 파해쳐 보자.

1. `^`와 `$`로 문자열 전체를 일치시키는 것만 찾는다.
2. `(`는 첫번째 하위 표현을 의미한다.
3. `\d{1, 2}` 숫자 1~2개
4. `-`: 하이픈 일치
5. `)`: 첫번째 하위 표현 종료
6. `{2}` 첫번째 표현과 정확히 2개 일치하는 경우
7. `\d{2}`: 정확히 두개의 숫자
8. `(\d{2})?`: 두개의 숫자. 그러나 옵셔널 이므로, 년도는 2개나 4개가 가능해진다.

## 조심해야 할 것

### lookbehind 문법은 사파리와 익스플로러에서 쓸 수 없다

[여기](/2020/03/regex-formatting-number)에서도 한번 언급했던 문제. `x(?<=y)` `x(?<!y)`와 같은 lookbehind문법은 [사파리와 익스플로러에서는 지원하지 않으므로](/2020/03/regex-formatting-number), 다른 방법으로 처리해야한다.

### Catastrophic Backtracking

정규식에는 두가지 알고리즘이 존재한다.

- Deterministic Finite Automaton (DFA): 문자열의 문자를 한번만 확인한다.
- Nondeterministic Finite Automaton (NFA): 최적의 일치를 찾을 때 까지 여러번 확인한다.

여기에서 자바스크립트는 NFA 알고리즘을 사용하고 있는데, NFA의 동작으로 인해 Catastrophic Backtracking 가 일어날 수 있다.

무슨말인지 잘 모르겠으니 아래 정규식을 살펴보자.

```javascript
;/(g|i+)+t/
```

매우 간단한 정규식이지만, 매우 무거운 정규식이기도 하다.

- `(g|i+)`: 주어진 문자열이 `g`로 시작하는지, 또는 `i`가 하나이상 있는지 확인한다.
- `+`: 이전 그룹이 한개이상 존재하는지 확인한다.
- `t`: 문자열은 `t`로 끝나야 한다.

이제 다음 정규식에 맞는 글자들은..

```
git
giit
gggt
gigiggt
igggt
```

가 될 것이다.

이 정규식이 얼마나 오래 걸리는지 확인해보자.

```javascript
const regexp = /(g|i+)+t/
console.time('Regexp')
'giiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiit'.search(regexp)
console.timeEnd('Regexp')
// Regexp: 0.210ms
```

제법 빠르게 잘 찾는 것을 볼 수 있다. 그런데, 여기에서 이제 마지막 `t`를 `v`로 바꾸면,,,

```javascript
const regexp = /(g|i+)+t/
console.time('Regexp')
'giiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiv'.search(regexp)
console.timeEnd('Regexp')
// Regexp: 16.360ms
```

엄청나게 오래걸리는 것을 볼 수 있다.

자바스크립트 정규식 엔진은, 첫번째로 성공했던 유효성 검사에서 일련의 문자를 한번 확인한뒤, 다시 이후 검사를 계속한다. `(g|i+)` 만약 특정 위치에서 실패하면, 이전 위치로 다시 돌아가서 또다른 글자를 찾는다.

만약 이 뒤로 돌아가서 글자를 찾는 과정, 즉 역추적이 너무 복잡해지면 알고리즘은 더 많은 컴퓨팅 파워를 보시하게 되고, 이로 인해 Catastrophic Backtracking가 발생하게 된다.

### Nodejs환경에서의 ReDos

[ReDos](https://en.wikipedia.org/wiki/ReDoS)는 앞서 언급했던 Catastrophic Backtracking를 활용하여 nodejs 서버를 공격할 수 있다. 자바스크립트는 싱글 스레드 이기 때문에, `ReDos` 공격은 요청이 완료 될 때 까지 서버가 중단되도록 공격할 수 있다.

일례로, 2.15.2이하 버전의 Moment.js 에서는 ReDos 취약성이 존재한다.

https://snyk.io/test/npm/moment/2.15.2

```javascript
var moment = require('moment')
moment.locale('be')
moment().format('D                               MMN MMMM')
```

위 예제에서는, 날짜 형식은 40자인데 공백만 31개가 있다. 이로 인해 역추적이 발생해 실행시간이 엄청나게 오래걸리게 된다. (moment가 느린 요인 중 하나는 정규식을 사용한다는 것이다.)

이러한 문제가 발생한 것은, moment에서 `+` 연산자를 너무 과도하게 사용했다는 것이다. `/D[oD]?(\[[^\[\]]*\]|\s+)+MMMM?/`

## 안전한 정규식 작성하는 방법

### 1. 가능한 간단하게 작성하기

두 개이상의 `*`, `+`, `}`가 가까 이 있는 경우에 Catastrophic Backtracking 이슈가 발생할 수 있다. 따라서 정규식을 단순화 해서 위와 같은 패턴을 피해야 한다.

### 2. validation 라이브러리 사용

- https://github.com/validatorjs/validator.js
- https://express-validator.github.io/docs/

와 같은 라이브러리로 정규식을 한번 검토하고 나갈 필요가 있다.

### 3. 정규식 analyzer 사용

- https://github.com/davisjam/safe-regex
- https://www.cs.bham.ac.uk/~hxt/research/rxxr2/

를 사용하여, 안전한 정규식인지 한번 확인할 필요가 있다.

### 4. Nodejs의 디폴트 정규식 엔진을 사용하지 말 것.

NodeJS의 디폴트 정규식은 `ReDos` 공격에 취약하므로, 구글에서 만든 [re2](https://github.com/uhop/node-re2)와 같은 별도의 엔진을 사용하는 것이 좋다. 이 엔진은 `ReDos`를 방어할 수도 있으며, 기존 정규식 엔진과 사용도 거의 동릴하다.

```javascript
var RE2 = require('re2')
var re = new RE2(/(g|i+)+t/)
var result = 'giiiiiiiiiiiiiiiiiiit'.search(re)
console.log(result) //false
```

`false`가 나오는 이유는, Catastrophic Backtracking로 부터 안전하지 않기 때문이다.


아직도 정규식이랑 안 친함. 오늘부터 1일....

Page 11

프론트엔드 프로젝트를 위한 github CI workflow

리액트 18에서 변경될 새로운 SSR 아키텍쳐

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

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

자바스크립트에서의 정규식, 이론부터 조심해야 할 것 까지