맥에서 웹을 개발하다보면 단점 아닌 단점이 하나 있는데, 바로 웹 화면이 다른 플랫폼에서 스크롤로 도배되어 있다는 것이다. 맥의 경우에는 커서가 플랫폼 화면에 올라오는 순간에 스크롤 막대가 올라온다.

![naver-mac](./images/naver-mac.png)

> 맥은 스크롤바가 보이지 않는다.

![naver-window](./images/naver-window.png)

> 그러나 윈도우는 기본적으로 스크롤바를 깔고 간다.

같은 사이트라 할지라도, 맥은 기본적으로 애플리케이션 영역에 커서가 올라오지 않는 이상 스크롤바를 보여주지 않는다. 이는 다음과 같은 속성 때문이다.

![mac](./images/mac-scroll-preference.png)

> 스크롤 막대보기: 마우스 또는 트랙패드에 따라 자동으로 설정이 기본값으로 되어 있다.

종종 이러한 특징 때문에 맥에 대한 비난 내지는 혼선이 빚어지는데, 사실 범인은 개발자다.

**결론부터 이야기 하자면 `overflow:scroll`는 항상 스크롤 막대를 표시한다.** 그러나 대부분의 개발자들은 맥의 기본동작 처럼, 필요한 경우에만 스크롤 바를 표시하고 싶을 것이다. 이를 위해서는 `overflow: auto`를 활용하여 브라우저 스스로가 스크롤 바가 필요한지 여부를 자동으로 결정하도록 해야 한다.

이러한 문제가 발생하고 있는 곳이 링크드인 이다.

![linkedin-window-scroll](./images/linkedin-window-scrollbar.png)

링크드인에서 포스트를 올릴 때, 스크롤이 필요하지 않은 상황임에도 윈도우에서 비활성화된 스크롤바가 보이는 것을 볼 수 있다. 사진까지 올리면 이제 스크롤바가 불필요하게 중첩까지 된다.

![linkedin-window-duplicated-scrollbar.png](./images/linkedin-window-duplicated-scrollbar.png)

문제는 `overflow-y: scroll`이다. 해당 옵션을 수정하면 컨텐츠가 넘쳐날 때만 스크롤 바가 뜬다.

![linkedin-post-window-scroll-auto](./images/linkedin-post-window-scroll-auto.png)

![linkedin-post-window-scroll](./images/linkedin-post-window-scroll.png)

> 스크롤바를 의도한 걸 수도 있다. 하지만 대부분은 버그입니다.

https://developer.mozilla.org/ko/docs/Web/CSS/overflow

> `scroll`:콘텐츠를 안쪽 여백 상자에 맞추기 위해 잘라냅니다. 브라우저는 콘텐츠를 실제로 잘라냈는지 여부를 따지지 않고 항상 스크롤바를 노출하므로 내용의 변화에 따라 스크롤바가 생기거나 사라지지 않습니다. 프린터는 여전히 넘친 콘텐츠를 출력할 수도 있습니다.

> `auto`: 사용자 에이전트가 결정합니다. 콘텐츠가 안쪽 여백 상자에 들어간다면 visible과 동일하게 보이나, 새로운 블록 서식 문맥을 생성합니다. 데스크톱 브라우저의 경우 콘텐츠가 넘칠 때 스크롤바를 노출합니다.

이와 별개로 가로 스크롤바가 생기는 문제가 간혹 있는데, 이는 `body`나 `html`에 `100vw`를 설정했을 때다. 이 또한 맥에서는 정상적으로 작동하지만, 다른 플랫폼에서는 그렇지 못하다.

![window-100vw](./images/window-100vw.png)

> 윈도우 크롬에서 `body`에 `100vw`를 적용

![mac-100vw](./images/mac-100vw.png)

> 맥 크롬에서 `body`에 `100vw`를 적용

그 이유는 아마도 다른플랫폼에서는 `100vw`에 스크롤바의 너비까지 포함하기 때문일 것이다. 이 경우 `100%`를 적용하면 해결이 된다.


맨날 맥만 봐서 이런 줄도 몰랐다 반성합니다

overflow: auto vs overflow: scroll 왜 윈도우에서만 쓸모없는 스크롤바가 노출될까

