네트워크를 통해서 리소트를 가져오는 것은 느리고 비싸다.

- 리소스가 많아지면 서버와 브라우저 사이에서 라운드트립이 잦아진다.
- 중요 리소스가 다운로드 될 때 까지 페이지가 로딩되지 않는다.
- 만약 누군가 모바일로 제한된 데이터로 접근하려 할 경우, 불필요한 리소스 호출은 그들에게 돈장비로 이어진다.

이러한 불필요한 네트워크 요청을 줄이는 가장 좋은 방법은 HTTP Cache다.

## 브라우저 호환성

HTTP Cache라고 불리우는 하나의 API가 존재하는 것은 아니다. 보통 HTTP Cache라고 한다면, 아래와 같은 것들을 의미한다.

- [Cache-control](https://developer.mozilla.org/docs/Web/HTTP/Headers/Cache-Control#Browser_compatibility)
- [Etag](https://developer.mozilla.org/docs/Web/HTTP/Headers/ETag#Browser_compatibility)
- [Last-modified](https://developer.mozilla.org/docs/Web/HTTP/Headers/Last-Modified#Browser_compatibility)

위 기술들은 모든 브라우저에서 작동한다.

## HTTP Cache는 어떻게 작동하는가?

브라우저가 시도하는 모든 HTTP 요청은 먼저 브라우저 캐시로 라우팅되어, 요청을 수행하는데 사용할 수 있는 유효한 캐시가 있는지를 먼저 확인한다. 만약 유효한 캐시가 있으면, 이 캐시를 읽어서 불필요한 전송으로 인해 발생하는 네트워크 대기시간, 데이터 비용을 모두 상쇄한다.

HTTP 캐시의 동작은 [request header](https://developer.mozilla.org/en-US/docs/Glossary/Request_header)와 [response header](https://developer.mozilla.org/en-US/docs/Glossary/Response_header) 의 조합으로 제어된다. 이상적인 시나리오에서는 웹 어플리케이션의 코드(requset header)와 웹서버의 구성(response header) 모두를 제어할 수 있다.

https://developer.mozilla.org/ko/docs/Web/HTTP/Caching

## Request Header: 일반적으로 기본값을 유지

웹 애플리케이션의 request 요청에 포함되어야 하는 중요한 헤더들이 많지만, 브라우저는 요청을 할 때 거의 항상 사용자를 대신에 헤더를 생성한다. [If-None-Match](https://developer.mozilla.org/docs/Web/HTTP/Headers/If-None-Match), [If-Modified-Since](https://developer.mozilla.org/docs/Web/HTTP/Headers/If-Modified-Since) 와 같이 캐시의 신선도(?)를 확인하는 요청 헤더의 경우에는, 브라우저가 현재 값을 기준으로 요청을 날리게 된다.

이는 개발자에게는 희소식이다. 단순히 HTML에서 `<img src="my-image.png" />` 만 쓰더라도, 브라우저는 알아서 캐시에 필요한 요청을 날려준다.

> 물론 fetch의 헤더를 직접 작성하여 cache를 커스터마이징 할 수 있다.

## Response Header: 웹 서버 설정 변경

- [Cache-control](https://developer.mozilla.org/docs/Web/HTTP/Headers/Cache-Control#Browser_compatibility): 서버는 직접적으로 `Cache-Control`의 값을 리턴해서 어떻게, 그리고 얼마나 캐시할지를 직접적으로 개별 요청에 대해서 지시를 내릴 수 있다.
- [Etag](https://developer.mozilla.org/docs/Web/HTTP/Headers/ETag#Browser_compatibility): 만약 브라우저가 만료된 캐시 응답을 찾을 경우, 작은 토큰(일반적으로 파일 컨텐츠의 해쉬)를 서버로 보내서 파일이 변경되었는지를 확인할 수 있다. 만약 서버가 같은 토큰을 리턴한다면 파일이 변경되지 않았다는 뜻이므로, 다시 다운로드 할 필요가 없다.
- [Last-modified](https://developer.mozilla.org/docs/Web/HTTP/Headers/Last-Modified#Browser_compatibility): `Etag`와 같은 목적으로 만들어졌으며, 여기서는 대신에 시간을 기준으로 판단하게 된다.

일부 웹서버에는 기본적으로 이러한 헤더를 설정하는 기능이 내장되어 있으며, 다른 웹서버의 경우에는 명시적으로 구성하지 않으면 헤더를 완전히 제어 한다.

설령 `Cache-Control`의 값을 그대로 두어도 Http 캐싱이 비활성화되지 않는다. 대신 브라우저는 특정 유형의 컨텐츠에 가장 적합한 캐싱 동작 유형을 알아서 추측한다. 이를 [Heuristic Freshness](https://www.mnot.net/blog/2017/03/16/browser-caching#heuristic-freshness)라 한다.

## 어떤 Response Header를 사용해야 할까?

### 버전별 URL을 활용한 장기간 캐싱

만약 CSS 파일의 캐싱을 1년으로 설정해두었다고 해보자. 만약 디자이너가 방금 무언가를 고쳐서 다시 업데이트 해야하는 상황이라면? 어떻게 브라우저에게 업데이트 하라고 알려줄 것인가? URL자체를 바꾸지 않는 한 이는 불가능하다. 브라우저가 응답을 캐싱해버린 이상, `max-age`나 `expires`로 결정하거나, 사용자가 캐시를 날리지 않는 한 계속해서 남아있게 된다. 결과적으로, 새로 들어온 사용자와 기존 사용자가 다른 페이지를 보는 꼴이 되어 버린다. 이러한 경우를 방지하기 위해, 파일명에 버전명을 두는 방법을 사용한다.

만약 요청 URL에 특별한 지문이 있거나 버전 관리 정보를 포함하고, 데이터가 결코 변경될 일이 없다면 `Cache-Control: max-age=3153600` (1년) 을 응답에 추가한다.

이는 브라우저에 1년이 지나지 않는 한 (1년이 최대 값이다) 같은 URL에 대해서는 즉시 네트워크 요청없이 캐싱된 응답을 리턴하게 된다. [웹팩을 활용하여](https://webpack.js.org/guides/caching/#output-filenames)이러한 과정을 자동화 할 수 있다.

> `immutable`을 지정하여 절대로 바뀌지 않는 다는 것을 명시할 수도 있지만, 아쉽게도 모든 브라우저에서 작동하지는 않는다.

### 버전 없는 URL에 대해 서버에서 재검증

안타깝게도 모든 URL의 버전이 관리되는 것이 아니다. 예를 들어 www.naver.com/pay.html 에 대해서 URL 버저닝을 한다면 www.naver.com/pay.1cde52.html이 될텐데, 이렇게 하게되면 ...

HTTP 캐싱 만으로는 네트워크 요청을 피해가면서 캐싱하기에는 부족하다. 하지만 네트워크 요청을 가장 빠르고 최소화하여 캐싱할 수 있는 방법이 몇가지 있다.

아래의 `Cache-Control` 값은 버저닝 되지 않는 URL에 대한 최적화를 진행할 수 있다.

- `no-cache`. 이는 캐시된 버전의 URL을 사용하기 전에 서버에서 재검증을 해야 함을 브라우저에 지시할 수 있다.
- `no-store`. 브라우저 및 기타 중간 과정의 캐시 (`CDN` 같이)가 파일의 어떤 버전도 저장하지 않도록 지시한다.
- `private` 브라우저는 파일을 캐시할 수 있지만 중간 캐시를 할 수 없다.
- `public` 모든 응답이 캐시에 저장할 수 있다.

![cache-control flowchart](https://webdev.imgix.net/http-cache/flowchart.png)

### ETag

`ETag`나 `Last-Modified`를 사용하면, 조금더 재검증을 효과적으로 할 수 있다. 이들은 결국 요청 헤더에서 언급했던 `If-Modified-SInce`, `If-None-Match`를 트리거 하게 된다.

적절하게 구성된 웹서버가 이러한 요청 해더를 보게 되면, 브라우저가 이미 HTTP 캐시에 있는 리소스의 버전이 웹서버의 최신 버전과 일치하는지 확인 할 수 있다. 일치하는 항목이 있으면 서버는 304 not modified로 응답할 수 있다. 이는 '그냥 갖고 있는 것을 써라' 와 같다. 이러한 유형의 응답을 주고 받게 되면 실제 원본 데이터를 보내는 것 보다 데이터의 양을 확연히 줄일 수 있다.

![304](https://webdev.imgix.net/http-cache/http-cache.png)

## 요약

HTTP 캐시는 불필요한 네트워크 요청을 줄이기 때문에 웹페이지 로딩 성능을 향상 시킬 수 있는 좋은 방법이다.

## 더 많은 팁

- 일관된 URL을 사용하라. 다른 URL에서 동일한 콘텐츠를 제공하는 경우 해당 콘텐츠를 여러번 가져와서 저장한다.
- 리소스의 일부가 자주 업데이트되고, 나머지 파일은 업데이트가 잘 안되는 경우, 각각 파일을 나눠 캐시 전략을 따로 가져가는 것이 좋다.

## 예제

#### 1. Immutable content + Long max-age

```bash
Cache-Control: max-age=31536000
```

- 이 URL의 컨텐츠는 절대 변할일이 없다
- 따라서 브라우저/CDN은 이 리소스를 1년 간 캐싱해둘 것이다
- `max-age` 를 넘지 않는 리소스에 대해서 서버에 따로 요청하지 않고도 쓸 수 있다.

변경이 필요하면 URL의 컨텐츠를 바꾸는게 아니고 URL 자체를 바꿔야 한다.

일반적인 웹 서버들은 이 기능을 손쉽게 사용할 수 있도록 기능을 제공한다.

그러나 이러한 패턴을 아티클이나 블로그 포스트에 쓰면 안된다. URL은 버저닝 될 수 없지만, 컨텐츠는 변할 가능성이 존재하기 때문이다.

### 2. Mutable content, always server-revalidated

```bash
Cache-Control: no-cache
```

- 이 URL의 컨텐츠는 변동 가능성이 있다.
- 따라서 로컬에 캐시되어 있는 정보는 믿을 수 없어서, 서버에 요청을 해봐야 한다.

`no-cache`는 캐시를 안한다는 뜻이 아니다. 이는 캐시된 리소스를 사용하기전에 서버의 체크를 거쳐야 한다는 것이다. `no-store`는 브라우저가 캐시를 저장하지 않는 다는 것이다. 마찬가지로, `must-revalidate` 또한 무조건 재검증을 한다는 것이 아니다. `max-age`에 아직 도달하지 않았다면 로컬 리소스를 사용하고, 그렇지 않다면 재검증을 한다는 것이다.

이러한 경우 `ETag`나 `Last-Modified`를 응답 헤더에 추가할 수 있다. 다음에 클라이언트가 리소스를 요청할 경우, 방금 받았던 값을 `If-None-Match`나 `If-Modified-Since`에 넣어서 사용할 수 있는데, 이 경우 서버는 HTTP 304를 리턴하여, 그냥 가지고 있는 것을 쓰라고 응답할 수 있다.

`ETag`나 `Last-Modified`가 없다면, 서버는 항상 컨텐츠를 내려준다.

설명에도 나와있듯, 이 방법은 항상 네트워크 요청을 수반한다.

### 변경 가능한 content에 max-age를 세팅하는 것은 잘못된 선택일 수도 있다.

- `/article/`
- `styles.css`
- `/script.js`

가

```bash
Cache-Control: must-revalidate, max-age=600
```

로 제공된다고 가정해보자.

이는

- URL 내의 데이터가 변경될 수 있다.
- 만약 브라우저가 10분 이전의 데이터를 가지고 있다면, 서버에 요청하지 안흔ㄴ다.
- 그 외의 경우 네트워크 요청을 한다. `If-None-Match`나 `If-Modified-Since`를 함께 사용할 수 있다.

를 의미한다.

테스트시에는 잘 동작하는 것처럼 보일 수도 있지만, 실제 사용시에 문제를 야기할 수 있으며, 문제를 추적하기도 어렵다. 위 예제에서, 만약 CSS 만 서버에서 업데이트 되었다면, 버전 불일치가 발생하게 된다. 이 리소스들은 서로 상호 읜존적이지만 캐싱 헤더는 이를 표현할 수 있다. 사용자는 리소스 중 한두개만 새거를, 그리고 나머지는 오래된 리소스를 사용할 수 있다.

`max-age`는 응답 시간과 관련이 있으므로, 모든 리소스가 동일한 내비게이션의 일부로 요청되면 거의 동시에 만료될 수 있지만 여전히 경주의 가능성이 존재한다. 그러나 이경우, 사용자가 해결할 수 있는 방법이 있긴 한다.

- 새로고침: 페이지가 새로고침으로 다시 로드 되는 경우, 브라우저는 항상 서버에서 다시 유효성 검사를 한다. 물론 사이트가 사용자에게 이런걸 강요할 수는 없다.

그러나 그렇다고 해서 `max-age`가 항상 잘못된 것은 아니다. 페이지 별로 종속성이 존재하지 않는다면, race condition은 문제 되지 않을 수 있다.

HTTP Cache로 불필요한 네트워크 요청 줄이기

네트워크를 통해서 리소트를 가져오는 것은 느리고 비싸다.
<ul>
<li>리소스가 많아지면 서버와 브라우저 사이에서 라운드트립이 잦아진다.</li>
<li>중요 리소스가 다운로드 될 때 까지 페이지가 로딩되지 않는다.</li>
<li>만약 누군가 모바일로 제한된 데이터로 접근하려 할 경우, 불필요한 리소스 호출은 그들에게 돈장비로 이어진다.</li>
</ul>
이러한 불필요한 네트워크 요청을 줄이는 가장 좋은 방법은 HTTP Cache다.
<h2 id="브라우저-호환성">브라우저 호환성</h2>
HTTP Cache라고 불리우는 하나의 API가 존재하는 것은 아니다. 보통 HTTP Cache라고 한다면, 아래와 같은 것들을 의미한다.
<ul>
<li><a href="https://developer.mozilla.org/docs/Web/HTTP/Headers/Cache-Control#Browser_compatibility">Cache-control</a></li>
<li><a href="https://developer.mozilla.org/docs/Web/HTTP/Headers/ETag#Browser_compatibility">Etag</a></li>
<li><a href="https://developer.mozilla.org/docs/Web/HTTP/Headers/Last-Modified#Browser_compatibility">Last-modified</a></li>
</ul>
위 기술들은 모든 브라우저에서 작동한다.
<h2 id="http-cache는-어떻게-작동하는가">HTTP Cache는 어떻게 작동하는가?</h2>
브라우저가 시도하는 모든 HTTP 요청은 먼저 브라우저 캐시로 라우팅되어, 요청을 수행하는데 사용할 수 있는 유효한 캐시가 있는지를 먼저 확인한다. 만약 유효한 캐시가 있으면, 이 캐시를 읽어서 불필요한 전송으로 인해 발생하는 네트워크 대기시간, 데이터 비용을 모두 상쇄한다.
HTTP 캐시의 동작은 <a href="https://developer.mozilla.org/en-US/docs/Glossary/Request_header">request header</a>와 <a href="https://developer.mozilla.org/en-US/docs/Glossary/Response_header">response header</a> 의 조합으로 제어된다. 이상적인 시나리오에서는 웹 어플리케이션의 코드(requset header)와 웹서버의 구성(response header) 모두를 제어할 수 있다.
<a href="https://developer.mozilla.org/ko/docs/Web/HTTP/Caching">https://developer.mozilla.org/ko/docs/Web/HTTP/Caching</a>
<h2 id="request-header-일반적으로-기본값을-유지">Request Header: 일반적으로 기본값을 유지</h2>
웹 애플리케이션의 request 요청에 포함되어야 하는 중요한 헤더들이 많지만, 브라우저는 요청을 할 때 거의 항상 사용자를 대신에 헤더를 생성한다. <a href="https://developer.mozilla.org/docs/Web/HTTP/Headers/If-None-Match">If-None-Match</a>, <a href="https://developer.mozilla.org/docs/Web/HTTP/Headers/If-Modified-Since">If-Modified-Since</a> 와 같이 캐시의 신선도(?)를 확인하는 요청 헤더의 경우에는, 브라우저가 현재 값을 기준으로 요청을 날리게 된다.
이는 개발자에게는 희소식이다. 단순히 HTML에서 <code>&#x3C;img src="my-image.png" /></code> 만 쓰더라도, 브라우저는 알아서 캐시에 필요한 요청을 날려준다.
<blockquote>
물론 fetch의 헤더를 직접 작성하여 cache를 커스터마이징 할 수 있다.
</blockquote>
<h2 id="response-header-웹-서버-설정-변경">Response Header: 웹 서버 설정 변경</h2>
<ul>
<li><a href="https://developer.mozilla.org/docs/Web/HTTP/Headers/Cache-Control#Browser_compatibility">Cache-control</a>: 서버는 직접적으로 <code>Cache-Control</code>의 값을 리턴해서 어떻게, 그리고 얼마나 캐시할지를 직접적으로 개별 요청에 대해서 지시를 내릴 수 있다.</li>
<li><a href="https://developer.mozilla.org/docs/Web/HTTP/Headers/ETag#Browser_compatibility">Etag</a>: 만약 브라우저가 만료된 캐시 응답을 찾을 경우, 작은 토큰(일반적으로 파일 컨텐츠의 해쉬)를 서버로 보내서 파일이 변경되었는지를 확인할 수 있다. 만약 서버가 같은 토큰을 리턴한다면 파일이 변경되지 않았다는 뜻이므로, 다시 다운로드 할 필요가 없다.</li>
<li><a href="https://developer.mozilla.org/docs/Web/HTTP/Headers/Last-Modified#Browser_compatibility">Last-modified</a>: <code>Etag</code>와 같은 목적으로 만들어졌으며, 여기서는 대신에 시간을 기준으로 판단하게 된다.</li>
</ul>
일부 웹서버에는 기본적으로 이러한 헤더를 설정하는 기능이 내장되어 있으며, 다른 웹서버의 경우에는 명시적으로 구성하지 않으면 헤더를 완전히 제어 한다.
설령 <code>Cache-Control</code>의 값을 그대로 두어도 Http 캐싱이 비활성화되지 않는다. 대신 브라우저는 특정 유형의 컨텐츠에 가장 적합한 캐싱 동작 유형을 알아서 추측한다. 이를 <a href="https://www.mnot.net/blog/2017/03/16/browser-caching#heuristic-freshness">Heuristic Freshness</a>라 한다.
<h2 id="어떤-response-header를-사용해야-할까">어떤 Response Header를 사용해야 할까?</h2>
<h3 id="버전별-url을-활용한-장기간-캐싱">버전별 URL을 활용한 장기간 캐싱</h3>
만약 CSS 파일의 캐싱을 1년으로 설정해두었다고 해보자. 만약 디자이너가 방금 무언가를 고쳐서 다시 업데이트 해야하는 상황이라면? 어떻게 브라우저에게 업데이트 하라고 알려줄 것인가? URL자체를 바꾸지 않는 한 이는 불가능하다. 브라우저가 응답을 캐싱해버린 이상, <code>max-age</code>나 <code>expires</code>로 결정하거나, 사용자가 캐시를 날리지 않는 한 계속해서 남아있게 된다. 결과적으로, 새로 들어온 사용자와 기존 사용자가 다른 페이지를 보는 꼴이 되어 버린다. 이러한 경우를 방지하기 위해, 파일명에 버전명을 두는 방법을 사용한다.
만약 요청 URL에 특별한 지문이 있거나 버전 관리 정보를 포함하고, 데이터가 결코 변경될 일이 없다면 <code>Cache-Control: max-age=3153600</code> (1년) 을 응답에 추가한다.
이는 브라우저에 1년이 지나지 않는 한 (1년이 최대 값이다) 같은 URL에 대해서는 즉시 네트워크 요청없이 캐싱된 응답을 리턴하게 된다. <a href="https://webpack.js.org/guides/caching/#output-filenames">웹팩을 활용하여</a>이러한 과정을 자동화 할 수 있다.
<blockquote>
<code>immutable</code>을 지정하여 절대로 바뀌지 않는 다는 것을 명시할 수도 있지만, 아쉽게도 모든 브라우저에서 작동하지는 않는다.
</blockquote>
<h3 id="버전-없는-url에-대해-서버에서-재검증">버전 없는 URL에 대해 서버에서 재검증</h3>
안타깝게도 모든 URL의 버전이 관리되는 것이 아니다. 예를 들어 <a href="http://www.naver.com/pay.html">www.naver.com/pay.html</a> 에 대해서 URL 버저닝을 한다면 <a href="http://www.naver.com/pay.1cde52.html%EC%9D%B4">www.naver.com/pay.1cde52.html이</a> 될텐데, 이렇게 하게되면 ...
HTTP 캐싱 만으로는 네트워크 요청을 피해가면서 캐싱하기에는 부족하다. 하지만 네트워크 요청을 가장 빠르고 최소화하여 캐싱할 수 있는 방법이 몇가지 있다.
아래의 <code>Cache-Control</code> 값은 버저닝 되지 않는 URL에 대한 최적화를 진행할 수 있다.
<ul>
<li><code>no-cache</code>. 이는 캐시된 버전의 URL을 사용하기 전에 서버에서 재검증을 해야 함을 브라우저에 지시할 수 있다.</li>
<li><code>no-store</code>. 브라우저 및 기타 중간 과정의 캐시 (<code>CDN</code> 같이)가 파일의 어떤 버전도 저장하지 않도록 지시한다.</li>
<li><code>private</code> 브라우저는 파일을 캐시할 수 있지만 중간 캐시를 할 수 없다.</li>
<li><code>public</code> 모든 응답이 캐시에 저장할 수 있다.</li>
</ul>
<img src="https://webdev.imgix.net/http-cache/flowchart.png" alt="cache-control flowchart">
<h3 id="etag">ETag</h3>
<code>ETag</code>나 <code>Last-Modified</code>를 사용하면, 조금더 재검증을 효과적으로 할 수 있다. 이들은 결국 요청 헤더에서 언급했던 <code>If-Modified-SInce</code>, <code>If-None-Match</code>를 트리거 하게 된다.
적절하게 구성된 웹서버가 이러한 요청 해더를 보게 되면, 브라우저가 이미 HTTP 캐시에 있는 리소스의 버전이 웹서버의 최신 버전과 일치하는지 확인 할 수 있다. 일치하는 항목이 있으면 서버는 304 not modified로 응답할 수 있다. 이는 '그냥 갖고 있는 것을 써라' 와 같다. 이러한 유형의 응답을 주고 받게 되면 실제 원본 데이터를 보내는 것 보다 데이터의 양을 확연히 줄일 수 있다.
<img src="https://webdev.imgix.net/http-cache/http-cache.png" alt="304">
<h2 id="요약">요약</h2>
HTTP 캐시는 불필요한 네트워크 요청을 줄이기 때문에 웹페이지 로딩 성능을 향상 시킬 수 있는 좋은 방법이다.
<h2 id="더-많은-팁">더 많은 팁</h2>
<ul>
<li>일관된 URL을 사용하라. 다른 URL에서 동일한 콘텐츠를 제공하는 경우 해당 콘텐츠를 여러번 가져와서 저장한다.</li>
<li>리소스의 일부가 자주 업데이트되고, 나머지 파일은 업데이트가 잘 안되는 경우, 각각 파일을 나눠 캐시 전략을 따로 가져가는 것이 좋다.</li>
</ul>
<h2 id="예제">예제</h2>
<h4 id="1-immutable-content--long-max-age">1. Immutable content + Long max-age</h4>
<pre class="language-bash"><code class="language-bash">Cache-Control: max-age=31536000
</code></pre>
<ul>
<li>이 URL의 컨텐츠는 절대 변할일이 없다</li>
<li>따라서 브라우저/CDN은 이 리소스를 1년 간 캐싱해둘 것이다</li>
<li><code>max-age</code> 를 넘지 않는 리소스에 대해서 서버에 따로 요청하지 않고도 쓸 수 있다.</li>
</ul>
변경이 필요하면 URL의 컨텐츠를 바꾸는게 아니고 URL 자체를 바꿔야 한다.
일반적인 웹 서버들은 이 기능을 손쉽게 사용할 수 있도록 기능을 제공한다.
그러나 이러한 패턴을 아티클이나 블로그 포스트에 쓰면 안된다. URL은 버저닝 될 수 없지만, 컨텐츠는 변할 가능성이 존재하기 때문이다.
<h3 id="2-mutable-content-always-server-revalidated">2. Mutable content, always server-revalidated</h3>
<pre class="language-bash"><code class="language-bash">Cache-Control: no-cache
</code></pre>
<ul>
<li>이 URL의 컨텐츠는 변동 가능성이 있다.</li>
<li>따라서 로컬에 캐시되어 있는 정보는 믿을 수 없어서, 서버에 요청을 해봐야 한다.</li>
</ul>
<code>no-cache</code>는 캐시를 안한다는 뜻이 아니다. 이는 캐시된 리소스를 사용하기전에 서버의 체크를 거쳐야 한다는 것이다. <code>no-store</code>는 브라우저가 캐시를 저장하지 않는 다는 것이다. 마찬가지로, <code>must-revalidate</code> 또한 무조건 재검증을 한다는 것이 아니다. <code>max-age</code>에 아직 도달하지 않았다면 로컬 리소스를 사용하고, 그렇지 않다면 재검증을 한다는 것이다.
이러한 경우 <code>ETag</code>나 <code>Last-Modified</code>를 응답 헤더에 추가할 수 있다. 다음에 클라이언트가 리소스를 요청할 경우, 방금 받았던 값을 <code>If-None-Match</code>나 <code>If-Modified-Since</code>에 넣어서 사용할 수 있는데, 이 경우 서버는 HTTP 304를 리턴하여, 그냥 가지고 있는 것을 쓰라고 응답할 수 있다.
<code>ETag</code>나 <code>Last-Modified</code>가 없다면, 서버는 항상 컨텐츠를 내려준다.
설명에도 나와있듯, 이 방법은 항상 네트워크 요청을 수반한다.
<h3 id="변경-가능한-content에-max-age를-세팅하는-것은-잘못된-선택일-수도-있다">변경 가능한 content에 max-age를 세팅하는 것은 잘못된 선택일 수도 있다.</h3>
<ul>
<li><code>/article/</code></li>
<li><code>styles.css</code></li>
<li><code>/script.js</code></li>
</ul>
가
<pre class="language-bash"><code class="language-bash">Cache-Control: must-revalidate, max-age=600
</code></pre>
로 제공된다고 가정해보자.
이는
<ul>
<li>URL 내의 데이터가 변경될 수 있다.</li>
<li>만약 브라우저가 10분 이전의 데이터를 가지고 있다면, 서버에 요청하지 안흔ㄴ다.</li>
<li>그 외의 경우 네트워크 요청을 한다. <code>If-None-Match</code>나 <code>If-Modified-Since</code>를 함께 사용할 수 있다.</li>
</ul>
를 의미한다.
테스트시에는 잘 동작하는 것처럼 보일 수도 있지만, 실제 사용시에 문제를 야기할 수 있으며, 문제를 추적하기도 어렵다. 위 예제에서, 만약 CSS 만 서버에서 업데이트 되었다면, 버전 불일치가 발생하게 된다. 이 리소스들은 서로 상호 읜존적이지만 캐싱 헤더는 이를 표현할 수 있다. 사용자는 리소스 중 한두개만 새거를, 그리고 나머지는 오래된 리소스를 사용할 수 있다.
<code>max-age</code>는 응답 시간과 관련이 있으므로, 모든 리소스가 동일한 내비게이션의 일부로 요청되면 거의 동시에 만료될 수 있지만 여전히 경주의 가능성이 존재한다. 그러나 이경우, 사용자가 해결할 수 있는 방법이 있긴 한다.
<ul>
<li>새로고침: 페이지가 새로고침으로 다시 로드 되는 경우, 브라우저는 항상 서버에서 다시 유효성 검사를 한다. 물론 사이트가 사용자에게 이런걸 강요할 수는 없다.</li>
</ul>
그러나 그렇다고 해서 <code>max-age</code>가 항상 잘못된 것은 아니다. 페이지 별로 종속성이 존재하지 않는다면, race condition은 문제 되지 않을 수 있다.

웹사이트의 렌더링 성능을 최적화하면서, 가장 중점적으로 살펴봐야 할 것은 렌더링을 막는 자바스크립트 실행이다. 그런데 종종, 블로킹 자바스크립트의 원인이 `async` 태그라는 것을 발견하게 되다. 많은 사람들이 async가 렌더링을 막지 않는다고 생각한다. 그러나 슬프게도, 그렇지 않다. async 태그는 렌더링을 블로킹할 뿐만아니라, 스크립트를 동기로 실행하는 것을 막을 수도 있다. 추정컨데, 동기식으로 만든 스크립트는 페이지에 중요한 컨텐츠 이므로, 이를 지연시키는 것은 사용자 경험에 안좋은 영향을 미친다.

이번 글에서는 `defer`가 `async` 보다 더 기본적으로 선택해야할 것인지를 알아본다.

## 병렬화는 성능에 중요하다.

아마도 실제 웹 성능 향상에 가장 중요하게 영향을 미친 것 중 하나는, 스크립트 다운로드를 병렬로 다운로드 받는 것이다. 2006년 이전에는, 브라우저는 모든 외부 스크립트를 순서대로 받았다.

```html
<script src="aphid.js"></script>
<script src="bmovie.js"></script>
<script src="seaserpent.js"></script>
<img src="deejay.gif" />
<img src="elope.gif" />
```

이런 페이지가 있다고 하면, 아래와 같은 순서로 실행된다.

```bash
aphid.js ====xxx
bmovie.js =====xx
seaserpent.js =====xx
deejay.gif =====
elope.gif =====
DOM Interactive *
image render *
```

여기서 `==`는 다운로드하는 작업을 의미하고, `xx`는 스크립트 파싱과 실행을 의미한다. DOM interactive는 브라우저가 HTML 구문 분석을 완효한 후에 실행된다.

이러한 접근 방식에는 많은 비효율이 존재한다. 스크립트는 뭐 순차적으로 실행될 순 있지만, 다운로드는 병렬로 진행할 수 있다. 또한 스크립트가 이미지와 같은 비 스크립트 리소스를 차단할 필요도 없다.

IE8을 필두로 많은 브라우저가 스크립트를 병렬로 다운로드 할 수 있는 `preloader`개념을 도입하기 시작했다. 이로 인해 페이지 속도가 엄청나게 빨라졌다.

```bash
aphid.js ====xxx
bmovie.js ===== xx
seaserpent.js ===== xx
deejay.gif =====
elope.gif =====
DOM Interactive *
image render *
```

`preloader`를 활용하여 모든 리소스가 병렬로 다운로드 되는 것을 볼 수 있다. 여전히 DOM interactive는 세 리소스를 기다려야 하지만, 이전에 비해서 훨씬더 빠르게 동작하는 것을 볼 수 있다.

## 동기 스크립트는 HTML 구문 분석을 차단한다.

preloader는 동기식 스크립트가 다른 리소스의 다운로드를 차단하지 않도록 변경하여 웹 성능을 향상시켰다. 그러나 동기 스크립트는 여전히 HTML 구문 분석을 차단한다. HTML 구문 분석이 `<script/>` 태그에 도달하면 해당 스크립트가 다운로드되고, 구문 분석이 실행 될 때까지 중지된다. HTML 파서가 차단되면 사용가자 페이지의 컨텐츠를 보기 위해 기다려야 한다. 이러한 이유로 인해 앞선 예제에서, 이미지가 다 다운로드 되었음에도 나중에 뵤여지게 된다.

동기스크립트가 HTML 분석을 차단하는 것을 막기 위해, 개발자들은 스크립트를 비동기적으로 로드하는 방법을 찾기 시작했다. 모든 스크립트가 비동기로 동작할 필요는 없다. 페이지 렌더링에 있어서 중요한 스크립트는 동기적으로 로딩되어야 한다. 그러나 중요한 렌더링 이외의 요소는 비동기적으로도 할 수 있다. 2009년 이전에는 이런 것을 처리하기 위한 [꼼수](https://www.stevesouders.com/blog/2009/04/27/loading-scripts-without-blocking/)가 존재했다. 그리고, HTML에 async와 defer가 추가되었다.

## async와 defer

async와 defer는 HTML 파서를 차단하지 않고 스크립트를 로드할 수 있다는 점에서 유사하다. 즉, 둘다 사용자는 페이지를 더 빨리 볼 수 있다. 그러나 여기에 차이점이 존재한다.

- `async`로 로드된 스크립트는 다운로드가 완료되면 즉시 구문 분석을 하고 실행된다. 그에 반해 `defer`는 HTML 문서가 파싱되기 전까지 실행되지 않는다.
- `async`는 순서없이 로드가 가능하지만 `defer`는 마크업 순서대로 로딩된다.

### async

```html
<script ASYNC src="aphid.js"></script>
<script src="bmovie.js></script>
<script src="seaserpent.js"></script>
<img src="deejay.gif">
<img src="elope.gif">
```

```bash
aphid.js ====xxx
bmovie.js ===== xx
seaserpent.js ===== xx
deejay.gif =====
elope.gif =====
DOM Interactive *
image render *
```

`aphid`가 async였지만, 다운로드가 먼저 되었기 때문에 다른 스크립트 실행을 차단하고 먼저 실행되었다. 다시말해, `async`는 다운로드 된 뒤에 모든 동기 스크립트 실행을 차단해 버린다.

### defer

```html
<script DEFER src="aphid.js"></script>
<script src="bmovie.js></script>
<script src="seaserpent.js"></script>
<img src="deejay.gif">
<img src="elope.gif">
```

```
aphid.js ==== xxx
bmovie.js =====xx
seaserpent.js ===== xx
deejay.gif =====
elope.gif =====
DOM Interactive *
image render *
```

defer는 DOM이 상호작용이 가능해지는 시점에 실행된다. defer는 다운로드가 먼저 되었음에도 다른 동기 스크립트가 실행된 이후에 실행된 것을 볼 수 있다.

## defer를 더 선호해야하는 이유

`defer`는 항상 `async`와 동시에, 또는 그 이후에 스크립트 실행을 발생시킨다. 아마도 스크립트 중에서도 덜 중요한 것들을 `defer`나 `async`로 만들 것이다. 따라서 기본 렌더링 시간 외에 실행 될 수 있도록 `defer`로 하는 것이 좋다. `defer`는 동기 스크립트를 차단할 수 없지만, `async`는 스크립트 다운로드에 따라 차단할 수도 있다. 동기 스크립트는 일반적으로 페이지에서 중요한 내용을 담고 있으므로, 다른 작업이 방해하지 않도록 `defer`를 쓰는 것이 좋다.

이러한 잘못된 최적화의 예는 종종 찾아볼 수 있다. [예전 인스타그램 웹페이지 테스트 결과](https://www.webpagetest.org/result/161204_ZY_9a82d23e52565194cb985a10cf8d5465/2/details/)를 한번 살펴보자. 4번째 스크립트가 `async`로 로딩되는 것을 볼 수 있다. 그리고 [Timeline](https://www.webpagetest.org/chrome/timeline.php?test=161204_ZY_9a82d23e52565194cb985a10cf8d5465&run=2)을 살펴보면, 이 스크립트가 다른 스크립트 보다 0.6초정도 먼저 (c0456c81549b.js) 실행되서 다른 스크립트를 블록했다.

반대로 yelp의 [웹 페이지 테스트결과](https://www.webpagetest.org/result/161206_RP_DBM/3/details/)를 보자. 두번째 스크립트가 defer로 로딩되어있는데, 다운로드가 된 이후에 실행은 `DOM Content Loaded` 이후에 이루어졌다. 따라서 다른 동기스크립트가 먼저 로딩 되었고, 렌더링이 더 빨리 이루어졌다.

## 결론

결론은 DOM Interactive 까지 defer 스크립트 실행을 지연하는 것과는 다르게, async는 다운로드가 빨리 되서 실행이 먼저되버리고, 다른 스크립트 분석을 멈춰버리게 하는 위험성을 가지고 있다는 것이다. 따라서, DOM Interative 시간을 아는 것이 굉장히 중요하다. [Alexa Top 100](https://www.alexa.com/topsites)에 따르면 2016년 11월 기준 DOM interactive의 중앙값은 2.1초이지만, 하위 95%의 경우에는 11.2초이다. 이정도 값이면, async 스크립트가 DOM Interative 이전에 다운로드를 마치고, 페이지 렌더링을 방해하고 있는지 합리적으로 의심해 볼법하다.

스크립트에서 async를 사용하면, defer로 바꿔서 렌더링이 더 빨리 되는지 확인해보자.

출처: https://calendar.perfplanet.com/2016/prefer-defer-over-async/

스크립트 실행 최적화를 위해 잘 고민해봐야 한다.

왜 Async 보다는 Defer를 써야할까

브라우저가 어떻게 스크립트를 스케쥴링 하고 실행하느냐에 따라서 웹페이지 성능에 큰 영향을 미친다. `<script defer />` `<link rel=preload>` 등등 스크립트 로딩에 영향을 미치는 다양한 기술들이 있으며 이러한 기술을 브라우저에서 어떤 순서로 처리하는지 이해하는 것도 중요하다.

### Table of Contents

### `<head />` 안에 있는 `<script />`

#### 로딩 우선 순위

중간, 높음

#### 실행 우선 순위

매우높음, 파서 실행을 멈춤

### 사용처

- First Meaningful Paint, First Contentful Paint 컨텐츠
- 다른 스크립트 이전에 실행해야 되는 스크립트

#### 예

- 프레임워크 런타임 (정적 렌더링이 아닌 경우)
- 폴리필
- 전체 페이지 DOM 구조에 영향을 미치는 A/B 테스트

### `<link rel=preload` + `<script async>` 또는 `<script type=module async />`

#### 로딩 우선 순위

중간, 높음

#### 실행 우선 순위

높음, 파서 실행을 방해함

#### 사용처

- 중요한 컨텐츠를 만드는 스크립트 (First Meaningful Paint)
- 그러나 페이지 상단 (above-the-fold)에는 영향을 미치지 않는 요소
- 동적으로 컨텐츠를 넣기 위해 네트워크 fetch를 실행하는 스크립트
- imports한 요소들이 모두 fetch된 이후 즉시 실행되어야 하는 스크립트는, `<script async type=module />`

#### 예

- `<canvas />` 에 그려야 하는 것

### `<script async />`

#### 로딩 우선 순위

제일 낮음, 낮음

#### 실행 우선 순위

높음, 파서를 방해함

#### 사용처

사용할 때 주의 해야 한다. (https://calendar.perfplanet.com/2016/prefer-defer-over-async/) 요즘 들어 중요하지 않은 스크립트를 로딩 할 때 많이 사용하고 있지만, 로딩 우선순위만 낮을 뿐 실행 우선순위는 높다는 것을 기억해야 한다.

### `<script defer />`

#### 로딩 우선 순위

제일 낮음, 낮음

#### 실행 우선 순위

매우 낮음, `<body />` 최하단에 있는 `<script />`가 실행된 이후에 실행

#### 사용처

- 중요하지 않은 컨텐츠를 만드는 스크립트
- 페이지 방문자의 50% 이상정도가 사용하는 중요한 상호작용 기능

#### 예

- 광고
- 프레임 워크 런타임 (클라이언트 또는 서버사이드 렌더링)

### `<body />` 최하단에 있는 `<script />`

#### 로딩 우선 순위

중간, 높음

#### 실행 우선 순위

낮음, 파서의 작업이 끝나기를 기다림

#### 사용처

이 방법은 생각만큼 낮은 우선순위로 실행되지 않는다.

### `<body />` 최하단에 있는 `<script defer />`

#### 로딩 우선 순위

가장 낮음, 낮음, 큐의 모든 작업이 끝난 후에 실행됨.

#### 실행 우선 순위

매우 낮음. `<body />` 최하단에 있는 `<script />` 보다도 낮음.

#### 사용처

- 사용자들이 가끔 사용하는 상호작용 기능

#### 예

- '연관된 기사들' 같은 컨텐츠 (중요도가 낮은)
- '피드백을 주세요' 같은 기능들 (역시 중요도가 낮은)

### `<link rel=prefetch />` + `<script/>`

#### 로딩 우선 순위

작업이 없을 때, 가장낮음

#### 실행 우선 순위

스크립트가 어떻게 작동하느냐에 따라 다름.

#### 사용처

다음 페이지 탐색을 위한 중요한 기능을 제공하는 스크립트

#### 예

- 다음 라우팅을 위한 자바스크립트 번들

### 마치며

- 브라우저 별로 동작이 통일되어 있지 않으므로 사용할 때 주의를 필요로 한다.
- 크롬에서 스크립트 우선순위를 알아내기 위해서는 네트워크 탭에서 Priority를 보면된다.

![priorities](https://addyosmani.com/assets/images/tweet-priorities@3x.png)

출처: https://addyosmani.com/blog/script-priorities/

크롬에서 자바스크립트를 로딩하는 순서

크롬에서 자바스크립트 로딩 순서

리액트로 웹페이지를 만들때, 최대한 작은 단위로 쪼개서 이를 개별 컴포넌트로 만들고 조립하는 방식을 택한다. 그런 방식을 택하다 보면, 십중 팔구 아래와 같은 구조로 구성하게 된다.

```javascript
function App() {
 return (
 <div>
 <MainNav />
 <Homepage />
 </div>
 )
}
function MainNav() {
 return (
 <div>
 <GitHubLogo />
 <SiteSearch />
 <NavLinks />
 <NotificationBell />
 <CreateDropdown />
 <ProfileDropdown />
 </div>
 )
}
function Homepage() {
 return (
 <div>
 <LeftNav />
 <CenterContent />
 <RightContent />
 </div>
 )
}
function LeftNav() {
 return (
 <div>
 <DashboardDropdown />
 <Repositories />
 <Teams />
 </div>
 )
}
function CenterContent() {
 return (
 <div>
 <RecentActivity />
 <AllActivity />
 </div>
 )
}
function RightContent() {
 return (
 <div>
 <Notices />
 <ExploreRepos />
 </div>
 )
}
```

위 구조는 실제 깃헙 홈페이지를 React로 구성한다고 했을 때의 모습이다. 매우 일반적인 구조고, 작동하는데 문제는 없지만, 아래와 같은 구조를 사용해본다면 어떨까?

```javascript
function App() {
 return (
 <div>
 <MainNav>
 <GitHubLogo />
 <SiteSearch />
 <NavLinks />
 <NotificationBell />
 <CreateDropdown />
 <ProfileDropdown />
 </MainNav>
 <Homepage
 leftNav={
 <LeftNav>
 <DashboardDropdown />
 <Repositories />
 <Teams />
 </LeftNav>
 }
 centerContent={
 <CenterContent>
 <RecentActivity />
 <AllActivity />
 </CenterContent>
 }
 rightContent={
 <RightContent>
 <Notices />
 <ExploreRepos />
 </RightContent>
 }
 />
 </div>
 )
}
function MainNav({ children }) {
 return <div>{children}</div>
}
function Homepage({ leftNav, centerContent, rightContent }) {
 return (
 <div>
 {leftNav}
 {centerContent}
 {rightContent}
 </div>
 )
}
function LeftNav({ children }) {
 return <div>{children}</div>
}
function CenterContent({ children }) {
 return <div>{children}</div>
}
function RightContent({ children }) {
 return <div>{children}</div>
}
```

이렇게 코드를 바꾼 구조적인 아이디어는, 대부분의 구성요소가 단순히 레이아웃만 담당한다는 것이다. 이들은 상태를 스스로 관리하기 위해 무언가 일을 하는 코드는 적고 (물론 자체적인 상태관리가 필요할 수도 있지만) 단순히 상태를 받아서 이를 나타나야 하는 페이지에 표시하는 역할만 한다.

만약 첫번째 예제와 같은 구조를 가지고 있다면, `prop-drilling`이 발생하게 된다. `<App/>` 에서 `<HomePage />`로 다시, `<CenterContent />`에서 `<AllActivity />`로 가는 등, prop을 넘기고 넘기는 과정이 반복된다. 이런 구조를 보게 되면 사람들은 아마도 React API인 `context` 를 사용하여 해결하려 할 것이다. 하지만 그러기 전에, 좀더 간단하게 생각해볼 필요가 있다. 자체적인 상태관리가 필요없고, 단순히 레이아웃인 컴포넌트라면 `prop`을 직접적으로 넘기면 된다. `<App />` 에서 `<AllActivity/>`로.

너무 많은 사람들이 `prop-drilling`에서 `context`로 섣불리 넘어가버리려고 한다. 더 많은 컴포넌트를 염두에 두고, 구성요소를 구조화 한다면 더 유지 보수가 쉬워지고, 성능및 관리 문제가 줄어들 것이다.

출처: https://epicreact.dev/one-react-mistake-thats-slowing-you-down

처음부터 구조를 잘 생각해 둔다면 성능상 에 이점을 가져갈 수 있다.

Prop drilling 해결을 위해 context를 사용하기 전에 구조를 생각해보자.

리액트로 웹페이지를 만들때, 최대한 작은 단위로 쪼개서 이를 개별 컴포넌트로 만들고 조립하는 방식을 택한다. 그런 방식을 택하다 보면, 십중 팔구 아래와 같은 구조로 구성하게 된다.
<pre class="language-javascript"><code class="language-javascript">function App() {
 return (
 &#x3C;div>
 &#x3C;MainNav />
 &#x3C;Homepage />
 &#x3C;/div>
 )
}
function MainNav() {
 return (
 &#x3C;div>
 &#x3C;GitHubLogo />
 &#x3C;SiteSearch />
 &#x3C;NavLinks />
 &#x3C;NotificationBell />
 &#x3C;CreateDropdown />
 &#x3C;ProfileDropdown />
 &#x3C;/div>
 )
}
function Homepage() {
 return (
 &#x3C;div>
 &#x3C;LeftNav />
 &#x3C;CenterContent />
 &#x3C;RightContent />
 &#x3C;/div>
 )
}
function LeftNav() {
 return (
 &#x3C;div>
 &#x3C;DashboardDropdown />
 &#x3C;Repositories />
 &#x3C;Teams />
 &#x3C;/div>
 )
}
function CenterContent() {
 return (
 &#x3C;div>
 &#x3C;RecentActivity />
 &#x3C;AllActivity />
 &#x3C;/div>
 )
}
function RightContent() {
 return (
 &#x3C;div>
 &#x3C;Notices />
 &#x3C;ExploreRepos />
 &#x3C;/div>
 )
}
</code></pre>
위 구조는 실제 깃헙 홈페이지를 React로 구성한다고 했을 때의 모습이다. 매우 일반적인 구조고, 작동하는데 문제는 없지만, 아래와 같은 구조를 사용해본다면 어떨까?
<pre class="language-javascript"><code class="language-javascript">function App() {
 return (
 &#x3C;div>
 &#x3C;MainNav>
 &#x3C;GitHubLogo />
 &#x3C;SiteSearch />
 &#x3C;NavLinks />
 &#x3C;NotificationBell />
 &#x3C;CreateDropdown />
 &#x3C;ProfileDropdown />
 &#x3C;/MainNav>
 &#x3C;Homepage
 leftNav={
 &#x3C;LeftNav>
 &#x3C;DashboardDropdown />
 &#x3C;Repositories />
 &#x3C;Teams />
 &#x3C;/LeftNav>
 }
 centerContent={
 &#x3C;CenterContent>
 &#x3C;RecentActivity />
 &#x3C;AllActivity />
 &#x3C;/CenterContent>
 }
 rightContent={
 &#x3C;RightContent>
 &#x3C;Notices />
 &#x3C;ExploreRepos />
 &#x3C;/RightContent>
 }
 />
 &#x3C;/div>
 )
}
function MainNav({ children }) {
 return &#x3C;div>{children}&#x3C;/div>
}
function Homepage({ leftNav, centerContent, rightContent }) {
 return (
 &#x3C;div>
 {leftNav}
 {centerContent}
 {rightContent}
 &#x3C;/div>
 )
}
function LeftNav({ children }) {
 return &#x3C;div>{children}&#x3C;/div>
}
function CenterContent({ children }) {
 return &#x3C;div>{children}&#x3C;/div>
}
function RightContent({ children }) {
 return &#x3C;div>{children}&#x3C;/div>
}
</code></pre>
이렇게 코드를 바꾼 구조적인 아이디어는, 대부분의 구성요소가 단순히 레이아웃만 담당한다는 것이다. 이들은 상태를 스스로 관리하기 위해 무언가 일을 하는 코드는 적고 (물론 자체적인 상태관리가 필요할 수도 있지만) 단순히 상태를 받아서 이를 나타나야 하는 페이지에 표시하는 역할만 한다.
만약 첫번째 예제와 같은 구조를 가지고 있다면, <code>prop-drilling</code>이 발생하게 된다. <code>&#x3C;App/></code> 에서 <code>&#x3C;HomePage /></code>로 다시, <code>&#x3C;CenterContent /></code>에서 <code>&#x3C;AllActivity /></code>로 가는 등, prop을 넘기고 넘기는 과정이 반복된다. 이런 구조를 보게 되면 사람들은 아마도 React API인 <code>context</code> 를 사용하여 해결하려 할 것이다. 하지만 그러기 전에, 좀더 간단하게 생각해볼 필요가 있다. 자체적인 상태관리가 필요없고, 단순히 레이아웃인 컴포넌트라면 <code>prop</code>을 직접적으로 넘기면 된다. <code>&#x3C;App /></code> 에서 <code>&#x3C;AllActivity/></code>로.
너무 많은 사람들이 <code>prop-drilling</code>에서 <code>context</code>로 섣불리 넘어가버리려고 한다. 더 많은 컴포넌트를 염두에 두고, 구성요소를 구조화 한다면 더 유지 보수가 쉬워지고, 성능및 관리 문제가 줄어들 것이다.
출처: <a href="https://epicreact.dev/one-react-mistake-thats-slowing-you-down">https://epicreact.dev/one-react-mistake-thats-slowing-you-down</a>

요즘 대부분의 리액트 코드는 함수형 컴포넌트와 리액트 hooks의 조합으로 개발된다. 그러나 여전히 [higher-order components(이하 HOC)](https://ko.reactjs.org/docs/higher-order-components.html)는 클래스형, 그리고 함수형 모두에 적용할 수 있다. 따라서 HOC는 레거시와 모던한 리액트 컴포넌트 사이에서 재사용 가능성을 높이며 쓸 수 있는 훌륭한 다리 역할을 하고 있다.

그러나 때때로 HOC의 사용은 자제해야하며, 몇몇 문제들은 hooks만으로도 해결할 수 있다.

## HOC와 HOOKS: Prop에서 오는 혼동

조건부 렌더링 기능을 적용하기 위해 HOC를 사용한다고 가정해보자.

```javascript
import * as React from 'react'

const withError = (Component) => (props) => {
 if (props.error) {
 return <div>Something went wrong ...</div>
 }

 return <Component {...props} />
}

export default withError
```

에러가 없는 경우, HOC가 어떻게 모든 props를 넘기는지 보자. 에러가 없는 경우에 정상적으로 작동할 것이지만, 다음 컴포넌트에 전달해야 하는 props 들이 굉장히 많으며, 이 props를 모두 신경쓰기는 어렵다.

```javascript
import * as React from 'react'

const withError = (Component) => ({ error, ...rest }) => {
 if (error) {
 return <div>Something went wrong ...</div>
 }

 return <Component {...rest} />
}

export default withError
```

위 코드 또한 `error` prop을 제거하고도 정상적으로 작동한다. 그러나 위 버전 또한 HOC를 사용하는 경우 오는 Props의 혼동을 피할 수는 없다. 전개 연산자를 사용하여 HOC에 props를 넘겨주었지만, 이 props들이 어디에 필요한지 명확히 하기가 굉장히 어렵다.

이는 HOC의 첫번째 약점이다. HOC가 어떤 컴포넌드들과 합성되어 있는지 빠르게 알 수 없기 때문에, 어떤 컴포넌에 어떤 것을 넘겨야 할지 예측이 어렵다. 예를 들어, loading 인디케이터가 있는 HOC를 하나더 만들어 보자.

```javascript
import * as React from 'react'

const withLoading = (Component) => ({ isLoading, ...rest }) => {
 if (isLoading) {
 return <div>Loading ...</div>
 }

 return <Component {...rest} />
}

export default withLoading
```

이제 두개의 HOC를 사용해야 한다면, 아래와 같이 써야할 것이다.

```javascript
const DataTableWithFeedback = compose(
 withError,
 withLoading,
)(DataTable);

const App = () => {
 ...

 return (
 <DataTableWithFeedback
 columns={columns}
 data={data}
 error={error}
 isLoading={isLoading}
 />
 );
};
```

HOC에 대해 세세히 알고 있지 않다면, 어떤 props가 어떤 HOC에 넘어가는지 알수 없다. 한단계 더 나아가 이제 데이터를 가져오는 HOC까지 있다고 가정해보자.

```javascript
const DataTableWithFeedback = compose(
 withFetch,
 withError,
 withLoading,
)(DataTable);

const App = () => {
 ...

 const url = 'https://api.mydomain/mydata';

 return (
 <DataTableWithFeedback
 url={url}
 columns={columns}
 />
 );
};
```

갑자기 `withFetch`를 사용하면서 `error`와 `isLoading`이 필요 없게 되었다. 정확히는, 아래와 같이 props가 흘러가게 된다.

```bash

App withFetch withError withLoading DataTable

 data-> data-> data-> data
url-> error-> error
 isLoading-> isLoading-> isLoading
```

`withFetch`는 내부적으로 `error`와 `isLoading`을 처리하고, 이를 위해 `withLoading`과 `withError`를 필요로 하게 된다. 이에 대한 이해가 부족할 경우 버그를 만들어낼 가능성이 존재한다.

결과적으로, HOC를 통해서 넘어가는 props는 블랙박스로 남게 되어 이를 이해하기 위해서는 꽤나 많은 주의를 기울여야 한다. HOC에 대한 자세한 이해가 없이는, HOC 들 사이에서 무슨일이 일어나고 있는지 알기 어렵다.

반면에 리액트 hook 에서는 어떻게 처리하는지 살펴보자.

```javascript
const App = () => {
 const url = 'https://api.mydomain/mydata'
 const { data, isLoading, error } = useFetch(url)

 if (error) {
 return <div>Something went wrong ...</div>
 }

 if (isLoading) {
 return <div>Loading ...</div>
 }

 return <DataTable columns={columns} data={data} />
}
```

리액트 hooks을 사용하면, 블랙박스 안으로 들어가는 `url`과 이를 통해 나오게 되는 `data`, `isLoading`, `error`를 모두 볼수 있다. `useFetch`가 어떻게 구현되어 있는지는 몰라도, 이 함수를 통해 들어가는 input과 output을 명확하게 볼 수 있다. `useFetch`가 다른 HOC와 같이 블랙박스처럼 취급 된다하더라도, 복잡했던 HOC와는 다르게 단 한줄로 모든 것을 표현하고 있다. 그러나 HOC를 합성해서 사용하는 경우 input과 output이 명확하지 않았다.

## HOC와 HOOKS: 이름 간의 충돌

만약 컴포넌트에서 두개의 prop이 사용된다면, 후자가 전자를 엎어버리게 된다. (그전에 에러가 나겠지만)

```javascript
<Headline text="Hello World" text="Hello React" />
```

만약 HOC에서 다음과 같은 일이 벌어진다면 어떻게 될까?

```javascript
const UserWithData = compose(
 withFetch,
 withFetch,
 withError,
 withLoading,
)(User);

const App = () => {
 ...

 const userId = '1';

 return (
 <UserWithData
 url={`https://api.mydomain/user/${userId}`}
 url={`https://api.mydomain/user/${userId}/profile`}
 />
 );
};
```

위 예제는 두 번의 fetch를 위해서 HOC를 합성한 예제다. 그러나 앞서 언급한 것처럼, 동일한 prop이 존재한다면 후자만 유효하게 된다. 이를 위해서, `withFetch`의 `url`을 배열로 만들었다고 가정해보자. 그렇다고해서 문제가 해결되는 것이 아니다.

- 모든 요청이 끝났을 때 `loading` 인디케이터가 사라져야 하는가?
- 하나만 실패해도 에러 페이지를 보여줘야 하는가?
- 만약 한 요청이 다른 요청에 의존하면 어떻게 되는가?

이 문제를 HOOKS로 풀어보도록 하자.

```javascript
const App = () => {
 const userId = '1';

 const {
 data: userData,
 isLoading: userIsLoading,
 error: userError
 } = useFetch(`https://api.mydomain/user/${userId}`);

 const {
 data: userProfileData,
 isLoading: userProfileIsLoading,
 error: userProfileError
 } = useFetch(`https://api.mydomain/user/${userId}/profile`);

 if (userError || userProfileError) {
 return <div>Something went wrong ...</div>;
 }

 if (userIsLoading) {
 return <div>User is loading ...</div>;
 }

 const userProfile = userProfileIsLoading
 ? <div>User profile is loading ...</div>
 : <UserProfile userProfile={userProfileData} />;

 return (
 <User
 user={userData}>
 userProfile={userProfile}
 />
 );
};
```

앞선 HOC 예제에 비해 복잡도도 줄어들고, 조건별로 처리할 수 있는 여지도 많아졌다.

HOC를 사용할 때는, 내부적으로 같은 prop 명을 사용하고 있는 컴포넌트가 있는지 조심해야 한다.

## HOC와 HOOKS: 의존성

HOC는 강력하지만, 때로는 너무 강력할 때가 있다. HOC는 부모로 부터 props를 받거나, 혹은 컴포넌트 내부에서 처리하는 방법으로 변수를 받을 수 있다. 아래 예제를 살펴보자.

```javascript
const withLoading = ({ loadingText }) => (Component) => ({
 isLoading,
 ...rest
}) => {
 if (isLoading) {
 return <div>{loadingText ? loadingText : 'Loading ...'}</div>
 }

 return <Component {...rest} />
}

const withError = ({ errorText }) => (Component) => ({ error, ...rest }) => {
 if (error) {
 return <div>{errorText ? errorText : 'Something went wrong ...'}</div>
 }

 return <Component {...rest} />
}
```

```javascript
const DataTableWithFeedback = compose(
 withError({ errorText: 'The data did not load' }),
 withLoading({ loadingText: 'The data is loading ...' }),
)(DataTable);

const App = () => {
 ...

 return (
 <DataTableWithFeedback
 columns={columns}
 data={data}
 error={error}
 isLoading={isLoading}
 />
 );
};
```

`errorText`와 `loadingText`를 각각 받아서, 에러와 로딩 문구를 커스터마이징 할 수 있도록 처리했다. 그러나 이제 props를 받는 곳이 한군데 가 더 늘어나서 혼란이 가중되었다. 만약 여기에서, `userId` 까지 필요하다면 어떻게 될까?

```javascript
const UserWithData = compose(
 withFetch(props => `https://api.mydomain/user/${props.userId}`),
 withFetch(props => `https://api.mydomain/user/${props.userId}/profile`),
)(User);

const App = () => {
 ...

 const userId = '1';

 return (
 <UserWithData
 userId={userId}
 columns={columns}
 />
 );
};
```

만약 여기서 더 나아가 두번째 요청이 첫번째 요청에 의존적이라고 한다면 어떻게 될끼?

```javascript
const UserProfileWithData = compose(
 withFetch(props => `https://api.mydomain/users/${props.userId}`),
 withFetch(props => `https://api.mydomain/profile/${props.profileId}`),
)(UserProfile);

const App = () => {
 ...

 const userId = '1';

 return (
 <UserProfileWithData
 columns={columns}
 userId={userId}
 />
 );
};
```

HOC간에 강한 연결을 만들어 문제를 해결했지만, HOC간에 강결합을 통해서 문제를 해결하는 것은 굉장히 어렵고 혼란이 가중된다.

그러나 Hooks을 쓰면 더 쉽게 해결할 수 있다.

```javascript
const App = () => {
 const userId = '1';

 const {
 data: userData,
 isLoading: userIsLoading,
 error: userError
 } = useFetch(`https://api.mydomain/user/${userId}`);

 const profileId = userData?.profileId;

 const {
 data: userProfileData,
 isLoading: userProfileIsLoading,
 error: userProfileError
 } = useFetch(`https://api.mydomain/user/${profileId}/profile`);

 if (userError || userProfileError) {
 return <div>Something went wrong ...</div>;
 }

 if (userIsLoading || userProfileIsLoading) {
 return <div>Is loading ...</div>;
 }

 return (
 <User
 user={userData}>
 userProfile={userProfileData}
 />
 );
};
```

Hook은 오직 함수형 컴포넌트에서만 직접적으로 쓰이기 때문에, 데이터를 넘기기 유용하다. 또한 블랙박스가 존재하지 않고, custom hook간에 데이터를 넘기는 ㄴ것 또한 명확하게 볼 수 있다. 의존성이 있는 경우에는, hook을 쓰는 것이 더 코드에 많은 이점을 가져올 수 있다.

HOC는 좋지만, hooks을 사용하는 습관을 기르자.

yceffort

HTTP Cache로 불필요한 네트워크 요청 줄이기

왜 Async 보다는 Defer를 써야할까

크롬에서 자바스크립트 로딩 순서

Prop drilling 해결을 위해 context를 사용하기 전에 구조를 생각해보자.

리액트의 Hooks과 HOC, HOC의 사용이 복잡해지는 경우