자바스크립트는 6가지 원시 타입이 있으며, 그 외에는 모두 객체 타입이다. 따라서 배열도 객체 중 하나라고 볼 수 있다. 그렇다면 아래의 객체도 배열이라고 볼 수 있을까?

```javascript
const a = {
  0: 0,
  1: 1,
  2: 2,
  length: 3,
}

a[0] // 0
a[1] // 1
a[2] // 2
a.length //3
```

그렇다면 정확히 배열이라는 것은 무엇일까?

## 배열

### 기본 정보

배열은 아래 4가지 방법으로 생성할 수 있다.

- 배열 리터럴 (`[]`)
- Array 생성자 함수
- [Array.of](https://developer.mozilla.org/ko/docs/Web/JavaScript/Reference/Global_Objects/Array/of)
- [Array.from](https://developer.mozilla.org/ko/docs/Web/JavaScript/Reference/Global_Objects/Array/from)

```javascript
const a = {
  0: 0,
  1: 1,
  2: 2,
  length: 3,
}

const b = [1, 2, 3]

typeof a // object
typeof b // object

Object.getPrototypeOf(a) === Object.prototype
Object.getPrototypeOf(b) === Array.prototype // true
```

객체와 배열은 기본적으로 다음과 같은 서로다른 특징이 있다.

|                 | Object       | Array           |     |
| --------------- | ------------ | --------------- | --- |
| structure       | key & value  | index & element |     |
| reference       | property key | index           |     |
| order           | X            | O               |     |
| length property | X            | O               |     |

가장 큰 차이로는, 순서와 `length` property 유무다.

### 희소배열

자바스크립트의 배열은, 일반적인 밀집 배열이 아니다.

여기서 밀집 배열이란, 데이터 타입이 통일되어 있으며 서로 메모리 상에서 연속적으로 인접해 있는 배열을 의미한다. 밀집배열은 따라서 데이터에 접근하는게 효율적이고, 빠르다.

그러나 자바스크립트는 희소배열 형태로 되어 있다. 희소배열은, 밀집 배열과 반대로 배열의 요소를 위한 데이터 공간과 크기가 다르고, 연속적으로 밀집되어 있지도 않은 배열을 의미한다. 이경우 당연히 접근하는데 속도는 조금 느리지만, 요소를 삽입하거나 삭제하는 경우에는 더 빠르다.

## 이터레이션 프로토콜

이터테이련 프로토콜이란, 앞서 언급한 배열 처럼, 순회 가능한 자료 구조를 만들기 위하여 ECMAScript 에서 정의한 규악이다.

ES6 이전에는 배열, 문자열, DOM 콜렉션 등이 각자 방법으로 데이터를 순회할 수 있도록 구성되어 있었지만, ES6에 들어서면서 이러한 순회 가능한 데이터 들이 이터레이션 프로토콜을 준수하여 동일하게 동작하게 끔 설계했다. 이러한 이터레이션 프로토콜에는 두가지가 있다.

### 이터러블 프로토콜

어떠한 값들이 루프되는 것과 같은 이터레이션 동작을 정의하거나, 사용자 정의하는 것을 의미한다. 다시 말해, `Symbol.iterator`를 호출하면 이터레이터를 반환하는 것을 이터러블 프로토콜 이라고 한다.

즉, 해당 객체에 프로토타입을 통해서든, 직접 구현을 했든, `Symbol.iterator`를 호출할 수있고 그것이 이터레이터를 반환한다면, 이터러블이다.

```javascript
const a = {
  0: 0,
  1: 1,
  2: 2,
  length: 3,
}

const b = [1, 2, 3]

a[Symbol.iterator] // undefined
b[Symbol.iterator] === Array.prototype[Symbol.iterator] // true
```

### 이터레이터 프로토콜

값들의 순서를 만드는 표준 방법을 의미한다. 객체가 `next()`를 가지고 있고, 그 객체가 `value`와 `done` (`true`, `false`)를 리턴한다면 이터레이터 프로토콜을 준수한 이터레이터다.

## 나만의 이터러블 만들어보기

피보나치 배열을 리턴하는 이터러블을 만들어보자.

```javascript
const fibonacci = function (max) {
  let prev = 0
  let curr = 1

  return {
    [Symbol.iterator]() {
      return {
        next() {
          last = prev + curr
          prev = curr
          curr = last

          return {
            value: curr,
            done: curr >= max,
          }
        },
      }
    },
  }
}

const fibonacci100 = fibonacci(100)

for (const i of fibonacci100) {
  console.log(i) // 1, 2, 3, 5, 8, 13, 21, 34, 55, 89
}

const result = [...fibonacci100] // [1, 2, 3, 5, 8, 13, 21, 34, 55, 89]

const iterator = fibonacci(100)[Symbol.iterator]()

console.log(iterator.next()) // { value: 1, done: false }
console.log(iterator.next()) // { value: 2, done: false }
console.log(iterator.next()) // { value: 3, done: false }
console.log(iterator.next()) // { value: 5, done: false }
```

위와 같은 동작은 배열과 유사하다.

```javascript
const a = [1, 2, 3, 5]
const iterator = a[Symbol.iterator]()

console.log(iterator.next()) // { value: 1, done: false }
console.log(iterator.next()) // { value: 2, done: false }
console.log(iterator.next()) // { value: 3, done: false }
console.log(iterator.next()) // { value: 5, done: false }
console.log(iterator.next()) // { value: undefined, done: true}
```

## 이터러블 이면서, 이터레이터인 객체를 리턴

```javascript
const fibonacciFunc = function (max) {
  let prev = 0
  let curr = 1

  return {
    [Symbol.iterator]() {
      // 메소드 함수의 this는 메서드를 호출한 객체에 바인딩 된다.
      // 즉
      /*
            {
              next: [Function: next],
              [Symbol(Symbol.iterator)]: [Function: [Symbol.iterator]]
            }
            */
      return this
    },
    next() {
      last = prev + curr
      prev = curr
      curr = last

      return {
        value: curr,
        done: curr >= max,
      }
    },
  }
}

const fibonacci100 = fibonacciFunc(100)

for (const i of fibonacci100) {
  console.log(i) // 1, 2, 3, 5, 8, 13, 21, 34, 55, 89
}

const result = [...fibonacci100] // [1, 2, 3, 5, 8, 13, 21, 34, 55, 89]

const iterator = fibonacciFunc(100)

console.log(iterator.next()) // { value: 1, done: false }
console.log(iterator.next()) // { value: 2, done: false }
console.log(iterator.next()) // { value: 3, done: false }
console.log(iterator.next()) // { value: 5, done: false }
```


이터러블과 이터레이터 이름이 헷갈림

자바스크립트의 배열, 그리고 이터러블과 이터레이터 (ES6)

자바스크립트는 새로운 feature 가 제안 되어도, 항상 이전 버전과의 하위호환이 깨지지 않는 선에서 지원이 가능해야 한다. 따라서, 모든 새로운 기능들은 polyfill로 지원이 가능하다. 그러나 이걸 가져다 써보기만 해봤지, 직접 만들어 본적은 없는 것 같다. 그래서 한번 직접 만들어 보려고 한다.

tc39문서를 보다가 새롭게 보게 된 feature 중 하나가 바로 이것이다.

## `Array.prototype.at`

- https://tc39.es/proposal-relative-indexing-method/
- https://github.com/tc39/proposal-relative-indexing-method

`array[0]` 과 비슷 해보이지만, 이것은 파이썬의 그것과 비슷하게 음수까지 지원해 준다. 예컨데, `[-1]`로 인덱싱을 하면 가장 마지막 것을 불러오는 것이다. 이 기능을 한번 polyfill로 구현해보자.

```javascript
function at(n) {
  n = parseInt(n, 10) || 0

  // 음수 일 경우 길이 만큼 더한다. 이렇게 하면 음수 인덱싱을 대응할 수 있다.
  if (n < 0) {
    n += this.length
  }

  // 인덱싱에 대응할 수 없을 경우 undefined를 리턴한다.
  if (n < 0 || n >= this.length) {
    return undefined
  }

  return this[n]
}

for (let T of [Array, String]) {
  Object.definedProperty(T.prototype, 'at', {
    value: at,
    writable: true,
    enumerable: false,
    configurable: true,
  })
}
```

여기서 배울 수 있는 것은 다음과 같다.

### this

정적으로 결정되는 스코프와 다르게, `this`는 어떻게 호출되었는지에 따라서 달라진다. 메서드 this는, 메서드를 호출한 객체, 즉 `.` 연산자 앞에서 호출한 객체가 바인딩 된다.

```javascript
let arr = [1, 2, 3]
arr.at(1)
```

우리는 위와 같은 방식으로 `.at()`을 호출하기 때문에, `at` 함수 내부의 `this`는 `at()`을 호출한 객체인 리스트가 될 것이다.

### prototype

`prototype` 프로퍼티는 함수 객체만이 지닌 프로퍼티다. (그리고 `Array`, `String`은 함수다. 사실 당연 한 거아님?) 이는 생성자 함수가 생성할 인스턴스의 프로토타입을 가리킨다. 생성자 함수가 자신이 생성할 객체의 프로토타입을 할당해주기 위해 사용하는 것으로, 여기에 있는 메소드들은 향후 새롭게 생성되는 객체들의 `__proto__` 또는 `Object.getPrototypeOf`로 접근할 수 있다.

> 모든 Array 인스턴스는 Array.prototype을 상속합니다. 다른 생성자와 마찬가지로, Array() 생성자의 프로토타입을 수정하면 모든 Array 인스턴스도 수정의 영향을 받습니다. 예를 들면, 새로운 메서드와 속성을 추가해 모든 Array를 확장할 수 있으므로, 폴리필에 쓰입니다.

![array-prototype](./images/array-prototype.png)

```javascript
Array.prototype === Object.getPrototypeOf([1, 2, 3]) // true
```

## `definedProperty`

`definedProperty`를 알기 위해서는, property attribute를 알아야 한다. 이는 프로퍼티의 상태를 의미하며, 데이터 프로퍼티와 접근자 프로퍼티가 있다.

- 데이터 프로퍼티: 일반적인 프로퍼티로, 키와 값으로 구성되어 있다.
- 접근자 프로퍼티: 자체적으로 값을 가지고 있지는 않지만, 다른 데이터 프로퍼티의 값을 읽거나 지정할 때 호출되는 접근자 함수로 구성된 프로퍼티

여기에서 우리가 사용해야할 것은 데이터 프로퍼티로, `value` `writable` `enumerable` `configurable`을 값을 가진다. 그리고 `definedProperty`를 통해서, 새로운 프로퍼티를 정의할 수 있다. 나는 `Array` 와 `String`에 각각 지정했다.

## 공식 polyfill과 다른점

### 1. Math.trunc vs parseInt

숫자를 처리하는데 있어 나는 `parseInt`를 썼지만, 저 친구는 `Math.trunc`를 사용했다. 이는 그냥 소수점 이하 단위를 버리는 함수다. 굳이 굳이 비교하면 뭔차이가 있을까 하고 찾아봤는데

https://www.samanthaming.com/tidbits/55-how-to-truncate-number/

> parseInt is mainly used for a string argument. So if you're dealing with numbers, it's way better to use Math.trunc().

뭔가 성능에 있어서 차이가 있나보다. 아쉽게도 `jsPerf`가 뻗어있어서 (2021.02.15 기준) 알수가 없었지만, 아무튼 그런가 보다. 시간나면 해보자.

### 2. 형식화 배열

자바스크립트의 `Indexed Collections`에는 다음과 같은 것들이 있다.

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects#indexed_collections

- Array
- Int8Array
- Uint8Array
- Uint8ClampedArray
- Int16Array
- Uint16Array
- Int32Array
- Uint32Array
- Float32Array
- Float64Array
- BigInt64Array
- BigUint64Array

https://developer.mozilla.org/ko/docs/Web/JavaScript/Typed_arrays

> JavaScript 형식화 배열(typed array)은 배열같은 객체이고 원시(raw) 이진 데이터에 액세스하기 위한 메커니즘을 제공합니다. 이미 아시다시피, Array 객체는 동적으로 늘었다 줄고 어떤 JavaScript 값이든 가질 수 있습니다. JavaScript 엔진은 이러한 배열이 빨라지도록 최적화를 수행합니다. 그러나, audio 및 video 조작과 같은 기능 추가, WebSocket을 사용한 원시 데이터에 액세스 등 웹 어플리케이션이 점점 더 강력해짐에 따라, 빠르고 쉽게 형식화 배열의 원시 이진 데이터를 조작할 수 있게 하는 것이 JavaScript 코드에 도움이 될 때가 있음이 분명해 졌습니다.

사실 자바스크립트의 배열은 엄밀히 말하면 자료구저의 배열이 아니다. 자료구조의 배열은, 동일한 크기의 메모리 공간이 빈틈없이 연속적으로 나열되어 있어야 한다. (밀집 배열) 그러나 자바스크립트 배열은 희소배열이다. 자바스크립트는 동일한 크기를 연속적으로 확보하는 것이 불가능하므로 (무슨타입이 올줄 알고?) 배열의 동작을 흉내내서 만들었다. 그러나 위에 언급된 `Array`를 제외한 나머지 배열들을 `.from()`으로 만들경우, 진짜 `dense array`, 밀집 배열을 만들 수 있다.

> When Array.from() gets an array-like which isn't an iterator, it respects holes. TypedArray.from() will ensure the result is dense.

물론 Array로도 밀집 배열을 만들 수 있다. https://2ality.com/2012/06/dense-arrays.html

아무튼 지간에 결론은, 자바스크립트에는 저런 배열들도 있으므로, 저런 배열의 prototype에도 마찬가지로 추가를 해줬어야 했다.


나만의 자바스크립트 polyfill 만들고 공부하기

50% 확률로 reject 되는 아래와 같은 함수가 있다고 가정해보자.

```javascript
async function resolveOrReject() {
  // 1초를 그냥 기다린다.
  await new Promise((_) => setTimeout(_, 1000))

  // 50% 확률로 true false
  const randomResult = Boolean(Math.round(Math.random()))

  if (randomResult) {
    return 'good'
  } else {
    throw Error('bad')
  }
}
```

## 그냥 호출

```javascript
async function a() {
  try {
    resolveOrReject()
  } catch (e) {
    return 'caught!'
  }
}
```

이 경우 `a()`는 1초를 기다리지 않고 언제나 `undefined`를 `fulfilled` (이행) 할 것이다. 우리가 여기에서 `await` 하거나 껼과를 기다리지 않으므로, 실패했을 경우에 대해서 처리를 할 수가 없다. 대부분 이런 코드는 실수일것이다.

## await

```javascript
async function b() {
  try {
    await resolveOrReject()
  } catch (e) {
    return 'caught!'
  }
}
```

이 함수의 경우에는 항상 1초를 기다리며, `undefined`가 오거나 `caught`가 올 것이다. `resolveOrReject`의 결과를 기다리기 때문에, 실패 했을 경우 `catch` 블록을 실행할 수 있게 되었다. 그러나 실패하지 않았을 경우에는 이 값을 가지고 아무것도 하지 않는다.

## return

```javascript
async function c() {
  try {
    return resolveOrReject()
  } catch (e) {
    return 'caught'
  }
}
```

이 경우에도 마찬가지로 1초를 기다리며, 성공할 경우 `good` 이 오고, 실패할 경우에는 `caught`가 오는 것이 아니고 그냥 에러가 던져진다. 따라서 실패할 경우엔 `catch` 블록에 들어가지 않는다는 것을 알 수 있다.

## return await

```javascript
async function d() {
  try {
    return await resolveOrReject()
  } catch (e) {
    return 'caught'
  }
}
```

1초를 기다리며, `good`이 오거나 `caught`가 오게 된다. `resolveOrReject`의 결과를 기다리므로, 에러가 났을 때는 `catch` 블록으로 , 이행이 되었을 경우 정상적으로 결과를 리턴한다.

위 함수를 나누면 이렇게 볼 수 있다.

```javascript
async function d() {
  try {
    // resolveOrReject 의 결과를 기다리며, 결과를 변수에 넣는다.
    const result = await resolveOrReject()
    // 만약 위에서 에러가 던져졌다면, catch 블록으로 넘어간다.
    // 그렇지 않으면, 결과를 리턴한다.
    return result
  } catch (e) {
    return 'caught'
  }
}
```

**이 것은 어디까지나 `try ... catch` 블록에서만 유효하다.** 그 외의 영역에서는 `return await`은 의미하다. `async` 함수 내에 있는 `return await`은 프로미스를 기다렸다가 결과가 나올때까지, 현재의 함수를 콜스택에 넣어두며, 외부 promise가 resolve 되기전에 추가로 마이크로 태스크가 생기게 된다. 따라서 `try ... catch` 블록이 아니라면 단순히 `return something`으로 처리하면 된다.

https://github.com/eslint/eslint/blob/master/docs/rules/no-return-await.md


try catch 블록에서는 동작이 다르네

no return, await, return, await return 의 차이

## ECMAScript 언어 명세 상의 차이

- `undefined`: 변수에 값이 할당되지 않았을 때 사용된다. https://tc39.es/ecma262/#sec-undefined-value primitive value used when a variable has not been assigned a value

- `null`: 의도적으로 어떤 객체의 값이 비어 있다는 것을 나타낼 때 사용된다. primitive value used when a variable has not been assigned a value primitive value that represents the intentional absence of any object value

다른 언어와 다르게, 두개의 non-value가 있는 것은 자바스크립트 설계의 실수라고 한다. 그러나 이것이 지금까지 사용되고 있는 것은 자바스크립트가 구버전과의 호환성을 절대로 깨뜨리지 않는 다는 원칙이 있기 때문이다. [비슷한 사례로 `typeof null`이 있다.](https://2ality.com/2013/10/typeof-null.html)

자바스크립트가 많은 영감을 받은 자바에서는, 변수의 정적 타입에 따라 값을 초기화 한다.

- 객체 타입의 변수는 `null`로 초기화 한다.
- 원시 타입의 변수는 각자의 초기 값으로 초기화 한다. 숫자의 경우 0 이다.

자바스크립트의 경우에는, 변수가 객체가 될 수도 있고, 원시값이 될 수도 있다. 그러므로 만약 `null`이 "객체가 아니다" 라면, 자바스크립트는 "객체도 아니고 원시값도 아닌" 초기 값이 필요해 진다. 그것이 바로 `undefined` 다.

## undefined가 나오는 경우

```javascript
// 초기 값을 주지 않은 경우
let var

// 객체에서 정의 하지 않은 속성에 접근하는 경우
const obj = {}
obj.prop

// 함수의 리턴이 없는 경우
function func() {}
assert.equal(func(), undefined)

// 리턴은 있는데 아무것도 안하는 경우
function func() {
  return
}
assert.equal(func(), undefined)

function func(x) {
  assert.equal(x, undefined)
}

// 정의 되지 않은 파라미터
func()

undefined?.prop
null?.prop
```

## null이 나오는 경우

```javascript
// 프로토타입의 종점
Object.getPrototypeOf(Object.prototype) // null

// 정규식
/a/.exec('x') // null

// JSON은 undefined를 지원 하지 않는다.
JSON.stringify({a: undefined, b: null}) // "{"b":null}"
```

## undefined와 null을 특별하게 처리하는 연산자

### 함수 파라미터의 기본값

함수 파라미터의 기본값은 두가지 경우에서만 사용된다.

- 파라미터가 존재하지 않는 경우
- 파라미터의 값이 `undefined`인 경우

```javascript
function func(arg = 'abc') {
  return arg
}
console.log(func()) // abc
console.log(func(undefined)) // abc
console.log(func(null)) // null
```

### 분해연산자의 기본값과 undefined

위의 기본값 예제와 동일하게 동작한다.

```javascript
const [a = 'a'] = [] // a
const [b = 'b'] = [undefined] // b
const { prop: c = 'c' } = {} // c
const { prop: d = 'd' } = { prop: undefined } //d
const [e = 'e'] = [null] // null
const { prop: f = 'f' } = { prop: null } // null
```

### 옵셔널 체이닝

값이 nullish한 경우 (`null` `undefined`) `undefined`를 리턴한다.

```javascript
function getProp(obj) {
  return obj?.prop
}
getProp({ prop: 123 }) // 123
getProp(undefined) // undefined
getProp(null) // undefined
```

### undefined, null, nullish coalescing (null 병합 연산자)

`||` 와는 다르게 `nullish` 한 값에 대해서만 대응한다.

```javascript
undefined ?? 'default value' // default value
null ?? 'default value' // default value
0 ?? 'default value' // 0
'' ?? 'default value' // ''
```

null 병합 할당 현산자인 `??=` 도 마찬가지로 동작한다.

## 결론(?)

명시적으로 값이 없다는 걸 나타내고 싶다면, `null`을 쓰는게 좋다. `undefined`는 기본값 할당, JSON에서 생략되는 등 의도치 않은 동작을 나타낼 수 있다. 내가 의도적으로 빈값을 두고 싶다면, `null`이 나은 것 같다. 그렇다고 `undefined`가 내가 짠 코드에서 안나오는 것은 아닐 것이다. 말하고 싶은 것은 의도적으로 빈값을 집어 넣을 때 둘중에 `null`을 더 선호한다 정도일 것이다. 그러나 이건 어디까지나 내취향의 문제일 뿐, 적절히 헷갈리지만 않게 쓰면 될 것 같다.


이런 것 또한 매력이라면 매력이 아니다

null과 undefined의 차이, 그리고 역사

## Table of Contents

CSS는 웹 페이지의 성능에 영향을 미치는 중요한 요소중 하나다. 그 이유는

1. 브라우저는 렌더 트리를 만들기 전가지 페이지를 렌더링 할 수 없음
2. 렌더트리는 DOM과 CSSOM을 합쳐서 만드는 것
3. DOM은 HTML과 함께 자바스크립트의 실행을 차단함
4. CSSOM 이란 DOM에 적용해야 하는 모든 CSS 규칙을 의미함
5. 자바스크립트는 `async` 와 `defer`로 차단하지 않도록 만드는 것은 쉽지만
6. CSS를 비동기로 처리하는 것은 매우 어렵
7. 따라서 페이지가 가장 느린 스타일 시트가 렌더링 되는 순간에 페이지가 렌더링 된다는 것을 명심해야 한다.

이러한 점을 염두해두고, DOM과 CSSOM을 최대한 빠르게 구성해야 한다. 일반적으로 DOM은 HTML 응답에 따라서 만들어지므로 비교적 빠르다. 그러나 CSS는 거의 대부분 HTML의 하위리소스이기 때문에 CSSOM을 구성하는 것은 일반적으로 시간이 더 걸린다.

## Critical CSS

렌더링 시작 시간을 줄이는 가장 효과적인 방법은 Critical CSS Pattern을 사용하는 것이다. 이는 렌더링 시작에 필요한 모든 스타일 (일반적으로 스크롤 하지 않아도 맨 처음에 필요한 모든 항목에 필요한 스타일)을 의미한다. 문서의 `<head/>`에 `<style/>` 태그로 인라인처리하고, 나머지 스타일 시트는 비동기적으로 로드 하는 방식이다.

물론 이방식은 효과적이지만 간단하지는 않다. 사이트가 엄청나게 동적일 경우, 스타일을 추출하는 것이 어렵다. 또한 프로세스를 자동화 해야 하며, 안보이는 부분에 대한 정의를 내려야 하고, 예외 처리를 하기가 어렵다. 이는 코드가 커질 수록 어렵다.

## 미디어 쿼리로 나누기

현재 컨텍스트 (medium, 스크린크기, 해상도, 방향 등)에 맞는 css를 가장 최우선 순위로 다운로드 하고, 그 외의 것은 나중에 다운로드 하는 방식이다. 기본적으로 현재 뷰를 렌더링하는데 필요하지 않은 CSS는 브라우저에 의해 지연되어 로딩 된다.

```html
<link rel="stylesheet" href="all.css" />
```

이처럼 되어 있는 것을 미디어 쿼리로 분할 할 수 있다면 네트워크가 분할해서 다르게 취급할 것이다.

```html
<link rel="stylesheet" href="all.css" media="all" />
<link rel="stylesheet" href="small.css" media="(min-width: 20em)" />
<link rel="stylesheet" href="medium.css" media="(min-width: 64em)" />
<link rel="stylesheet" href="large.css" media="(min-width: 90em)" />
<link rel="stylesheet" href="extra-large.css" media="(min-width: 120em)" />
<link rel="stylesheet" href="print.css" media="print" />
```

https://caniuse.com/css-mediaqueries 대부분의 브라우저에서 사용할 수 있다.

물론 여전히 브라우저가 모든 css 파일을 다운로드 하긴 하지만, 현재 컨텍스트를 충족하는데 필요한 파일의 렌더링만 차단한다.

## `@import` 사용하지 않기

`@import`는 아무튼 느리다. 그래서 렌더링 성능에 안좋다. `@import`의 작동 과정을 살펴보자.

1. HTML 다운로드
2. HTML이 CSS를 요청
3. CSS가 또 다른 `@import`에 있는 CSS를 요청
4. 이게 다 끝나면 렌더 트리 생성

```html
<link rel="stylesheet" href="all.css" />
```

안에

```css
@import url(imported.css);
```

와 같은 코드가 있다면, 폭포수 형태로 다운로드를 시작할 것이다.

이는 그냥 단순히

```html
<link rel="stylesheet" href="all.css" />
<link rel="stylesheet" href="imported.css" />
```

로 처리한다면 두개를 동시에 병렬화 하여 다운로드 할 것이다. 그런데 현재 파일에서 `@import` 구문을 지울 수 없는 상황이라 할지라도, 저렇게 별개로 따로 선언해주는 것이 좋다. 그렇다고 해서 브라우저가 중복으로 파일을 다운로드 받지 않을 것이다.

## `<link rel="stylesheet" />`를 비동기 코드 전에 두지 않기

**브라우저는 현재 실행중인 CSS가 있을 경우 `<script/>`를 실행하지 않는다.**

```html
<link rel="stylesheet" href="slow-loading-stylesheet.css" />
<script>
  console.log('I will not run until slow-loading-stylesheet.css is downloaded.')
</script>
```

이는 의도된 다분히 의도적인 동작이다. CSS가 다운로드 중이라면, HTML은 어떤 동기 `<script/>`도 실행하지 않는다. 스크립트 태그 내에서 CSS 가 도착하여 파싱되기 전까지 이에 대한 정보를 찾는 경우, Javascript가 응답하는 내용이 잘못될 수도 있다. 이를 방지하기 위해 브라우저는 CSSOM이 구성될 때 까지 `<script/>`를 실행하지 않는다.

따라서 CSS의 다운로드 시간이 비동기 코드에 영향을 미친다는 것이다. 만약 `<link rel="stylesheet" />` 앞에 비동기 코드를 둔다면, 이는 CSS파일이 다운로드 되어 파싱되기 전까지 실행되지 않을 것이다. 이 말인 즉슨 CSS가 모든 작업을 뒤로 미룬다는 뜻이 된다.

```html
<link rel="stylesheet" href="app.css" />

<script>
  var script = document.createElement('script')
  script.src = 'analytics.js'
  document.getElementsByTagName('head')[0].appendChild(script)
</script>
```

이렇게 순서가 주어지면, CSSOM이 생성되기 전까지 자바스크립트 파일이 다운로드 되지 않는 다는 것을 알 수 있다. 이는 구글 애널리틱스와 같이 제 3자 스크립트를 안전하게 로드 하기 위해 비동기 코드를 제공하는 방식이다. 개발자가 이러한 제3자 코드를 코드 맨 뒷부분에 배치 하고 싶은 것은 일반적이다. 그러나 이는 실수가 될 수 있다.

따라서 `<script/>` 내에 css에 의존하는 코드가 없다면, 이를 상단에 배치하는 것이 좋다.

```html
<script>
  var script = document.createElement('script')
  script.src = 'analytics.js'
  document.getElementsByTagName('head')[0].appendChild(script)
</script>

<link rel="stylesheet" href="app.css" />
```

따라서

- CSSOM에 의존하지 않는 자바스크립트는 CSS이전에
- CSSOM에 의존하는 자바스크립트는 이후에

둔다.

파일이 서로 의존적이지 않은 경우, 차단 스크립트를 차단 스타일 위해 배치 해야 한다. 자바스크립트가 실제로 의존하지 않는 CSS때문에 자바스크립트 실행을 지연시킬 필요는 없다. 만약 자바스크립트 중 일부는 CSS에 의존하고, 일부는 그렇지 않는 경우에는 두개로 분할하는 것이 가장 빠른 방식이다.

```html

<script src="i-need-to-block-dom-but-DONT-need-to-query-cssom.js"></script>

<link rel="stylesheet" href="app.css" />


<script src="i-need-to-block-dom-but-DO-need-to-query-cssom.js"></script>
```

이러한 로딩 순서를 이용하면, 다운로드와 실행이 모두 최적의 순서로 발생된다.

## `<link rel="stylesheet" />`는 `<body/>`에 위치 시키기

기존 HTTP 1.1 에서는 모든 스타일을 하의 기본 번들로 연결하는 것이 일반적이다.

```html
<!DOCTYPE html>
<html>
  <head>
    <link rel="stylesheet" href="app.css" />
  </head>
  <body>
    <header class="site-header">
      <nav class="site-nav">...</nav>
    </header>

    <main class="content">
      <section class="content-primary">
        <h1>...</h1>

        <div class="date-picker">...</div>
      </section>

      <aside class="content-secondary">
        <div class="ads">...</div>
      </aside>
    </main>

    <footer class="site-footer"></footer>
  </body>
</html>
```

그러나 위 코드는 아래와 같은 비효율성이 있다.

1. 실제 페이지에서 필요한 css는 일부분 이지만, 필요한 것보다 더 많은 `app.css`를 다운로드 하고 있다.
2. 캐시전략이 비효율적이다. 예를 들어서 특정 섹션의 배경색만 변경하기 위해서는, `app.css` 전체의 캐시를 버려야 한다.
3. 현재 페이지에서 `app.css`의 어느정도를 필요로 하든지간에, 전체 내용이 도착하기 전까지 렌더링이 블로킹 된다.

이제 http/2 를 사용하면 1, 2번 문제를 해결할 수 있다.

```html
<!DOCTYPE html>
<html>
  <head>
    <link rel="stylesheet" href="core.css" />
    <link rel="stylesheet" href="site-header.css" />
    <link rel="stylesheet" href="site-nav.css" />
    <link rel="stylesheet" href="content.css" />
    <link rel="stylesheet" href="content-primary.css" />
    <link rel="stylesheet" href="date-picker.css" />
    <link rel="stylesheet" href="content-secondary.css" />
    <link rel="stylesheet" href="ads.css" />
    <link rel="stylesheet" href="site-footer.css" />
  </head>
  <body>
    <header class="site-header">
      <nav class="site-nav">...</nav>
    </header>

    <main class="content">
      <section class="content-primary">
        <h1>...</h1>

        <div class="date-picker">...</div>
      </section>

      <aside class="content-secondary">
        <div class="ads">...</div>
      </aside>
    </main>

    <footer class="site-footer"></footer>
  </body>
</html>
```

이제 모든 것을 다 다운로드 하는 대신에, 페이지에 필요한 css만 다운로드 할 수 있다. 그러면 주요 렌더링 과정에서 차단 CSS의 크기가 줄어든다. 또한 캐시 전략을 보다 신중하게 선택할 수 있다. 캐시가 필요한 파일만 날리고, 나머지는 유지한다.

하지만 여전히 해결하지 못한 점은 이 모든 것이 렌더링을 가로막는 다는 것이다. 여전히 우리 사이트는 가장 느린 스타일시트의 속도에 좌우되고 있다. 그러나 이제 크롬 69버전 이후, 파이어폭스, IE/Edge 등에서 아래와 같은 코드가 가능해진다.

```html
<!DOCTYPE html>
<html>
  <head>
    <link rel="stylesheet" href="core.css" />
  </head>
  <body>
    <link rel="stylesheet" href="site-header.css" />
    <header class="site-header">
      <link rel="stylesheet" href="site-nav.css" />
      <nav class="site-nav">...</nav>
    </header>

    <link rel="stylesheet" href="content.css" />
    <main class="content">
      <link rel="stylesheet" href="content-primary.css" />
      <section class="content-primary">
        <h1>...</h1>

        <link rel="stylesheet" href="date-picker.css" />
        <div class="date-picker">...</div>
      </section>

      <link rel="stylesheet" href="content-secondary.css" />
      <aside class="content-secondary">
        <link rel="stylesheet" href="ads.css" />
        <div class="ads">...</div>
      </aside>
    </main>

    <link rel="stylesheet" href="site-footer.css" />
    <footer class="site-footer"></footer>
  </body>
</html>
```

이를 활용하면 페이지를 점진적으로 렌더링할 수 있다. 자세한 내용은 [여기](https://jakearchibald.com/2016/link-in-body/)를 참조.

## 요약

- 렌더링 시작에 필요하지 않은 CSS 를 지연시킨다.
  - Critical CSS로 분리하거나
  - CSS를 미디어 쿼리로 분리한다.
- `@import`의 사용을 줄인다.
- 동기 CSS와 자바스크립트의 순서에 주의한다.
  - CSS 이후에 있는 자바스크립트는 CSSOM이 구성되기 전까지 실행되지 않는다.
- DOM이 필요로 하는 CSS만 불러온다.
  - 이는 점진적 렌더링을 가능하게 하고, 초기 렌더링을 블록하지 않는다.

내 일이 아니라고 생각하면 관심이 안가더라고

Page 8

자바스크립트의 배열, 그리고 이터러블과 이터레이터 (ES6)

나만의 자바스크립트 polyfill 만들고 공부하기

no return, await, return, await return 의 차이

null과 undefined의 차이, 그리고 역사

CSS와 웹페이지 성능과의 관계