웹 사이트의 크기는 해가 갈 수록 커지고 있다. 3년 전과 비교 했을 때, 데스크톱 사이트는 20.5%, 모바일 웹 사이트의 경우에는 24.1%나 커졌다.

![total-kb](./images/website-total-kilobytes.png)

https://httparchive.org/reports/page-weight?start=2016_11_15&end=latest&view=list

다행히도(?) 단순히 사이즈만 커져가지는 않았다. 웹사이트 방문자들에게 가능한 최소한의 사이즈로 제공하기 위한 많은 노력들이 있다. 그중에 하나가 HTTP 압축이다.

## HTTP Compression

간단하게 얘기해서, 압축을 해서 웹서버에서 더 작은 파일을 서빙할 수 있도록 하는 기술이다. 사용자가 URL을 통해서 웹사이트에 접속을 하면, 브라우저는 웹서버가 압축을 해서 보낸 다는 것을 인지한다. 이러한 압축은 네트워크 요청을 빠르게 하여 가능한 로딩을 빠르게 도와준다. (압축을 푸는 것이 네트워크 요청보다 더 빠르므로)

### Gzip

이러한 압축 알고리즘으로 가장 널리 알려져 있는 것이 [gzip](https://ko.wikipedia.org/wiki/Gzip)이다. 최대 70%까지 사이즈를 줄여주는 가장 보편적인 압축 알고리즘이다. Gzip은 웹사이트 파일의 중복코드, 띄어쓰기의 양을 줄여서 동작하고, 9단계에 걸친 옵션을 제공하여 압축량과 압축에 걸리는 시간을 세세하게 조정할 수도 있다.

웹 사이트에서 Gzip을 제공하는 방법은 호스팅 공급자와 웹서버에 따라 달라진다.

아파치 서버의 경우, `.htacess`에 아래 코드를 추가하면 된다.

```bash
AddOutputFilterByType DEFLATE text/plain
AddOutputFilterByType DEFLATE text/html
AddOutputFilterByType DEFLATE text/xml
AddOutputFilterByType DEFLATE text/css
AddOutputFilterByType DEFLATE application/xml
AddOutputFilterByType DEFLATE application/xhtml+xml
AddOutputFilterByType DEFLATE application/rss+xml
AddOutputFilterByType DEFLATE application/javascript
AddOutputFilterByType DEFLATE application/x-javascript
```

nginx의 경우에는 다음과 같다.

```bash
gzip on;
gzip_comp_level 2;
gzip_http_version 1.0;
gzip_proxied any;
gzip_min_length 1100;
gzip_buffers 16 8k;
gzip_types text/plain text/html text/css application/x-javascript text/xml application/xml application/xml+rss text/javascript;
gzip_disable "MSIE [1-6].(?!.*SV1)";
gzip_vary on;
```

> 물론 이거 같다 붙힌다고 만사 해결이 되는 것은 아니다. 반드시 세세한 설정을 거쳐야 한다.

이렇듯 gzip은 설치가 용이하고, 압축도 잘되며, 압축에 걸리는 시간도 빠르기 때문에 널리 사용되고 있다.

## Brotli

- https://github.com/google/brotli
- https://en.wikipedia.org/wiki/Brotli
- https://aws.amazon.com/ko/about-aws/whats-new/2020/09/cloudfront-brotli-compression/

2013년, 구글은 웹 폰트 압축을 위해 Brotli라는 새로운 압축 알고리즘을 만들었으며, 2년 뒤인 2015년에는 HTTP 압축에 사용할 버전을 만들었다. 이는 앞서 언급한 GZip에 비해 많은 우위를 가지고 있었다.

![css file size](https://miro.medium.com/max/2000/1*j-3dAHj0pu5E1GmtD6eMuw.png)

![javascript file size](https://miro.medium.com/max/2000/1*i3xJiqPfF84H1h2Rt7na9w.png)

![overall](https://miro.medium.com/max/1400/1*_GVXtCwykvrPzclpIcpAsw.png)

[이 글](https://certsimple.com/blog/nginx-brotli)에 따르면 Brotli를 활용했을 경우 자바스크립트 파일의 경우 gzip에 비해 14%, HTML은 21%, css는 17% 더 작게 만들어 준다고 나와있다.

https://tools.keycdn.com/brotli-test 에서 brotli를 지원하는지 확인할 수 있다.

![yceffort blog](./images/yceffort-brotli.png)

> content-encoding이 br로 되어 있으면 brotli를 사용한다는 뜻이다.

### 적용하는 방법

**apache**

```bash
<VirtualHost *:443>
…
…
RewriteEngine On
RewriteCond %{HTTP:Accept-Encoding} br
RewriteCond %{DOCUMENT_ROOT}/%{REQUEST_FILENAME}.br -f
RewriteRule ^(.*)$ $1.br [L]
RewriteRule ".br$" "-" [NS,E=no-gzip:1,E=dont-vary:1]
<Files *.js.br>
  AddType "text/javascript" .br
  AddEncoding br .br
</Files>
<Files *.css.br>
  AddType "text/css" .br
  AddEncoding br .br
</Files>
<Files *.svg.br>
    AddType "image/svg+xml" .br
    AddEncoding br .br
</Files>
<Files *.html.br>
    AddType "text/html" .br
    AddEncoding br .br
</Files>
</VirtualHost>
```

[nginx-brotli](https://github.com/google/ngx_brotli)를 설치하여 제공할 수 있다.

**nginx**

```bash
http{
    brotli_static on;
    brotli_types text/plain text/css application/javascript application/x-javascript text/xml application/xml application/xml+rss text/javascript image/x-icon image/vnd.microsoft.icon image/bmp image/svg+xml;
}
```

자세한 내용은 https://www.tezify.com/how-to/use-brotli-compression/ 를 참조.

주의 할 것은, jpg, jpeg와 같이 이미 압축되어 있는 컨텐츠를 다시 압축할 필요는 없다는 것이다. 또한 html, js만 압축할 것이 아니라 xml, json등의 파일도 압축 대상에 포함시켜야 한다.

## 그러나

그러나 brotli는 ie에서 지원하지 않는다.

https://caniuse.com/brotli

![can-i-use-brotli](./images/can-i-use-brotli.png)

따라서, ie 환경을 고려하고 있다면 gzip 방식으로도 컨텐츠를 제공해야 한다.


왜 이걸 이제 알았나 자괴감 들고 괴로워

더 나은 압축 알고리즘, Brotli

일반적으로 캐싱은 데이터를 저장해두었다가, 다시 요청할 때 이를 요청하지 않고 저장한 데이터를 불러와서 성능을 향상시켜 요청이 더 빨리 처리되도록 한다. 예를 들어, 네트워크의 캐시된 리소스는 서버로 왔다리 갔다리 하는 일을 피할 수 있다. 캐시된 결과는 동일한 계산을 수행하는 것을 막을 수 있다. 크롬에서는, 이러한 캐싱을 위한 여러가지 메커니즘이 있으며, HTTP 캐시를 그중 하나로 예를 들 수 가 있다.

## Chrome 85 까지의 캐싱 동작

크롬 85 버전 까지는, 크롬은 네트워크로 부터 요청한 데이터를 캐싱하는데 있어서 각 리소스 URL을 캐시키로 활용했다. 아래 예를 살펴보자.

1. `https://a.example`에서 `https://x.example/doge.png`를 요청했다. 이 미지는 `https://x.example/doge.png`를 캐시키로 캐싱이 된다.
2. 1과는 다른 `https://b.example`에서 1과 동일한 이미지인 `https://x.example/doge.png`를 요청했다. 브라우저는 HTTP 캐시를 확인할 때 해당 미지 URL 키를 기준으로 검사하여 이 리소스가 캐시되었는지 확인한다. 1에서 이미 캐시를 했었으므로 캐시된 리소스 버전을 사용한다.
3. `https://c.example`에서 iframe 으로 `https://d.example`를 요청하고, 이 `https://d.example`에서 `https://x.example/doge.png` 를 요청했다고 가정해보자. 이 경우에도 마찬가지로 리소스 URL을 캐시키로 활용하기 때문에 캐싱된 이미지를 사용한다.

이러한 매커니즘은 성능이라는 관점에서 굉장히 잘 작동하므로 오랫동안 이용되어 왔다. 그러나 HTTP 요청에 응답하기 위해 웹 사이트가 필요로 하는 이 시간은, 과거 브라우저가 동일한 리소스에 액세스 했다는 것을 식별할 수 이으며, 이는 브라우저를 다음과 같은 보안 공격에 취약하게 만든다.

1. 유저가 특정한 사이트를 방문했는지를 식별할 수 있음: 공격자는 캐시에 특정 사이트 또는 사이트 cohort에 해당하는 리소스가 있는지 확인하여 사용자의 검색 기록을 탐지할 수 있다.
2. [크로스 사이트 검색 공격](https://portswigger.net/daily-swig/new-xs-leak-techniques-reveal-fresh-ways-to-expose-user-information): 공격자는 특정 웹 사이트에 사용하는 '검색 결과 없음' 이미지가 브라우저의 캐시에 있는지 확인하여, 사용자의 검색 결과에 특정 문자열이 있는지 여부를 확인할 수 있다.
3. 크로스 사이트 트래킹: 이 캐시를 사용하여 쿠키와 유사한 식별자를 크로스 사이트 트래킹 매커니즘으로 악용할 수 있다.

이런 이유 때문에, 크롬에서는 86부터 (사파리는 이미 적용된듯) 파티셔닝 HTTP 캐시 전략을 사용하기로 결정했다.

## 캐시 파티셔닝이 크롬 HTTP 캐시에 미치는 영향

캐시 파티셔닝을 사용하면, 캐시된 리소스는 리소스 URL 외에 추가로 'Network Isolation Key'를 활용하여 키를 만든다. 이 키는 최상위 사이트와 현재 프레임 사이트로 구성된다.

이 전략을 사용하면, 위의 예제가 아래처럼 바뀌게 된다.

1. `https://a.example`에서 `https://x.example/doge.png`를 요청한다. 이 경우 캐시키는 아래오 같이 구성될 것이다. (위에서 부터 top-level site, current-frame site, resource url)

```bash
{
  https://a.example,
  https://a.example,
  https://x.example/doge.png
}
```

2. `https://b.example`에서 `https://x.example/doge.png`를 요청한다. 1에서 같은 이미지를 요청했음에도 불구하고, 캐시 키가 일치하지 않기 때문에 캐시를 불러오지 않는다.

```bash
{
  https://b.example,
  https://b.example,
  https://x.example/doge.png
}
```

3. `https://a.example`에서 iframe으로 embedded 된 `https://a.example`를 불러오는 경우. 여기에서 같은 이미지 `https://x.example/doge.png` 를 요청했다고 가정해보자. 이 경우에는 캐시를 불러올 수 있다.

```bash
{
  https://a.example,
  https://a.example,
  https://x.example/doge.png
}
```

4. `https://a.example`에서 iframe으로 embedded 된 `https://c.example`를 불러오는 경우. 여기에 같은 이미지 리소스를 불러온 다 하더라도, frame이 다르기 때문에 캐시키를 불러올 수 없다.

```bash
{
  https://a.example,
  https://c.example,
  https://x.example/doge.png
}
```

5. `https://a.example`의 서브 도메인 `https://sub.a.example`에서 iframe으로 embedded 된 `https://c.example:8080`를 불러오는 경우. 이 경우엔 키는 `"scheme://eTLD+1"` 전략으로 생성되기 때문에, 4번에서 생성한 캐시를 가져올 수 있게 된다.

```bash
{
  https://a.example,
  https://c.example,
  https://x.example/doge.png
}
```

6. `https://a.example`에서 `https://b.example`를 embedded하고 또 이것이 `https://c.example`를 불러오는 경우. 이 경우에는 top-site 가 기준이므로 캐시키는 아래와 같이 생성되고, 이경우에도 4번의 캐시키를 히트 할 수 있다.

```bash
{
  https://a.example,
  https://c.example,
  https://x.example/doge.png
}
```

## 적용되었는지 확인하는 법

https://www.zdnet.com/article/chromes-new-cache-partitioning-system-impacts-google-fonts-performance/

1. `chrome://net-export/`로 진입해서 `Start Logging to Disk`를 누른다.
2. 로그를 저장할 위치를 고른다
3. 크롬에서 웹 서핑을 한다
4. 1번으로 돌아가서 로깅을 멈춘다.
5. https://netlog-viewer.appspot.com/#import 로 들어간다
6. 저장한 로그 파일을 업로드 한다.

`SplitCacheByNetworkIsolationKey`에서 `Experiment_`로 되어 있다면 파티셔닝 캐시가 활성화 되어 있는 것이다. `Control_`나 `Default_`는 활성화 되지 않은 것이다.

```bash
SplitCacheByNetworkIsolationKey:Experiment_Triple_Key_20201210
```

내 경우엔 활성화 되어 있었다.

## 테스트 하는법

크롬을 `--enable-features=SplitCacheByNetworkIsolationKey`와 [함께 실행하면 된다.](https://www.chromium.org/developers/how-tos/run-chromium-with-flags)

## 개발자가 취해야할 조치

breaking change는 아니지만, 일부 웹서비스의 성능에 대한 고려를 해볼 수 있다. 글꼴이나 인기 있는 스크립트를 제공하는 CDN 사이트의 경우 트래픽 요청이 증가할 수 있다.

> 예를 들어 google font를 사용한다고 해서 이제 웹 사이트의 성능적인 이점을 누릴 수 없다. 여기저기서 범용적으로 사용하는 google font를 사용한다 하더라도, 파티셔닝 캐시로 인해서 캐시를 히트하지 못하고, 이는 사이트 방문시에 같은 폰트를 다른 사이트에서 쓴적이 있다 하더라도 새롭게 받을 것이다. 따라서 그냥 google font를 쓰는 것보다 폰트나 리소스를 self-hosting 하는게 낫다.

## 성능에 미치는 영향

전체 캐시 누락률이 약 3.6% 정도 증가하고, FCP (First Contentful Paint)가 0.3%, 네트워크에서 로드되는 전체 바이트 비율이 4%정도 증가할 수 있다.

## 브라우저 별 차이

[HTTP cache partitions은 fetch 표준](https://fetch.spec.whatwg.org/#http-cache-partitions)이다. 그러나 브라우저 별로 약간의 차이가 있다.

- Chrome: top-level 과 프레임에 `scheme://eTLD+1`를 사용한다.
- Safari: top-level `scheme://eTLD+1`를 사용한다. [참고](https://webkit.org/blog/8613/intelligent-tracking-prevention-2-1/)
- Firefox: [적용 예정](https://bugzilla.mozilla.org/show_bug.cgi?id=1536058) top-level `scheme://eTLD+1`를 사용하며, 크롬처럼 2번째 키 사용을 고려중

출처: https://developers.google.com/web/updates/2020/10/http-cache-partitioning


Google Font 를 써도 이제 캐시 효과는 못받겠네요

파티셔닝 캐시 (partitioning cache)

오늘날 90%가 넘는 브라우저가 모던 자바스크립트를 실행할 수 있음에도 불구하고, 레거시 자바스크립트는 오늘날 웹 성능 문제에 큰 원인 중 하나로 남아 있다. ES2017 문법을 사용하여 웹 페이지 또는 패키지를 작성하고 퍼블리싱 하면 성능을 매우 향상 시킬 수 있다.

## 모던 자바스크립트란 무엇일까

모던 자바스크립트는 특정 ECMAScript 버전으로 작성된 코드를 말하는게 아니고, 모던 브라우저에서 지원하는 문법으로 이루어진 것을 의미한다. 크롬, 엣지, 파이어폭스, 사파리와 같은 모던 웹 브라우저는 브라우저 시장의 90% 이상을 차지하고 있으며, 이 렌더링 엔진에 의존하는 다른 브라우저가 5% 쯤 된다. 따라서 글로벌 웹 트래픽의 95%가 지난 10년간 가장 널리 사용되는 자바스크립트 언어 기능을 지원하는 브라우저에서 비롯된다.

> 아마도 엣지 레거시와 구 IE를 제거한 수치로 보면 될 것 같다. 우리나라에서는 약 93% 정도 된다.

<div id="all-browser-KR-monthly-201912-202011" width="600" height="400" style="width:600px; height: 400px;"></div><p>Source: <a href="https://gs.statcounter.com/browser-market-share/all/south-korea/#monthly-201912-202011-bar">StatCounter Global Stats - Browser Market Share</a></p><script type="text/javascript" src="https://www.statcounter.com/js/fusioncharts.js"></script><script type="text/javascript" src="https://gs.statcounter.com/chart.php?all-browser-KR-monthly-201912-202011&chartWidth=600"></script>

여기서 말하는 문법은 이정도다.

- 클래스 (ES2015)
- 화살표 함수 (ES2015)
- 제네레이터 (ES2015)
- 블록 스코프 (ES2015)
- 디스트럭쳐링 (ES2015)
- 전개 연산자 (ES2015)
- 객체 축약 (ES2015)
- async await (ES2017)

이 후에 나온 기능, 예를 들어 ES2020, ES2021에 나온 기능들은 브라우저의 70% 정도가 지원한다. 여전히 70%면 많은 수치이지만, 그 기능에 온전히 기대는 것은 안전하지 않다. 따라서 모던 자바스크립트를 타겟으로 한다면, 가장 널리 알려져 있으며 지원하는 브라우저가 많은 ES2017 정도가 적당해 보인다. 다른 말로 하자면,  ES2017이 오늘날의 가장 모던한 문법인 것이다.

> 물론 이 글은 2020년 12월 15일에 작성되어 있습니다. 시간이 흐르면 더 달라지겠죠?

https://dev.to/garylchew/bringing-modern-javascript-to-libraries-432c

## 레거시 자바스크립트

레거시 자바스크립트란 위에서 언급한 새로운 기능을 사용하지 않은 코드라 볼 수 있다. 대부분의 개발자는 모던한 문법으로 작성하지만, 브라우저의 지원을 늘리기 위하여 레거시 구문으로 컴파일한다🤪. 레거시 구문으로 컴파일하면 브라우저 지원 범위가 증가하지만, 그 효과는 우리가 생각하는 것보다 작다. 레거시 자바스크립트로 95% 정도의 수치를 98% 로 늘릴 수 는 있지만, 그 비용은 엄청나다.

> 나머지 2%는 no javascript 가 아닐까 싶습니다

- 레거시 자바스크립트는 모던 자바스크립트와 비교 했을 때 일반적으로 20% 정도 용량이 더 크고 느리다. 만약 여기에서 잘못 구성한다면 그 차이가 더 커질 수 있다.
- 별도로 설치하는 자바스크립트 라이브러리의 경우 일반적인 자바스크립트 코드의 90% 정도를 차지 한다. 이 코드에 폴리필 등이 추가 된다면 더 많은 자바스크립트 오버헤드가 발생할 수 있다.

## npm에서 모던 자바스크립트

[최근에 nodejs는 패키지의 엔트리 포인트를 지정할 수 있게 해주었다.](https://nodejs.org/api/packages.html#packages_package_entry_points)

```json
{
  "exports": "./index.js"
}
```

`exports` 필드에서 참조하는 모듈은 최소 ES2019를 지원하는 12.8의 노드 버전을 의미한다. 따라서 exports를 참조하는 모듈은 모던 자바스크립트로 작성할 수 있음을 의미한다. 따라서 모던 코드만 있는 패키지를 배포하고, 트랜스파일링은 사용하는 사람에게 맡기고 싶다면 위처럼 `exports` 필드만 사용하면 된다.

`exports`와 함께 `main`을 사용한다면, 레거시 브라우저를 위한 ES5와 CommonJS를 제공할 수 있다. 일종의 modern 한 코드의 레거시 폴백이다.

```json
{
  "name": "foo",
  "exports": "./modern.js",
  "main": "./legacy.cjs"
}
```

CommonJS로 작성된 fallback에, `module`을 추가한다면 유사하게 legacy fallback 번들로 동작하지만, 자바스크립트 모듈 문법인 `import`와 `export`도 사용 가능하다.

```json
{
  "name": "foo",
  "exports": "./modern.js",
  "main": "./legacy.cjs",
  "module": "./module.js"
}
```

이렇게 하는 이유는, 웹팩과 롤업과 같은 번들러에서 트리쉐이킹을 할 수 있도록 하기 위해서다. 이 코드는 `import` `export` 이외에 모던 코드를 사용하지 않는 레거시 번들 이므로, 레거시 코드를 지원함과 동시에 번들링에 최적화 시킬 수 있다는 장점을 가지고 있다.

## 애플리케이션의 모던 자바스크립트

써드파티 디펜던시는 프로덕션 웹 애플리케이션의 대부분을 차지한다. npm 의존성은 역사적으로 레거시 ES5로 퍼블리싱 되어왔지만, 이에 의존하는 것은 더이상 안전하지 못한 가정이며, 애플리케이션에서 브라우저 지원을 해칠 수도 있는 위험한 행동이다.

모던 자바스크립트로 이동하는 npm 패키지가 점차 많아지면서 이를 다룰 수 있는 도구를 설치하는 것이 중요 해졌다. 여거라지 방법이 있지만, 일반적으로 좋은 아이디어는 의존성을 내가 작성하는 코드의 문법 수준과 맞춰 트랜스파일 하는 것이다.

## 웹팩

웹팩5에서 부터, 번들 및 모듈에 대한 코드를 생성할 때 마다 사용할 문법을 설정할 수 있다. 이는 코드나 의존성을 트랜스파일링 하는 것이 아니고, 오직 webpack에 의해 생성된 코드를 붙일 때 영향을 미친다. 브라우저 지원 타겟을 설저하기 위해서는 `browserlist`설정을 추가하거나, 혹은 웹팩 설정에 바로 넣어두면 된다.

```javascript
module.exports = {
  target: ['web', 'es2017'],
};
```

또한 웹팩에서 모던 ES 모듈 환경을 타겟으로 한다면, 불필요한 wrapper 함수를 생략하여 번들 크기를 최적화하는 설정을 할 수 다.

```javascript
module.exports = {
  target: ['web', 'es2017'],
  output: {
    module: true,
  },
  experiments: {
    outputModule: true,
  },
};
```

이외에도 웹팩을 활용하여 모던 자바스크리븥 문법을 활용하면서 동시에 레거시 브라우저도 지원할 수 있도록 도와주는 많은 도구들이 존재한다.

## Optimize Plugin

[Optimize Plugin](https://github.com/developit/optimize-plugin)은 개별 자바스크립트 파일을 레거시 자바스크립트로 만드는 대신에, 최종적으로 만들어진 모던 번들 코드를 레거시 자바스크립트로 변환시켜주는 도구다. 웹팩 설정을 통해 모든 것이 모던 자바스크립트라고 가정하기 때문에, 특별한 처리가 필요하지 않다. 또한 이는 개별 모듈이 아닌 번들 레벨에서 동작하므로 애플리케이션의 코드와 디펜던시를 동등하게 처리한다. 이는 최종 번들링된 파일을 다시 레거시 문법으로 만드는 것이기 때문에, 전통적인 방식보다 빠를 수 있다. 이러한 두개의 모듈은 [module/nomodule pattern](https://web.dev/serve-modern-code-to-modern-browsers/)에서 사용된다.

```javascript
// webpack.config.js
const OptimizePlugin = require('optimize-plugin');

module.exports = {
  // ...
  plugins: [new OptimizePlugin()],
};
```

`Optimize Plugin`은 모던 코드와 레거시 코드를 따로 번들링 하는 기존 방식보다 더 빠르고 효율적이다. 또한 `Babel`처리도 가능하며, `Terser`를 활용하여 각각의 번들 크기를 줄일 수도 있다. 마지막으로, 레거시 번들에 필요한 폴리필을 따로 관리하기 때문에, 모던 브라우저에서 이를 로딩하지 않도록 도와준다.

<video style="width: 100%;" controls="" autoplay="" loop="" muted="" class="w-screenshot">
    <source src="https://storage.googleapis.com/web-dev-assets/fast-publish-modern-javascript/transpile-before-after.webm" type="video/webm">
    <source src="https://storage.googleapis.com/web-dev-assets/fast-publish-modern-javascript/transpile-before-after.mp4" type="video/mp4">
  </video>

  ## BabelEsmPlugin

  웹팩 플러그인 중 하나인 [BabelEsmPlugin](https://github.com/prateekbh/babel-esm-plugin)는 `@babel/preset-env` 와 함께 사용할 수 있으며, 현재 가지고 있는 번들을 모던 브라우저에 서비스 할 수 있도록 트랜스파일링을 최소화 해준다. 이는 Next.js나 preact cli에서도 사용하는 가장 유명한 module/nomodule 솔루션이다.

  ```javascript
  // webpack.config.js
const BabelEsmPlugin = require('babel-esm-plugin');

module.exports = {
  //...
  module: {
    rules: [
      // your existing babel-loader configuration:
      {
        test: /\.js$/,
        exclude: /node_modules/,
        use: {
          loader: 'babel-loader',
          options: {
            presets: ['@babel/preset-env'],
          },
        },
      },
    ],
  },
  plugins: [new BabelEsmPlugin()],
};
```

`BabelEsmPlugin`는 애플리케이션에서 크게 분리된 두가지 빌드를 실행하기 때문에 다양한 웹팩 설정을 지원한다. 두 번 컴파일 하는 것은 대규모 애플리케이션에 약간의 추가 시간이 걸릴 수 있지만, 이는 BabelEsmPlugin이 기존의 웹팩 설정에 원활한 통합 등을 도와주며, 편의성도 제공한다.

## node_modules을 트랜스파일 하기 위한 babel-loader 설정

위에서 언급한 두개의 플러그인 대신 `babel-loader`를 사용하고 있다면, npm 모듈을 모던 자바스크립트로 사용하기 위한 중요한 단계가 남아 있다. 두개의 개별적인 바벨 로더를 구성해서 정의한다면, node_modules에서 발견되는 최신 언어 스펙을 ES2017로 자동으로 컴파일 하는 동시에, 프로젝트에 구성된 babel 플러그인과 사전 설정으로 자신의 코드를 1차적으로 변환할 수 있다. 이는 module/nomodule 설정의 번들을 생성하지는 않지만, 오래된 브라우저 지원을 깨트리지 않고 모던 자바스크립트가 포함된 npm 패지키를 설치하고 사용하는 것을 가능하게 한다. 

[webpack-plugin-modern-npm](https://www.npmjs.com/package/webpack-plugin-modern-npm) 을 사용하면, npm 디펜던시에 `exports`가 있는 코드들을 컴파일한다.

```javascript
// webpack.config.js
const ModernNpmPlugin = require('webpack-plugin-modern-npm');

module.exports = {
  plugins: [
    // auto-transpile modern stuff found in node_modules
    new ModernNpmPlugin(),
  ],
};
```

대신에 이 기능을 수동으로 설정할 수 도 있다.

```javascript
// webpack.config.js
module.exports = {
  module: {
    rules: [
      // Transpile for your own first-party code:
      {
        test: /\.js$/i,
        loader: 'babel-loader',
        exclude: /node_modules/,
      },
      // Transpile modern dependencies:
      {
        test: /\.js$/i,
        include(file) {
          let dir = file.match(/^.*[/\\]node_modules[/\\](@.*?[/\\])?.*?[/\\]/);
          try {
            return dir && !!require(dir[0] + 'package.json').exports;
          } catch (e) {}
        },
        use: {
          loader: 'babel-loader',
          options: {
            babelrc: false,
            configFile: false,
            presets: ['@babel/preset-env'],
          },
        },
      },
    ],
  },
};
```

이 방법을 사용할 때는 minifier가 이러한 모던 코드를 지원할 수 있도록 해야 한다. `Terser` `Uglify-es`에 `{ecma: 1027}`를 지정할 수 있는 옵션이 있으며, 경우에 따라 압축하거나 포맷하는 와중에 `ES2017`구문을 생성하기도 한다. 

## 추가적인 빌드 툴

- https://parceljs.org/
- https://www.snowpack.dev/
- https://github.com/vitejs/vite
- https://github.com/preactjs/wmr

## 결론

ES2017 이 요즘 흔히 말하는 모던 자바스크립트에 가장 근접한 스펙이며, npm, babel, rollup 등을 빌드 시스템에 사용하여 패키지와 문법을 모던 자바스크립트에서 동작할 수 있도록 설정할 수 있다. 

출처: https://web.dev/publish-modern-javascript/

아니 그래서 IE 11 언제 없앨 건데요

더 빠른 웹 애플리케이션을 위한 모던 자바스크립트

뒤로가기/앞으로가기 캐시 (이해 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.

yceffort

browser

overflow: auto vs overflow: scroll 왜 윈도우에서만 쓸모없는 스크롤바가 노출될까

더 나은 압축 알고리즘, Brotli

파티셔닝 캐시 (partitioning cache)

더 빠른 웹 애플리케이션을 위한 모던 자바스크립트

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