브라우저 렌더링 원리

브라우저는 받은 HTML·CSS·JS를 정해진 단계를 거쳐 픽셀로 바꾼다. 이 파이프라인을 알면 ‘왜 이 코드가 화면을 느리게 만드는가’를 추론할 수 있다.

• 파싱 → DOM: HTML을 읽어 요소의 트리(DOM)를 만든다.
• 파싱 → CSSOM: CSS를 읽어 스타일 규칙의 트리(CSSOM)를 만든다.
• 렌더 트리: DOM과 CSSOM을 합쳐 ‘화면에 보이는 것’만 담은 트리를 만든다(display:none은 제외).
• 레이아웃(Layout/Reflow): 각 요소의 위치와 크기를 계산한다.
• 페인트(Paint): 색·텍스트·그림자 등 픽셀을 칠한다.
• 합성(Composite): 여러 레이어를 GPU에서 합쳐 최종 화면을 만든다.

첫 화면이 그려지기까지 반드시 거쳐야 하는 단계들을 임계 렌더링 경로(Critical Rendering Path)라 한다. 이 경로를 막는 리소스를 줄이는 것이 첫 화면 속도(FCP·LCP)의 핵심이다.

<!-- 차단: 여기서 파싱이 멈추고 스크립트를 받고 실행 -->
<script src="app.js"></script>

<!-- defer: HTML 파싱을 막지 않고, 파싱이 끝난 뒤 순서대로 실행 -->
<script src="app.js" defer></script>

<!-- async: 받는 즉시 실행(순서 보장 안 됨) — 독립적 분석 스크립트 등에 -->
<script src="analytics.js" async></script>

화면이 한 번 그려진 뒤에도, DOM이나 스타일을 바꾸면 파이프라인의 일부가 다시 돈다. 위치·크기가 바뀌면 리플로우(Reflow), 색·배경만 바뀌면 리페인트(Repaint)가 일어난다. 리플로우가 더 비싸다.

자바스크립트는 한 개의 메인 스레드에서 돈다. 이 스레드가 렌더링도 담당하기 때문에, 긴 JS 작업은 화면을 통째로 멈춘다. 이벤트 루프를 이해하면 ‘왜 버벅이는가’가 보인다.

console.log('1')                      // 동기

setTimeout(() => console.log('4'), 0)  // 매크로태스크 (다음 루프)

Promise.resolve()
  .then(() => console.log('3'))        // 마이크로태스크 (현재 작업 직후)

console.log('2')                       // 동기

// 출력: 1 → 2 → 3 → 4
// 동기 코드 → 마이크로태스크 비우기 → 렌더링 기회 → 다음 매크로태스크

DOM 조작이 ‘느리다’고들 하는데, 정확히는 조작 자체보다 그것이 유발하는 리플로우·리페인트가 비싸다. 변경을 한 번에 모아서 적용할수록 좋다. 이 발상이 React 같은 라이브러리가 쓰는 가상 DOM의 출발점이다.