뒤로가기/앞으로가기 캐시 (이해 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...)
- 하이브리드 앱/일렉트론은 계속해서 유의미한 선택지로 남아있을 것 같다.


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

PWA 적용 후기 및 장단점

인터넷 연결은 시시때때로 끊길 수 있고 불안정하므로, PWA에서는 오프라인 환경과 신뢰할 수 있는 성능을 안정적으로 제공하는 것이 필수다. 또한 완벽히 온라인 환경이 제공된다 하더라도, 캐싱과 다른 스토리지 기술을 적절히 활용한다면 사용자의 경험을 향상 시킬 수 있다. 정적 애플리케이션 리소스(HTML, Javascript, CSS)와 데이터 (사용자 데이터, 뉴스 기사 등)를 캐싱하는 방법이 꽤 있다. 어떤 것이 가장 좋은 해결책이며, 이들은 얼마나 저장할 수 있을까?

## 무엇을 사용해야 하는가?

- 네트워크 리소스나 파일 기반의 콘텐츠가 필수적일 때는, [Cache Storage API](https://developer.mozilla.org/en-US/docs/Web/API/CacheStorage)를 사용하는 것이 좋다.
- 다른 데이터의 경우에는, [IndexedDB](https://developer.mozilla.org/ko/docs/Web/API/IndexedDB_API) 를 사용하는 것이 좋다.

이 두 방식은 모두 모던 브라우저에서 지원한다 (IE 제외). 그리고 둘다 비동기로 이루어지며 메인스레드를 블로킹하지 않는다. 또한 `window`, 웹 워커, 서비스 워커에서 접근 가능 하기 때문에 어디서든 사용하기 쉽다.

## 다른 스토리지는?

물론 이 외에도 브라우저에서 사용할 수 있는 다른 스토리지가 존재한다. 그러나 이들은 사용에 제한이 있으며, 성능적인 문제 또한 존재한다.

- [SessionStorage](https://developer.mozilla.org/ko/docs/Web/API/Window/sessionStorage): 데이터가 탭과 연결되어 있기 때문에, 탭의 라이프타임과 함께 한다. 따라서 세션과 관련된 작은 양의 데이터를 저장하는데 유용하다. (IndexedDB의 키 등) 또한 동기로 작동하며 메인스레드를 블로킹하기 때문에 사용에 주의가 필요하다. 5MB 까지의 데이터만 저장가능하며, 문자열만 가능하다. 또한 탭에 묶여 있기 때문에, 웹워커나 서비스워커에서는 사용이 불가능하다.
- [LocalStorage](https://developer.mozilla.org/ko/docs/Web/API/Window/localStorage): 마찬가지로 메인스레드를 블로킹하고 동기로 작동한다. 마찬가지로 5MB까지 가능하며, 문자열 데이터만 저장가능하다. 웹 워커와 서비스워커에서는 사용이 불가능하다.
- [Cookies](https://developer.mozilla.org/en-US/docs/Web/HTTP/Cookies): 쿠키는 쿠키 나름대로의 사용처가 있기 때문에, 데이터 저장용도로 사용해서는 안된다. 쿠키는 모든 HTTP 요청에 함께 보내지기 때문에, 큰 데이터를 저장했다가는 모든 HTTP 요청에 함께 날라가게 되므로 신 사이즈가 커지게 된다. 또한 이들은 동기로 작동하며, 웹워커에서는 접근이 불가능하다. 위 두개와 마찬가지로, 문자열 데이터만 저장 가능하다.
- [File System API](https://developer.mozilla.org/en-US/docs/Web/API/File_and_Directory_Entries_API/Introduction): 샌드박스 (제한된 영역의) 파일시스템에 파일을 읽고 쓸 수 있도록 도와준다. 비동기로 작동되는 반면 [크로미윰에서만 지원되기 때문에](https://caniuse.com/filesystem) 널리 사용하기는 어렵다.
- [File System Access API](https://web.dev/file-system-access/): 사용자가 로컬 파일 시스템에 파일을 읽고 쓰기 쉽게 만들어주는 API다. 따라서 사용자에게 권한을 획득하는 것이 필수 이며, 또한 이 권한은 세션을 넘어가면 유지 되지 않는다.
- WEB SQL: IndexedDB의 등장과 함께 사라진 기능으로, 사용해서는 안된다.
- [Application Cache](https://developer.mozilla.org/ko/docs/Web/HTML/Using_the_application_cache): 이 또한 deprecated 되었다. 브라우저에서 지원이 중단될 예정이며, 서비스워커와 Cache API로 대체 해야 한다.

## 얼마나 저장할 수 있는가?

몇 백 메가바이트, 그리고 잠재적으로 수백 기가바이트 이상이 될 수도 있다. 브라우저 별로 다를 수 있지만, 사용가능한 스토리지의 크기는 대개 장치에서 사용 가능한 스토리지의 크기에 따라서 결정된다.

- 크롬에서는 원래 전체 디스크 공간의 60%까지 허용해주었지만, 이제는 80% 까지 가능하다. StorageManger API를 이용해서 사용가능한 스토리지의 크기를 점검할 수 있다. 다른 크로미윰 기반 브라우저의 경우 더 많은 스토리지를 사용할 수도 있다. [여기](https://github.com/GoogleChrome/web.dev/pull/3896)를 참고
- IE 10 이상의 브라우저에서는 250mb까지 가능하며, 10mb이상의 스토리지를 사용할 경우 사용자에게 메시지를 띄운다.
- 파이어폭스는 여유 디스크공간의 50%까지 사용하게 해준다. `eTLD+1` (effective Top Level Domain) 의 경우에는 최대 2GB까지 가능하다. StorageManager API를 통해서 얼마나 사용가능한지 확인할 수 있다.
- 사파리는 1gb까지 지원하는 것으로 보인다. 최대 스토리지에 도달하면, 사용자에게 메시지를 띄우고 200mb 를 추가로 사용할 수 있게 해준다. (이에 대한 정확한 공식문서는 찾지 못했으므로, 약간의 차이가 있을수 있다.)

과거 스토리지 용량 최대치에 근접하게 되면, 브라우저는 사용자에게 메시지를 띄워서 권한을 획득한 후, 추가로 스토리지용량을 제공했다. 그러나 요즘 모든 브라우저는 사용자에게 특별히 메시지를 띄우지 않고 최대 사용량 까지 사용하게 해준다. 사파리의 경우는 조금 다르다. 앞서 이야기 한것처럼 추가 할당량 사용여부를 유저에게 묻고 허락할 경우 사용하게 해주지만, 그 이상은 불가능 한 것으로 보인다.

## 사용가능한 스토리지 용량 확인하는 방법

[Storage Manager API](https://caniuse.com/mdn-api_storagemanager)를 통애서 확인 가능하다.

```javascript
if (navigator.storage && navigator.storage.estimate) {
  const quota = await navigator.storage.estimate()
  const percentageUsed = (quota.usage / quota.quota) * 100
  const remaining = quota.quota - quota.usage

  console.table(quota)
}
```

| index        | value        | caches    | indexedDB | serviceWorkerRegistrations |
| ------------ | ------------ | --------- | --------- | -------------------------- |
| quota        | 299977904946 |           |           |                            |
| usage        | 621244075    |           |           |                            |
| usageDetails |              | 620952837 | 256156    | 35082                      |

Storage Manager API가 모든 브라우저에서 사용가능한 것은 아니므로, feature detect를 꼭 걸어줘야 한다. 또한 quota를 넘는 경우 에러가 발생할 수도 있으므로, `try.. catch`로 이를 잡아 주는 처리를 해야 한다.

[예제 사이트 확인해보기](https://storage-quota.glitch.me/)

## 사용량 초과시 대처

중요한 점은 코드를 작성할 시에 `QuotaExceededError`와 같은 에러에 대해 염두해 두어야 한다는 것이다. IndexedDB 와 Cache API 모두 사용량 초과시에 `DOMError`나 `QuotaExceededError`를 던진다.

### IndexedDB

데이터 사용량을 초과한다면, `IndexedDB`에 쓰려는 시도는 모두 실패한다. 트랜색션의 `onabort()`가 호출된다. 여기에는 `DOMException`이 포함된다. 에러의 `name`을 확인하면 `QuotaExceededError`가 보일 것이다.

```javascript
const transaction = idb.transaction(['entries'], 'readwrite')
transaction.onabort = function (event) {
  const error = event.target.error // DOMException
  if (error.name == 'QuotaExceededError') {
    // Fallback code goes here
  }
}
```

### Cache API

```javascript
try {
  const cache = await caches.open('my-cache')
  await cache.add(new Request('/sample1.jpg'))
} catch (err) {
  if (error.name === 'QuotaExceededError') {
    // Fallback code goes here
  }
}
```

## Eviction

> 최대 용량 초과로 인해 데이터가 지워지는 것을 의미한다.

웹 스토리지는 `Best Effort`와 `Persistent` 두개의 버켓으로 구분할 수 있다. `Best Effort`란 스토리지가 사용자를 방해하지 않고 브라우저에 의해 정리될 수 있다는 것을 의미하는데, 이는 중요한 데이터에 적합하지 않다는 것을 의미한다. `Persistent` 스토리지는 저장가용량이 낮더라도 자동으로 삭제 되지는 않는다. 사용자가 수동으로 데이터를 삭제 해야 한다.

기본적으로, 사이트의 데이터는 `Best Effort`로 분류되어 사이트가 별도로 [persistent storage를 요청](https://web.dev/persistent-storage/)하지 않는다면, 가용량이 낮아지게 되면 자동으로 데이터를 삭제하게 된다.

`best effort`내에서 eviction 정책은 아래와 같다.

- 크로미윰 기반 브라우저는 브라우저의 저장공간이 부족할 때 데이터를 제거하며, 브라우저의 저장공간이 초과되지 않을 때 까지 가장 오래된 데이터부터 삭제하기 시작한다.
- IE 10이상에서는 데이터를 제거되지는 않지만, 더이상 데이터를 쓰는 것이 불가능해진다.
- 파이어 폭스는 크로미윰과 마찬가지로 저장공간이 초과되지 않을 때까지 오래된 데이터부터 삭제한다.
- 사파리의 경우 이전 버전에서는 데이터를 제거하지 않았는데, 최근에는 스토리지에 대해 7일짜리 제한을 두기 시작했다.

> iOS, iPadOS 13.4, 맥의 safari 13.1 부터, Cache API, indexed DB, storage 등의 쓰기 스토리지에 대해서 7일간의 제한을 걸어두기 시작했다. 이는 사용자가 사이트에서 인터랙션을 하지 않을 경우, 사파리가 7일 이후에는 캐시에서 모든 데이터를 제거한다는 것을 의미한다. 이 정책은 홈스크린에 설치된 PWA에는 적용되지 않는다. 자세한 내용은 [여기](https://webkit.org/blog/10218/full-third-party-cookie-blocking-and-more/)를 참조!

## 왜 indexedDB 래퍼를 사용해야 할까?

IndexedDB는 저수준 API로, 아주 작은 양의 데이터를 저장하는데 사용한다 할지라도 처음 설치에 있어 많은 심혈을 기울여야 한다. 다른 모든 promise 기반 API와는 다르게, 이벤트 베이스로 작동된다. [idb](https://github.com/jakearchibald/idb)를 사용하면 일부 강력한 기능을 사용할수 없지만 트랜잭션과 스키바 버전과 같은 복잡한 기능을 사용하지 않더라도 promise 기반의 indexeddb를 사용할 수 있게 해준다.

출처: https://web.dev/storage-for-the-web/


PWA에서 가장 적절한 것은 무엇일까

웹에서 사용 가능한 스토리지 살펴보기

## Server Side Events

일반적이고 전통적인 웹페이지의 경우, 새로운 데이터를 받기 위해서는 서버에 데이터 요청을 해야만 한다. 이른바 폴링이라는 기술로, 웹페이지가 서버에 요청을 해야만, 서버가 그 요청에 따른 데이터를 적절하게 리턴해주는 방식이라고 볼 수 있다. 하지만 Server Side Events, 이하 (SSE)를 활용하면, 웹페이지가 별도로 요청하지 않아도 서버가 데이터를 보내는 것이 가능하다. 즉, 서버에서 클라이언트로 업데이트 되는 내용을 스트리밍을 하는 것이 가능해진다. SSE를 활용하면, 서버와 클라이언트 사이에 단방향 채널을 여는 것과 같은 이점을 얻르 수 있다.

## vs Web Socket?

그렇다면 우리가 일반적으로 알고 있는 web socket 과의 차이는 무엇일까? 웹 소켓은 양반향 통신을 위한 프로토콜은 제공하지만 (채팅과 같은), 일부 시나리오에서는 그러한 양방향 통신이 필요하지 않을 때가 있다. 클라이언트에서 굳이 데이터를 전송하지 않고, 서버의 데이터만 클라이언트에 보내서 업데이트를 해야하는 경우가 있다. (긴 시간이 걸리는 요청에 대해서 요청을 일부분씩 나눠서 보내는 등) 이러한 경우에는 Web Socket보다는 SSE가 훨씬 더 좋은 대안이 될 수 있다. 또한 웹 소켓과는 다르게, 전통적인 HTTP로도 전송이 가능하다. 즉, 특별한 프로토콜이나 서버구현이 필요하지 않다.

## How to use

### Support

대다수의 모던 브라우저가 지원하는 반면, 아쉽게도 역시나 우리의 IE는 SSE를 지원하지 않는다.

https://caniuse.com/eventsource

폴리필을 사용하면 될 것 같다. (써보진 않았지만) https://github.com/Yaffle/EventSource

### Javascript API

이벤트 스트림을 구독하기 위해서는, EventSource를 만들고 URL을 넘겨야 한다.

```javascript
if (!!window.EventSource) {
  var source = new EventSource('stream.php')
} else {
  // SSE를 사용할 수 없는 환경
}
```

만약 URL이 절대 주소로 되어 있다면, 호출 페이지와 scheme, domain, port 등이 일치해야 한다.

이제 소스에 이벤트 핸들러를 달아서 실제로 구독을 해보자.

```javascript
source.addEventListener(
  'message',
  function (e) {
    console.log(e.data)
  },
  false,
)

source.addEventListener(
  'open',
  function (e) {
    // 연결성공
  },
  false,
)

source.addEventListener(
  'error',
  function (e) {
    if (source.readyState == EventSource.CLOSED) {
      // 연결이 닫히는 경우
    }
  },
  false,
)
```

서버에서 데이터를 푸쉬하면, `message`가 실행되고, `e.data`에서 데이터를 가져올 수 있다.

소스의 이벤트 스트림은 SSE 형식인 `Content-type` `text/event-stream`을 사용하여 텍스트 응답을 작성해야 한다. 기본적인 응답형식은 아래와 같다.

```bash
data: response \n\n
```

`data:`행 다음에 메시지가 오고, 스트림 맨 마지막에는 `\n` 문자가 두개 있다면 스트림이 끝난 것으로 간주한다.

메시지가 길어서 여러줄을 보내야 한다면, `data:`행을 사용하여 메시지를 분할하면 된다.

```bash
data: first response\n
data: second response\n\n
```

`\n`으로 하나만 줄바꿈이 되어 있다면, `message`이벤트는 하나만 발생한다.

JSON 데이터를 보내야 한다면 어떻게 할까?

```bash
data: {\n
data: "msg": "hello world",\n
data: "id": 12345\n
data: }\n\n
```

```javascript
source.addEventListener(
  'message',
  function (e) {
    var data = JSON.parse(e.data)
    console.log(data.id, data.msg)
  },
  false,
)
```

물론 json 데이터를 압축해서 한줄로 보내도 가능할 것이다.

이벤트에 ID를 달아서 고유한 ID도 함께 보낼 수 있다.

```bash
id: 123\n
data: hello\n
data: world\n
```

ID를 설정하게 되면, 브라우저는 마지막에 발생한 이벤트를 추적할 수 있게 된다. 이는 만약 연결이 끊겼을 때, `Last-Event-ID`라고 불리는 특별한 HTTP 헤더가 새 요청으로 설정된다. 이는 브라우저가 어떤 이벤트를 발생하기에 적합한지 판단할 수 있게 해준다. 이 메시지 이벤트네는 `e.lastEventId` 속성이 포함되어 있다.

브라우저는 각 연결이 종료 된 후에 3초후에 다시 연결을 시도하려고 한다. 여기에 `retry:`를 시간과 함께 설정하여, 이 시간제한을 변경할 수 있다.

```bash
retry: 10000\n
data: hello world\n\n
```

이렇게 하게 되면 10초 후에 다시 연결을 시도하게 된다.

하나의 이벤트 소스에 이벤트 이름을 넣어두면, 여러가지 이벤트를 생성할 수 있다. `event:`로 시작하는 행에 이벤트 명을 명시하는 경우, 그 이벤트를 해당 이름에 바인딩 시킬 수 있다. 클라이언트에서는 이벤트 리스너를 설정하여 해당 이벤트를 구독할 수 있다.

```bash
data: {"msg": "First message"}\n\n
event: userlogon\n
data: {"username": "John123"}\n\n
event: update\n
data: {"username": "John123", "emotion": "happy"}\n\n
```

```javascript
source.addEventListener(
  'message',
  function (e) {
    var data = JSON.parse(e.data)
    console.log(data.msg)
  },
  false,
)

source.addEventListener(
  'userlogon',
  function (e) {
    var data = JSON.parse(e.data)
    console.log('User login:' + data.username)
  },
  false,
)

source.addEventListener(
  'update',
  function (e) {
    var data = JSON.parse(e.data)
    console.log(data.username + ' is now ' + data.emotion)
  },
  false,
)
```

## 예제

```javascript
const koa = require('koa')
const Router = require('koa-router')

const router = new Router()

router.get('/event', async (ctx) => {
  ctx.res.writeHead(200, {
    'Content-Type': 'text/event-stream',
    'Cache-Control': 'no-store',
    'Access-Control-Allow-Origin': '*',
  })

  const lastEventId =
    Number(ctx.request.headers['last-event-id']) || Number(ctx.query.id) || 100
  let timeoutId = 0
  let i = lastEventId
  let c = i + 100

  let f = function () {
    if (++i < c) {
      ctx.res.write(`id: ${i} \n`)
      ctx.res.write(`data: ${i} \n\n`)
      timeoutId = setTimeout(f, 1000)
    } else {
      ctx.res.end()
    }
  }

  f()

  ctx.res.on('close', function () {
    clearTimeout(timeoutId)
  })
})

router.get('/', async (ctx) => {
  ctx.res.write(`<!DOCTYPE html>
  <html>
  <head>
      <meta charset="utf-8" />
      <title>EventSource example</title>
      <meta http-equiv="X-UA-Compatible" content="IE=edge">
      <script>
        var es = new EventSource("/event?id=50");        
        
        es.addEventListener('message', function(e) {
          var div = document.createElement("div");     
          div.appendChild(document.createTextNode('>>' + e.data));
          document.body.appendChild(div);
        }, false);
        
        es.addEventListener('open', function(e) {          
          var div = document.createElement("div");     
          div.appendChild(document.createTextNode("SSE connected!"));
          document.body.appendChild(div);
        }, false);
        
        es.addEventListener('error', function(e) {
          console.log('failed')
        }, false);
      </script>
  </head>
  <body>
  </body>
  </html>`)
})

async function main() {
  const app = new koa()

  app.use(router.routes()).use(router.allowedMethods())

  app.listen(3001)
}

try {
  main()
} catch (err) {
  console.error(err)
}
```

결과

```bash
SSE connected!
>>51
SSE connected!
>>52
SSE connected!
>>53
SSE connected!
>>54
SSE connected!
>>55
SSE connected!
>>56
SSE connected!
>>57
SSE connected!
>>58
SSE connected!
>>59
SSE connected!
>>60
SSE connected!
>>61
SSE connected!
>>62
SSE connected!
>>63
SSE connected!
>>64
SSE connected!
>>65
SSE connected!
>>66
SSE connected!
>>67
SSE connected!
>>68
SSE connected!
...
```


이거 꼭 한번 해보고 싶었는데 😭

서버 사이드 이벤트 (Server Side Events, SSE)

[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...

yceffort

web

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

PWA 적용 후기 및 장단점

웹에서 사용 가능한 스토리지 살펴보기

서버 사이드 이벤트 (Server Side Events, SSE)

자바스크립트의 비용