## Table of Contents

## Introduction

웹 개발자가 웹 페이지 속도를 개선하기 위해서 가장 먼저 알아야할 것은, 웹 페이지 로딩 속도 개선을 위한 테크닉이나 팁이 아닌 바로 브라우저의 동작 원리다. 우리가 최적화 하려고 노력하는 것 만큼, 브라우저도 웹페이지를 로딩할 때 최적화 하려고 더 노력한다. 하지만 우리의 이런 최적화 노력이 의도치 않게 브라우저의 최적화 노력을 방해할 수도 있다.

페이지 속도 개선에 있어 가장 먼저 이해해야할 것 중 하나는 바로 브라우저의 프리로드 스캐너다. 프리로드 스캐너는 무엇인지, 그리고 우리가 이 작업을 방해하지 않기 위해서는 무엇을 해야 하는지 알아보자.

## Pre-load Scanner란 무엇인가

모든 브라우저는 raw markup 상태의 파일을 [토큰화](https://en.wikipedia.org/wiki/Lexical_analysis#Tokenization) 하고, [객체 모델](https://developer.mozilla.org/ko/docs/Web/API/Document_Object_Model)로 처리하는 HTML 파서를 기본적으로 가지고 있다. 이 모든 작업은 이 파서가 `<link />` 또는 `async` `defer`가 없는 `<script />`와 같은 [블로킹 리소스](https://web.dev/render-blocking-resources/)를 만나기 전 까지 계속 된다.

![html-parser](https://web-dev.imgix.net/image/jL3OLOhcWUQDnR4XjewLBx4e3PC3/mXRoJneD6CbMAqaTqNZW.svg)

CSS 파일의 경우, [스타일링이 적용되지 않는 콘텐츠가 잠깐 뜨는 현상(Flash of unstyled content, AKA FOUC)](https://en.wikipedia.org/wiki/Flash_of_unstyled_content)을 방지하기 위해 파싱과 렌더링이 차단된다.

그리고 자바스크립트의 경우에는, 앞서 언급했듯 `async` `defer`가 없는 `<script/>`를 만나게 되면 파싱과 렌더링 작업이 중단된다.

> `<script />`에 `type=module`이 있다면 기본적으로 `defer`로 동작한다.

그 이유는 HTML 파서가 동작하는 동안, 이 스크립트가 DOM을 수정할 것인지 브라우저 입장에서는 알 수 없기 때문이다. 따라서 일반적으로는 이러한 자바스크립트를 문서의 끝에 두어 렌더링 및 파싱에 미치는 영향을 제한하는 것이 일반적이다.

어쩄든, 이러한 중요한 파싱 단계를 차단하는 것은 바람직하지 않다. 왜냐하면 다른 중요한 리소스를 찾는 과정을 지연시킴으로써 퍼포먼스를 저하시킬 수 있기 때문이다. 이러한 문제를 완화 시키기 위한 것이 바로 프리로드 스캐너라고 하는 보조 HTML 파서다.

![pre-load scanner](https://web-dev.imgix.net/image/jL3OLOhcWUQDnR4XjewLBx4e3PC3/6lccoVh4f6IJXA8UBKxH.svg)

> 기본 HTML 파서는 CSS를 로딩하고 처리할 때 블로킹 되지만, 프리로드 스캐너는 마크업에서 이미지 리소스를 찾고 기본 HTML 파서가 차단 해제되기전에 로드를 시작할 수 있다.

이 프리로드 스캐너의 역할은 speculative, 즉 추측에 근거하며, 이 말의 뜻은 기본 HTML 파서가 리소스를 발견하기 전에 먼저 리소스를 찾기위해 마크업 문서를 훑는 다는 것을 의미한다.

## 프리로드 스캐너가 언제 동작하는지 확인하는 방법

앞서 이야기 하였듯이, 렌더링과 블로킹을 차단하는 리소스가 있기 때문에 프리로드 스캐너가 존재한다. 이러한 두 가지 성능 문제가 존재하지 않는다면 딱히 프리로드 스캐너가 필요하지 않을 것이다. 따라서 웹 페이지가 프리로드 스캐너의 이점을 얻을 수 있는지 여부를 파악하는 열쇠는 이러한 블로킹 현상의 존재 여부에 따라 다르기 때문에, 프리로드 스캐너가 동작하는지 알기 위해서는 인위적인 딜레이를 집어넣을 필요가 있다.

[프리로드 스캐너의 동작 방식을 확인해보기 위한 예제 페이지](https://preload-scanner-fights.glitch.me/artifically-delayed-requests.html)

> 결과: https://www.webpagetest.org/result/220612_BiDcZ0_2E9/

먼저 CSS 파일은 렌더링과 파싱을 모두 차단하기 때문에, 스타일 시트를 집어 넣음으로서 아래와 같은 인위적인 딜레이를 집어넣을 수 있다. 이러한 딜레이 덕분에, 프리로드 스캐너가 작동하는 것을 볼 수 있다.

![waterfall-chart](https://www.webpagetest.org/waterfall.php?test=220612_BiDcZ0_2E9&run=1&cached=&step=1)

> css가 블로킹 리소스라서 잠시간 딜레이가 있었지만, 이미지는 프리로드 스캐너가 먼저 발견해서 찾은 모습이다.

이 차트에서 볼 수 있는 것 처럼, 프리로드 스캐너는 렌더링 및 파싱이 차단되는 와중에서 `<img />`를 검색한다. 이 최적화 없이는 차단 되는 동안 리소스를 가져올 수 없으므로, 리소스를 가져오는 과정은 동시적이 아닌 연속적으로 이루어질 것이다.

## async script 삽입

`<head/>`에 아래와 같은 자바스크립트를 삽입해보자.

```html
<script>
  const scriptEl = document.createElement('script')
  scriptEl.src = '/yall.min.js'

  document.head.appendChild(scriptEl)
</script>
```

삽입되는 스크립트는 `async`가 기본값이기 때문에 비동기적으로 동작하는 것 처럼 보일 것이다. 즉 가능한 빨리 실행되고, 렌더링을 차단하지 안흔다. 물론, 이는 최적화가 적용되어 있는 것 처럼 보이지만.. 이 인라인 스크립트가 외부 CSS 파일을 로드하는 `<link/>`뒤에 온다고 가정하면 다음과 같은 결과가 나타난다.

[테스트 페이지](https://preload-scanner-fights.glitch.me/injected-async-script.html)

[결과](https://www.webpagetest.org/result/220612_BiDcPM_2FE/)

![waterfall-chart](https://www.webpagetest.org/waterfall.php?test=220612_AiDcHH_2FY&run=1&cached=&step=1)

무슨일이 일어났는지 하나씩 살펴보자.

1. 0초에 문서를 요청했다.
2. 1.3초 쯤에 요청에 대한 첫번째 바이트 응답이 왔다.
3. 2.4초 쯤에 이미지와 CSS 요청이 이루어졌다.
4. 파서가 스타일 시트를 로딩하느라 차단되고, 비동기 스크립트를 주입하는 인라인 자바스크립트가 2.8초 쯤에 나타나기 때문에 스크립트가 제공하는 `async` 기능을 바로 사용할 수 없게 됨

스타일 시트 다운로드가 완료된 이후에만 스크립트에 대한 요청이 발생한다. 따라서 스크립트가 최대한 빨리 실행되지 않는다. 이는 페이지의 TTI(Time To Interactive)에 영향을 미칠 수 있다. 이와 반대로, `<img/>`는 서버에서 제공하는 마크업에서 감소하기 때문에 프리로드 스캐너에 의해 검색될 것이다.

그렇다면 스크립트를 DOM에 주입하는 대신, `async` 값과 함께 일반 `<script/>`를 사용하면 어떻게 될까?

```html
<script src="/yall.min.js" async></script>
```

[웹페이지](https://preload-scanner-fights.glitch.me/inline-async-script.html)

[결과](https://www.webpagetest.org/result/220612_AiDcSY_2HM/)

![waterfall-chart](https://www.webpagetest.org/waterfall.php?test=220612_AiDcSY_2HM&run=1&cached=&step=1)

> 이 페이지는 하나의 스타일 시트와 `async` `<script/>`한개가 포함되어 있다. 프리로드 스캐너는 렌더 블로킹 단계에서 스크립트를 발견하고, CSS와 동시에 로딩한다.

[`rel=preload`](https://developer.mozilla.org/en-US/docs/Web/HTML/Link_types/preload)를 사용하면 문제를 해결할 수도 있지 않을까? 이는 효과적일 수도 있지만, 약간의 부작용이 있을 수 있다. 그렇다면 왜 `<script/>`를 DOM에 주입하지 않음으로써 피할 수 있는 문제를 해결하기 위해 `rel=preload`를 사용하는 이유는 무엇일까?

[웹페이지](https://preload-scanner-fights.glitch.me/preloaded-injected-async-script.html)

[결과](https://www.webpagetest.org/result/220612_AiDcVX_2JA/)

![waterfall-chart](https://www.webpagetest.org/waterfall.php?test=220612_AiDcVX_2JA&run=1&cached=&step=1)

> 이 페이지는 하나의 스타일 시트와 `async` 스크립트를 삽입했는데, `async` 스크립트는 발견되는 즉시 프리로딩 된 것을 알 수 있다.

프리로딩은 여기서 문제를 해결한 것 처럼 보이지만, 처음 두 데모의 `async` 스크립트는 `<head />`에 삽입되었음에도 불구하고 낮은 우선순위로 로드 되는반면, 스타일 시트는 높은 우선순위로 로딩된다. 비도기 스크립트가 preloading된 마지막 데모페이지에서는, 스타일 시트와 스크립트의 우선순위가 모두 높음으로 승격되었다.

> 우선순위는 크롬의 dev tool 네트워크 탭에서 볼 수 있다.

리소스의 우선순위가 올라가면, 브라우저는 더 많은 대역폭을 리소스에 할당한다. 즉, 스타일 시트 우선순위가 가장 높더라도 스크립트의 우선순위가 높아지면 이러한 대역폭에 경합이 발생할 수 있다. 연결 속도가 느리거나, 리소스가 상당히 크다면 이러한 문제가 더 두드러질 수 있다.

답은 간단하다. 스크립트가 웹 페이지 시작중에 실행되어야 한다면 DOM에 삽입하여 프리로드 스캐너를 방해하지 말자. `<script/>` 요소의 위치 뿐만 아니라, `defer` `async` 속성에 대한 실험도 해보면서 확인해봐야 한다.

## 자바스크립트 Lazy Loading

레이지 로딩은 데이터를 불러오기 위한 효과적인 방법으로 일반적으로 이미지에 적용된다. [그러나 때때로 이 레이지 로딩이 above the fold 영역에 있는 이미지에 잘못 적용될 수 있다.](/2022/06/optimize-LCP#lcp-%EB%A5%BC-lazy-load-%ED%95%98%EC%A7%80-%EB%A7%90-%EA%B2%83)

이로인해 프리로드 스캐너가 관련된 리소스를 검색하는 문제에 잠재적으로 문제를 일으킬 수 있으며, 이미지라면 이미지에 대한 참조를 검색하고 다운로드 하고 디코딩하며 표시하는데 걸리는 시간을 불필요하게 지연시킬 수 있다.

```html
<img data-src="/sand-wasp.jpg" alt="Sand Wasp" width="384" height="255" />
```

이 `data-` 자바스크립트에서 주로 활용되는 레이지 로더다. 이미지가 뷰포트로 스캐너 된다면 `lazy-loader` 는 `data-` 를 제거하여 정상적인 `src`로 바꾼다. 그러면 브라우저는 이 리소스를 불러올 것이다.

이 패턴은 페이지 최초 로딩에 걸리지 않는 이미지라면 크게 문제되지 않는다. 그러나 문제는 프리로더 스캐너가 `data-src`와 같은 것은 읽지 않기 때문에 이미지를 일찍 검색하지 못한다. 더 나쁜 것은 이 이미지는 `lazy-loader`가 자바스크립트로 다운로드, 컴파일, 실행 될 때 까지 지연된다.

[웹페이지](https://preload-scanner-fights.glitch.me/js-lazy-load-suboptimal.html)

[결과](https://www.webpagetest.org/result/220612_BiDcPB_2JM/)

![waterfall-chart](https://www.webpagetest.org/waterfall.php?test=220612_BiDcPB_2JM&run=1&cached=&step=1)

이미지의 크기, 뷰포트의 크기에 따라 이 이미지는 LCP에 걸릴수도 있다. 프리로드 스캐너가 미리 이미지 리소스를 가져올 수 없는 경우에는 LCP에 피해를 입을 것이다.

이미지 마크업을 다음과 같이 바꿔보자.

```html
<img src="/sand-wasp.jpg" alt="Sand Wasp" width="384" height="255" />
```

이렇게 최적화 한다면 프리로드 스캐너가 이미지 리소스를 빠르게 검색하고 가져올 수 있기 때문에, LCP에 걸리는 이미지라면 매우 좋은 방법이 될 것이다.

[웹페이지](https://preload-scanner-fights.glitch.me/js-lazy-load-optimal.html)

[결과](https://www.webpagetest.org/result/220612_AiDcMW_2PY/)

![waterfall-chart](https://www.webpagetest.org/waterfall.php?test=220612_AiDcMW_2PY&run=1&cached=&step=1)

이 결과 LCP가 향상되었음을 알 수 있다. 물론 그다지 드라마틱한 효과가 아닌것처럼 보일 수 있지만, 수정해야하는 양이 작고 매우 쉽다. LCP 내 리소스는 다른 많은 자원들과 함께 대역폭을 놓고 경쟁해야하는 경우가 빈번해 지므로 이와 같은 최적화가 중요해지고 있다.

> 이미지 뿐만 아니라 `<iframe>` 도 이와같은 영향을 받을 수 있으며, `<iframe/>`는 하위 리소스가더 많기 때문에 성능에 더 심한 영향을 미칠 수 있다.

## CSS background image

브라우저 프리로드 스캐너는 마크업을 스캔한다. 그러나 프리로드 스캐너는 CSS에 있는 `background-image` 속성에 있는 리소스와 같은 타입의 리소스는 검색하지 않는다.

HTML과 마찬가지로 브라우저는 CSSOM으로 알려진 자체 객체 모델로 CSSOM을 처리한다. 만약 CSSOM에 외부 리소스가 발견된다면, 그런 자원들은 프리로드 스캐너가 아닌 발견된 시점에 리퀘스트가 일어난다.

[웹페이지](https://preload-scanner-fights.glitch.me/css-background-image-no-preload.html)

[결과](https://www.webpagetest.org/result/220612_AiDcCK_2TG/)

![waterfall-chart](https://www.webpagetest.org/waterfall.php?test=220612_AiDcCK_2TG&run=1&cached=&step=1)

이 경우에는 프리로드 스캐너가 관여하지 않는다. 그렇지만서도, 만약 LCP에 CSS background-image가 존재한다면, 아무래도 미리 로드되기를 바랄 것이다.

```html

<link rel="preload" as="image" href="lcp-image.jpg" />
```

이 `rel=preload` 힌트는 작지만, 브라우저가 이미지를 더 빠르게 발견하는데 도움이 된다.

[웹페이지](https://preload-scanner-fights.glitch.me/css-background-image-with-preload.html)

[결과](https://www.webpagetest.org/result/220612_BiDcV2_2T8/)

![waterfall-chart](https://www.webpagetest.org/waterfall.php?test=220612_BiDcV2_2T8&run=1&cached=&step=1)

`rel=preload`를 사용하면 LCP를 빠르게 발견하여 LCP 시간이 단축된다. 이 힌트가 이 문제를 해결하는데 도움이 되었지만, 더 나은 방법도 있다. `<image>`를 사용하면 뷰포트에 적합한 이미지를 로드하는 동시에 프리로드 스캐너가 해당 이미지를 검색할 수 있다.

## 마크업을 클라이언트 사이드 자바스크립트에서 렌더링

당연히 의심할 여지도 없다. [자바스크립트는 페이지 속도에 영향을 미친다.](https://almanac.httparchive.org/en/2021/performance#total-blocking-time-tbt) 자바스크립트를 단순히 사용자와 페이지 간의 상호작용 뿐만 아니라 콘텐츠 자체를 전달하기 위해서도 의존하는 경향이 있다. 이는 개발자에게는 좀더 나은 개발자 경험 (DX)을 줄 수도 있지만, 이 경험이 사용자에게 이어지는 것은 아니다.

이야기한 것 처럼, 프리로드 스캐너에게 안좋은 영향을 미치는 방법은 바로 클라이언트사이드 자바스크립트로 마크업을 렌더링하는 것이다.

[웹페이지](https://preload-scanner-fights.glitch.me/client-rendered.html)

[결과](https://www.webpagetest.org/result/220612_AiDcK5_2WK/)

![waterfall-chart](https://www.webpagetest.org/waterfall.php?test=220612_AiDcK5_2WK&run=1&cached=&step=1)

> 이 페이지는 `preact`를 활용하여 제작되었다. 그렇지만 방법은 단순하다. `html`내부 내용 전체를 단순히 문자열로 넘겨서 렌더링하는 것이다. https://preload-scanner-fights.glitch.me/js/content.js

마크업이 완전히 자바스크립트 코드 내부에 존재해서 렌더링 될 때, 이 마크업 내부의 모든 리소스는 프리로드 스캐너에 감지되지 않는다. 이로인해 주요 리소스 발견은 늦춰지고, LCP에 부정적인 영향을 미친다. 이 예제의 경우 매우 눈에 띄게 서버사이드 렌더링 대비 상당히 지연된 모습을 볼 수 있다.

이 글의 주제에서 약간 벗어나긴 하지만, 렌더링 마크업이 클라이언트에 미치는 영향은 프리로드 스캐너를 능가한다. 최초 페이지 로딩에 필요하지 않은 작업을 위해 자바스크립트를 도입하면, [INP(Interaction Next Paint)](https://web.dev/inp/)에 영향을 줄 수 있는 불필요한 처리시간이 발생해버린다.

또한 클라이언트에서 많은 양의 마크업을 렌더링하면, 서버에서 전송되는 동일한 양의 마크업에 비해 [처리시간이 길어질 수 있다.](https://web.dev/long-tasks-devtools/) 그 이유는 자바스크립트가 필요로 하는 작업을 제외하고, 브라우저가 서버로부터 마크업을 스트리밍하고, 이 과정에서 작업이 길어지는 것을 피하기 위해 렌더링을 청크업 하기 때문이다. 그러나 이에 반해 클라이언트 렌더링 마크업은 INP외에도 TBT (Total Blocking Time), FID(First Input Delay)와 같은 페이지 응답 메트릭 점수에 영향을 미칠 수 있다.

만약 서버에서 페이지 마크업을 제공할 수 없는 이유가 있는가? 그렇지 않다면, 즉 서버에서 페이지 마크업을 만들 수 있으면 서버사이드 렌더링이나 정적으로 생성된 마크업을 고려해야 한다.

페이지 마크업의 일부에 특정한 기능을 추가하기 위해 자바스크립트가 필요한 경우에도, SSR 환경에서 자바스크립트 [hydration](https://www.patterns.dev/posts/progressive-hydration/)을 활용하는 방법도 고려할 수 있다.

## 프리로드 스캐너가 잘 작동할 수 있게 하는 방법

프리로드 스캐너는 페이지가 더 빨리 로딩되도록 도와주는 매우 효과적인 브라우저 최적화 수단이다. 중요한 리소스를 미리 발견하지 못하는 현상을 막아줌으로써, 개발을 단순화하고 웹 바이탈 등 여러 지표에서 더 나은 결과를 제공하여 더 좋은 사용자 환경을 만들 수 있다.

- 브라우저의 프리로드 스캐너는 메인 스캐너 대비 먼저 검색하여 더 빨리 가져올 수 있는 리소스를 발견하는 과정에서 차단되는 경우를 막기 위해 메인 스캐너보다 먼저 검색하는 보조 HTML 파서다.
- 프리로드 스캐너가 동작하지 않는 경우는
  - 초기 리퀘스트 요청시 서버에서 제공하는 마크업에 없는 리소스
  - 자바스크립트를 활용하여 DOM에 리소스를 삽입하는 경우
  - 자바스크립트를 활용하여 Above the fold 영역에 있는 lazy load 이미지 또는 iframe
  - 자바스크립트를 사용하여 문서내 리소스를 참조로 한 클라이언트 마크업 렌더링
- 프리로드 스캐너는 HTML 만 스캔한다. CSS 내부에 있는 이미지들은 검색되지 않는다.

어떤 이우로든, 프리로드 스캐너에 부정적인 영향을 미치는 패턴을 피할 수 없다면 `rel=preload` 리소스 힌트를 고려해보자. 이 리소스 힌트를 사용해보고 테스트하여 원하는 효과를 얻을 수 있는지 확인해보자. 그리고 마지막으로, 더무많은 리소스를 미리 로딩하지 말자. 모든 것을 우선시하면 아무것도 우선시 되지 않는다.

브라우저의 프리로드 스캐너(pre-load scanner)와 파싱 동작의 이해

## Table of Contents

LCP는 가장 최적화하기 쉬운 Core Web Vital 이다. 3가지 중 유일하게 개발자의 로컬 환경과 실제 환경에서의 수치가 거의 비슷하게 나오는 요소이기도 하다. 그럼에도, 가장 최적화 되지 않는 요소 이기도 하다.

> Once more, we saw an increase in the number of origins having good Core Web Vitals (CWV) driven by improved good CLS.

> - 52.7% of origins had good LCP
> - 94.9% of origins had good FID
> - 70.6% of origins had good CLS
> - 39.0% of origins had good LCP, FID, and CLS

> https://twitter.com/ChromeUXReport/status/1501325517634490376?ref_src=twsrc%5Etfw%7Ctwcamp%5Etweetembed%7Ctwterm%5E1501325517634490376%7Ctwgr%5E%7Ctwcon%5Es1_c10&ref_url=https%3A%2F%2Fcsswizardry.com%2F2022%2F03%2Foptimising-largest-contentful-paint%2F

어떻게 하면 LCP를 쉽게 최적화 할 수 있는 지 살펴보자.

## 정의

LCP를 최적화 하기전에, 먼저 그 정의를 살펴보자.

> 최대 콘텐츠풀 페인트(LCP) 메트릭은 페이지가 처음으로 로드를 시작한 시점을 기준으로 뷰포트 내에 있는 가장 큰 이미지 또는 텍스트 블록의 렌더링 시간을 보고합니다.

> 최대 콘텐츠풀 페인트(LCP)는 페이지의 메인 콘텐츠가 로드되었을 가능성이 있을 때 페이지 로드 타임라인에 해당 시점을 표시하므로 사용자가 감지하는 로드 속도를 측정할 수 있는 중요한 사용자 중심 메트릭입니다. LCP가 빠르면 사용자가 해당 페이지를 사용할 수 있다고 인지하는 데 도움이 됩니다.

> https://web.dev/lcp/

여기에서 알아둬야 할 점 중 하나는, 구글 (라이트 하우스)는 LCP가 빨리 도달하기만 하면, 그 방법이야 어찌되었던 크게 신경쓰지 않는 다는 것이다. 페이지 로딩 라이프사이클과 LCP 사이에서는 다음과 같은 많은 일 들이 일어난다.

- DNS, TCP, TLS
- 리다이렉트
- TTFB
- First Paint
- FCP

만약 이것들 중 어떤 것이라도 느리다면, LCP에는 안좋은 영향을 미친다. 이러한 것들을 가능한한 낮게 얻을 수 있다면 LCP에 도움이 될 것이다.

## LCP 최적화 기법

이미지 기반의 LCP가 있다면, 적절한 파일 포맷, 적절한 크기, 그리고 또 압축이 잘되어 있는지 확인해봐야 한다. 그리고 LCP 요소들은 3MB TIFF 를 넘어서는 안된다.

물론 가장 좋은 방법은 LCP를 텍스트 기반으로 만드는 것이다. 당연하게도 텍스트는 이미지보다 훨씬 크기가 작고, LCP 수치를 높이는데 많은 도움을 준다.

물론, 이미지를 빼는 선택을 하기에는 어려운 상황들이 많을 것이다. 당장에 이미지를 빼고 글자를 채우자고 한다면 그 누구도 좋아하지 않을 것이다. 그렇다면 이 것을 어떻게 최적화 하면 좋을지 살펴보자.

LCP 내의 이미지를 선언하는 방법들은 다음과 같은 것이 있다.

- `<img />`
- `<svg />` 내부의 `<img />`
- `<video />`의 poster
- HTMLElement에 css로 background image `url()` 를 사용하여 이미지를 깔아 놓은 경우
- 텍스트 노드 또는 인라인 레벨의 텍스트를 포함하는 [블록 레벨](https://developer.mozilla.org/ko/docs/Web/HTML/Block-level_elements) HTMLElement

### 테스트

```html
<img src="lcp.jpg" ... />
```

https://yceffort.kr/LCP/img.html

```html
<svg xmlns="http://www.w3.org/1000/svg">
  <image href="lcp.jpg" ... />
</svg>
```

https://yceffort.kr/LCP/svg.html

```html
<video poster="lcp.jpg" ...></video>
```

https://yceffort.kr/LCP/video.html

```html
<div style="background-image: url(lcp.jpg)">...</div>
```

https://yceffort.kr/LCP/background-image.html

각 페이지를 https://www.webpagetest.org/ 에서 테스트 해보자.

### 테스트 결과

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

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

https://www.webpagetest.org/video/compare.php?tests=220610_AiDc96_7AZ%2C220610_AiDc3F_7B4%2C220610_BiDc9B_7JJ%2C220610_AiDc1M_7B6&thumbSize=150&ival=500&end=visual

#### `<img />`

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

이미지가 LCP에서 차지하는 비중이 높다면, 가장 먼저 선택해야할 방법이다. `<img />`는 특별하게 개발자가 망치지 않는 한, [프리로드 스캐너](https://andydavies.me/blog/2013/10/22/how-the-browser-pre-loader-makes-pages-load-faster/)에 의해 빠르게 요청되기 때문에, 병렬적으로 요청하여 미리 그려질 수 있다. (블로킹 리소스와 함께도 가능하다)

#### `<picture />`, `<source />`

`<picture />`가 `<img />`와 같은 방식으로 동작한 다는 점을 알고 있어야 한다. 따라서 `srcset` `size` 속성에 상세하게 작성해야 한다. 이를 정확히 제공하면, 앞서 언급한 프리로드 스캐너를 통해 이미지에 대한 충분한 정보를 브라우저에 제공하게 되면, 레이아웃을 기다릴 필요가 없어진다. (물론 기술적으로 연산에 필요한 오버헤드는 존재할 수 있다.)

https://developer.mozilla.org/en-US/docs/Web/HTML/Element/picture

#### `<svg/>`

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

svg 내부의 이미지는 두가지 흥미로운 동작이 있다. 먼저 한가지는 크롬이 svg 내부의 이미지가 미처 불러와지지 않았음에도 LCP가 완료된 것 처럼 판단한다는 것이다. 상황에 따라 점수만 먹고 튀고 싶다면(?) 이 방법을 응용할 수도 있다.

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

> 물론 이는 어디까지나 현재 블로그 글을 작성 중인 102 버전 이하의 동작으로, 이후에는 수정될 수도 있다.

어쨌든 이는 LCP 상의 버그 일뿐, 실제로 브라우저가 리소스를 처리하는 방법에는 영향을 주지는 않는다. 위 스크린샷에서도 볼 수 있는 것처럼, 워터폴 방식으로 느리게 불러오는 것을 볼 수 있다.

svg 내부에 있는 img는 프리로드 스캐너에서 숨겨진 것 처럼 보인다. 즉, 내부의 `href`는 브라우저의 기본 파서가 이를 발견할 때까지 구분 분석되지 않는다. 이를 미루어 보아 프리로드 스캐너는 SVG가 아닌 HTML 를 스캔하기 위해 만들어졌다는 것을 알 수 있다.

#### `<video />`의 `poster`

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

사실 `video` 의 `poster` 가 이렇게 선방할 줄은 몰랐다. 이는 `img`와 동일하게 동작하는 것으로 보이며, 프리로드 스캐너에 의해 조기에 발견된다. 이는 본질적으로 poster가 굉장히 빠르다는 것을 의미한다.

그리고 또다른 소식 중 하나는, `poster`가 없는 `video`는 첫번째 프레임을 LCP로 가져가려는 의도가 있다는 것이다. https://bugs.chromium.org/p/chromium/issues/detail?id=1289664 즉 동영상을 실제로 로딩해서 LCP로 가져가려 한다는 뜻인데, 아무래도 동영상은 이미지보다 용량이 크므로, LCP로 동영상을 가져가기 위해서는 `poster`가 필수적으로 보인다.

#### `background-image: url()`

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

CSS에 정의된 리소스 (url 을 통해 요청된 모든 리소스) 는 기본적으로 느리다. 여기서 말하는 리소스는 background-image과 web font 등이다.

이러한 리소스가 느린 이유는, 브라우저가 해당 리소스를 필요로 하는 DOM노드를 그릴 준비가 될 때 까지 리소스를 요청하지 않기 때문이다.

이는 background-image 가 LCP의 마지막 순간에 요청된다는 것을 의미인데, 이는 사실 너무 늦은 타이밍이긴하다. 따라서 background-image가 있는 LCP는 적절하지 못하다.

현재 LCP에 background-image가 있는 사이트는 지금 리팩토링할 수 있는 여지가 존재한다. 그리고 이를 가장 빠르게 해결하는 방법이 있다.

```html
<div style="background-image: url(lcp.jpg)">
  <img
    src="lcp.jpg"
    alt=""
    width="0"
    height="0"
    style="display: none !important;"
  />
</div>
```

이러한 방법을 활용하면 프리로드 스캐너로 하여금 브라우저가 `<div />`를 렌더링할 때 까지 않고 이미지를 가져오게 만들 수 있다. 이것은 단순 구현보다 1.058초 더 빠르게 앞당길 수 있다. 이는 `<img/>` 옵션과 거의 똑같다는 것을 알 수 있게 될 것이다.

## 요약

- 텍스트 기반의 LCP는 언제나 옳다. 가장 빠르다.
- `<img />` 와 `poster`는 프리로드 스캐너에 발견될 수 있기 때문에 빠르게 로딩할 수 있다.
- `poster`가 없는 `<video/>`는 동영상의 첫번째 프레임이 LCP에 들어갈 수 있다.
- `<svg />` 에 있는 `<img />` 는 매우 느리고, 이는 href가 프리로드 스캐너에 포함되지 않기 때문이다.
- `background-image` 는 기본적으로 CSS의 동작 방식 때문에 느리다.
  - 이 안에 보이지 않는 `<img/>`를 집어 넣으면 개선할 수 있다.

## 조심해야할 것들

이와 반대로, LCP를 개선하기 위한 작업 외에 하지 말아야 할 것들이 있다. 개발자들이 무심코 LCP 점수를 깎아먹는 일들이 무엇이 있는지 알아보자.

### LCP 를 lazy load 하지 말 것

`loading=lazy`는 프리로드 스캐너에서 이미지를 숨긴다는 문제가 있다. 즉 이미지가 뷰포트에 있더라도 브라우저는 이미지를 늦게 요청한다. 따라서 모든 이미지에 `loading=lazy`를 하는 것은 안전하지 못한 선택이고, 만약 다 추가했다면 브라우저가 잘 로딩해주기를 기도하는 수밖에 없다.

### Fade in 하지 말기

예상했던 것처럼, 이미지를 만약 500ms fade in 한다면 LCP도 그만큼 늦춰진다.

### LCP 에셋은 직접 호스팅할 것

가능하다면, LCP 에셋은 셀프 호스팅하는 것이 좋다. 사이트 관리자들이 Cloudinary와 같은 이미지 최적화 서비스를 사용하여 크기 조정, 포맷 변환, 압축 등 자동으로 이미지를 최적화 하는 솔루션을 사용하곤 한다. 그러 나 이러한 서비스 성능 향상을 고려한다면, 이러한 다른 origin에서 이미지를 가져오는 것은 이렇게 최적화 한 비용을 상쇄해버리고도 남는다. 중요하지 않은 이미지에서는 기존 처럼 자동화된 이미지를 사용하되, 가능하면 최적화된 이미지는 직접 호스팅하는 것이 좋다.

### LCP를 클라이언트에서 빌드 하지 말것

사이트에서 정보를 요청했을 때, 처음으로 오는 응답은 HTML이다. 그리고 이 안에서 `<img />`를 발견하고, 프리로드 스캐너가 이를 읽어드리길 바랄 것이다. 그러나 만약 이 작업 이전에 `framework.js` 와 같은 요청이 온다면 이미지를 발견하기전에 이 자바스크립트를 다운로드 하고 파싱하는 작업이 수행될 것이다. 이렇게 되면 LCP는 js를 해석하여 삽입하는 시간 만큼 뒤로 밀리게 될 것이다.

즉 LCP 영역은 가능하다면 서버사이드에서 미리 빌드된 채로 오는 것이 좋다.

### LCP를 오염하지 말 것

LCP 내부에 있는 컨텐츠를 뒤늦게 로드 하면 안된다. 여기에서 말하는 것은 콘텐츠를 덮고 매우 늦게 로딩되는 쿠키 배너나 각종 광고, 모달 등이 포함된다. 이런 쿠키 배너 등의 요소가 필요하다면

- 가능한 즉시 렌더링한다
- 컨텐츠 크기를 너무 크게 하지 않는다.

## 요약

텍스트 기반의 LCP가 빠르다는 것은 누구나 알 것이다. 그러나 대부분의 경우 이는 불가능할 것이다. LCP에는 `<img/>`나 `<video/>`의 poster를 활용하는 것이 가장 빠르다. 그리고 LCP 내부의 컨텐츠를 lazy 로딩 하지 말고, LCP에 js 빌드 작업을 포함시켜서는 안된다.

## 참고

- [브라우저의 프리로드 스캐너(pre-load scanner)와 파싱 동작의 이해](/2022/06/preload-scanner)


브라우저 동작 방식을 이해하기

Largest Contentful Paint (LCP) 최적화하기

웹 애플리케이션에서 자바스크립트 프로파일링 해보기

## 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 태그에는 끝 태그 문자 `/>`가 존재한다. 따라서 브라우저는 자동으로 해당 태그와 일치하는 태그를 닫을 수 있다. 아래 예시를 살펴보자.

{/* prettier-ignore-start */}

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

{/* prettier-ignore-end */}

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

```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)에 잘 나와있습니다


Browser 1

브라우저의 프리로드 스캐너(pre-load scanner)와 파싱 동작의 이해

Largest Contentful Paint (LCP) 최적화하기

웹 애플리케이션에서 자바스크립트 프로파일링 해보기

HTML 문서에서 DOM으로의 여정

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