## Table of Contents

## Introduction

[이전 글](/2021/11/journey-from-server-to-client)에서는 브라우저에서 서버로 URL이 전송되었을 때 어떻게 처리하는지, 그리고 관련 리소스 전달을 위해 어떻게 최적화 되고 있는지 등에 대해 알아보았다. 이제 데이터가 왔으니, 브라우저 엔진이 이 리소스를 렌더링하여 웹 페이지로 만들어야 한다. 어떻게 하면 HTML을 화면에 만들 수 있는 페이지로 만드는지 살펴보자.

## Parsing

네트워크를 통해서 서버에서 클라이언트로 리소스가 전달되면 이를 변환하는 작업이 필요하다. 가장 첫번째로 일어나는 일은 HTML 파서로, 여기에서 인코딩, pre-parsing, 토큰화 (tokenization), 트리 구조 변환 등을 처리한다.

### 1. Encoding

http 응답은 HTML 텍스트에서 이미지에 이르기 까지 모든 것이 될 수 있다. 파서가 첫번째로 해야 하는 일은 방금 응답으로 밭은 바이트를 해석하는 방법을 알아내는 것이다. HTML 문서를 처리한다고 가정해보자. HTML 문서를 처리하기전에, 디코더는 텍스트 문서가 어떻게 바이트로 변환되었는지 확인해야 한다.

> 텍스트도 사실 컴퓨터에서 바이너리로 변환을 해야 컴퓨터가 읽을 수 있다는 사실을 기억해야 한다.

