브라우저 렌더링 기초

학습 목표

브라우저는 어떤 입력으로부터 화면 픽셀을 만들지의 과정을 이해하고, 프론트의 체감 성능 이슈를 데이터 지연과 분리해 바라보는 감각을 만든다.

렌더링은 단계별 파이프라인이다

브라우저 렌더링은 보통 아래 흐름으로 설명됩니다.

1. HTML 파싱 → DOM 생성
2. CSS 파싱 → CSSOM 생성
3. DOM + CSSOM 결합 → 렌더 트리 구성
4. 레이아웃 계산
5. 페인팅 및 합성

각 단계는 앞 단계의 산출물을 입력으로 받기 때문에, 중간 단계가 바뀌면 이후 단계의 해석도 바뀝니다.

React와 브라우저 렌더의 관계

React는 브라우저 바깥에서 독자적으로 화면을 그리는 게 아니라, 브라우저의 DOM/CSSOM 상태를 변경해 렌더 파이프라인을 다시 타게 하는 역할을 수행합니다.

• 상태 변경은 React 내부 렌더 계산으로 시작해
• 커밋된 결과는 DOM/CSSOM 변화로 이어지고
• 브라우저는 다시 렌더 트리/레이아웃/페인팅을 수행합니다.

그래서 API 응답/상태 변경/브라우저 재계산은 하나의 연결된 사슬입니다.

개념적으로 기억할 분기축

렌더링 비용의 차이는 결국 두 축으로 나눠 생각할 수 있습니다.

• 구조 축: 레이아웃에 영향을 주는 변경(위치/크기/정렬 등)
• 외형 축: 색상/그림자/투명도처럼 구조를 바꾸지 않는 변경

구조 축은 다음 단계로 영향을 더 많이 전파하고, 외형 축은 상대적으로 전달 범위가 좁습니다.

백엔드 감각의 핵심은 이 분기축을 통해서, 느린 데이터와 느린 렌더가 왜 같은 문제가 아닌지 구분하는 데 있습니다.

시간 개념: 지표는 서로 다른 질문에 답한다

• TTFB는 “서버 응답이 언제 시작되는가”를 봅니다.
• FCP는 “브라우저가 픽셀을 처음 보이기 시작했는가”를 봅니다.
• 인터랙션 가능 시점은 “사용자 입력이 실제 동작을 일으키는가”를 봅니다.

같은 페이지라도 세 지표는 같은 원인을 가리키지 않습니다.

SSR/CSR 경계에서의 렌더 위치

SSR은 초기 화면을 만드는 경계이고, CSR은 그 화면을 상호작용 가능한 상태로 완성하는 경계입니다.

이 경계를 구분해 두면 렌더를 “누가”, “언제”, “무엇을” 책임지는지 모델링이 가능해져 추적이 쉬워집니다.

다음 문서: 데이터 가져오기와 상태