Datetime을 다루는 것은 분명 쉬운 일은 아니다. 한참 vanilla 자바스크립트에 취해 있을 때, least library challenge(?)의 일환으로 datetime을 내재화 해서 관리하곤 했지만 이는 분명 어려운 일이었다. 그 때 마다 결국 가장 익숙한 moment로 돌아와서 하곤 했는데, 언젠가 bundle 분석을 한 뒤로 moment에 대한 사용을 조금 꺼리기 시작했다. moment는 내가 쓰는 기능 대비 정말 큰 용량을 차지하고 있었다. (timezone을 제외 하더라도) 분명 내가 moment의 좋은 기능을 쉽게 사용하는 면도 있었지만, 조금이라도 더 빠른 애플리케이션을 사용하기 위해서는 moment 외에 다른 대안이 필요했다.

그러던 중, [moment 가 deprecated 된다는 소식을 알려왔다.](https://momentjs.com/docs/)

> ... The modern web looks much different these days. Moment has evolved somewhat over the years, but it has essentially the same design as it did when it was created in 2011. Given how many projects depend on it, we choose to prioritize stability over new features.

조금 많이 뒷북이긴 하지만, 왜 moment가 역사 속으로 사라졌는지 몇가지 이유를 짚고 넘어가고자 한다.

## 1. 느리다

단도직입적으로 그래프를 통해서 알수 있다. 다른 datetime library 대비 속도가 많이 느렸다.

![speed1](https://raygun.com/blog/wp-content/uploads/2017/09/image4-2.png)

![speed2](https://raygun.com/blog/wp-content/uploads/2017/09/image3.png)

![speed3](https://raygun.com/blog/wp-content/uploads/2017/09/image1.png)

출처: https://raygun.com/blog/moment-js-vs-date-fns/

뭐 여러가지 이유가 있겠지만, regex를 주로 쓰는 moment에 대비 다른 라이브러리들은 `Z`로 끝나면 `new Date(string)`을 쓴다던지, 혹은 느린 regex 대신에 자체적으로 개발한(?) `if` 와 `charAt` 등을 쓴다던지 다양한 노력들을 하고 있었다. regex를 파싱해서 이해하는 작업은 확실히 느리다.

## 2. 무겁다

![size-of-datetime-libraries](./images/size-of-datetime-libraries.png)

출처: https://inventi.studio/en/blog/why-you-shouldnt-use-moment-js

https://github.com/jmblog/how-to-optimize-momentjs-with-webpack

기본적으로 momentjs는 232kb, (gzip시 66kb) 이며, webpack으로 locale을 제거할 경우 사이즈는 68kb (gzip시 23kb) 까지 떨어진다. 그리고 더이상의 tree shaking은 불가능하다. js-joda가 제법 크긴 하지만 기간과 타임존까지 기본으로 제공하는 라이브러리라는 것을 알아둬야 한다. 그리고 나머지 라이브러리들은 트리쉐이킹이 가능하다.

## 3.mutable이다.

이는 moment 공식 가이드에서도 언급한 문제다.

> As an example, consider that Moment objects are mutable. This is a common source of complaints about Moment. We address it in our usage guidance but it still comes as a surprise to most new users. Changing Moment to be immutable would be a breaking change for every one of the projects that use it. Creating a "Moment v3" that was immutable would be a tremendous undertaking and would make Moment a different library entirely. Since this has already been accomplished in other libraries, we feel that it is more important to retain the mutable API.

https://inventi.studio/en/blog/why-you-shouldnt-use-moment-js

```javascript
const startedAt = moment()
const endedAt = startedAt.add(1, 'year')

console.log(startedAt) // > 2020-02-09T13:39:07+01:00
console.log(endedAt) // > 2020-02-09T13:39:07+01:00
```

`moment`를 조작하는 모든 method 들은 리턴 값과 참조값 모두를 바꿔 버리기 때문에, 에러를 만들 소지가 높다.

## 4. 디버깅이 어렵다.

`moment`안에 파라미터를 넣는 것은 좋은 아이디어이긴하지만, 그 안에 따라서 동작이 매우 일관적이지 못하다. 예를 들어, moment 안에 잘못된 값을 넣었을 경우 에러가 나는게 아니라 그냥 현재 시간이 나와버릴 수도 있다.

```javascript
moment().format() // > 2019-02-08T17:07:22+01:00
moment(undefined).format() // > 2019-02-08T17:07:22+01:00
moment(null).format() // > Invalid date
moment({}).format() // > 2019-02-08T17:07:22+01:00
moment('').format() // > Invalid date
moment([]).format() // > 2019-02-08T17:07:22+01:00
moment(NaN).format() // > Invalid date
moment(0).format() // > 1970-01-01T01:00:00+01
```

요약하자면, `undefined`는 가능하지만, `null` `''`, `NaN`은 안된다.

## 결국

lighthouse에서도 에러가 뜨고

![lighthouse warning](https://pbs.twimg.com/media/EhM0XE3UwAA2Co5?format=jpg&name=medium)

https://twitter.com/addyosmani/status/1304676118822174721

moment를 최적화 하는 방법까지도 알려지기 시작했다.

https://github.com/GoogleChromeLabs/webpack-libs-optimizations#moment

## 대안

사이즈가 중요한 프론트엔드의 경우 `date-fns`나 `day.js`가 좋다. 그 외의 경우에는 기능이 가장 리치한 `js-joda`를 사용하는 것이 좋다.

|          | size   | size(gzip) | speed(to) | tree-shaking | immutable | throw error | timezone |
| -------- | ------ | ---------- | --------- | ------------ | --------- | ----------- | -------- |
| moment   | 232/68 | 66/26      | 16.527    | X            | X         | X           | O        |
| day.js   | 6      | 3          | 9.129     | X            | O         | X           | X        |
| luxon    | 64     | 18         | 15.406    | X            | O         | O           | O        |
| js-joda  | 208    | 39         | 11.397    | X            | O         | O           | O        |
| date-fns | 30     | 7          | 5.175     | O            | O         | X           | X        |
| native   |        |            | 1.297     |              | X         | X           | X        |

출처: https://inventi.studio/en/blog/why-you-shouldnt-use-moment-js#fnref2

그럼에도, 저렇게 큰 라이브러리 자체를 deprecated 시킬 수 있다는 것 만으로도 자바스크립트 생태계가 건강하게 나아가고 있다는 방증인 것 같다. 여전히, 많은 수의 프로젝트가 moment에 의존하고 또 그 편리함에 많은 도움을 얻었다. moment가 이야기 한 `modern web looks much different these days` 처럼, 이제는 다른 라이브러리를 쓸 때가 왔다. 그리고 나 또한, 오래되고 낡은 코드를 과감하게 deprecated 시킬 용기가 필요하다.


왜 moment 는 deprecated 되었을까

가비지 컬렉션은 모든 언어에서 굉장히 중요한 프로세스다. C와 같은 언어에서 수동으로 처리하고, 다른 언어에서는 이를 자동으로 처리한다. 이를 자바스크립트 내부에서는 어떻게 처리할까?

## 자바스크립트 메모리 라이프 사이클

거의 모든 프로그래밍 언어의 메모리 라이프 사이클은 다음과 같이 작동한다.

1. allocate (할당)
2. use (사용)
3. release (해제)

차이 점은 이를 수행하는 방식 (사용하는 알고리즘)과 각 단계를 처리하는 방식(수동인지, 자동인지 여부)에 있다.

자바스크립트의 경우, 할당 및 해제는 자동으로 이루어 진다. 그렇다고 해서 개발자가 이에 대해 관심을 갖지 말라는 것은 아니다. 무한 루프, 잘못된 재귀처리, 콜백 지옥 등은 메모리 낭비를 이르켜 메모리 누수로 이어진다. 따라서 코딩을 잘해서 이러한 시나리오가 발생하지 않도록 하는 것이 중요하다.

자바스크립트의 경우, 새로운 변수가 선언되면 메모리에 공간이 할동 된다.

```javascript
var bar = 'bar'
```

그리고 메모리가 더이상 사용되지 않는다면, [변수 스코프](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/var) 제한을 고려하여 메모리 공간 해제가 이루어진다.

하지만 어떻게 자바스크립트에서 더이상 메모리가 사용되지 않는다는 것을 알까? 그것은 바로 가비지 콜렉를 통해서 이루어진다.

## 가비지 콜렉션 전략

자바스크립트는 두개의 유명한 가비지 콜렉션 전략을 사용한다.

- Reference-counting
- Mark-and-sweep

[레퍼런스 카운팅](https://en.wikipedia.org/wiki/Reference_counting)은 파일, 소켓, 메모리 슬롯등 할당된 각 리소스를 가리키는 참조의 수를 계산하는 것이다.

메모리에 할당된 각 객체에 연결된 count 필드가 포함되어 있다고 생각해보자. 객체에 더이상 가리키는 참조가 없을 떄 자동으로 가비지 콜렉팅 된다.

```javascript
var bar = {
  name: 'bar',
}
bar = ''
```

위 예제에서 `bar`와 `name`이 존재한다. `bar`는 새로운 값을 받았기 때문에, `name`은 가비지 콜렉팅 된다.

좀 더 복잡한 아래 예제를 살펴보자.

```javascript
var bar = {
  name: 'bar',
}
var bar = 'foo'

function check() {
  var bar = {}
  var foo = {}
  bar.name = foo
  foo.name = bar

  return true
}
check()
```

자바스크립트는 객체에 대한 참조 기반의 언어로, 이는 즉 객체 명이 매모리 내 인스턴스화 된 값을 가리키는 것을 의미한다. 이 예제에서는, 자식의 객채/변수는 부모가 자동으로 참조한다.

위 예제에서는 순환 참조를 만들고 있다. `check`함수내의 `bar`는 `foo`를 참조하고 있으며 그 반대 경우도 마찬가지다.

일반적으로 함수가 실행을 마치면 내부 요소는 가비지 컬렉팅이 된다. 그러나 이경우에는 객체가 여전히 서로 참조되고 있기 때문에 가비지 컬렉팅 되지 않는다.

여기에서 이제 자바스크립트의 두번째 작전인 `mark-and-sweep` 알고리즘이 동작한다.

이 알고리즘은 자바스크립트의 최상위 객체인 `global`(`window`)에 도달할 수 없는 객체를 찾는 방식으로 작동한다.

![mark-and-sweep1](https://d33wubrfki0l68.cloudfront.net/eff15dde3b4a6db32945c32b8b04047bc9ec9b8a/47eba/images/blog/2020-10/figure2.png)

보시다시피, 자바스크립트는 `name` 객체를 최상위에서 쉽게 찾을 수 있다.

만약 다음 코드가 실행되면 어떻게 될까?

```javascript
var bar = 'foo'
```

![mark-and-sweep2](https://d33wubrfki0l68.cloudfront.net/ad95ba131dc543352e80b6b34d48cf2003c7011b/3160a/images/blog/2020-10/figure3.png)

이제 더이상 `name`은 root에서 접근할 수 없는 객체가 된다.

나머지 프로세스는 굉장히 직관적이다. 알고리즘은 루트에서 하단의 객체까지 각각 루트에서 접근할 수 있는 객체인지, 혹은 `name`처럼 더이상 접근할 수 없는 객체인지를 별도로 표시해둔다.

이 과정은 자바스크립트의 GC만 알고 있는 몇몇 내부 조건을 통해 반복되고 있는데, 이는 대부분의 언어의 GC에서도 동일하게 동작한다.

## Node.js의 가비지 콜렉션

Node.js의 가비지 콜렉션이 어떻게 동작하는지 이해하기 전에, heap과 stack에 대해서 알아두어야 한다.

heap은 참조유형에 해당하는 데이터들이 나타나는 곳이다. 여기서 참조 유형이라 함은 객체, string, 클로져 등을 의미한다.

따라서 자바스크립트에서 객체가 만들어지면, 객체는 heap에 위치하게 된다.

```javascript
const myCat = new Cat('Joshua')
```

반면에, stack은 heap에서 생성된 객체에 대한 참조가 저장되는 곳이다. 예를 들어 함수의 argument는 stack에 존재하는 참조의 좋은 예다.

```javascript
function Cat(name) {
  this.name = name
}
```

그리고 힙은 `new space`와 `old space`로 나누어진다.

![heap](https://d33wubrfki0l68.cloudfront.net/0c2c3b1c7345423b26f87fa469dac4b20ec11d16/5db77/images/blog/2020-10/figure4.png)

`New space`는 새로운 객체와 변수를 할당하는 메모리 영역이며, 이름 그대로 새로운 것들이기 때문에 GC 처리가 빠르다. 이름에서 알 수 있듯이, 이영역은 비교적 이르게 할당된 객체들이 존재한다.

`Old space`는 `new space`에서 수집되지 않는 객체들이 얼마 후에 이동하는 곳이다. 사이즈가 큰 객체나, V8로 컴파일된 코드와 같은 것들이 존재한다.

Node.js는 GC가 `old space`로 가지 않도록 최선을 다한다. 왜냐하면 `old space`는 GC를 하는데 더 많은 비용이 들기 때문이다. 따라서 전체 대상의 20% 정도만 `old space`로 이동한다.

- `Scavenge`: 이 가비지 컬렉터는 실행될 때마다 메모리의 작은 부분을 청소하여 `young generation`을 처리한다. 매우 빠르다.
- `Mark-and-sweep`: 아까 언급했던 알고리즘으로, 느리지만 `old generation`에서 유용하게 동작할 수 있다.

## Node.js의 메모리 누수 예제

자바스크립트가 Nodejs 에서 메모리를 다루는 방법을 보는 좋은 예제는 아주 클래식한 메모리 누수 예제를 보는 것이다. 메모리 누수는 모든 GC전략이 루트 객체와의 연결을 잃어서 객체를 찾지 못할 때 발생한다. 그 외에도, 객체가 항상 다른 객체에 의해 참조되면서 동시에 크기가 커지는 경우에도 발생할 수 있다.

예를 들어 간단한 nodejs서버가 아래와 같이 있으며, 모든 요청에서 중요한 데이터를 저장하려 한다고 생각해보자.

```javascript
const http = require('http')

const ml_Var = []
const server = http.createServer((req, res) => {
  let chunk = JSON.stringify({ url: req.url, now: new Date() })
  ml_Var.push(chunk)

  res.writeHead(200)
  res.end(JSON.stringify(ml_Var))
})

const PORT = process.env.PORT || 3000
server.listen(PORT)
```

모든 요청에 대해서 json stringify로 리스트에 푸쉬한다고 가정해보자. `ml_Var`는 글로벌 변수 이기 때문에 서버가 종료될 때 까지 메모리에서 계속 존재할 수 있다. 이는 굉장히 위험한 지점이다.

특히 다른 개발자들이, 내가 볼 수 없는 지점에서 아이템을 추가할 수 있기 때문에, 이러한 객체는 애플리케이션에서 문제를 야기할 수 있다.

```bash
node --inspect index.js
```

```bash
Debugger listening on ws://127.0.0.1:9229/16ee16bb-f142-4836-b9cf-859799ce8ced
For help, see: https://nodejs.org/en/docs/inspector
```

이제 크롬에서 `chrome://inspect` 명령어로 살펴보면 아래와 같은 화면이 나온다.

![chrome-inspection](./images/chrome-inspection.png)

`remote target` 섹션에 `inspect`링크가 있다. 이를 클릭하면, nodejs 애플리케이션의 세션을 볼 수 있는 화면이 뜬다. 로그, 소스, CPU 프로파일링 및 메모리 분석 등을 수행할 수 있다.

메모리 탭에서 `Take snapshot`을 크릭하면, 현재 실행중인 애플리케이션의 더미 스냅샷 프로필 (메모리 덤프)를 생성한다. 메모리 누수가 일어나기 전후의 메모리를 비교하는 것이 일단 목표다.

메모리 덤프를 가져오기에 앞서, 벤치 마킹을 돕기 위한 도구로 [siege.js](https://www.npmjs.com/package/siege)를 사용할 것이다. 이 라이브러리는 엔드포인트에 대해 수백 수천건의 요청을 실행하는 작업을 단순화 하는 node.js의 벤치마킹 도구다.

```javascript
const siege = require('siege')
siege().on(3000).for(2000).times.get('/').attack()
```

3000포트에 대해서 `/`요청을 2000번 날릴 것이다.

```bash
GET:/
GET:/
GET:/
GET:/
GET:/GET:/GET:/GET:/        done:2000        200 OK: 2000        rps: 2721        response: 1ms(min)      24ms(max)     5ms(avg)
```

DevTool로 돌아가서 `Take snap shot`버튼을 누르자.

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

수 많은 string 들이 쌓인 것을 볼 수 있다. 실제 애플리케이션이었다면, 더 많은 양의 string 이 쌓여 있을 것이다. 따라서 이러한 메모리 누수를 조기에 발견하고 해결해야 할 것이다.

## 더 읽어보기

- [ibm의 javascript memory leak 보고서](https://www.ibm.com/developerworks/web/library/wa-memleak/wa-memleak-pdf.pdf)
- [Mozilla Performance](https://developer.mozilla.org/en-US/docs/Mozilla/Performance)


원래 이런건 이해가 될 때 까지 하는거임

자바스크립트의 가비지 컬렉션

대부분의 프론트엔드 개발자들은 V8이라는 용어를 들어본 적이 있을 것이다. V8은 구글에서 만든 오픈소스 자바스크립트 및 웹 어셈블리 엔진으로, C++ 로 작성 되어있으며 현재 크롬과 Nodejs 등에서 사용되고 있다. V8의 중요한 역할 중 하나는 generational (데이터의 시간에 따라서 정렬한다는 뜻인데, 정확히 뭐라고 표현해야 할지 모르겠다) 하면서도 매우 정확한 가비지 콜렉션이다. 메모리를 많이 사용하지 않더라도, 자바스크립트가 더 이상 필요하지 않은 객체를 수집하도록 최적화 되어 있다. 이 외에도 V8은 역사적으로 자바스크립트의 속도를 느리게 만드는 고유의 기능성을 개선하기 위해 일련의 다른 툴과 feature들을 사용한다. 이 글에서 이러한 도구 (Ignition 과 TurboFan)와 다양한 기능에 대해서 알아보고자 한다. 그 외에도 V8의 내부 기능, 컴파일 및 가비지 콜렉션 절차, 단일 스레드 특성 등의 기본 특성을 알아보고자 한다. 기회가 된다면, 정말 V8을 코드 레벨로도 살펴볼 수 있었으면 좋겠다.

## 기초부터 살펴보기

기계 코드 (Machine code)는 어떻게 동작할까? 기계 코드란 메모리의 특정부분에서 실행될 수 있는 매우 저수준의 언어 명령의 집합이다. C++ 를 기준으로 그 과정을 묘사해보자면 아래와 같다.

![process](https://d33wubrfki0l68.cloudfront.net/b08f7bc5a007ad810a62c6c2edf1510bcd18001f/2f357/images/blog/2020-07/figure01.png)

더 나아가기전에, 자바스크립트의 interpretation 과 는 다른 컴파일 과정이라는 것에 대해 알아볼 필요가 있다. 컴파일러는 프로세스가 끝날 때 전체 프로그램을 생성하는 반면, interpreter는 instruction (자바스크립트의 스크립트와 같은)을 읽고 실행 가능한 명령으로 말 그대로 번역하여 그 일을 하는 프로그램으로 자체 동작하게 된다.

이러한 interpretation 과정은 즉시 (인터프리터가 현재 명령 구문만 분석하고 실행) 이루어지거나 완전히 구문 분석을 마친뒤에 (인터프리터가 기계명령을 진행하기 전에 스크립트 전체를 완전히 번역할때) 모두 발생할 수 있다.

그림으로 돌아가서 다시 보면, 컴파일 프로세스는 일반적으로 알려져 있는 것처럼 소스코드로부터 시작된다. 코드를 구현하고, 이를 저장한 뒤에 실행한다. 컴파일러는 여느 프로그램처럼 머신에서 실행된다. 그런 다음 모든 코드를 살펴보고 객체 파일을 생성한다. 이러한 파일은 기계 코드다. 특정 컴퓨터에서 실행되는 최적화된 코드이므로 다른 OS 에서 이를 활용 할 때는 다른 컴파일러를 사용해야 한다.

그러나 이를 위해 별도의 객체 파일을 실행할 수는 없으므로, `.exe`와 같이 실행파일 형태의 단일 파일로 결합해야 한다. 이것이 바로 링커의 일이다.

마지막으로 로더는 해당 exe 파일의 코드를 OS 의 가상메모리로 전송하는 에이전트 이다. 그리고 마침내 프로그램이 실행된다.

대부분의 경우 (은행의 메인 프레임에서 Assembly로 직접 작업하는 개발자가 아니라면) Java, C#, Ruby, Javascript 와 같은 고수준 언어로 프로그래밍을 하는데 많은 시간을 할애 한다. 언어의 수준은 높을 수록 느리다. 기계어 코드인 어셈블리언어에 가까울 수록 빨라지며, 그렇기 때문에 C와 C++이 빠르다.

성능과 별도로 V8의 주요 이점 중 하나는 ECMAScript 표준을 넘어서 C++ 도 이해 할 수 있다는 것이다.

![V8](https://d33wubrfki0l68.cloudfront.net/d056b38131c76fa5337d0fc172b70382662d87e6/8f55e/images/blog/2020-07/figure02.png)

자바스크립트의 기능은 ECMAScript를 준수한다. 그리고 V8은 이 규정을 준수하는 한편으로, 이에 제한되지 않는다.

C++ 기능을 V8에 이용할 수 있는 능력은 매우 훌륭하다. C++은 파일조작, 메모리 및 스레드 처리와 같은 OS의 특수성을 매우 능숙하게 다를 수 있는데, 이러한 기능을 자바스크립트에서도 할 수 있게 끔 구현 해 두었다.

## 단일 스레드

Node 개발자라면 V8의 단일 스레드 특성에 익숙할 것이다. 각 자바스크립트 실행 컨텍스트는 하나의 스레드를 가지고 있다. 물론 이러한 OS 쓰레드 메커니즘을 V8이 뒤에서 제어하고 있다. 복잡한 소프트웨어이고, 동시에 많은 것을 수행해야 하기 때문에 이는 둘 이상의 스레드에서 작동한다. 코드를 실행하는 메인스레드, 코드를 컴파일를 다른 스레드, 가비지를 수집하는 스레드 등이 존재할 수 있다.

그러나 V8은 각 자바스크립트 컨텍스트 마다 하나의 싱글 스레드 환경을 만들어준다. 나머지는 V8의 제어 하에 놓여져 있다.

자바스크립트 코드가 호출한 함수의 스택을 상상해보자. 자바스크립트는 각 함수를 삽입 또는 호출한 순서에 따라 한 함수를 다른 함수 위에 쌓는 (스택) 방식으로 작동한다. 각 함수의 콘텐츠에 도달하기 전까지, 다른 함수를 호출하는지를 알 수 없다. 만약 그렇게 된다면, 호출자의 바로 뒤에 호출된 함수가 스택으로 배치될 것이다. 예를 들어 콜백의 경우, 맨 끝에 놓여지게 된다.

이러한 스택의 관리와 메모리 배치가 V8의 메인 작업 중 하나다.

## Ignition, Turbofan

2017년 5월에 발표된 5.9 버전 이후로, V8은 [Ignition](https://v8.dev/docs/ignition) 이라고 하는 V8 인터프리터를 자바스크립트 실행 파이프라인 최 상단에 배치 하였다. 또한 더 나은 최적화 컴파일러인 [Turbofan](https://v8.dev/docs/turbofan)도 모습을 드러냈다.

이러한 변화는 전체적인 성능에 초점을 맞추었고, 구글 개발자들이 자바스크립트 생태계가 제기하는 빠르고 상당한 엔진의 변화를 적용할 때 구글 개발자들이 직면하는 어려움을 해결하는데 중점을 두었다. 프로젝트가 시작될 때 부터 V8 메인테이너들은 자바스크립트가 진화하는 것과 같은 속도로 V8의 성능을 향상 시킬 수 있는 좋은 방법을 찾는것에 대한 고민이 있었다. 이러한 노력 덕분에, 새엔진을 가동할 떄 큰 성능의 이점을 볼 수 있다.

![performance-of-5.9](https://d33wubrfki0l68.cloudfront.net/c145cd3d5a9719cb841c61baf13fef7819b41450/c4b00/images/blog/2020-07/figure03.png)

## Hidden Classes

V8의 마법같은 요소 중 하나다. 자바스크립트는 동적 언어다. 즉 실행 되는 과정에서 새로운 속성이 추가되거나, 대체되거나, 삭제될 수 있다는 것을 의미한다. 자바나 대다수의 언어의 경우 애플리케이션 시작 이후에는 동적으로 변경될 수 없는 언어와는 다른 차이다. 이러한 특징 때문에 해시 함수를 기초로한 dictionary lookup을 수행하여 이 변수가 객체가 메모리에 할당되는 위치를 장확히 알고 있다. 그러나 이는 최종 프로세스에 많은 비용이 든다. 이에 반해 다른언어에서는 객체가 생성될 떄, 암묵적인 속성 중 하나로 주소(포인터)를 받는다. 이 방법으로 이들이 메모리 어디에 위치하고 있는지, 얼마나 많은 공간을 할당해야 하는지를 정확히 알 소 있다.

그러나 자바스크립트는 아직 존재하지 않는 것을 매핑할 수 없기 때문에 이러한 방법을 적용하는 것은 불가능하다. 그리고 여기에서 hidden class를 사용한다. 이는 자바에서와 거의 동일하다. 고정된 클래스와 고유 주소를 사용하여 위치를 찾는다. 그러나 프로그램 실행전에 하는 것이 아니고, V8은 런타임 도중에, 객체의 구조에 동적인 변화가 수행될 때 마다 이를 수행한다. 아래 코드를 살펴보자.

```javascript
function User(name, phone, address) {
  this.name = name
  this.phone = phone
  this.address = address
}
```

자바스크립트는 프로토타입 기반의 언어이므로, User 객체를 초기화 하면 아래처럼 된다.

```javascript
var user = new User('John May', '+1 (555) 555-1234', '123 3rd Ave')
```

그러면 V8은 hidden class를 만든다. `_User0`이라고가정하자.

![_User0](https://d33wubrfki0l68.cloudfront.net/a875a24a8469140ca028f18f67a9b2c3f46cdef3/51e3d/images/blog/2020-07/figure04.png)

각 객체는 메모리에서 클래스 표현에 대한 참조를 가지고 있다. 이 시점에서 방금 새로운 객체를 인스턴스화 했기 때문에, 메모리 속에 숨겨진 클래스를 만들었다. 그리고 당장은 비어있다. 그리고 함수의 첫번째 줄을 실행하게 되면, 새로운 hidden class가 이전 hidden class를 기반으로 생성된다. 그리고 이를 `_User1`이라고 해보자.

![_User1](https://d33wubrfki0l68.cloudfront.net/af62dca2334af839e484b038be90d54bb3119a22/ccce1/images/blog/2020-07/figure05.png)

기본적으로 `User`의 메모리 주소는 `name`속성을 갖는다. 이 예제에서는, `name`만 가진 `user`를 속성으로 사용하는 것이 아니라, 매번 이렇게 할 때마다 hidden class V8이 참조로 로드된다. `name` 속성은 메모리 버퍼에 `offset 0`으로 추가되는데, 이 뜻은 첫번째 속성으로 분류된다는 것이다.

V8은 또항 transition value를 `_User0` hidden class에 추가 했다. 이는 인터프리터가 `User`에 `name`속성이 추가 될 때 마다, `_User0`에서 `_User1` 로 값의 이동이 이루어 져야 한다는 것을 알려 준다.

그리고 두번째 줄이 호출되면, 같은 과정이 반복되면서 hidden class 가 생성된다.

![_User2](https://d33wubrfki0l68.cloudfront.net/1ab5bbae18ab7ed6fccc301c742ba15dd9599503/57581/images/blog/2020-07/figure06.png)

hidden class가 스택형태로 쌓여 있는 것을 볼 수 있다. 하나의 hidden class가 체이닝 형태로 값을 이어가고 있는 것을 볼 수 있다. 이 속성의 순서는 V8이 hidden class를 만드는 순서를 결정한다. 속성의 순서를 바꾼다면, 생성되는 hidden class의 순서도 바뀐다. 이러한 이유 떄문에 개발자들이 가급적이면 존재하는 hidden class를 재사용하기 위해 속성의 순서를 유지하는 것이다.

## 인라인 캐싱

JIT 컴파일러를 사용한다면 이는 매우 익숙한 용어다. 이는 hidden class의 콘셉트와 바로 직결된다. 예를 들어, 객체를 매개변수로 하는 함수를 호출 할 때마다 V8은 이 동작을 보고, "음.. 이 객체는 이 함수에 대한 매개변수를 두번이상 성공적으로 전달했군, hidden class를 검증하는 프로세스를 다시 수행하지 않고 향후 호출을 위해 캐시에 저장해두면 어떨까?" 라는 생각을 하게 된다.

```javascript
function User(name, fone, address) {
  // Hidden class _User0
  this.name = name // Hidden class _User1
  this.phone = phone // Hidden class _User2
  this.address = address // Hidden class _User3
}
```

`User` 객체가 함수의 파라미터로 두번이상 초기화 된다면, V8은 hidden class를 참고하는 것을 스킵하고 바로 속성의 offset을 참고한다. 이게 훨씬 빠르다. 그러나 항상 명심해 두어야 할 것은, 속성의 순서가 변하게 된다면 다른 hidden class를 만들게 되기 때문에 인라인 캐싱이 어려워진다.

## 가비지 컬렉팅

V8의 가비지 컬렉팅은 프로그램 실행 스레드와 다른 스레드에서 이뤄지기 때문에, 프로그램 실행에 영향을 미치지 않는다. V8은 [mark-and-sweep](https://en.wikipedia.org/wiki/Tracing_garbage_collection#Copying_vs._mark-and-sweep_vs._mark-and-don't-sweep)이라는 방식으로 메모리에서 죽거나 오래된 객체를 가비지 컬렉팅 한다. 이 방법은, GC가 메모리 객체를 스캔하여 수집을 위해 '표시'하는 단계는 이를 작업하기 위해 실행을 일시 중지 시키기 때문에 다소 느리다.

그러나 V8은 점진적으로 최대한 많은 객체에 'mark'를 해두려고 한다. 수집이 끝날 때 까지, 전체 실행은 중단될 필요가 없기 때문에 빠르게 이뤄진다. 대용량 애플리케이션에서는, 이러한 성능의 향상이 많은 차이를 만든다.


맛만 볼게 아니고 직접 코드 까봐서 공부를 해봐야 되는데 😭

V8 엔진에 대해 가볍게 살펴보기

뒤로가기/앞으로가기 캐시 (이해 bfcache)는 브라우저에서 일어나는 최적화로, 앞으로가기나 뒤로가기가 발생했을 때 화면을 즉시 보여주는 역할을 한다. 이는 사용자의 브라우저 사용성을 향상시키는데, 특히 느린 네트워크/디바이스에서 빛을 발한다.

## 브라우저 호환성

bfcache는 [파이어폭스](https://developer.mozilla.org/en-US/docs/Mozilla/Firefox/Releases/1.5/Using_Firefox_1.5_caching)와 [사파리](https://webkit.org/blog/427/webkit-page-cache-i-the-basics/)에서 몇년전부터 지원하고 있었다. 크롬 역시 마찬가지다

## bfcache란

bfcache는 인메모리 캐시로, 자바스크립트 힙까지 포함해 페이지 전체를 완전히 캐시로 저장해버리는 것을 의미한다. 전체 페이지가 메모리 안에 있기 때문에, 사용자가 이전페이지로 돌아가고자 했을 때 빠르게 전체 페이지를 보여줄 수 있다.

### bfcache가 비활성화 되어 있다면

이전 페이지 로딩을 위해서 새로운 요청을 시도할 것이며, 반복적인 방문에 따라서 웹페이지가 얼마나 최적화 되어 있냐에 따라서 브라우저는 재다운로드, 재 parsing, 재 실행등을 일부 실행하거나 혹은 이를 다 다시 처음부터 시도할 것이다.

### bfcache가 활성화 되어 있다면

전체 페이지가 메모리에 저장되어 있기 때문에, 네트워크 요청을 할 필요 없이 이전 페이지 로딩이 즉시 이루어진다.

크롬의 사용 데이터에 따르면 데스크톱의 탐색중 10%, 모바일 탐색 중 20%가 뒤로가기/또는 앞으로가기에서 이루어진다. bfcache를 이용하게 되면 웹페이지를 로드하는데 소요되는 데이터, 시간 등을 아낄 수 있다.

## 어떻게 동작하는가?

우리가 흔히 알고 있는 HTTP cache와는 동작이 다르다. bfcache는 자바스크립트 힙을 포함해 전체 페이지를 통채로 스냅샷을 떠서 메모리에 올려 버린다. 이에 반해 HTTP 캐시는 이전 요청에서 이루어진 응답에 대해서만 캐싱할 뿐이다. 페이지 로딩에 필요한 모든 요청을 HTTP 캐시로 만족시키는 것은 매우 드물기 때문에, bfcache 복원을 사용한 페이지 방문은 bfcache를 사용하지 않은 '잘 최적화된' 캐시보다 항상 빠르다.

그러나 페이지 스냅샷을 메모리에 올린다는 것은, 현재 실행중인 코드를 보존하려고 할 때 복잡해진다. 예를 들어, 페이지가 bfcache가 되어 있는 동안에 `setTimeout`호출이 있으면 어떻게 해야할까?

정답은 브라우저가 보류중인 timer, 또는 promise의 실행을 일시 중지하고 (기본적으로 자바스크립트 태스크 큐에 있는 모든 작업) 페이지가 bfcache로 부터 복원이 되었을 때 다시 실행하는 것이다.

이는 매우 합리적인 방법으로 보이지만, 때로는 굉장히 복잡한 결과나 이해할 수 없는 행동을 만들어 낼 수도 있다. 만약에 브라우저가 `IndexedDB transaction` 의 일환인 작업을 중지한다고 한다면, 다른 탭에서도 접근할 수 있는 indexedDB의 특성상 다른 탭에서 페이지를 열었을 때 영향을 미칠 수 있다. 그래서 브라우저는, IndexedDB 트랜잭션 또는 다른 페이지에 영향을 줄 수 있는 API 호출 중에는 페이지를 캐싱하려 하지 않는다.

## bfcache의 작업을 api로 살펴보기

bfcache는 브라우저가 자동으로 하는 최적화이지만, 여전히 개발자들이 이 동작을 잘 이해 한다면 페이지를 최적화 하거나 성능을 측정하고 조정하는데 도움을 얻을 수 있다.

bfcache를 관찰할 수 있는 가장 좋은 이벤트는 `pageshow`와 `pagehide`다. [새로운 페이지 라이프 사이클 이벤트](https://developers.google.com/web/updates/2018/07/page-lifecycle-api)인 `freeze` 와 `resume`도 bfcache를 확인하는데 도움을 얻을 수 있다. 예를 들어, CPU 사용량을 최소화 하기 위하여 백그라운드 탭을 프리징할 때에 이 이벤트를 쓸 수 있다. 하지만 이는 오로지 크로미윰 브라우저에서만 확인가능하다.

### bfcache를 복원하는 순간을 확인하기

`pagehide`와 `pageshow`는 쌍으로 일어난다. `pageshow`는 페이지가 정상적으로 로딩 되거나, bfcache 로부터 페이지 복원 될 때 일어난다. `pagehide`는 마찬가지로 페이지가 정상적으로 언로드 되거나, bfcache로 들어가는 순간에 일어난다.

`pagehide`는 `persisted`속성을 가지고 있는데, `false`가 리턴되면 page가 bfcache되지 않음을 의미하는 것이다. 그렇다고 `true` 라고 해서 bfcache를 보장하는 것은 아니다. 단지 브라우저가 페이지를 캐싱 시도했다는 것을 의미하며, 무언가 다른 이유로 인해서 캐싱이 안될 수도 있다.

```javascript
window.addEventListener('pagehide', function (event) {
  if (event.persisted === true) {
    console.log('bfcache가 될 수도 있음')
  } else {
    console.log(
      '정상적으로 unload되며 이전 페이지 상태는 bfcache가 안들어가기 때문에 다 버려짐.',
    )
  }
})
```

비슷하게 `freeze`에도 같은 속성이 있으며, 같은 이유로 캐싱을 보장하지 않는다.

## bfcache로 페이지 최적화 하기

모든 페이지가 bfcache로 처리되는 것은 아니며, 심지어 캐싱이 되었다 하더라도 영원히 남아 있는 것은 아니다. 개발자들이 캐시 히트 레이트를 극대화 하기 위해 bfcache를 가능하게/혹은 불가능하게 만드는 것을 이해하는 것이 중요하다.

### 절대로 `unload` 이벤트를 사용하지 말 것

모든 브라우저에서 bfcache로 최적화하는데 가장 중요한 것은 절대절대로 `unload`이벤트를 임의로 사용해서는 안된다는 것이다. 이 `unload`이벤트는 bfcache 이전에 발생하고, 인터넷의 많은 페이지가 `unload`이벤트가 발행 후에는 페이지가 더이상 존재하지 않는다는 (합리적인) 가정하에 동작하기 때문에, `unload`의 이벤트는 문제를 야기 할 수 있다. 많은 개발자들이 `unload` 이벤트가 더이상 사용자가 페이지 네비게이션을 하지 않을 때 발생한다고 믿고 있는데, 이는 사실이 아니다.

> Many developers treat the unload event as a guaranteed callback and use it as an end-of-session signal to save state and send analytics data, but doing this is extremely unreliable, especially on mobile! The unload event does not fire in many typical unload situations, including closing a tab from the tab switcher on mobile or closing the browser app from the app switcher.

파이어폭스는 `unload`에 리스너가 달려 있을 경우, bfcache에 적합하지 않은 페이지로 처리한다. 사파리는 `unload`이벤트 리스너와 함께 페이지 케싱을 시도하는데, 잠재적인 버그를 줄이고자 유저가 네비게이션을 실행해버리면 `unload` 이벤트를 실행시키지 않는다. 크롬은 현재 [전체 페이지의 65%에 `unload`이벤트를 달았는데](https://www.chromestatus.com/metrics/feature/popularity#DocumentUnloadRegistered) 사파리와 마찬가지로 이를 실행하지 않는다.

`unload`이벤트 대신에 `pagehide`이벤트를 사용하는 것이 좋다.

### 조건이 있을 때만 `beforeunload`이벤트를 추가해라

`beforeunload`는 크롬과 사파리에 영향을 받지 않지만, 파이어 폭스의 경우 bfcache를 무력화 할 수 있으므로 사용해서는 안된다.

`unload`이벤트와는 다르게, 합리적으로 `beforeunload`를 사용할 수 있는 케이스가 존재한다. 예를 들어, 사용자가 데이터를 저장하지 않고 페이지를 떠나려고 하는 경우, `beforeunload`를 사용하여 사용자에게 경고를 하고, 사용이 끝난 즉시 지워버리는 것이 좋다.

🙅‍♂️ 하지 말것

```javascript
// 이벤트가 계속 남아있게 된다.
window.addEventListener('beforeunload', (event) => {
  if (pageHasUnsavedChanges()) {
    event.preventDefault()
    return (event.returnValue = 'Are you sure you want to exit?')
  }
})
```

🙆 해도 되는 것

```javascript
function beforeUnloadListener(event) {
  event.preventDefault()
  return (event.returnValue = 'Are you sure you want to exit?')
}

onPageHasUnsavedChanges(() => {
  window.addEventListener('beforeunload', beforeUnloadListener)
})

// 더이상 사용이 필요 없으면 바로 지운다.
onAllChangesSaved(() => {
  window.removeEventListener('beforeunload', beforeUnloadListener)
})
```

### window.opener references의 사용을 피할 것

일부 브라우저 (크롬 86 포함) 페이지를 `window.open`또는 `target=_blank`에 `rel="noopner"`를 명시하지 않고 페이지를 열었을 경우 열린 페이지는 페이지를 이 페이지를 열어준 페이지에 대해서 참조를 사용하게 된다.

또한 보안상의 이유로 인해, `window.opener`의 null이 아닌 참조를 가지고 있는 페이지는 bfcache를 안전하게 사용할 수 없다. 이는 bfcache에 접근을 시도하는 페이지에 대해 위협이 되기 때문이다.

따라서 `window.opener`를 쓸 때는 반드시 `rel="noopener"`를 써야 한다. 만약 열린 윈도우에 대해 제어가 필요하다면 `window.postMessage`를 사용하는게 좋다. 그렇지 않고 윈도우 객체를 직접 참조하게되면, 열린 페이지 또한 열려있는 페이지 모두 bfcache를 누리지 못하게 된다.

### 사용자가 다른 페이지로 가기전에 모든 connection을 close해라.

위에서 언급했던 것처럼, bfcache에 들어가기전에 모든 예약된 자바스크립트 태스크는 중단되고, cache에서 나올때 다시 시작된다. 만약 스케쥴된 자바스크립트 태스크가 단순히 DOM Api에 접근하거나, 현재 페이지와 별개로 작동하는 API라고 한다면, 페이지를 일시정지해서 bfcache로 들어가는 것이 크게 문제가 되지 않는다.

만약 IndexedDB, Web Locks, WebSockets과 같이 다른 페이지에서도 접근하라 수 있는 데이터와 관련된 API 라고한다면, 다른 탭의 실행에도 영향을 미칠 수 있기 때문에 문제가 될 수 있다. 따라서 다음 시나리오 상에서는 대부분의 브라우저가 bfcache를 시도하지 않는다.

- 페이지에 끝나지 않은 indexedDB transaction이 있는 경우
- fetch나 XMLHttpRequest가 진행 중인 경우
- WebSocket, WebRTC 연결이 살아 있는 경우

만약 페이지에서 위의 경우에 해당한다면, `pagehide`나 `freeze`이벤트에서 이러한 연결을 모두 끊어 버리는 것이 좋다. 이는 다른 탭에 영향을 주는 위험이 없이 안전하게 cache를 하는 방법이다.

그리고, bfcache로 부터 페이지가 살아난다면, 이러한 API를 다시 열어두면 된다. `pageshow` `resume` 이벤트에서 다시 연결해두면 된다.

> 유저가 페이지르 떠나기전에 해당 API가 사용 중이지 않다면 bfcache는 사용가능하다. 그러나 Embedded Plugins, Workers, Broadcast Channel 등 [일부 API](https://source.chromium.org/chromium/chromium/src/+/master:content/browser/frame_host/back_forward_cache_impl.cc;l=124;drc=e790fb2272990696f1d16a465832692f25506925?originalUrl=https:%2F%2Fcs.chromium.org%2F)들은 사용하게 되면 bfcache가 불가능하게 된다. 크롬이 bfcache 초기 출시 당시 의도적으로 보수적으로 접근하고 있지만, 장기적인 목표로는 최대한 많은 API에서 동작하게 끔 하려고 한다.

### 페이지가 캐싱 가능한지 테스트

page가 unloading시에 캐싱이 되는지 안되는지 확실히 결정할수는 없지만, 뒤로가기나 앞으로가기시에 bfcache가 올바르게 되고 있는지는 확인이 가능하다. 크롬의 경우 bfcache가 최대 3분까지 남아 있으므로, Puppetter나 Webdriver와 같은 테스트 도구로 `pageShow`이벤트의 `persisted`의 속성이 true로 남아있는지 확인하기에 충분하다.

물론 일반적인 상황에서는 캐시가 가능한 길게 남아있지만, 시스템의 메모리가 부족한 아쉬운 상황에서는 언제든 캐시가 날아갈 수 있다. 실패 테스트가 반드시 캐시가 안된다고는 단언할 수 없으므로, 실패의 기준과 테스트 설정을 유심히 해야할 필요가 있다.

> 크롬의 bfcache는 모바일에서만 가능하므로, 데스크톱에서 사용하기 위해서는 [#back-forward-cache 설정을 켜야 한다.](https://www.chromium.org/developers/how-tos/run-chromium-with-flags)

### bfcache를 제거하는 법

최상단 페이지 응답에 아래와 같이 설정해두면 bfcache를 제거할 수 있다.

```
Cache-Control: no-store
```

`no-cache`와 `no-store`등은 bfcache에 영향을 미치지 않는다.

이는 bfcache를 무력화시키는 확실한 방법이지만, [성능과 캐싱을 위해서 각자가 원하는 방법을 적용할 수 있도록 하자는 제안도 존재한다.](https://github.com/whatwg/html/issues/5744) (예를 들어 로그아웃과 같이 명시적인 시점에 bfcache 날린다던지)

## bfcache 가 분석 및 성능 측정에 미치는 영향

만약 분석 도구를 활용하여 사이트의 방문을 추적해본적이 있다면, 크롬이 bfcache를 사용함에 따라서 전체 페이지뷰가 감소한다는 것을 인지했을 수도 있다. 실제로 bfcache를 구현한 브라우저는 다른 브라우저에 비해 페이지뷰를 과소보고 하는 경우가 있는데, 이는 대부분의 트래킹 라이브러리들이 bfcache의 복원을 새로운 페이지뷰로 간주하지 않기 때문이다.

이를 방지하기 위해서는 아래와 같은 코드 추가를 고려해볼 수도 있다.

```javascript
// Send a pageview when the page is first loaded.
gtag('event', 'page_view')

window.addEventListener('pageshow', function (event) {
  if (event.persisted === true) {
    // Send another pageview if the page is restored from bfcache.
    gtag('event', 'page_view')
  }
})
```

### 성능 측정

bfcache는 특히 실제 수집된 성능 지표, 그 중에서도 페이지 로드 시간을 측정하는 지표에 부정적인 영향을 미칠 수 있다. bfcache 네비게이션은 실제 새로운 페이지를 로딩하는게 아니고 기존 페이지를 단순히 복원하는 것이기 때문에, bfcache를 사용하게 되면 수집된 페이지 로드의 총 숫자가 감소한다. 중요한 것은 bfcache로 복원으로 대체되는 페이지 로드가 페이지 속도 측정 중에서 가장 빠른 페이지로드로 인식될 수 있다는 것이다. 그 결과 데이터 집합에서 빠른 페이지 로드가 줄어들어, 사용자가 경험하는 실제 성능이 향상되었음에도 불구하고 그래프 상으로는 속도가 일정하지 않은 것 처럼 보일 수도 있다.

이 문제를 해결하는 데 몇가지 방법이 있는데 그 중 하나는, 모든 페이지 로드 메트릭에 `navigate` `reload` `back_forward` `prerender`와 같은 주석을 달아두는 것이다. 이러한 접근 방식은 TTFB(Time to First Byte)와 같은 사용자 중심 페이지 로드 메트릭에 권장된다. Core Web Vitals와 같은 사용자 중심 메트릭의 경우, 사용자가 경험하는 것을 정확하게 나타내는 값을 보고하는 것이 더 좋다.

### Core Web Vital에 미치는 영향

[Core Web Vital](https://web.dev/vitals/)이란 로딩 속도, 상호작용성, 시각적 안정성 등 다양한 면에 결쳐 웹페이지의 사용자 경험을 측정한다. bfcache 복원으로 사용자는 기존 페이지로드보다 더 빠르게 탐색하게 되므로, Core Web Vital에 이를 반영하는 것이 중요하다. 당연하게도, 사용자는 무슨 기법을 썼든지 간에 아무튼 속도가 빠른 것에만 신경을 쓰기 때문에.

곧 [Chrome User Experience Report](https://developers.google.com/web/tools/chrome-user-experience-report)와 같은 도구에서 bfcache 복원을 별도의 페이지 방문으로 처리하도록 업데이트 될 예정이다.

bfcache 복원에 따른 성능을 측정하기 위한 web performance api는 아직 존재하지 않지만, 기존 API로 대략 유추 해볼 수는 있다.

- [Largest Contentful Paint(LCP)](https://web.dev/lcp/): `pageshow` 이벤트의 타임스템프와 다음 프레임이 페인트 되는 시점의 타임스탬프를 비교하여 사용할 수 있다. (bfcache의 경우 LCP와 FCP의 값은 같다.)
- [First Input Delay(FID)](https://web.dev/fid/): `pageshow`이벤트에 이벤트 리스너를 다시 달아서 bfcache 복원 후 FID의 지연을 보고 할 수 있다.
- [Cumulative Layout Shift(CLS)](https://web.dev/fid/): 기존 performance observer를 계속 사용할 수 있으며, 현재 CLS 값을 0으로 재설정하면 된다.

## 더 읽어보기

- [Firefox Caching](https://developer.mozilla.org/en-US/Firefox/Releases/1.5/Using_Firefox_1.5_caching)
- [Page Cache](https://webkit.org/blog/427/webkit-page-cache-i-the-basics/)
- [브라우저에 따른 bfcache](https://docs.google.com/document/d/1JtDCN9A_1UBlDuwkjn1HWxdhQ1H2un9K4kyPLgBqJUc/edit?usp=sharing)
- [bfcache 테스터](https://back-forward-cache-tester.glitch.me/?persistent_logs=1)

출처: https://web.dev/bfcache/#optimize-your-pages-for-bfcache


항상 브라우저에 감사하십시오 frontend developers.

뒤로가기, 앞으로가기의 캐시 aka bfcache

PWA가 나타난 이후로, [이제 모든 웹 프로젝트는 PWA로 이루어져야 한다](https://alistapart.com/article/yes-that-web-project-should-be-a-pwa/), 라든지 PWA가 웹 프로젝트의 미래라든지, 이제 모든 애플리케이션이 PWA로 만들어질 것이라든지, 더이상 일렉트론은 사라질 것이라든지의 많은 글을 봐왔다. 귀에 딱지가 앉도록 많이 들었기 때문에, 한번 해보고 싶은 마음이 들었다. 어차피 막나가는 토이 프로젝트 블로그에 PWA 하나 추가된다고 별일 없을 것이다, 라는 생각으로 블로그에 PWA를 적용해 보았다.

## HOW TO

정석대로 하는 방법은 https://web.dev/progressive-web-apps/ 여기를 참고 하는게 좋다. 원래 번역까지 해보려고 했는데, 굳이 그렇게 까지 안해도 될 것 같아서 읽고 공부해보기만 했다.

### next-pwa

고맙게도 nextjs 환경에서 pwa를 적용해줄 수 있는 라이브러리가 존재한다. 바로 [next-pwa](https://github.com/shadowwalker/next-pwa)이다. 별다른 설정을 해주지 않아도 next를 pwa환경으로 바꾸어 주었다. 그외에 설정에 맞게 `manifest.json` 추가, `<meta/>` 를 추가했다.

### pwa-asset-generator

pwa를 ios나 안드로이드에서 제대로 보여주기 위해서는 아이콘과 splash이미지를 잘 준비해야 한다. 특히 ios의 splash 이미지는 [apple launch screen 가이드에 따라서 모든 사이즈에 대응할 수 있는 이미지](https://developer.apple.com/design/human-interface-guidelines/ios/visual-design/adaptivity-and-layout/#device-screen-sizes-and-orientations)가 준비되어 있어야 해서 조금 귀찮다. 그런 작업들을 모두 [pwa-asset-generator](https://github.com/onderceylan/pwa-asset-generator)가 도와주었다. 아이콘과 스플래시 이미지, 그리고 그에 따른 태그를 알아서 만들어준다. 감사합니다

## 결과

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

lighthouse 검사결과에서 PWA로 잘 인식되는 것을 볼 수 있다. `start_url`이 응답을 안한다고 하는 것은 [light house의 버그로 보인다.](https://github.com/shadowwalker/next-pwa/issues/107)

![pwa-offline](./images/pwa-offline.png)

네트워크가 오프라인으로 되어 있어도 서비스 워커를 통해서 서비스가 잘 작동하는 것을 볼 수 있다.

![pwa2-1](./images/pwa2-1.png)

![pwa2-2](./images/pwa2-2.png)

![pwa2-3](./images/pwa2-3.png)

pwa로 등록되면 크롬 주소창에 앱으로 등록할 수 있다는 뜻의 작은 아이콘이 뜬다. 이를 등록해두면 애플리케이션처럼 사용가능해진다.

![pwa-splash](./images/pwa-splash.png)

안드로이드가 없어서 테스트 해보지는 못했지만, ios에서는 splash이미지가 잘나오고 있었다.

![pw3-1](./images/pwa3-1.png)

![pw3-2](./images/pwa3-2.png)

ios에서 이렇게 실제 앱과 비슷하게 사용할 수 있었다.

## 단점

장점은 여기저기에 나열되어 있으니, 단점과 개인적인 소회를 적어보려고 한다.

### 네이티브 인터페이스를 사용할 수 없다는 한계

네이티브 인터페이스가 없기 때문에 당연히 일반 모바일 애플리케이션 대비 할 수 있는 액션이 제한되어 있다. iOS의 경우 푸쉬 알림이 불가능하며, 사용자가 PWA를 앱 아이콘으로 등록하지 않으면, 7일이 넘는 캐시데이터를 자동으로 삭제한다.

### (모바일 애플리케이션을 대체할 수 있다는 관점에 한해서) 높은 진입 장벽

PWA를 정말 일반 애플리케이션 처럼 쓰려면 모바일 기준으로, 일반사용자가 한다고 했을 때 아래와 같은 과정을 거쳐야 한다.

- PWA로 되어 있는 해당 사이트 방문 (사파리만 가능)
- 화면 중앙 하단의 공유 버튼 클릭
- 스크롤을 조금 더 내려서 홈 화면에 추가

일반적인 사용자가 절대로 경험해본적이 없을 UX이며, 설령 이 과정을 toast 든 팝업이든 알려준다 치더라도 실제로 이를 실행에 옮길 사용자가 몇이나 될까 싶다.

대부분의 사용자들은 애플리케이션 설치를 곧 앱스토어에 접속한다는 행위로 인식하고 있기 때문에, 앱스토어에 PWA를 등록하게 해주지 않는 이상 - 이러한 장점은 거의 없다고 봐야할 것이다.

## PWA의 의미

https://medium.com/iquii/progressive-web-app-pwa-what-they-are-pros-and-cons-and-the-main-examples-on-the-market-318f4538c670 의 글을 빌리자면, PWA의 장점은 아래와 같다(고한다.)

- Progressive
- Responsive
- AppLike
- Updated
- Secure
- Searchable
- Reactivable
- Installable
- Linkable
- Offline

이에 대해 의견을 달아보면

- ~~Progressive~~: 브라우저에 관계없이 사용할 수 있다는 것은, 그냥 웹의 장점이다. 모바일 웹 어플리케이션을 만들어도 가능하다.
- ~~Responsive~~: 반응형은 모든 웹사이트에서 구현 가능한 것이다.
- ~~AppLike~~: 위에서 언급한 이유 때문에, 앱과 비슷한 경험을 준다는 것은 사용자에게 장점으로 어필하기 쉽지 않다. 어차피 모바일 웹 어플리케이션으로 만드나, 네이티브 애플리케이션으로 만드나 일반사용자들은 차이를 느끼기가 어려울 것이다.
- ~~Updated~~: 서비스워커로든, http fetch로든 언제든 데이터를 제공할 수 있다. 앱과 다르게 배포가 필요하지 않다는 장점도 있지만 이는 비단 PWA만의 장점은 아니다.
- ~~Secure~~: https를 반드시 이용해야 PWA를 사용가능하지만, secure는 장점이 아니고 필수다.
- ~~Searchable~~: 웹 도 충분히 검색엔진에서 검색될 수 있다.
- Reactivable
- ~~Installable~~: AppLike와 같음
- ~~Linkable~~: 웹 사이트도 링크를 제공할 수 있다.
- Offline: 확실히 오프라인상태에서도 사용자 경험을 제공할 수 도 있다는 것은 장점이긴 했다. 그러나 이는 크게 장점으로 어필하긴 어려울 것 같다. 이미 대부분의 사용자들은 거의 99% 온라인 상태로 휴대기기를 유지하고 있을 것이고, `오프라인 = 앱이 동작하지 않는 상태`로 이미 이해하고 있다. 오프라인 상태로도 정적인 컨텐츠를 제공하고 이게 유의미한 서비스라면 모를까?

그외에 장점으로는 개발하기 굉장히 쉬웠다는 것이 있다. 앱스토어 권한 획득하고, 무거운 에뮬레이터 띄워가면서 난리 치지 않더라도 쉽게 만들 수 있었다. https로 서비스 할 수 있는 PWA를 만드는 것은, 여러가지 면에서 실제 모바일 네이티브 애플리케이션을 만드는것보다 쉬웠다.

사용자 입장에서, PWA의 장점은 앱과 비슷한 경험을 웹으로도 줄 수 있다는 정도로 볼 수 있을 것 같다. 물론 그 비슷한 경험에도 명확하게 한계가 있기 때문에 100% 호환이 된다고 하긴 어렵지만, iOS와 안드로이드에서 PWA를 얼마나 밀어주느냐에 따라서 미래가 달려있다고 볼 수 있을 것 같다. 물론 이 또한 긍정적이지는 않다. 인앱결제도 못하는 PWA를 자사 앱스토어 시장을 그대로 둔채로 밀어줄 것 같지는 않다. 하다못해 푸쉬라도 제대로 되면 좋을텐데, 애플느님이 해주실 것 같진 않다.

그렇기 때문에 여전히, 모바일 서비스의 대부분은 지금처럼 앱/플레이 스토어가 중심이 될 것이다. 그렇다고 웹이 들어갈 자리가 없는 것은 아니다. 언제든 업데이트가 가능하다는점, 브라우저 스펙을 잘 따르면 거의 비슷한 사용자 경험을 줄 수 있다는 장점 때문에 앱처럼 보이는 웹, 그러니까 하이브리드 앱이 지금처럼 계속 대세를 이룰 것 같다. (그에 대한 방증으로 대부분의 회사에서 프론트 엔드 인력을 필요로 하고 있다.) 멀티플랫폼 지원, iOS, 안드로이드 의 공통 리소스 확보, 상시 업데이트를 위해 대다수의 사이즈가 큰 애플리케이션들은 이미 하이브리드 앱으로 구동되고 있다. 데스크톱 앱의 경우, 일렉트론이 여전히 유의미한 대안으로 존재하고 있다.

## 요약

- PWA로 일반 모바일 애플리케이션과 비슷한 경험을 제공할 수 있다
- 그러나 그 경험을 일반 사용자가 느끼기엔 ...........
- PWA로 느낄 수 있는 향상된 경험은 일반 웹에서도 충분히 고민해볼만한 것들이다 (secure, responsive, progressive...)
- 하이브리드 앱/일렉트론은 계속해서 유의미한 선택지로 남아있을 것 같다.


노력은 나만 하고 즐기는것도 나만 즐긴다

yceffort

왜 moment 는 deprecated 되었을까

자바스크립트의 가비지 컬렉션

V8 엔진에 대해 가볍게 살펴보기

뒤로가기, 앞으로가기의 캐시 aka bfcache

PWA 적용 후기 및 장단점