텍스트를 어떻게 디코딩 해야 하는지 알아내는 것은 브라우저가 해야할 일이다. 서버는 `Content-Type` 헤더로 브라우저에 이 콘텐츠에 대한 힌트를 줄 수 있으며, [BOM](https://en.wikipedia.org/wiki/Byte_order_mark)을 통해서 맨 앞 비트를 가지고 분석을 할 수도 있다. 그럼에도 브라우저가 인코딩 할 수 없을 경우에는, 브라우저는 휴리스틱을 활용하여 최선의 인코딩을 분석할 수 있다. 혹은 html 태그에서 `<meta />` 태그로 인코딩된 콘텐츠에서 발견할 수도 있다. 최악의 경우, 브라우저가 일단 추측을 한다음, 파싱이 본격적으로 시작된 후로 이 인코딩에 대한 정보가 담겨있는 `<meta />` 태그를 발견할 수도 있다. 이러한 경우에는 이전까지 디코딩한 콘텐츠를 다 버리고 다시 처음부터 시작해야 한다. 브라우저는 종종 오래된 웹 콘텐츠 (레거시 인코딩으로 된)를 처리할 때가 있는데, 이러한 페이지들이 이런 방식으로 처리되고 있다.

### 2. Pre-parsing 및 scanning

인코딩을 확인하게 되면, 추가 리소스에 대한 왕복 딜레이를 최소화 하기 위해, 콘텐츠를 스캔하기 위한 initial pre-parsing을 시작하게 된다. 이 pre-parser는 완전한 파서로 보기는 어렵다. 왜냐하면 HTML이 얼마나 중첩되어 있는지, 그리고 부모-자식 관계는 무엇인지 확인하지 못하기 때문이다. 하지만 특정 HTML 태그의 속성 등을 파악할 수는 있다. 예를 들어 HTML 콘텐츠 어딘가에

```html
<img src="https://somewhere.example.com/images/dog.png" alt=">
```

가 있다고 가정하자.

이 pre-parser는 이 `src`의 값을 확인하고 이 리소스 값을 리소스 요청 대기열에 집어 넣어준다. 이렇게 함으로써 이미지를 최대한 빨리 요청할 수 있고, 이미지가 도착하는데 까지 걸리는 시간을 최소화 할 수 있다. 이외에도 [preload](https://developer.mozilla.org/en-US/docs/Web/HTML/Preloading_content)나 [pre-fetch 지시자](https://developer.mozilla.org/en-US/docs/Web/HTTP/Link_prefetching_FAQ)와 같은 것들을 확인하여 대기열에 집어 넣어줄 수 있다.

#### Tokenization

토큰화는 HTML 파싱 과정 중 하나로, 마크업을 `begin tag` `end tag` `text run` `comment` 등과 같은 개별 토큰으로 변환하여, 파서의 다음 상태로 만들어 준다. `tokenizer`는 상태 머신으로, HTML 언어의 서로다른 상태를 처리해준다. `|`를 이 상태 머신이 처리하는 과정이라고 간주해보자.

- `<|video controls>`: 태그가 열려 있는 상태임
- `<video con|trols>`: 태그의 `controls`이라고 하는 속성을 파악
- `<video controls|>`: 태그가 닫혀있음.

이렇듯 `tokenizer`는 문자를 읽을 때 마다 반복적으로 태그의 상태를 파악하는 역할을 한다.

![tokenization](https://i0.wp.com/alistapart.com/wp-content/uploads/2018/10/fig2.png?w=960&ssl=1)

[HTML 스펙 문서](https://html.spec.whatwg.org/multipage/parsing.html)를 살펴보면 `tokenizer`를 위해서 대략 80여개의 상태를 정의해둔다. 텍스트의 내용이 유효한 HTML 콘텐츠가 아니라도, 텍스트 컨텐츠를 처리하고 HTML 문서로 변환할 수도 있다. 이와 같은 탄력성은 개발자들이 쉽게 웹 개발을 할 수 있도록 해주는 특징이다. 그러나 이러한 탄력성이 예상치 못한 결과를 야기할 수도 있으며, 이로 인해 미묘한 버그가 발생할 수도 있다. HTML validator로 한번 검사하면 이러한 실수를 사전에 방지 할 수 있다.

마크업 언어 정확성에 엄격하게 대응하기 위해, 어떠한 실패라도 렌더링하지 못하게 막는 메커니즘이 있다. 이 parsing module은 [HTML을 처리할 때 XML규칙을 사용](https://en.wikipedia.org/wiki/XHTML)하며, 문서를 `application/xhtml+xml` 유형으로 브라우저에 전송하면 된다.

브라우저는 이 pre-parser단계와 tokenization 단계를 최적화를 위해서 한꺼번에 수행할 수도 있다.

### 3. 파싱 및 트리 구조화

브라우저는 웹 페이지 내부(메모리)에 표현할 무언가가 필요한데, 이를 정의하는 것이 [DOM 표준](https://dom.spec.whatwg.org/)이며, 이 스펙에서 어떻게 어떤 형태로 표현해야하는지 정의한다. 여기서 파서가 할 일은, 이전에 tokenizer가 만든 토큰을 가져와서 적절한 방식으로 만든 다음, Document Object Model(DOM) 객체에 삽입하는 것이다. DOM은 우리가 알다시피 트리 데이터 구조로 생성되므로, 이 프로세스를 [트리 구조화](<https://en.wikipedia.org/wiki/Tree_(data_structure)>) 라고도 한다.

> 놀랍게도 IE는 역사적으로 봤을 때 이를 트리구조로 사용한 적이 별로 없다. https://blogs.windows.com/msedgedev/2017/04/19/modernizing-dom-tree-microsoft-edge/

![DOM tree](https://i1.wp.com/alistapart.com/wp-content/uploads/2018/10/fig3.png?w=960&ssl=1)

HTML 파싱은 그 구조가 꽤 복잡하다. 그 이유는 앞서 언급한 것 처럼, 레거시 HTML 콘텐츠를 오늘날의 브라우저와 호환 가능하도록 구조를 유지하는 선에서 지원해야 하기 때문이다. 예를 들어, 대다수의 HTML 태그에는 끝 태그 문자 `/>`가 존재한다. 따라서 브라우저는 자동으로 해당 태그와 일치하는 태그를 닫을 수 있다. 아래 예시를 살펴보자.



```html
<p>sincerely<p>The authors</p>
```



파서는 위와 같은 ~~개같은~~ 구조를 암시적으로 종료 태그로 작성하는 규칙을 가지고 있다. 파서는 위 코드를 아래와 같이 변환한다.

```html
<p>sincerely</p>
<p>The authors</p>
```

이러한 규칙 덕분에, 자동으로 두 `<p/>` 태그가 형제 형태로 자리잡을 수 있게 되었다. parser의 규칙 중에서, HTML 테이블은 아마도 적절한 표 구조를 가질 수 있도록 보장하기 위한 가장 복잡한 규칙일 것이다.

이러한 복잡한 파싱 규칙을 일단 거치고 나면, 일단 DOM 트리가 만들어지고 나면 더 이상 이 규칙은 실행되지 않는다. 예를 들어, 자바스크립트를 사용하여 DOM트리르 마구잡이로 이상한 형태로 만들어 낼수도 있다. (비디오 태그에 테이블 셀을 집어 넣는다던지...) 따라서 렌더링 시스템은 이와 같은 모순된 상황에 대처하는 방법을 알아야 한다.

HTML 파싱을 복잡하게 하는 또다른 요인 중 하나는, 파서가 작업을 수행하는 동안 자바스크립트가 또 파싱해야할 콘텐츠를 추가할 수 있다는 것이다. `<script/>` 태그 내부에는 파서가 수집하고 다시 스크립팅 엔진에 보내야 하는 text를 포함하고 있다. 스크립트 엔진이 스크립트 텍스트를 구분분석하고, 평가하는 동안 parser는 기다린다. 만약 여기에서`document.write` API를 호출하는 경우, 또다시 HTML 파서가 실행되어야 한다. 건축 과정에 비유하자면, `<script/>`와 `document.write`는 공사작업을 하던 도중에 갑자기 무언가 필요한게 생각 나서 모든 작업을 중단하고 필요한 것을 사러가는 행위다. 이렇게 무언가를 사러나는 동안, 모든 공사작업은 중단된다.

### 4. 이벤트

parser가 끝나면, `DOMContentLoaded`라는 이벤트가 실행된다. 이벤트는 자바스크립트가 듣고 응답할 수 있는, 브라우저에 내장된 일종의 브로드캐스팅 시스템이다. `DOMContentLoaded`와 마찬가지로, 웹 페이지에는 다양한 이벤트 - `load` (파싱이 수행되고, 이미지, CSS, 비디오 등 파서가 요청한 모든 리소스가 다운로드 됨), `unload` (웹 페이지가 닫힐 예정임을 의미) - 가 존재한다. 대다수의 이벤트는 사용자가 화면을 터치하는 행위, 마우스를 사용하는 행위, 키보드를 사용하는 행위 등 사용자 입력으로 이루어져있다.

브라우저는 DOM에 이벤트 객체를 만들고, 이와 관련된 유용한 상태 정보 (화면 터치 위치, 눌린 키보드 등)의 정보를 가지고 이벤트를 실행한다. 이벤트를 수신하는 모든 자바스크립트 코드가 이밴트 객체와 함께 실행된다.

DOM 트리 구조는 트리의 모든 레벨(위치)에서 이벤트를 리슨할 수 있도록 함으로서, 코드가 얼마나 자주 이벤트에 자주 반응할지를 필터링할 수 있게 해준다. 브라우저는 먼저 트리에서 이벤트를 실행할 위치 (`<input/>` 과 같은 DOM 객체)를 결정한 다음, 트리의 루트 부터 시작하여 각 분기 (`<input/>`에 도달할 때 까지)를 거쳐 루트로 돌아가는 이벤트를 위한 일종의 경로를 계산한다. 격로에 있는 각 객체는 이벤트 리스터를 트리거하여, 결국에는 트리의 루트에 있는 리스너가 많은 이벤트를 볼 수 있게 해준다.

![이벤트 흐름](https://i0.wp.com/alistapart.com/wp-content/uploads/2018/10/fig4.png?w=960&ssl=1)

이 중 일부 이벤트는 취소 할 수도 있다. 예를 들어, form이 제대로 작성되지 않은 경우 form submit을 취소할 수도 있다.

### 5. DOM

HTML 은 파서가 처리할 수 있는 마크업의 범위를 훨씬 뛰어 넘는, 많은 기능을 제공한다. 파서는 어떤 element가 다른 element를 가지고 있는지, 어떤 attribute를 가지고 있는지 정도 수준의 구조를 구축한다. 이러한 구조와 상태를 조합하면, 기본적인 렌더링과 사용자가 인터랙션을 할 수 있는 환경을 제공하기에 충분하다. 그러나 CSS와 자바스크립트가 없다면 웹 페이지는 매우 단조로워 보일 것이다. DOM은 HTML의 엘리먼트와 HTML과 전혀 관련 없는 다른 객체들에 추가적인 기능을 제공한다.

#### element

파서는 트리에 넣을 객체를 만들때, 엘리먼트의 이름 (네임 스페이스)을 조회하고, 객체를 감싸기 위해 이와 일치하는 HTML 인터페이스를 찾는다.

인터페이스는 엘리먼트의 특징에 따라서 몇가지 기능을 추가한다. 이중 몇가지 기능을 사렾보자면

- 특정 엘리먼트의 하위 항목 전체 또는 일부를 나타내는 HTML Collection에 접근할 수 있는 기능
- 엘리먼트의 속성, 하위, 혹은 상위 엘리먼트를 검색하는 기능
- 새로운 엘리먼트를 만들고 (파서 없이) 트리에 붙이거나 분리하는 기능

`<table/>`과 같은 특정 엘리먼트의 경우, 태이블 내의 모든 행, 열, 셀을 찾기 위한 테이블 고유 기능 뿐만 아니라, 테이블에서 행과 셀을 제거하고, 추가하기 위한 기능들도 제공한다. `<canvas/>`에는 선, 도형, 텍스트 및 이미지를 그릴 수 있는 기능이 제공된다. 이러한 Api를 사용하기 위해서는, HTML 마크업만으로는 불가능하며, 자바스크립트를 사용한다.

위에서 설명한 api로 트리에 DOM을 변경하면, 이에 대한 변경 및 업데이트를 분석하는 작업이 브라우저에서 시작된다. 화면에 보이는 것을 최대한 빨려 보여주기 위해 노력한다. 이 트리는 이러한 반복적인 업데이트를 빠르고 효율적으로 만들기 위한 다음과 같은 최적화 기능을 활용한다.

- common 엘리먼트의 이름과 속성을 숫자로 접근 (빠른 식별을 위해 해시테이블 활용)
- 엘리먼트에서 자주 사용되는 하위 항목을 캐시 (빠른 하위 항목 iteration을 위해)
- 하위 트리의 변경이 전체트리의 변경으로 이어지지 않도록 변경을 최소화

#### 다른 api

HTML 엘리먼트와 DOM 내부의 HTML 인터페이스는 화면에 콘텐츠를 표시하는 브라우저의 유일한 메커니즘이다. CSS는 레이아웃에 영향을 미칠 수 는 있지만, HTML 엘리먼트에 존재하는 컨텐츠에 대해서만 영향을 미칠 수 있다. 궁극적으로 화면에서 콘텐츠를 보기 위해서는, 트리의 일부인 HTML 인터페이스를 통해야 한다.

지금까지는 파서가 어떻게 서버에서 가져온 HTML을 DOM 트리로 가져왔는지를 살펴보았으며, 그리고 DOM 내부의 엘리먼트 인터페이스를 사용하여 트리에 추가, 제거, 수정을 할 수 있는 지 알아보았다. 그러나 브라우저의 프로그래밍 가능한 DOM은 상당히 방대하며, 이는 HTML 엘리먼트 인터페이스에만 국한되는 것은 아니다.

브라우저의 DOM의 스코프는 앱이 OS에서 사용할 수 있는 기능들과 유수한 수준의 기능들을 가지고 있다. 예를 들어

- 스토리지 시스템에 접근 (데이터베이스, key/value 스토리지, 네트워크 캐시 스토리지)
- 디바이스에 접근 (geolocation, 근접 및 방향 센서, USB, MIDI, 블루투스 등)
- 네트워크 (http, 양방향 서버 소켓, 실시간 미디어 스트리밍)
- 그래픽 (2d, 3d, 쉐이더, 가상 및 증강 현실)
- 멀티스레딩 등등..

DOM에 의해 제공되는 기능은 주요 브라우저 엔진에 의해 새로운 웹 표준이 개발되고, 브라우저가 점차 이 기능을 구현해 나가면서 증가하고 있다.

HTML 문서에서 DOM으로의 여정

## Table of Contents

## Introduction

브라우저에서 웹사이트를 보여주기 위해 무언가를 하기전에, 먼저 브라우저가 어디로 가는지 알아야 한다. 주소 표시줄에 URL을 입력하거나, 페이지 또는 다른 앱의 링크를 클릭하거나, 즐겨찾기를 클릭하는 등 다양한 방법으로 웹사이트에 접근할 수 있다. 어떤 경우든, 결국 `navigation`이라는 과정이 일어나게 된다. 소위 이 탐색이라는 과정은, 웹 사이트를 상호작용하는 과정의 첫 번째 단계이며, 이 후에 웹 페이지 로드에 필요한 이벤트가 연쇄적으로 일어난다.

## 최초 요청

브라우저에 로딩해야할 URL이 주어지면, 아래 몇가지 일이 일어난다.

### HSTS 확인

> https://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security

먼저 쁘라우저는 URL이 HTTP 방식을 지정하는지를 확인해야 한다. 만약 HTTP 요청이라면, 브라우저는 도메인이 [HSTS](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Strict-Transport-Security) 목록에 있는지 확인 해야 한다. 이 목록은 사전에 로딩한 목록과 HSTS를 사용하도록 선택되어진 이전에 방문한 사이트 목록으로 구성되어 있으며, 두 사이트 목록 모두 브라우저에 저장된다. 요청된 HTTP 호스트가 HSTS 목록에 저장되어 있는 경우, HTTP 대신 HTTPS 버전의 URL로 요청이 이루어진다. 그렇기 때문에 브라우저에 http://yceffort.kr 를 입력해도 https://yceffort.kr 로 대신 보내진다.

### 서비스워커 확인

다음 부터는, 브라우저는 [서비스 워커](https://developer.mozilla.org/en-US/docs/Web/API/Service_Worker_API)가 요청을 처리할 수 있는지 확인해야 한다. 이 서비스 워커는 사용자가 오프라인 상태이고, 네트워크 연결이 없을 때 특히 중요하다. 서비스 워커는 비교적 최근에 나온 기능이다. (라고 하기엔 나온지는 꽤 되었지만) 서비스 워커는 오프라인에서도 웹 사이트를 사용할 수 있도록 네트워크 요청을 차단하고 [캐시](https://developer.mozilla.org/en-US/docs/Web/API/Cache)에서 처리할 수 있도록 도와준다.

서비스 워커는 페이지를 방문했을 때, [서비스 워커 등록 및 로컬 데이터 베이스에 URL 매핑을 기록할 수 있다.](https://www.w3.org/TR/service-workers-1/#dfn-scope-to-registration-map) 서비스 워커가 설치되었는지 여부를 확인하는 것은 데이터베이스에서 이전에 탐색한 적이 있는 URL을 조회하는 것 만큼이나 간단하다. 지정된 URL에 서비스 워커가 있는 경우, 요청에 대한 응답을 처리할 수 있다. 브라우저에서 [Navigation Preload](https://developers.google.com/web/updates/2017/02/navigation-preload#the-solution)를 사용할 수 있고, 사이트가 이 기능을 활용할 수 있는 경우, 브라우저는 초기 네비게이션 요청을 위해 네트워크를 동시에 참조한다. 이는 브라우저가 서비스 워커가 느려서 요청을 차단하지 않도록 하기 때문에 유용하다.

초기 요청을 처리한 서비스 워커가 없는 경우 (또는 Navigation Preload가 이미 사용 중인 경우) 브라우저는 네트워크 계층을 참조하기 시작한다.

### 네트워크 캐시 확인

브라우저는 네트워크 계층을 통해 캐시에 새로운 응답이 있는지 확인 한다. 일반적으로 이는 응답의 [Cache-Control](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cache-Control) 헤더에 의해 정의된다. `max-age` 으로 캐시된 항목이 얼마나 유효한지 정의할 수 있으며, `no-store`로 저장되지 않는 캐시를 정의할 수도 있다. 그리고 물론, 브라우저가 네트워크 요청의 캐시에서 아무것도 확인할 수 없는 경우에는, 네트워크 요청이 필연적으로 필요하다. 이후에 약 캐시에 새로운 응답이 있을 경우, 페이지를 로드하기 위해 리턴된다. 리소스가 발견되었지만, 굳이 새로운 리소스가 필요하지 않은 경우, 브라우저는 이 요청을 조건부 재평가 요청 (conditional revalidation request) 으로 반환할 수 있다. 여기에는 브라우저가 캐시에 이미 있는 콘텐츠 버전을 서버에 알리는 `If-Modified-Since` `If-None-Match` 헤더가 포함된다. 서버는 응답 없이 HTTP 304를 반환하여 사본이 여전히 유효하다는 것을 알리거나, 새 버전의 리소스와 함께 200 응답을 반환하여 사본이 오래된 것임을 브라우저에 알릴 수도 있다.

### 연결 확인

호스트 및 특정 포트에 대해 이전에 설정되어있는 연결이 있는 경우, 새 연결을 설정하는 대신에 이전 연결을 계속해서 사용하게 된다. 이전 연결이 없는 경우에는, 브라우저는 네트워크 레이어를 참조하여 [DNS](https://ko.wikipedia.org/wiki/%EB%8F%84%EB%A9%94%EC%9D%B8_%EB%84%A4%EC%9E%84_%EC%8B%9C%EC%8A%A4%ED%85%9C) 조회가 필요한지 파악한다. 이 작업에는 로컬 DNS 캐시를 살펴보는 작업도 포함되며, 캐시의 유통기한에 따라서 리모트 네임 서버도 참조할 수 있으며 (인터넷 서비스 공급자가 호스팅 하는 경우), 이 과정을 거치게 되면 브라우저가 연결 할 수 있는 올바른 IP 주소를 얻게 된다.

경우에 따라 브라우저가 접근할 도메인을 미리 예측할 수도 있으며, 예측 가능한 경우 이 도메인에 대한 연결이 준비 될 수도 있다. 링크 태그의 `rel="preconnect"`와 같은 [리소스 힌트](https://www.w3.org/TR/resource-hints/)를 사용하여 이후에 연결을 할 도메인에 대해 브라우저에 힌트를 제공할 수 있다. 예를 들어, 구글에 검색 결과가 나왔다고 가정해보자. 구글 사이트 입장에서, 사용자는 최상단 몇개 정도의 사이트에 사용자가 접근할 예정이라고 가정할 수 있다. 이 경우 해당 도메인에 대한 링크를 준비해두면 나중에 해당 링크를 클릭할 때 DNS를 조회하고, 연결설정을 하는등의 비용을 지불할 필요가 없다.

### 연결

이제 브라우저는 드디어 서버와 연결을 설정할 수 있으므로, 서버는 클라이언트로부터 송수신이 일어날 것을 알 수 있다. TLS를 사용하는 경우, 서버에서 제공하는 인증서의 유효성을 확인하기 위해 TLS 핸드셰이크를 수행해야 한다.

### 서버에 요청 보내기

이 연결을 통과하는 첫 번째 요청은 바로 최상위 (루트) 페이지 요청이다. 일반적으로 이 파일은 서버에서 클라이언트로 제공되는 HTML 파일이다.

### 응답 다루기

클라이언트로 데이터가 스트리밍 되면서, 이제 응답 데이터를 분석하게 된다. 먼저 브라우저는 [응답의 헤더](https://developer.mozilla.org/en-US/docs/Glossary/Response_header)를 확인한다. [HTTP 헤더](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers)는 HTTP 응답의 일부로 발송되는 일련의 `key:value` 쌍이다. 여기에서 응답 헤더가 `Location Header` 등을 활용해 리다이렉트를 지정하는 경우, 브라우저는 탐색 프로세스를 다시 시작하고, 여기서 언급한 첫번째 단계로 돌아간다.

서버 응답이 압축되어 있는 경우, 브라우저는 이 압축을 해제하려고 시도한다.

다음으로, 브라우저는 브라우저로 전송되는 파일의 MIME 유형을 파악하여 파일 로드 방법을 적절하게 해석할 수 있게 된다. 예를 들어 HTML이 파싱 및 렌더링 되는 동안 이미지 파일이 이미지 파일은 이미지 그 자체로 로드 된다. HTML 파서가 실행되면, 응답에서 다운로드 될 가능성이 있는 리소스의 URL을 검색하여, 브라우저에서 페이지를 렌더링하기 전에 미리 다운로드를 시작할 수 있다.

이 때, 요청된 URL이 브라우저 히스토리에 입력되어 브라우저의 앞, 뒤 버튼으로 탐색이 가능해진다.

여기까지 다룬 내용을 플로우 차트로 살펴보자.

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

페이지에는 이미지, 자바스크립트, 스타일 시트를 필요하여 페이지를 꾸미는데 필요한 다양한 하위 리소스가 있기 때문에 페이지는 계속해서 요청을 한다. 또한 백그라운드 이미지 (css), `fetch()` `import()` 또는 ajax 호출로 인해 시작된 리소스 등 호출이 필요한 다양한 리소스들이 존재한다. 이것들이 없다면 우리는 별다른 상호작용을 할 수 없는 평범한 페이지만 보게 될 것이다. 이렇게 요청한 리소스는 브라우저의 캐싱 정책에 의하여 부분적으로 영향을 받는다.

## 캐싱

앞서 계속해서 언급했던 것 처럼, 브라우저는 네트워크 캐시를 관리하며 이는 이전에 다운로드 한 리소스를 재사용할 수 있게 도와준다. 이는 특히 로고나, 자바스크립트의 프레임워크와 같이 잘 변하지 않는 리소스에 매우 유용하다. 로컬에서 사용 가능한 캐시 리소스를 확인하고 재사용하는 것이, 네트워크 요청을 줄이는데 도움을 줄 수 있으므로 최대한 캐시를 활용해야 한다. 이는 결과적으로 번거로운 작업을 최소화 하여 페이지 로딩 시간을 단축하는데 많은 도움을 준다.

물론, 네트워크 캐시는 저장될 아이템의 개수와 저장 기간을 가지고 있다. 이 것은 웹 사이트가 이 문제를 컨트롤 할 수 없다는 것을 의미한다. 응답의 `Cache-control` 헤더는 브라우저의 캐시 로직을 제어 한다. 경우에 따라 캐시 하지 않는 것이 좋을 때도 있다. (`Cache-Control: no-store`) 어떤 경우에는 브라우저가 무기한 캐시하는 것이 좋을 수도 있다. (`Cache-Control: immutable`) 이 경우 캐시된 버전으로만 사용되므로, 동일한 URL의 리소스를 변경하는 대신, 다른 URL을 지정해줘서 다른 버전을 사용하도록 자연스럽게 유도하는 것이 좋다.

물론 네트워크 캐시가 브라우저가 할 수 있는 유일한 캐시는 아니다. 자바스크립트를 활용해서도 캐시를 구현할 수 있다. (프로그래밍 캐시) 위에서 언급했던 서비스 워커에서, 최상위 페이지에 대한 초기 리소스 요청은, 서비스워커가 이 요청을 인터셉터 한 다음 프로그래밍 캐시로 정의된 리소스를 대신 사용하게 할 수 잇다. 이는 웹 사이트가 캐시된 아이템을 언제 사용할 수 있는지 더 원활하게 제어할 수 있기 때문에 유용하다. 이러한 캐시는 `origin`을 기준으로 묶이며, 이는 곧 다른 도메인이 다른 도메인의 캐시로부터 분리된 제어 가능한 고유한 샌드박스 캐시 집합을 가지고 있음을 의미하기도 한다.

## Origin

origin은 데이터를 샌드박스로 만들고 보호하는 방법을 정의내릴 수 있는 중요한 브라우저의 개념 중 하나다. 대부분의 경우 보안을 위해 브라우저는 same-origin policy를 적용한다. 한 origin이 다른 origin에 접근할 수 없다.

만약에 `yceffort.kr`이 `yceffort1.kr`이라는 다른 origin의 자바스크립트 파일을 요청하고자 한다면, 이는 cross-origin 리소스 요청이 되는 것이다. 이를 해결하기 위해서는, `yceffort.kr`을 위해 `yceffort1.kr`이 [CORS 헤더](https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS)를 지정해줘야 한다.

> origin에 대한 정리는 [여기](/2020/09/referer-and-referrer-policy#origin)에 잘 나와있습니다


서버에서 클라이언트로의 여정 - 브라우저와 서버는 어떻게 데이터를 주고 받을까

## Introduction

오늘날 웹 환경은 우리가 생각하는 것 보다 더 빠르게 성장할 것을 요구하고 있다. 이러한 압박으로 부터 자유롭기 위해, 우리는 가능한 생산적인 수단을 사용해야 한다. 이 말을 다르게 풀어보자면, 웹 애플리케이션을 구축할 때 오버헤드를 만들거나, 성능과 접근성을 저해할 수 있는 패턴을 반복적으로 사용할 가능성도 거친다.

웹 개발은 오늘날 많은 뉴비 개발자들이 뛰어들고 있는 가장 '쉬워 보이는' 개발이지만, 사실 그렇게 쉬운 영역은 아니다. (물론 진입장벽을 치기 위해서 하는 말은 아니다) 다들 쉽게 웹 개발을 시작하지만, 다들 하다보면 첫 개발부터 무언가 완벽하지 않다는 것을 깨닫게 된다. 물론 처음부터 완벽할 필요는 없다. 우리는 그 이후에 개선을 해나갈 수 있으며, 여기서 하고자 하는 말은 그 '개선'에 관한 것이다. 완벽은 아직 멀었다.

## 최적화 목록 점검하기

### 트리쉐이킹

먼저 자신이 속한 웹 개발 환경이 트리쉐이킹을 효과적으로 하고 있는지 확인해봐야 한다. 트리쉐이킹에 관한 글은 많다. 트리쉐이킹에 한번더 요약하자면, 사용되지 않는 코드를 프로덕션 번들에서 제거하는 과정이다.

- https://yceffort.kr/2021/08/javascript-tree-shaking
- https://yceffort.kr/2020/07/how-commonjs-is-making-your-bundles-larger
- https://ui.toast.com/weekly-pick/ko_20180716
- https://developers.google.com/web/fundamentals/performance/optimizing-javascript/tree-shaking

트리쉐이킹은 webpack, rollup, parcel과 같은 도구를 사용하면 즉시 해결할 수 있다. (번들러가 아닌 태스트러너인 grunt나 gulp는 도움이 되지 않는다.) 트리쉐이킹을 효과적으로 하기 위해서는, 아래 지침을 따라야 한다.

1. 애플리케이션 로직과 프로젝트에 설치하는 패키지를 모두 ES6로 작성하거나 활용해야 한다. CommonJS를 트리쉐이킹하는 것은 현실적으로 불가능하다.
2. 번들러가 빌드시에 ES6 모듈을 다른 모듈 형식으로 변환해서는 안된다. babel에서 이러한 상황이 발생하는 경우, es6코드가 commonjs로 변환하지 않도록 [@babel/preset-env 설정](https://babeljs.io/docs/en/babel-preset-env)을 반드시 [modules: false](https://babeljs.io/docs/en/babel-preset-env#modules) 로 해야 한다.

트리쉐이킹의 효과는 애플리케이션 개발 환경마다 조금씩 차이가 있을 수 있다. 또한 import하는 module이 [side effect](<https://en.wikipedia.org/wiki/Side_effect_(computer_science)>)를 도입하느냐에 따라 달라지기도 하는데, 이는 사용하지 않는 `exports`를 제거하는 번들러에 영향을 미칠 수 있다.

### 코드 스플릿

아마도 어떤 형식으로든 코드스플릿을 쓰고 있을 가능성이 높지만, 어떻게 동작되고 있는지 다시 한번 살펴볼 필요가 있다. 코드 스플릿 방법에 관계 없이, 코드 스플릿에 대해서 다음과 같은 질문에 대해 답할 수 있어야 한다.

https://developers.google.com/web/fundamentals/performance/optimizing-javascript/code-splitting/

1. 코드 [entry point](https://webpack.js.org/concepts/entry-points/) 간에 중복 코드를 제거 하고 있는지?
2. [dymaic import()]()를 사용하여 레이지 로딩을 하고 있는지?

중복 코드를 줄이는 것은 성능에 매우 필수적이므로 꼭 해야 한다. 레이지 로딩은 첫 페이지의 초기 자바스크립트 용량을 줄임으로써 성능을 향상 시킨다. 또한 [Bundle Buddy](https://github.com/samccone/bundle-buddy)와 같은 도구를 사용하면 문제가 있는지 확인할 수도 있다.

레이지 로딩을 어디서 부터 손봐야할지 살펴보는 것은 다소 어려울 수도 있다. 기존 프로젝트에서 레이지 로딩을 적용할 곳을 찾을 때에는, 먼저 클릭이나 키보드 이벤트 등 코드 베이스 전반에 걸쳐 사용자 인터랙션 포인트가 발생하는 곳을 찾는 것이 좋다. 사용자 상호작용으로 실행 되는 코드들은 `dynamic import`를 사용하기에 적합한 후보다.

데이터 사용량이 큰 문제가 아니라면 [rel=prefetch](https://www.w3.org/TR/resource-hints/#prefetch) 리소스 힌트를 사용하여 낮은 우선순위로 스크립트를 로드할 수도 있다. 설령 [이 리소스 힌트를 지원하지 않는 브라우저](https://caniuse.com/link-rel-prefetch)라 하더라도 어차피 마크업 상에서 무시되기 때문에 크게 신경쓰지 않아도 된다.

### 써드 파티 코드 분석

웹 애플리케이션을 구성할 때, 가능한 사이트의 의존적인 리소스는 자체적으로 호스팅하는 것이 좋다. 어떤 이유로든지 제3자로부터 리소스를 가져와야 할 경우, [번들러 구성에서 이를 externals로 표시](https://webpack.js.org/configuration/externals/)하는 것이 좋다.그렇지 않으면 웹 사이트 방문자가 로컬에 있는 코드와 똑같은 코드를 써드파티로 부터 다운로드 할 수도 있다.

예를 한가지 들어보자. 만약 사이트에서 public CDN에서 lodash를 불러온다고 가정해보자. 그리고 내 프로젝트 개발을 하기 위해 로컬에서 lodash를 설치했다. 그러나 lodash를 external로 표시하지 않을 경우, 프로덕션 번들링에 lodash가 또 들어가버리게 될 것이다.

써드파티 의존성을 자체적으로 호스팅해야할지 확인이 없다면 [dns-prefetch](https://css-tricks.com/prefetching-preloading-prebrowsing/#dns-prefetching), [preconnect](https://css-tricks.com/prefetching-preloading-prebrowsing/#preconnect) [preload](https://www.smashingmagazine.com/2016/02/preload-what-is-it-good-for/)을 도입해보는 것을 검토해보자. 이렇게하면 [사이트가 인터랙션이 가능해지는 시간](https://developers.google.com/web/tools/lighthouse/audits/time-to-interactive)을 낮출수도 있고, 만약 사이트의 콘텐츠를 렌더링하는게 중요하다면 [Speed Index](https://developers.google.com/web/tools/lighthouse/audits/time-to-interactive)에도 좋은 영향을 미칠 수 있다.

### 오버헤드를 줄이기 위한 또다른 방법

자바스크립트 생태계는 마치 엄청나게 큰 시장과도 같고, 개발자로서 우리는 오픈소스가 제공하는 다양한 코드에 때로는 경외심을 느끼기도 한다. 프레임워크와 라이브러리를 활용해 애플리케이셔늘 확장하는데 들어가는 시간과 노력을 줄이고, 모든 작업을 신속하게 마무리할 수도 있다.

개인적으로는 프로젝트에서 프레임워크와 라이브러리의 사용을 최소화 하는 것을 선호하지만, 솔직히 이를 사용하는 것은 아주 큰 유혹으로 느껴지기도 한다. 하지만 우리는 패키지를 설치함에 있어 항상 비판적인 자세를 유지할 필요가 있다.

리액트는 아주 정말로 유명하지만 서도, [Preact](https://preactjs.com/)는 리액트보다 더 작고, 대부분의 API를 공유하고 있으며, 리액트 애드온 등으로 호환성도 유지할 수 있다. [Luxon](https://moment.github.io/luxon/#/)과 [date-fns](https://date-fns.org/)는 [moment.js](https://momentjs.com/)의 효과적인 대안이다.

- https://yceffort.kr/2020/12/why-moment-has-been-deprecated

lodash와 같은 라이브러리는 정말로 유용한 많은 메소드를 제공하지만, 사실 이는 ES6문법을 활용하면 쉽게 대체할 수 있다.

- https://github.com/you-dont-need/You-Dont-Need-Lodash-Underscore#_chunk

선호하는 도구가 무엇이든 간에, 우리가 생각해봐야 할 것은 동일하다. 더 작은 대안이 있는가? 혹은 자체적으로 구현이 가능한가?

## 브라우저별로 다른 스크립트 제공하기

요즘 대부분의 애플리케이션은 [ES6를 지원하지 않는 브라우저](https://caniuse.com/es6)에서 사용할 수 있는 코드로 변환하기 위해 babel을 사용하고 있을 가능성이 높다. 반대로 생각해보자. es6를 지원하는 브라우저가 더 많은데, 여전히 es6를 지원하지 않는 브라우저를 위해서 트랜스파일링이 된 번들링을 계속해서 제공해야 할까? 두개의 다른 빌드를 제공하면 되지 않을까?

1. 이전 브라우저에서 작동하는데 필요한 모든 도구, 폴리필을 포함하고 있다. 대부분의 애플리케이션이 현재 이런 상태일 것이다.
2. 모던 브라우저를 타겟으로 한 또다른 번들링을 만들어, 폴리필, 트랜스파일링 등을 모두 제거한다. 이 번들은 대부분의 애플리케이션이 제공하고 있지 않다.

이를 달성하기 위해서는 어떻게 해야할까?

[가장 단순한 패턴](https://v8.dev/features/modules#browser)은 바로 이것이다.

```html

/js/app.mjs

/js/app.js
```

그러나 이 패턴을 사용하면, IE11, Edge 15 ~ 18 에서는 두 번들링을 모두 다운로드 한다는 문제가 있다.

https://gist.github.com/jakub-g/5fc11af85a061ca29cc84892f1059fec

```javascript
var scriptEl = document.createElement('script')

if ('noModule' in scriptEl) {
  // 모던 스크립트
  scriptEl.src = '/js/app.mjs'
  scriptEl.type = 'module'
} else {
  // 레거시 스크립트
  scriptEl.src = '/js/app.js'
  scriptEl.defer = true // 순서가 중요하다면 defer를 false로
}

// Inject!
document.body.appendChild(scriptEl)
```

https://caniuse.com/mdn-html_elements_script_nomodule

## 가능한 트랜스파일은 적게!

> transpile less!

https://twitter.com/_developit/status/1110229993999777793

바벨을 그만 쓰자는 이야기는 아니다. 바벨은 절대로 없어서는 안된다. 하지만, 바벨은 내가 모르는 사이에 더 많은 것들을 하므로 이를 자세히 알아보는 것이 좋다. 이러한 작은 습관은 바벨이 만드는 코드에 긍정적인 영향을 미칠 수 있다.

```javascript
function logger(message, level = 'log') {
  console[level](message)
}
```

여기서 주의해야할 것은 기본값이 `log`인 함수다. 이 함수를 트랜스파일링 하면 어떻게 될까?

```javascript
'use strict'

function logger(message) {
  var level =
    arguments.length > 1 && arguments[1] !== undefined ? arguments[1] : 'log'
  console[level](message)
}
```

> https://babeljs.io/repl#?browsers=%3E%200.25%25%2C%20not%20dead&build=&builtIns=false&corejs=3.6&spec=false&loose=false&code_lz=GYVwdgxgLglg9mABAGzgczQUwE4AoC2mAzkQIZYA0KmAbpsogLyIBEqaLAlIgN4BQiRBARE4yTAG1xdZAF0CxMlk4BuPgF8gA&debug=false&forceAllTransforms=false&shippedProposals=false&circleciRepo=&evaluate=false&fileSize=false&timeTravel=false&sourceType=module&lineWrap=true&presets=env%2Creact%2Cstage-2&prettier=false&targets=&version=7.16.4&externalPlugins=&assumptions=%7B%7D

분명 편리한 기본값 지정을 위해서 저렇게 코드를 썼건만, 몇바이트였던 코드가 바벨을 거치면서 프로덕션 코드에서는 훨씬 더 커졌다.

```javascript
function logger(...args) {
  const [level, message] = args

  console[level](message)
}
```

```javascript
'use strict'

function logger() {
  for (
    var _len = arguments.length, args = new Array(_len), _key = 0;
    _key < _len;
    _key++
  ) {
    args[_key] = arguments[_key]
  }

  var level = args[0],
    message = args[1]
  console[level](message)
}
```

> https://babeljs.io/repl#?browsers=%3E%200.25%25%2C%20not%20dead&build=&builtIns=false&corejs=3.6&spec=false&loose=false&code_lz=GYVwdgxgLglg9mABAGzgczQUwE4AoB0hAhtmgM4CUiA3gFCKIQJlSIDaymAbpsgDSIAtpjJkiWALqIAvIhLkA3LXqNmcTh268JuYaPGYKSgL5A&debug=false&forceAllTransforms=false&shippedProposals=false&circleciRepo=&evaluate=false&fileSize=false&timeTravel=false&sourceType=module&lineWrap=true&presets=env%2Creact%2Cstage-2&prettier=false&targets=&version=7.16.4&externalPlugins=&assumptions=%7B%7D

`...args`는 분명 편리하지만, `babel`은 함수의 인수가 몇개가 올지 추론할 수 없기 때문에 위와 같이 트랜스파일링 해버렸다.

위와 같은 상황을 방지하기 위해서는, 아래와 같이 `||`을 사용하는 것이 좋다.

```javascript
function logger(message, level) {
  console[level || 'log'](message)
}
```

결과가 같다.

```javascript
'use strict'

function logger(message, level) {
  console[level || 'log'](message)
}
```

물론 이처럼 주의해야 할 것이 기본 파라미터만은 아니다. 화살표 함수나 전개 연산자들도 트랜스파일 하면 꽤나 복잡해진다.

이러한 기능을 모두 사용하지 않으려면, 다음과 같은 방법으로 영향도를 줄일수도 있다.

1. 라이브러리 작성자라면, [@babel/plugin-transform-runtime](https://babeljs.io/docs/en/babel-plugin-transform-runtime)와 함께 [@babel/runtime](https://babeljs.io/docs/en/babel-runtime)을 사용하여 바벨이 코드에 추가하는 helper함수를 제거할 수 있다.
2. 앱의 폴리필을 위해서는, [@babel/preset-env `useBuiltIns:"usage"`](https://babeljs.io/docs/en/babel-preset-env#usebuiltins)을 [@babel/polyfill](https://babeljs.io/docs/en/babel-polyfill)과 함께 선택적으로 사용할 수 있다.

개인적인 의견이지만, 모던 브라우저용으로 생성된 번들링을 트랜스파일링 하지 않는 것이 최선의 방법이라고 생각한다. 물론 이는 `jsx`나 널리 사용되지 않는 기능들 같이 무조건 어떤 브라우저든 상관없이 변환해야 하는 경우에는 불가능할 수도 있다. 그렇다면 이 앞선 도구가 꼭 필요한 것인지 되물어볼 필요가 있다. 만약 바벨이 코드 툴체인의 일부가 무조건 되어야 한다면, 바벨이 하고 있는 것들을 잘 살펴보고 개선할 필요가 있다.

## 성능향상은 레이스가 아니다

가능한 빨리 무언가를 얻으려고 하는 것은 때로는 사용자 경험의 고통으로 이어질 수도 있다. 물론 웹 개발 커뮤니티가 경쟁이라는 미명아래 더 빨리 반복하는 것에 집착하고 있기 때문에 조금은 속도를 늦출 필요가 있다고 생각한다. 그렇게 함으로써, 경쟁사만큼 빠른 이터레이션은 거치지 못할 지언정, 애플리케이션 경험은 더욱 향상될 수 있다.

코드 베이스에 성능 향상을 적용 하기전에, 이 모든 것이 하루 밤 사이에 되지 않는 것도 또한 알아둬야 한다. 웹 개발도 하나의 직업이다. 진정으로 영향력 있는 개발을 하기 위해서는 끊임 없이 고민하고 오랜시간 동안 헌신 할 때 비로소 이뤄진다. 꾸준히 향상에 집중해보자. 측정과 테스트를 반복하다보면 사이트의 사용자 경험이 향상되어 시간이 지남에 따라 조금씩 빨라질 것이다.

알지만 왠지 선뜻 내키지 않는 최적화, 이유가 무엇일까 🤔

자바스크립트 코드가 가져야할 책임감 (2)

## Table of Contents

## Introduction

가끔씩 심심할 때 마다 들어가는 사이트가 있는데, 그 중 하나가 [State of Javascript](https://httparchive.org/reports/state-of-javascript?start=2021_01_01&end=latest&view=list)다. 이 레포트가 어떻게 생성되는지는 모르겠지만, 아무튼 전세계 사이트의 자바스크립트 관련 통계를 보여준다. 보여주는 내용은 크게 3가지로 볼 수 있다.

- javascript bytes: 사이트 접근시 내려받는 자바스크립트 크기의 평균
- javascript requests: 사이트 접근시 수행되는 평균 요청 갯수
- javascript boot-up time: 페이지당 스크립트가 소비하는 cpu 시간

2021년이 되면서 이제 평균 자바스립트 크기는 450kb, 500kb를 넘어섰다. 하지만 우리가 알아둬야 할 것은 단지 전송된 크기라는 점, 대부분의 전송에는 압축이 수반되기 때문에 실제 압축해제한 크기는 더 크다는 것이다. 물론, 리소스를 전송하는데 시간을 단축하는 것도 유의미한 일이지만, 클라이언트는 실제 다운로드한 450kb 정도의 리소스를 압축해제 후 처리해야 하기 때문에, 실제 처리해야하는 자바스크립트 코드의 크기는 아마도 1mb를 넘을 것이다. 1mb가 크다면 크고, 작다면 작은 크기 이겠지만, 이를 잘 처리하는지는 처리하는 기기에 달려 있을 것이다. 이를 연구하기 위한 많은 노력이 이뤄지고 있지만, 아무튼 간에 처리하는데 소요되는 시간은 장치마다 크게 다를 것이다.

긍정적으로 생각하자면, 고객이 웹을 탐색하는 기기와 네트워크 환경은 점차 개선되고 있다. 그러나 한편으로는 우리는 그런 이득을 상쇄할 만큼 복잡한 사이트를 만들고 있다. 따라서 우리는 책임감 있게 자바스크립트 코드를 작성해야 한다. 그리고 이 책임감은, 우리가 어떻게 코드를 작성하고 있는지 부터 이해해야 한다.

## 웹 앱, 그리고 웹 사이트

우리는 일반적으로 '웹 사이트'와 '웹 앱' 이라는 용어를 혼용해서 쓰고 있다. 그러나 이를 혼동하는 것은 안좋은 결과를 가져올 수 있다. 비즈니스용 웹 사이트를 만드는 경우, 강력한 프레임워크에 의존하여 DOM 변경사항을 관리하거나, 클라이언트 사이드 라우팅 등을 만들 가능성이 적다. 작업에 적합하지 않은 도구를 사용하는 것은 만드는 사람들에는 생산성을 떨어뜨리고, 사이트를 사용하는 사람들에게도 앞선 관점에서 피해를 끼칠 수 있다.

하지만 '웹 앱'을 만들 때를 생각해보자. 수백에서 수천개의 dependencies를 가지는 패키지를 아주 자연스럽게 설치하는데, 사실 우리는 이 패키지가 안전한지 100% 확신하지 않고 설치한다. 모듈 번들을 위한 구성도 매우 복잡하다. 어떻게 보면 이러한 복잡성이 흔하게 몰아치는 개발 환경 속에서, 빠르게 프로그램을 만들고 접근이 쉽도록 하기 위해서는 프론트엔드 전반에 걸쳐 넓은 지식이 필요하고, 경계심 또한 늦추지 말아야 한다. 만약 의존성이 의심스럽다면 `npm ls --prod`를 실행하여 모든 의존성에 대해 내가 인지하고 있는지 확인해야 한다. 물론 이렇게 한다고 해서 모든 써드파티 스크립트를 다 고려할 수 있는 것은 아니다.

아무튼, 우리가 잊어버리는 것은 웹 사이트와 이 웹 앱이 모두 하나의 환경, '웹'이라고 하는 생태계에서 건설되고 있다는 것이다. 둘 모두 네트워크의, 기기의 영향을 받고 있다. 그러나 많은 사람들이 '웹 앱'을 만든다고 결심하기 시작하면서 부터 이러한 환경을 잊어도 되는 것처럼 생각한다. '앱'이라고 부르기로 결정했다고 해서 이러한 제약이 사라지는 것도 아니고, 갑자기 사용자의 기기가 마법과도 같은 힘을 발휘하는 것도 아니다.

우리가 만든 것을 누가 사용하는지 이해하고, 이들이 인터넷을 접속하는 조건이 우리와 다르다는 것을 받아드리는 것 부터 이러한 책임이 시작되는 것이다. 우리가 달성하고자 하는 목적을 알아야 하며, 그리고 이러한 목적을 달성하라 수 있는 무언가를 만들어야 한다.

결론적으로, 자바스크립트의 의존성과 자바스크립트의 활용 (HTML, CSS를 제외하더라도) 이 성능과 접근성을 해치는 패턴을 사용하는 것을 항상 경계해야 한다.

## 프레임워크로 인해 지속 불가능한 패턴을 만드는 것을 경계할 것

아래 리액트 코드를 살펴보자.

```javascript
import React, { Component } from "react";
import { validateEmail } from "helpers/validation";

class SignUpForm extends Component {
  constructor (props) {
    super(props);

    this.handleSubmit = this.handleSubmit.bind(this);
    this.updateEmail = this.updateEmail.bind(this);
    this.state.email = "";
  }

  updateEmail (event) {
    this.setState({
      email: event.target.value
    });
  }

  handleSubmit () {
    if (validateEmail(this.state.email)) {
      // ... sign up...
    }
  }

  render () {
    return (
      <div>
        <span>Enter your email:</span> <input type="text">

        <button onClick={handleSubmit}>Sign Up</button>
      </div>
    );
  }
}
```

위 코드엔 몇가지 문제가 있다.

1. `<form>`을 사용하지 않는 다면 그것은 form이라고 부를 수 없다. `<div role="form">`이라는 기법도 있지만, form을 작성하기 위해서는 적절한 동작과 메서드를 가진 `<form/>`을 쓰는 것이 좋다. `<form/>`의 `action`은 해당 컴포넌트가 서버사이드에서 렌더링된 경우라도, 자바스크립트 없이도 해당 작업을 수행할 수 있도록 보장할 수 있기 때문이다.
2. `<label>`이 없다면 접근성 이점을 누릴 수 없다.
3. form을 제출하기전에 클라이언트에서 무언가를 하기 원한다면, `<button/>` 의 `onClick`이 아닌 `<form/>`의 `onSubmit`을 활용해야 한다.
4. 이메일 유효성 검사에 특별한 기능이 필요한게 아니라면, IE 10 부터 광범위하게 지원하는 HTML5의 폼 validation의 활용하는 것이 여러모로 좋다. `<input type="email">`은 [많은 브라우저에서 지원하고 있으므로](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/email), `required` 속성과 함꼐 활용한다면 된다. 다만 스크린리더를 고려한다면 [몇가지 주의사항](https://www.tpgi.com/required-attribute-requirements/)이 있다.
5. 이 컴포넌트는 라이프 사이클 메소드에 의존적이지 않다. 따라서 stateless한 컴포넌트로 리팩토링할 수 있다. 이는 일반적인 리액트 컴포넌트보다 훨씬더 적은 자바스크립트를 사용한다.

따라서 이를 리팩토링한다면,

```javascript
import React from 'react'

const SignupForm = (props) => {
  const handleSubmit = (event) => {
    // 비동기로 폼 이벤트를 발생시키기 위해서 필요하다.
    // 자바스크립트가 disable된 서버사이드 렌더링 환경에서도 유효 할 것이다.
    event.preventDefault()

    // Do Something...
  }

  return (
    <form method="POST" action="/signup" onSubmit={handleSubmit}>
      <label for="email" class="email-label">
        Enter your email:
      </label>
      <input type="email" id="email" required />
      <button>Sign Up</button>
    </form>
  )
}
```

이제 이 컴포넌트는 접근성도 향상되었고, 자바스크립트도 덜 사용하게 되었다. 자바스크립트 범벅인 웹 세상에서, 자바스크립트를 줄이는 것은 거의 대부분 옳다. 브라우저는 우리에게 많은 기능을 공짜로 제공하고 있으므로, 항상 이를 최대한 활용할 수 있어야 한다.

이와 같은 예제는, 프레임워크에 의존적일 때 접근성이 떨어지는 패턴이 생긴다는 것을 의미하는 것 뿐만 아니라 HTML과 CSS를 제대로 이해하지 못하는 이해의 격차가 있다는 것을 방증한다. 자바스크립트, 그리고 HTML과 CSS 사이의 지식의 격차는 우리가 인지하지 못하는 실수를 초래하곤한다. 프레임워크는 생산성을 높이는 도구가 될 수도 있지만, 그것보다 더 중요한 것은 핵심적인 웹 기술에 대해서 이해하고, 나아가 무슨 툴을 사용하던지 사용자에게 좋은 사용자 경험을 안겨주는 것이다.

## 웹 플랫폼에 의존하기

angular, vue, react와 같은 웹 프레임워크에 많은 시간을 쏟고 있지만, 웹 플랫폼 또한 그자체 만으로도 어마어마한 프레임워크라 할 수 있다. 이전 섹션에서 알아 본 것처럼, 이미 확립된 마크업 패턴과 브라우저의 기능에 의존하는 것이 더욱 효과적이다.

### 싱글 페이지 애플리케이션

개발자들이 가장 많이 하는 실수 중 하나는 별다른 고민없이 Single Page Application을 채택하는 것이다. SPA가 물론, 클라이언트 라우팅을 통해 성능적 이점을 누릴수도 있다. 하지만 반대로 잃는 것은 무엇인가? 브라우저의 내비게이션은 비록 동기적으로 작동하지만 많은 이점을 제공한다. 이러한 방문이력은 [복잡한 스펙](https://alistapart.com/article/responsible-javascript-part-1/#:~:text=a%20complex%20specification)에 따라 관리된다. 자바스크립트를 활용할 수 없는 환경에서도 SPA를 사용할 수 있게 하려면, 서버사이드 렌더링을 고려해야 한다.

> https://kryogenix.org/code/browser/everyonehasjs.html

![CSR vs SSR](https://i2.wp.com/alistapart.com/wp-content/uploads/2019/04/fig2.png?resize=960%2C324&ssl=1)

클라이언트의 라우터가 페이지의 어떤 컨텐츠가 변경되었는지 알리지 않는다면 접근성 측면 에서도 좋지 못하다.

일부 클라이언트 라이브러리는 매우 작지만, 이를 [리액트와 함께 사용하는 것을 고려한다면](https://bundlephobia.com/package/react-router@6.0.2),그리고 여기에 [상태 관리 라이브러리를 얹는다면](https://bundlephobia.com/package/redux@4.1.2) 더 커진다. 따라서 개발하기전에 무엇을 구축하고 있는지, 그리고 클라이언트 사이드 라우팅이 손익계산을 해봤을 때 충분히 필요한 것인지 신중하게 고려해봐야 한다. 일반적으로는, 없는게 낫다.

만약 네비게이션 성능이 우려된다면, [rel=prefetch](https://www.w3.org/TR/resource-hints/#prefetch-link-relation-type)을 사용하여 동일한 오리진의 문서를 미리 가져올 수도 있다. 이는 document를 캐시에서 즉시 사용할 수 있으므로, 페이지의 로딩 성능을 높이는데 큰 영향을 미친다. prefetch는 낮은 우선순위로 진행되므로, 다른 중요한 리소스와 경쟁할 가능성도 낮다.

이 기법의 단점 중 하나는 일단 쓰고 보는 식으로 낭비가 될 수 있다는 것이다. 이 경우 구글의 [Quicklink](https://github.com/GoogleChromeLabs/quicklink)를 사용하는 것도 좋은 방법이 될 수 있다. 클라이언트 연결이 느리다면, 데이터 보호 모드가 사용되고 있는지를 확인하여 이 문제를 완화시킬 수 있다. 기본적으로, 교차 오리진에서는 링크를 미리 가져오지 않는다.

또한 서비스 워커를 활용한다면 클라이언트 라우팅을 사용하는지와 관계 없이 사용자 성능에 큰 도움을 줄 수 있다. 서비스 워커가 미리 경로를 파악해두면 앞서 언급한 기법과 마찬가지로 이점을 얻을 수 있지만, 요청과 응답에 대해 더 큰 제어권을 얻을 수 있다.

- https://developers.google.com/web/ilt/pwa/caching-files-with-service-worker

오늘날 서비스워커를 활용하는 것은 아마도 자바스크립트의 책임감을 높이는데 있어 가장 좋은 방법중 하나일 것이다.

## 자바스크립트는 레이아웃 문제를 해결하는데 별로 도움이 되지 않는다

레이아웃 문제로 인해 패키지를 설치하기전에, 반드시 내가 해결하고자 하는 문제가 무엇인지 명확히 할 필요가 있다. 이 레이아웃 문제를 해결하기 위한 가장 좋은 방법은 CSS다. [박스 위치 조정, 정렬, 사이즈](https://www.npmjs.com/package/flexibility) [문자열 오버플로우](https://www.npmjs.com/package/shave) 혹은 [레이아웃 시스템 전반](https://www.npmjs.com/package/lost)을 해결하기 위한 대부분의 자바스크립트 패키지들은 대부분 CSS로도 마찬가지로 해결할 수 있다. Flexbox, Grid와 같은 최신 레이아웃 엔진은 특별히 프레임워크가 필요 없을 정도로 잘 지원 된다. CSS가 곧 프레임워크다. CSS 내부에서 [feature queries](https://hacks.mozilla.org/2016/08/using-feature-queries-in-css/)를 사용한다면, 점진적으로 레이아웃 문제를 해결하기에 유용하다.

```css
/* Your mobile-first, non-CSS grid styles goes here */

/* The @supports rule below is ignored by browsers that don't
   support CSS grid, _or_ don't support @supports. */
@supports (display: grid) {
  /* Larger screen layout */
  @media (min-width: 40em) {
    /* Your progressively enhanced grid layout styles go here */
  }
}
```

우리는 모든 브라우저에서 사이트가 동일하게 페이지가 보이도록 개발해야 한다. 2009년으로 시간을 되돌려보자. IE 보다 더 좋은 브라우저에서도, 그리고 IE6 에서도 똑같이 보이게 하는 일을 해야만 하곤 했다. 그리고 2021년 현재, 만약 우리가 모든 브라우저에서 동일하게 페이지를 보이는 것을 목표로 하고 있다면 이 목표를 수정할 필요가 있다.에버그린 브라우저가 할 수있는 일을 하지 못하는 일부 브라우저를 지원하는 일을 계속해서 지원해 나가야 한다. 모든 플랫폼에서 동일하게 보이길 바라는 것을 바라는 것은 헛된 노력이며, 점진적 향상을 이룩하는데 있어 걸림돌이 될 것이다.

## 자바스크립트를 그만 쓰자는 이야기는 아니다

자바스크립트에 악의가 있는 것은 아니다. 자바스크립트로 인해 많은 것을 배울 수 있었고, 해마다 할 수 있는 것도 많아지고 기능도 성숙해지고 있다.

그러나 자바스크립트와 의견이 다를 때가 종종있다. 자바스크립트에 대해 항상 비판적인 자세를 취해야 한다. 좀더 정확히 말하자면, 우리가 웹을 구축하기 위한 첫번째 수단으로 자바스크립트를 생각해서는 안된다. 뒤에서 엉킨 전선, 코드 줄을 뜯어보다보면 웹이 자바스크립트에 취해 (drunken) 있다는 것을 볼 때가 한두번이 아니다. 우리는 거의 모든 문제에 자바스크립트를 가져다 댄다. 우리는 이러한 자바스크립트의 과도한 '숙취'를 막기 위해 실용적으로 다가갈 필요가 있다.


책임감 있는 코드를 작성하고 있는지 항상 뒤돌아보기

자바스크립트 코드가 가져야할 책임감 (1)

다른 사람들이 읽기에 좋은 코드를 작성하는 것은 중요하다. 같은 일을 하는 코드라면, 성능에 크게 영향을 미치지 않는 한에서 읽기 쉬운 코드를 작성하는 것이 좋다. 읽기 쉬운 이란 무엇인가? 복잡한 것을 간단하게 보일 수 있는 코드다. 그러나 '간단함' 이라는 것은 무엇인가? 이는 보는 사람의 수준에 기초한다. 읽기 쉬운 코드를 작성하고자 할 때 우리는 무엇을 목표로 해야할까? 이에 대한 해답은 상황에 따라 다를 것이다.

자바스크립트 개발자의 개발 경험을 개선하기 위해, TC39는 꾸준히 새로운 기능을 ECMAScript에 추가해 왔다. ES2019에서 추가된 기능 중 하나는, [Array.prototype.flat()](https://developer.mozilla.org/ko/docs/Web/JavaScript/Reference/Global_Objects/Array/flat) 이다. 이는 배열을 평평하게 만드는 역할을 담당하고 있다. 이 메소드가 존재하기 이전에는, 우리는 이 작업을 하기 위해 아래와 같이 코드를 작성해 왔다.

```javascript
let arr = [1, 2, [3, 4]]
let flatted1 = [].concat.apply([], arr)
let flatted2 = arr.flat()
```

`flat`을 사용한게 더 읽기 좋은가? 당연히 그 대답은 예스 일 것이다. 첫번째 코드는 알고리즘 테스트나 면접에서 볼 법한 코드로 한번에 코드의 목적을 이해하기 어렵다. 이 코드 중 어떤 코드가 더 읽기 쉬운지에 대한 대답은 뉴비나 전문가나 같을 것이다.

그러나 모든 개발자가 `flat()`의 존재를 아는 것은 아니다. 그러나 그 메소드의 존재를 알지 못하더라도, 메소드 자체가 기술 동사로 의미를 전달하기 때문에 보기만 해도 한눈에 알 수 있을 것이다. 이는 `concat.apply`보다 훨씬 더 직관적이다.

아마도 이러한 경우는 '어떤 코드가 더 읽기 좋은가' 의 질문에서 명확하게 대답할 수 있는 희귀한 케이스 일 것이다.

자바스크립트의 놀라운 점 중 하나는 바로 다재다능하다는 것이다. 이게 좋은 점이든 단점이든 간에, 암튼 다재다능하기 때문에 널리 사용되고 있을 것이다.

그러나 이러한 다재다능함과 함께 선택의 순간도 찾아온다. 여러가지 방법으로 동일한 코드를 작성할 수 있다. 우리는 과연 어떠한 방법이 옳은지 어떻게 결정할까?

자바스크립트 함수형 프로그래밍의 사례로 `map`을 살펴보자. `map`은 배열을 순회하면서 똑같은 길이의 배열을 만들 수 있다.



```javascript
const arr = [1, 2, 3]
let double = arr.map(item => item * 2)
// double is [2, 4, 6]
```


이제 다음 예제를 살펴보자.

```javascript
const arr = [1, 2, 3]
let double = arr.map((item) => item * 2)
```

두 예제의 차이점은 매개변수에 괄호가 있고 없고 일 뿐이다. 둘 이상의 매개변수가 있는 함수는 괄호를 항상 사용해야 하지만, 하나의 경우엔 그렇지 않다. 여기에 괄호를 넣어도 결과에는 차이가 없다. 단순히 prettier가 괄호가 없는 함수를 참지 못하는 것인가?

다른 예제를 살펴보자.

```javascript
let double = arr.map((item) => {
  return item * 2
})
```

이번에는 괄호와 return을 화살표 함수에 추가했다. 이제 좀 전통적인 함수 처럼 보이기 시작했다. 보통 함수 내부에 논리가 들어가야 한다면 이런식으로 작성한다.

```javascript
let double = arr.map(function (item) {
  return item * 2
})
```

자 이번엔 화살표 함수를 제거하고, 함수 키워드를 사용했다. 처음 코드를 작성했을 때 보다 복잡해졌는데, 이게 과연 나쁜 것일까?

```javascript
const timesTwo = (item) => item * 2
let double = arr.map(timesTwo)
```

이번엔 함수를 넘겨줬다. 함수 이름만 전달한다면 위와 같은 경우에는 문제가 발생하지 않는다. 하지만 이 코드가 혼란을 야기할 수 있지 않을까? `timesTwo`가 객체가 아닌 함수라는 것을 어떻게 확신할 수 있을까? `map`이라는 메소드가 이에 대한 힌트를 줄 수 있지만, 자세한 것을 알기엔 부족하다. `timesTwo`가 다른 곳에서 초기화 되거나 선언된다면 어떻게 되는가? 찾기 쉬워질까? 코드가 무엇을 하고 있고 어떤 영향을 미치지는지 확인하는 것은 매우 중요하다.

보는 것처럼, 명확한 대답은 없다. 그러나 코드 베이스에 적합한 선택을 한다는 것은 특정 동작을 수행하는 코드를 작성할 수 있는 모든 옵션과 그 한계를 명확히 이해한다는 것을 의미한다. 일관성을 유지하기 위해서는 괄호, 중괄호, return 키워드 등이 중요하다.

코드를 작성할 때는 항상 스스로에게 질문을 해야 한다. 가장 먼저 해야할 질문은 성능이다. 하지만 기능적으로, 그리고 성능적으로 동일한 코드를 볼 때는 인간이 코드를 읽는 방식으로 판단해야 한다.

```javascript
const { node } = exampleObject
```

위 코드는 변수를 초기화하고 할당하는 것을 모두 한줄에서 한다. 물론, 그렇게 할 필요는 없다.

```javascript
let node
;({ node } = exampleObject)
```

이 코드도 같은일을 한다. 하지만 이 코드를 자세히 보면 어색한 점이 많다. 세미 콜론을 사용하지 않는 코드에 어색한 코드를 강제로 줄 시작에 붙인다. 명령을 괄호안에 넣고 또 중괄호로 묶었다. 중괄호가 무엇을 하는지는 전혀 알수 없다. 결론적으로, 읽기가 쉽지 않다.

```javascript
let node
node = exampleObject.node
```

반면에 이 코드는 무엇을 하는지 명확하고, 누가 봐도 이해할 수 있다. 꼭 구조 분해 할당이 있다고 해서, 꼭 그것을 사용해야하는 것은 아니다.

물론, 그렇다고 해서 위코드로 써야 한다는 것이 아니다. `let`이 있다면 코드를 읽는 사람은 항상 이 변수가 언제 어디서 재할당되는지 긴장감을 가지고 살펴봐야 한다. 따라서, 이 경우에는 구조 분해할당을 하는 것이 좋다.

이번엔 전개 연산자와 `concat`에 대해 알아보자.

전개 연산자는 ECMAScript에서 새로나온 기능으로, 코드에 널리 사용되고 있다. 다양한 작업을 할 수 있는데, 그중 하나가 두 배열을 합치는 것이다.

```javascript
const arr1 = [1, 2, 3]
const arr2 = [9, 11, 13]
const nums = [...arr1, ...arr2]
```

물론 자바스크립트 코드에 익숙한 사람이 본다면 쉽게 이해할 수 있지만, 그렇지 않다면 직관적으로 무엇을 하는지 이해하기 어렵다. 모든 사람이 자바스크립트 코드에 익숙하다면 상관없지만, 그렇지 않은 사람들에게 혼란을 빚을 수 있다. 이 경우에는, `concat`이 훨씬 직관적일 것이다.

```javascript
const arr1 = [1, 2, 3]
const arr2 = [9, 11, 13]
const nums = arr1.concat(arr2)
```

자바스크립트 코드를 짜고 있는 인적 요인이 코드 선택에 이런식으로 영향을 미칠 수 있다. 또 자바스크립트 코드가 최신 코드 베이스가 아니라면 보다 엄격하게 표준을 유지해야한다.

> 이와 별개로, 전개연산자는 성능에 그다지 좋지 못하다.

```javascript
const array1 = []
const array2 = []
const mergeCount = 50
let spreadTime = 0
let concatTime = 0

for (let i = 0; i < 10000000; ++i) {
  array1.push(i)
  array2.push(i)
}

// The spread syntax performance test.
for (let i = 0; i < mergeCount; ++i) {
  const startTime = performance.now()
  const array3 = [...array1, ...array2]

  spreadTime += performance.now() - startTime
}

// The concat performance test.
for (let i = 0; i < mergeCount; ++i) {
  const startTime = performance.now()
  const array3 = array1.concat(array2)

  concatTime += performance.now() - startTime
}

console.log(spreadTime / mergeCount)
console.log(concatTime / mergeCount)

/*
 * Performance results.
 * Browser           Spread syntax      concat method
 * --------------------------------------------------
 * Chrome 75         626.43ms           235.13ms
 * Firefox 68        928.40ms           821.30ms
 * Safari 12         165.44ms           152.04ms
 * Edge 18           1784.72ms          703.41ms
 * Opera 62          590.10ms           213.45ms
 * --------------------------------------------------
 */
```

> 따라서, 이 경우에는 `concat`을 쓰는 것이 좋다.

전문가는 스펙의 모든 부분을 사용하는 사람이 아니라, 현명하게 문법을 배치하고, 합리적인 결정을 내릴 수 있을 만큼 스펙을 이해하고 있는 사람이다. 우리 스스로가 전문가가 되기 위해서는 어떻게 해야할까? 코드를 작성해야 하는 것은 스스로에게 많은 질문을 하는 것을 의미하기도 한다. 이는 개발자가 다른 개발자를 고객으로 바라보고 고려하는 것을 의미하기도 한다. 작성할 수 있는 최상의 코드는 복잡한 기능을 수행하면서도, 다른 사람이 코드를 보고 쉽게 이해할 수 있도록 만드는 코드다. 그리고 이는 쉽지 않다. 그리고 대부분의 경우 명확한 답이 없다. 하지만 우리는 매번 코드를 쓸 때 이점을 뒤돌아 봐야 한다.

나는야 자바스크립트 키보드 워리어

Latest

HTML 문서에서 DOM으로의 여정

서버에서 클라이언트로의 여정 - 브라우저와 서버는 어떻게 데이터를 주고 받을까

자바스크립트 코드가 가져야할 책임감 (2)

자바스크립트 코드가 가져야할 책임감 (1)

읽기 좋은 자바스크립트 코드 작성하기