모던 웹사이트의 복잡성과 더불어 브라우저가 CSS를 처리하는 방식 까지 얹혀진다면, 일부 구식장치, 네트워크 지연, 제한된 데이터를 경험하는 사람들에게는 그리 많지 않은 CSS도 병목현상을 겪을 수 있다. 성능은 사용자 경험에서 필수적인 부분이기 때문에, 다양한 디바이스에서 일관된 고품질의 환경을 제공해야하며 이를 위해선 CSS 최적화가 필수다.

이 포스트에서는 CSS의 성능 이슈와, CSS의 성능을 향상 시키기 위해서는 어떤 작업들이 필요한지 다뤄보려고 한다.

## Table of Contents

## CSS는 어떻게 동작하는가

### CSS는 렌더링을 막는다

CSS의 존재 자체 만으로도, CSS가 파싱되기 전까지 브라우저는 렌더링이 지연된다. 대부분의 모던 웹사이트에서 CSS가 존재하지 않는다면 정상적으로 페이지를 이용할 수 없을 것이다. 만약 브라우저가 CSS가 없는 페이지를 그대로 노출된다면, 잠깐 동안 CSS가 파싱되면서 스타일이 적용되는 페이지가 나타나기 전까지 의 시간이 생기고 말 것이다. 이러한 것을 [FOUC(Flash of Unstyled Content)](https://en.wikipedia.org/wiki/Flash_of_unstyled_content)라고 한다.

### CSS는 HTML 파싱도 막을 수 있다.

브라우저가 CSS가 파싱되기 전까지 콘텐츠를 보여주지 않더라도, HTML의 로딩된 부분만을 일단 보여줄 수도 있다. 그러나 스크립트의 경우 `async` `defer` 이 없다면 파싱을 막게 된다. 스크립트는 잠재적으로 페이지를 조작할 여지가 있으므로, 브라우저는 스크립트 실행에 매우 주의를 기울일 필요가 있다.

![js-blocking-html-parsing](https://web-now-rbviiass9-calibreapp.vercel.app/_next/image?url=%2Fimages%2Fblog%2Fcss-performance%2Fparser-blocking-script.png&w=1920&q=75)

스크릡트가 페이지의 스타일에 영향을 줄 수 있기 때문에, 만약 브라우저가 CSS 관련 작업을 진행중이라면, 이 작업이 완료될 때 까지 기다렸다가 스크립트를 실행할 것이다. 스크립트가 실행되기 전까지 문서 파싱을 할 수 없기 때문에, CSS는 더이상 렌더링을 차단하는 요소로 작용하지 않는다. (하단 그림 참조) 문서의 외부 스타일시트 및 스크립트 순서에 따라서 때로는 HTML 파싱도 중지할 수 있다.

![css-can-block-html-parsing](https://web-now-rbviiass9-calibreapp.vercel.app/_next/image?url=%2Fimages%2Fblog%2Fcss-performance%2Fparser-blocking-css.png&w=1920&q=75)

파싱을 차단하는 상황을 피하기 위해서는, CSS를 최대한 빨리 불러와야 하고, 리소스를 최적의 순서로 불러와야 한다.

## CSS 사이즈 지켜보기

### CSS 압축하고 최소화 하기

외부 스타일 시트를 다운로드 하는 작업은 필연적으로 네트워크 지연이 발생지만, 네트워크에 전송되는 바이트의 양을 줄임으로써 이 과정을 최소화 할 수 있다.

파일을 압축하는 것은 속도 향상에 지대한 영향을 미치며, 많은 호스팅 플랫폼과 CDN에서는 기본적으로 애셋을 압축해준다. 가장 널리알려져 있는 압축 솔루션은 GZip이고, Brotil 또한 존재하지만, [Brotli는 일부 브라우저에서 지원을 하지 않는다.](https://caniuse.com/brotli)

Minification (최소화) 과정은 코드에서 필요없는 공백을 지우는 과정이다. 결과물은 이전 코드에 비해서 작아지지만, 브라우저는 충분히 코드를 파싱할 수 있으며 이를 통해 몇 바이트라도 더 절약할 수 있다. 가장 유명한 자바스크립트 압축 툴로 [terser](https://github.com/terser/terser)가 있고, [웹팩 v4 버전 이상 부터는 빌드 파일을 작게하는 도구가 내장되어 있다.](https://webpack.js.org/plugins/css-minimizer-webpack-plugin/)

### 사용하지 않는 CSS 제거

CSS 프레임워크를 사용하게 될 경우, 필요한 컴포넌트만 번들링 하지 않는 이상 사용되지 않는 CSS가 포함되는 것은 일반적인 문제다. 이와 비슷하게, 오랜시간에 걸쳐서 쌓이는 큰 코드 베이스에도 안쓰는 CSS가 남는 경우가 더러 있다.

사용하지 않는 CSS를 제거하는 것은 수동 작업이다. 따라서 코드가 얼마나 복잡하느냐에 따라서 난이도가 증가하게 된다. 이 작업은 웹사이트 전체에서, 가능한 모든 디바이스에서, 가능한 모든 상황에서, 가능한 모든 자바스크립트 실행 결과에 따라서 결정해야 한다. [UnusedCSS](https://unused-css.com/)나 [PurifyCSS](https://purifycss.online/) 와 같은 유명한 툴이 있지만, 항상 visual regression 테스트도 병행해서 이뤄져야 한다.

**바로 이것이 CSS-in-JS를 쓸 때 얻을 수 있는 가장 큰 이점이다. 각 컴포넌트가 렌더링에 필요한 CSS가 js내에 포함되어 있다. (따라서 컴포넌트 레벨로 관리하기 때문에 편하다는 것)** CSS-in-JS는 페이지 내부에 CSS를 인라인 처리하거나, 외부 CSS파일로 따로 번들링 해버린다. CSS를 자바스크립트 내부에 포함시켜 버리면 CSS 파싱과 평가가 느려진다.

## CSS의 우선순위 정하기

Critical CSS란 화면에 보이는 컨텐츠 (above-the-fold content)의 CSS 에 대해서만 inline 처리하는 것을 의미한다. HTML 문서의 `<head/>`에 있는 스타일을 따로 추출해서 인라이닝 하면 스타일을 가여오는 추가 요청을 할 필요가 없어져 렌더링이 빨라진다.

첫 렌더링 시의 라운드트립을 최소화 하기 위해서는, above-the-fold content의 크기를 14kb내로 유지해야 한다. (압축시)

Critical CSS를 정확히 정의하는 것은 어렵다. 디바이스의 크기에 따라서 사용자가 보이는 영역이 달라지기 때문이다. 이는 특히 매우 유동적인 사이트의 인 경우에는 더욱 어려워 진다. 그러나 이는 여전히 성능 향상에 중요한 부분 이므로, [Critical](https://github.com/addyosmani/critical) [CriticalCSS](https://github.com/filamentgroup/criticalCSS) [Penthouse](https://github.com/pocketjoso/penthouse) 등의 도구를 활용해서 자동화 할 필요가 있다.

### CSS 비동기로 불러오기

위 above-the-fold content를 최대한 빠르게 불러오는데 집중했다면, 나머지 영역은 비동기로 로딩하는 것이 최선이다.

```html
<link
  rel="stylesheet"
  href="non-critical.css"
  media="print"
  onload="this.media='all'"
/>
```

`"Print"` 미디어 타입이란, 사용자가 페이지를 프린트를 하려고 하는 경우에만, 브라우저가 해당 스타일 시트를 불러오는 것으로 렌더링에는 영향을 미치지 않는다. 그리고 여기에 `onload` 이벤트로 `this.media='all'`를 추가한다면, 스타일 시트가 로드가 완료되면 미디어 속성을 다시 `all`로 바꾸면서 스타일 시트가 적용된다.

또 다른 방법은 `<link rel="preload">`를 사용하는 것이다. 그러나 이 방법은 아래와 같은 단점이 있다.

- [브라우저 지원이 여전히 시원치 않으므로](https://caniuse.com/?search=preload), [loadCSS](https://github.com/filamentgroup/loadCSS/)와 같은 폴리필이 필요하다.
- `preload`는 생각보다 매우 이른 타이밍에, 높은 우선순위로 다운로드 되므로 다른 중요한 애셋의 다운로드 우선순위를 밀어 버릴 수 있다.
  - https://developer.mozilla.org/ko/docs/Web/HTML/Preloading_content

```html
<link rel="preload" href="/path/to/my.css" as="style" />
<link
  rel="stylesheet"
  href="/path/to/my.css"
  media="print"
  onload="this.media='all'"
/>
```

> https://www.filamentgroup.com/lab/load-css-simpler/

### @import 사용 자제하기

`@import`는 CSS파일의 렌더링 속도를 느리게 한다. 특히 `@import url(imported.css)`와 같은 코드는 네트워크 흐름을 아래와 같이 바꿔버린다.

![@import](https://web-now-rbviiass9-calibreapp.vercel.app/_next/image?url=%2Fimages%2Fblog%2Fcss-performance%2Fcss-import-blocking.png&w=1920&q=75)

그러나 두 파일을 별개로 분리하면 이런식으로 동시에 다운로드 하게 된다.

![parallel](https://web-now-rbviiass9-calibreapp.vercel.app/_next/image?url=%2Fimages%2Fblog%2Fcss-performance%2Fcss-parallel-download.png&w=1920&q=75)

## 효과적인 CSS 애니메이션 사용하기

페이지에 애니메이션이 있는 요소가 있는 경우, [브라우저는 종종 문서 내 요소의 위치와 크기를 재 계산한다.](https://calibreapp.com/blog/investigate-animation-performance-with-devtools#animation-performance) (레이아웃 발생) 예를 들어, 어떤 요소의 너비를 바꾸게 되면, 그 자식 요소들 까지 영향을 미치면서 페이지 내부에서 큰 레이아웃이 발생할 수 있다. 그리고 이 레이아웃의 크기가 커질 수록, 성능에 안좋은 영향을 미칠 것이다.

요소에 애니베이션을 넣을 때는, 레이아웃과 리페인트가 최소한으로 이뤄지도록 해야 한다. 모든 CSS 애니메이션 기술이 동일하지 않으며, 모던 브라우저에서는 위치, 크기, 회전, 불투명도 등을 가진 고성능 애니메이션을 만들 수 있다.

- `height` `width` 대신 `transform: scale()`을 쓰자
- 요소를 움직이게 하기 위해서는, `top` `right` `bottom` `left` 대신 `transform: translate()`를 쓰자.
- 배경에 blur를 먹이고 싶다면, opacity를 바꾸는 것보다 그냥 blur 된 이미지를 불러오는게 낫다.

### `contain` 속성

[contain](https://developer.mozilla.org/en-US/docs/Web/CSS/contain)은 브라우저에 요소와 하위 요소가 그 문서 트리와 무관한 것으로 간주된다는 것을 알려주는 속성이다. 페이지의 하위 트리와 나머지 페이를 분리한다. 그런 다음, 브라우저는 페이지에서 독립된 부분의 렌더링을 최적화하여 성능을 향상 시킬 수 있다.

`contain`는 페이지 내부에서 독립적으로 작동하는 위젯 등에서 매우 효과적이다. 이 속성을 활용하여 위젯의 내부에서의 변경사항이 바깥으로 전파되는 것을 막을 수 있다.

## CSS로 폰트 로딩 최적화 하기

### 폰트 로딩 중에는 보이지 않는 텍스트를 두지 않기

폰트는 로딩하는데 시간이 걸리는 큰 파일인 경우가 많다. 일부 브라우저는 폰트가 로딩되기 전까지 텍스트를 숨긴다. (FOIT, flash of invisible text) 속도를 최적화 하기 위해서는 보이지 않는 텍스트가 갑자기 나타나는 현상(FOIT)을 피하고, 시스템 폰트를 기본으로 사용하여 즉시 사용자에게 콘텐츠를 보여주는 것이 좋다. 폰트가 로딩 되면, 시스템 기본 글꼴로 로딩된 폰트를 대체 하는 FOUT(flash of unstyled text) 현상이 일어날 것이다.

이를 위한 방법 중 하나가 [font-display api](https://developer.mozilla.org/ko/docs/Web/CSS/@font-face/font-display)를 사용하는 것이다. `swap`을 사용하면, 브라우저가 폰트가 다운로드 되기 전에는 즉시 시스템 글꼴로 보여줘야 한다는 것을 알려줄 수 있다.

### variable font를 사용하여 파일 크기 줄이기

[Variable Font](https://variablefonts.io/)는 모든 너비, weight,style에 대해서 별도의 폰트 파일이 아니라 하나의 파일에 여러가지 다양한 폰트를 통합해줄 수 있도록 한다. CSS와 단일 `@font-face` 참조로 지정된 글꼴의 다양한 변형에 액세스 할 수 있다.

이는 글꼴의 여러 변형이 필요한 파일 크기를 획기적으로 줄일 수 있다. 일반, 볼드, 기울임꼴 폰트 버전을 각각 로딩 하는 대신 모든 정보가 포함된 하나의 단일 파일을 로딩할 수 있다.

[Monotype](https://www.monotype.com/resources/expertise/truetype-gx-variable-fonts) 에서는 12개의 폰트를 결합하여 이탤릭과 로만 모두에 3개의 다른 너비, 8개의 다른 weight를 생성하는 실험을 한 바 있다. 하나의 variable font에 48개의 개별글꼴을 모두 저장함으로써 파일의 크기가 88% 감소했다.

## CSS 선택자의 속도에 대해서 걱정할 필요는 없다.

CSS 셀렉터를 구조화하는 방법에 따라서 브라우저가 CSS를 매칭하는데 필요한 속도가 달라진다. 브라우저는 셀렉터를 오른쪽에서 왼쪽으로 읽기 때문에 자식에서 부모로 거쳐서 올라가게 된다.. 예를 들어, `nav a {}`가 있다면, 모든 `<a/>`를 찾고, 그 다음에 `nav` 하위에 있는 `<a/>`를 찾는다. 따라서 만약 선택자를 `<nav/>` 내부에 있는 `<a/>`에 대해서 `.nav-link`로 지정하 찾는다면, 전체 페이지에서 `<a/>`를 찾는 수고로움을 덜할 것이다. 따라서 `.container ul li a { }`와 같은 선택자는 따라서 비용이 많이 발생하게 된다.

선택자를 매칭 시키는 속도는 굉장히 빠르므로 굳이 걱정할 필요는 없다. CSS 선언은 압축 알고리즘에 매우 유연하게 동작하기 때문에, CSS 선택자를 최적화하는데 필요한 노력은 투자대비 더 큰 수익으로 다가올 것이다.

## 결론

CSS는 페이지 로딩과 유익한 사용자 경험을 주기 위한 필수적인 요소다. js나 image와 같은 요소에 최적화 하다보면, css에도 관심이 필요하다는 것을 잊을 수 있다. 위의 전략들을 활용하다보면, 사용자에게 더 빠르고 최적화된 웹사이트를 제공할 수 있을 것이다.


CSS의 황제가 출간한 CSS 완벽가이드를 장식용으로 구매...

CSS 성능 향상 시키기

## 요약

| method                       | Visible   | Accessible |
| ---------------------------- | --------- | ---------- |
| `.sr-only`                   | X         | O          |
| `aria-hidden="true"`         | O         | X          |
| `hidden=""`                  | X         | X          |
| `display: none`              | X         | X          |
| `visibility: hidden`         | X (Space) | X          |
| `opacity: 0`                 | X (Space) | Depends?   |
| `clip-path: circle(0)`       | X (Space) | Depends?   |
| `transform: scale(0)`        | X (Space) | O          |
| `width: 0`+`height: 0`       | X         | X          |
| `content-visibility: hidden` | X         | X          |

## `.sr-only`

`.sr-only`는 페이지에서는 가리지만, 스크린 리더에서는 접근 가능하도록 하는 일종의 CSS 선언이다. [bootstrap에 이와 관련된 코드가 있다](https://getbootstrap.com/docs/4.0/utilities/screenreaders/)

```css
.sr-only {
  border: 0 !important;
  clip: rect(1px, 1px, 1px, 1px) !important;
  -webkit-clip-path: inset(50%) !important;
  clip-path: inset(50%) !important;
  height: 1px !important;
  overflow: hidden !important;
  padding: 0 !important;
  position: absolute !important;
  width: 1px !important;
  white-space: nowrap !important;
}
```

이 방법은 텍스트를 마스킹하는데만 사용해야 한다. 다시 말해, 숨겨진 요소안에 focus 가능한 엘리먼트가 있어서는 안된다. 그렇지 않으면, 보이지 않는 엘리먼트가 스크롤이 되는 등의 귀찮은 일이 있을 수 있다.

## `aria-hidden` 속성

[aria-hidden](https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/ARIA_Techniques/Using_the_aria-hidden_attribute)이 `true`로 설정되면, accessibility tree에서 해당 콘텐츠를 가리지만, 여전히 시각적으로는 볼수 있다. `aria-hidden="true"` 엘리먼트에 기본 스타일을 적용하는 브라우저는 없다.

주의 할 점은 , `aria-hidden="true"`가 focusable한 요소가 되어서는 안된다는 것이다. 스크린리더에는 보이지 않지만, focus가 되기 때문이다.

```html

<button aria-hidden="true">press me</button>
```

## `display: none`과 `hidden`속성

이 두가지 방법은 모두 렌더링트리와 접근성 트리에서 사라지게 한다. `hidden`은 별도의 CSS가 없이도 HTML을 통해서 완전히 마스킹할 수 있어서 편리한 점이 있다.

## `visibility :hidden`

이 css 속성은 레이아웃에 영향을 미치지 않고 엘리먼트를 감춘다. 사라진 공간은 빈 공간으로 남으며, 리플로우가 일어나지 않는다. 접근성 관점에서 보았을 때는 위의 `display:none`과 동일하다.

## `opacity:0`, `clip-path: circle(0)`

이 두 속성은 엘리먼트의 요소를 안보이게 하지만, `visibility: hidden`과 마찬가지로 빈공간이 남아 있게 된다. 이 콘텐츠에 접근할 수 있는지 여부는 접근성 기술에 따라 다르다. 따라서 일관되게 숨시려면 이것을 사용하지 않는 것이 좋다.

## `transform: scale(0)`

시각적으로 엘리먼트를 감추지만, 위 두속성과 마찬가지로 빈공간이 남는다. 그러나 스크린 리더에서는 이 요소에 접근할 수가 있다.

## `width: 0`, `height: 0`

특정 요소의 너비와 높이를 0으로 설정하여 숨기는 방식으로, 스크린리더 또한 이 엘리먼트가 접근 가능하지 않은 것으로 간주하고 건너뛴다. 그러나 이 기술은 일종의 낚시(?ㅋㅋ)같은 수상한 기술이고, SEO 차원에서도 좋지 못하다.

## `content-visibility: hidden`

[이 속성](https://developer.mozilla.org/en-US/docs/Web/CSS/content-visibility)은 크롬브라우저에서 특정 요소의 렌더링을 뷰포트내에 있기전까지는 가리는 방법으로 도입되었다. 이 속성은 `display: none`과 마찬가지로 접근성 트리에서 사라진다. 접근성차원에서 봤을 때는 그다지 좋은 기술은 아니므로 쓰지 않는 것이 좋다.

- https://web.dev/content-visibility/
- https://wit.nts-corp.com/2020/09/11/6223

## 요약

일반적으로 말하자면, 시각적인 내용과 접근성으로 노출되는 내용간에 너무 많은 불일치가 존재해서는 안된다. 둘 모두에게 잘 동기화된 내용을 보여주어야 한다.

- 만약 화면과 접근성 모두에서 가리고 싶다면, `display:none` `hidden`을 사용하는 것이 좋다. (위젯을 토글하거나, 다이얼러그를 닫는 등)
- 접근성에서는 감추지만 시각적으로 보이고 싶을 경우에는, `aria-hidden="true"`를 사용하자. (아이콘과 같은 경우)
- 화면에서는 가리지만 접근성에서는 보이고 싶을 경우, `.sr-only`를 쓰자. (링크나 아이콘 버튼과 같이 접근성요소로 정보를 제공하고 싶은 경우)

원래 알던건 두 세가지밖에 안됨

HTML과 CSS를 활용해서 콘텐츠를 숨기는 10가지 방법

## Table of Contents

## 시작하며

자바스크립트 커뮤니티에서 요즘 가장 중요하게 생각하는 것중 하나는 번들 사이즈 인것 같다. 얼마나 많은 의존성을 가지고 있는가? 번들 사이즈를 더 작게 만들수는 없나? 레이지 로드를 잘 활용하고 있나? 사람들이 번들 사이즈에 대해 집착하는 이유 중 하나는 아무래도 눈에 잘 띈다는 점 때문일 거다. 물론, 번들 사이즈가 중요하지 않다는 것은 아니다. 하지만 번들 사이즈 외에도 중요한 것은 많이 있다.

- 파싱/컴파일에 걸리는 시간
- 실행 시간
- 파워 사용량
- 메모리 사용량
- 디스크 사용량

자바스크립트의 의존성은 위 모든 지표에 영향을 미친다. 위 지표는 그러나 번들 사이즈에 비해서는 덜 논의되는 편이다. 아무래도 번들사이즈에 비해 측정하기가 어렵기 때문일 것이다.

## 번들 사이즈

자바스크립트 코드의 크기를 논의 할 때, 우리는 명확히 할 필요가 있다. minified는 한 크기인가? gzip도? 트리쉐이킹은 했나? gzip 세팅은 제일 크게 했는가? 혹시 [브로틀리](https://yceffort.kr/2021/01/brotli-better-html-compression)를 사용했는가?

사소한걸 피곤하게 따지는 것 같지만, 사실 크기를 논의 할 때, 특히 압축과 비압축사이에서는 굉장히 중요하다. 압축된 크기는 사용자 브라우저에 얼마나 빠르게 전달되는지에 영향을 미칠 것이고, 비압축된 사이즈는 사용자의 브라우저에서 얼마나 빠르게 파싱되고, 컴파일되고, 실행되는지에 영향을 미칠 것이다.

### Bundlephobia

자바스크립트 라이브러리 크기를 분석하는데 있어서 유용한 툴은 바로 [Bundlephobia](https://bundlephobia.com/)다. 라이브러리의 의존성을 볼 수도 있고, minified된 사이즈와 압축된 사이즈까지 볼수도 있고 다운로드에 걸리는 시간도 볼 수 있다.

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

그러나 bundlephobia를 보는데 있어서 주의를 해야할 것이 있다.

- 여기에는 트리쉐이킹이 반영되있지 않다는 것이다. 라이브러리에서 특정 모듈만을 사용한다면, 다른 모듈들은 트리쉐이킹되어 줄어들 것이다.
- 또한 서브 디렉토리의 의존성에 대해서는 알수가 없다. 예를 들어 `preact`를 가져오는데 한 비용은 알수가 있다. 그러나 `preact/compat`에 대해서는 알 방법이 없다. `compat.js`가 정말 큰 파일이라도 그것을 알 방법이 없다.
- 만약 폴리필이 포함되는 경우 (`Object.assign()`나 `Buffer API`등 번들러가 주입하는 경우) 여기서 반드시 표시되지 않는다.

위의 요소들을 점검하기 위해서는, 번들러를 실행해서 결과물을 확인해보면 된다. 번들러는 서로 다 다르며, 설정과 여러가지 요소에 따라서 크기가 달라질 수 있다.

### Webpack Bundle Analyzer

[Webpack Bundle Analyzer](https://github.com/webpack-contrib/webpack-bundle-analyzer)는 웹팩 결과물로 나온 모든 청크들을 잘 보여주고, 어떤 모듈이 청크들을 구성하는지 확인할 수 있다.

![Webpack Bundle Analyzer](https://cloud.githubusercontent.com/assets/302213/20628702/93f72404-b338-11e6-92d4-9a365550a701.gif)

여기서 중요한 것은 `Parsed`와 `Gzipped`다. Bundlephobia와는 다르게 실제로 번들러를 거쳤을 때 의 크기를 볼 수가 있다.

### Rollup Plugin Analyzer

[Rollup Plugin Analyzer](https://github.com/doesdev/rollup-plugin-analyzer)는 번들의 크기를 빌드하는 과정에서 콘솔로도 볼 수 있다. 그러나, minified나 gzipped한 크기는 볼수가 없다.

그 외에도 아래와 같은 도구가 있다.

- [bundlesize](https://github.com/siddharthkp/bundlesize)
- [Bundle Buddy](https://www.npmjs.com/package/bundle-buddy)
- [Sourcemap Explorer](https://github.com/danvk/source-map-explorer)
- [Webpack Analyse](https://github.com/webpack/analyse)

## 번들 크기 말고 다른 것

앞에서도 언급했듯이, 번들사이즈가 전부는 아니다. 이 외에도 살펴볼 만한 다양한 것들이 많다.

### Runtime CPU Cost

첫번째 이자 가장 중요한 것중 하나는 런타임 시의 비용이다. 이는 여러가지 요소로 나눠서 생각해 볼 수 있다.

- Parsing
- Compilation
- Execution

이 세가지 요소는 기본적으로 엔드 투 엔드 비용으로, `require('something')` 이나 `import 'something'`를 호출 할 때 발생한다. 번들사이즈와도 연관이 있지만, 반드시 일치하는 것은 아니다.

```javascript
const start = Date.now()
while (Date.now() - start < 5000) {}
```

위의 이상한 코드를 살펴보자. Bunldephobia에서는 위 코드가 높은 점수를 받겠지만 (코드의 크기가 작기 때문에) 메인스레드를 무려 5초나 잡아먹는다. 위의 예제 처럼, 작은 라이브러리가 메인스레드에 악영향을 미치는 경우가 더러있다. DOM의 모든 요소를 순회하거나, 로컬 스토리지에 큰 배열을 포문을 돌거나 하는 등. 직접 모든 의존성을 하나하나 살펴 보지 않는 한, 내부에서 무엇을 하는지 알 수 없다.

Parsing과 Compilation은 모두 측정하기 어려운 항목이다. 브라우저는 바이트 코드 캐싱에 대한 최적화 기능을 가지고 있기 때문에 이 것들을 알기가 쉽지 않다. 예를 들어, 브라우저가 두세번째 페이지 로딩 부터는 파싱과 컴파일 단계를 거치지 않는다. 또는 자바스크립트가 서비스워커에서 캐싱을 했을 수도 있다. 따라서 실제로 브라우저가 미리 모듈을 캐시한다면, 모듈을 파싱하고 컴파일하는데 비용이 적게 든다고 생각할 수 있다.

따라서 100% 제대로 확인할 수 있는 방법은, 브라우저 캐시를 완전히 지우고 첫 페이지를 로딩하는 것이다. 일반적으로 이러한 작업은 private 모드나 주로 사용하지 않는 브라우저에서 이 작업을 수행한다. 또한 브라우저 확장 기능을 꺼둬야 한다.

또한 크롬의 기능을 활용하여 CPU 쓰로틀링을 4x 또는 6x를 설정해두는 것도 좋은 방법이다. 이는 하이엔드 개발자의 컴퓨터 보다 훨씬 더 실제 사용자를 더 잘 대표할 수 있다.

네트워크 속도의 경우, 네트워크 속도 조절 기능을 사용할 수 있다. (3G)

이를 모두 요약하자면, 다음과 같은 단계를 거친다.

1. 사생활 보호 모드로 브라우저를 킨다
2. `about:blank` 로 진입한다. (브라우저 홈 화면의 `unload` 이벤트를 측정하지 않기 위해)
3. 크롬의 DevTool을 연다
4. Performance Tab을 연다
5. Cpu와 네트워크 쓰로틀링을 켠다.
6. Record 버튼을 누른다
7. URL을 입력하고 엔터를 친다.
8. 페이지 로딩이 끝나면 레코딩을 중지한다.

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

이제 최초 페이지 로딩시에 자바스크립트 코드가 parse, compile, execution에 걸리는 시간을 측정할 수 있다.

이에 덧붙여 [User Timing API](https://developer.mozilla.org/en-US/docs/Web/API/User_Timing_API)를 활용해서 웹 애플리케이션의 일부를 사용자에게 의미 있는 이름으로 표시한다. 루트 애플리케이션의 초기렌더링, 블로킹 XHR 호출 등 비용이 많이 들 것으로 우려되는 부분에 초점을 맞춘다. 만약 이러한 측정 작업으로 인한 오버헤드가 우려되는 경우, 프로덕션에서 이러한 기능을 제거하는 방법도 있다. [쿼리 파라미터를 사용해서](https://github.com/nolanlawson/pinafore/blob/ba3b76f769455908eca9f6f59584d18e2bd19f0e/src/routes/_utils/marks.js) 측정 기능을 끌 수도 있고, [terser의 pure_funcs](https://terser.org/docs/api-reference.html#compress-options)를 활용해서 제거할 수도 있다.

```javascript
const enabled =
  process.browser &&
  performance.mark &&
  (process.env.NODE_ENV !== 'production' ||
    (typeof location !== 'undefined' && location.search.includes('marks=true')))

const perf = process.browser && performance

export function mark(name) {
  if (enabled) {
    perf.mark(`start ${name}`)
  }
}

export function stop(name) {
  if (enabled) {
    perf.mark(`end ${name}`)
    perf.measure(name, `start ${name}`, `end ${name}`)
  }
}
```

또 다른 유용한 도구는 [mark loader](https://github.com/statianzo/mark-loader)다. 이 플러그인은 디펜던시 런타임 비용을 볼수 있오록 모듈을 측정 api로 감싸는 웹팩 플러그인이다.

런타임 성능을 측정 할 때 한 가지 주의해야 할 점은, 축소된 코드와 그렇지 않은 코드 사이에 다를 수 있다는 것이다. 사용되지 않는 함수들이 제거 될 수 있고, 코드가 더 작아지고 최적화 될 수 있으며, `env.NODE_ENV === 'development'`로 인해 프로덕션 모드에서 코드가 정제될 수도 있다. 이러한 상황을 잘 해결할 수 있는 방법은, `performance.mark`와 `performance.measure`를 활용하는 것이다.

### Poser Usage

굳이 환경보호론자가 아니더라도 전력 사용을 최소화하는 것이 중요하다는 것은 누구나 알 것이다. 사람들은 점점 전원 콘센트가 꽂히지 않은 모바일 기기에서 웹을 많이 검색하고 있다. 그리고 고객들은 잘못된 웹사이트 때문에 전력이 바닥나는 것을 원치 않을 것이다.

전력 사용량은 CPU 사용량의 부분집합으로 취급되곤 한다. 몇 가지 예외를 제외하면, 대부분의 경우 웹사이트가 과도한 전력을 사용하는 이유는 메인스레드에서 과도하게 CPU를 사용하기 때문이다.

따라서 앞에서 설명한 자바스크립트의 parse/compile/execute 시간을 개선한다면, 전력 소비량도 줄일 수도 있다. 특히 수명이 긴 웹 애플리케이션의 의 경우, 대부분의 전력 소모가 첫 페이지 로드 이후에 발생한다. 그렇게 되면 사용자가 유휴 웹 페이지만 보고 있어도, 노트북 팬이 돌아가거나, 휴대폰이 뜨거워지는 것을 알아차릴 수 있다.

이러한 상황에서 선택할 수 있는 도구는 앞서 말한 Chrome DevTools의 Performance 탭이다. 일반적으로, 타이머 또는 애니메이션으로 인해 CPU 사용량이 증가한다. 예를 들어 잘못 코딩된 커스텀 스크롤바, Intersection Observer Polyfill 또는 애니메이션 로딩 스피너는, 매 requestAnimationFrame 이나 setInterval 루프에서 반복되고 있을 수 있다.

이러한 종류의 전원 누수는 또한 최적화되지 않은 CSS 애니메이션으로 인해 발생할 수 있다. 즉, 자바스크립트의 문제가 아닐 수도 있다. (이 경우 Chrome UI에서 보라색으로 표시된다.) CSS 애니메이션을 오래 실행하는 경우, GPU 가속 CSS 속성을 사용해야 한다.

Chrome Performance Monitor Tab은 Performance Tab과 다르다. 수동으로 추적을 시작/중지할 필요 없이 웹사이트가 작동하는 방식을 보여주는 일종의 하트비트 모니터다. 비활성 웹 페이지에서 CPU 사용량이 일정하지 않으면 전원 사용에 문제가 있을 수 있다.

![performance monitor](./images/performance-monitor.png)

> [performance monitor](https://developers.google.com/web/updates/2017/11/devtools-release-notes#perf-monitor)

### Memory Cost

메모리 사용량 분석은 어려웠지만, 최근에는 많은 도구들이 나오면서 개서되었다.

한가지 중요한 것은, 메모리 사용량과 메모리 누수는 별개의 문제라는 것이다. 별도의 메모리 누수가 없다 하더라도, 메모리 사용량이 높을 수도 있다. 반면 작은 규모의 웹사이트가, 유출로 인하여 메모리 사용량이 커질 수도 있다.

메모리 사용량을 분석하는 api는 [performance.measureUserAgentSpecificMemory](https://www.chromestatus.com/feature/5685965186138112)가 있다. 이 API는 다음과 같은 이점이 있다.

1. 가비지 콜렉팅 된 이후에 resolve 되는 Promise를 반환한다.
2. 자바스크립트 VM 크기 뿐만 아니라, 웹 워커와 iframe 등을 포함하는 DOM 메모리도 포함한다.
3. site isolation로 인해 프로세스가 분리된 cross-origin iframe도 세분화한다. 따라서 embedded나 광고가 메모리를 얼마나 먹는지 판단할 수 있다.

```javascript
{
  bytes: 60_000_000,
  breakdown: [
    {
      bytes: 40_000_000,
      attribution: [
        {
          url: "https://foo.com",
          scope: "Window",
        },
      ]
      types: ["JS"]
    },
    {
      bytes: 0,
      attribution: [],
      types: []
    },
    {
      bytes: 20_000_000,
      attribution: [
        {
          url: "https://foo.com/iframe",
          container: {
            id: "iframe-id-attribute",
            src: "redirect.html?target=iframe.html",
          },
        },
      ],
      types: ["JS"]
    },
  ]
}
```

위에 있는 `bytes`는 사용중인 메모리 양을 나타내는 지표다.

이 API를 사용하는 것은 그럼에도 여전히 까다로울 수 있다. 일단 Chrome 89+에서만 사용할 수 있다. (오래된 버전의 경우 실험용 기능을 체크하고 쓸 수 있다) 그러나 더 문제가 되는 것은, 이를 남용할 가능성 때문에 이 API의 호출은 cross-origin 의 격리된 컨텍스트로 제한되었다는 것이다. 따라서 일부 특수 헤더를 설정해야 하며, cross-origin 리소스 (외부 CSS, 자바스크립트, 이미지 등)에 의존하는 경우 일부 특수 헤더도 설정해야 한다.

이 API를 자동화된 테스트에만 사용할 계획이라면, `--disable-web-security`플래그를 사용하여 크롬을 실행할 수 있다. (물론 어느 정도 위험성을 감수해야 한다.) 그리고 또한가지 참고해야 할 것은, 메모리 측정은 헤드리스 모드에서는 작동하지 않는다는 것이다.

물론, 이 API 는 세분화해서 데이터를 제공하지 않는다. 예를 들어 리액트와 lodash가 각각 몇 바이트를 차지 하는지는 정확히 알 수 없다는 뜻이다. 이를 위한 가장 확실한 방법은 A/B 테스트다. 이는 메모리 측정을 위해 기존에 사용햇던 방법보다 훨씬더 나은 방법이다.

### Disk Usage

디스크 사용량은 장치에 따라 사용 가능한 저장 용량에 따라 브라우저 할당량 제한에 걸릴수도 있으므로 웹 애플리케이션 사용에 있어서 중요하게 고려해야 한다. 과도한 스토리지 사용은 서비스워커 캐시에 너무 많은 대용량 이미지를 채우는 등 여러가지 형태로 나타날 수 있으며, 자바스크립트 또한 마찬가지다.

자바스크립트 모듈의 디스크 사용량이 번들 크기와 직접적인 상관관계가 있다고 생각할 수 있지만, 꼭 그런것 만은 아니다. 예를 들어 [emoji-picker-element](https://github.com/nolanlawson/emoji-picker-element)의 경우, 이모지 데이터를 indexeddb에서 꽤나 무겁게 사용하고 있기 때문에, 데이터베이스가 디스크 사용을 어떻게 사용하고 있는지 인식해야 한다.

![application-storage](./images/application-storage.png)

크롬 DevTools에 있는 Application Tab에서 현재 웹사이트가 사용하고 있는 전체 용량을 알 수가 있다. 처음 보기엔 괜찮아 보이지만, IndexedDB 의 경우 브라우저 마다 구현 방식이 다르기 때문에 브라우저 마다 차지하는 용량이 다르게 나타날 수 있다. 이를 해결할 수 있는 방법 중하나는 Puppeteer와 비슷한 [Playwright](https://github.com/microsoft/playwright)에서 아래 코드를 실행하는 것이다.

```javascript
function getIdbFolder(browserType, userDataDir) {
  switch (browserType) {
    case 'chromium':
      return path.join(
        userDataDir,
        `Default/IndexedDB/http_localhost_${port}.indexeddb.leveldb`,
      )
    case 'firefox':
      return path.join(
        userDataDir,
        `storage/default/http+++localhost+${port}/idb`,
      )
    case 'webkit':
      return path.join(
        userDataDir,
        `databases/indexeddb/v1/http_localhost_${port}`,
      )
  }
}
```

초기화된 빈 브라우저를 시작할 수 있으므로, 브라우저를 먼저 시작하고 `/temp`에 스토리지를 기록한다음, 인덱싱된 스토리지를 측정하는 것이 가능하다.

## 결론

성능이란 것은 다방면적인 측면을 고려 해야 한다. 번들 사이즈만 줄여서 해결된다면 좋겠지만, 여러가지 측면을 고려해야 한다. 이 때문에 이것이 굉장히 부담스럽게 느껴질 수도 있다. 그래서 [core web vital](https://web.dev/vitals/)이나 번들 사이즈에 집중해서 문제를 해결하는 것이 꼭 나쁜 것 만은 아니다. 웹 애플리케이션 성능 측정에 여러가지를 고민해야 한다고 말하면, 사람들은 이에 압도되서 아무것도 안 할수도 있다. 그렇지만, 이런 것도 있다는 것을 알아둔다면 최적화에 도움이 되지 않을까.

> 참고: https://nolanlawson.com/2021/02/23/javascript-performance-beyond-bundle-size/


자바스크립트 성능에 중요한 건 번들크기 만은 아니다. 근데 개발 하느라 이것도 잘 못챙기고 있는듯.

자바스크립트 성능과 번들 사이즈

## 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만 불러온다.
  - 이는 점진적 렌더링을 가능하게 하고, 초기 렌더링을 블록하지 않는다.

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

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

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

![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%`를 적용하면 해결이 된다.


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

Browser 1

CSS 성능 향상 시키기

HTML과 CSS를 활용해서 콘텐츠를 숨기는 10가지 방법

자바스크립트 성능과 번들 사이즈

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

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