← 질문 목록
#26깊이 0
브라우저가 화면을 그리기까지 무슨 일이 일어나는가?
HTML과 CSS를 각각 트리로 만들고 둘을 합쳐 위치를 계산한 뒤 픽셀로 칠한다. 어느 단계를 건드리느냐에 따라 비용이 크게 갈린다.
파서→DOM
HTML을 읽어 요소 트리를 만든다
파서→CSSOM
스타일 규칙을 트리로 만든다
DOM+CSSOM→렌더 트리
화면에 나올 것만 남긴다
렌더 트리→레이아웃
각 요소의 위치와 크기를 잰다
레이아웃→페인트
색과 그림자를 칠한다
스타일을 바꾸면 어디까지 되돌아가는지가 성능을 가른다. 너비나 위치를 건드리면 레이아웃부터 다시 한다. 색만 바꾸면 페인트만 다시 한다. transform과 opacity는 합성 단계에서만 처리돼 앞의 둘을 건너뛴다.
자바스크립트가 이 흐름을 막을 수 있다. CSSOM이 완성되기 전에는 스크립트를 실행할 수 없고, 스크립트가 도는 동안에는 파싱이 멈춘다. 스타일시트를 위에, 스크립트를 아래에 두라는 오래된 조언이 여기서 나왔다.
스타일을 바꾼 직후에 offsetHeight 같은 값을 읽으면 브라우저가 그 자리에서 레이아웃을 다시 계산한다. 반복문 안에서 쓰기와 읽기를 번갈아 하면 매 회전마다 그 비용이 든다.
추천 꼬리질문
관련 질문
- 계산 단계와 반영 단계를 왜 나누는가?프론트엔드브라우저가 화면을 그리는 전체 과정(Critical Rendering Path)을 알아야 계산과 반영 단계의 구분 이유를 이해할 수 있다.
- 폰트 표시 지연과 깜빡임을 어떻게 줄이는가?프론트엔드브라우저의 렌더링 파이프라인(CRP)을 이해해야 폰트 로딩 시점과 렌더링 차단을 이해할 수 있다.
- 스타일을 바꿨을 뿐인데 왜 느려지는가?프론트엔드어느 단계부터 다시 그리는가가 느려짐의 원인이다 — 파이프라인 총론과 그 비용 각론이다.
- 첫 화면을 막는 리소스는 어떻게 줄이는가?프론트엔드첫 화면을 그리기까지의 렌더링 과정을 이해해야 렌더링을 막는 리소스를 줄이는 방법을 파악할 수 있다.
- 선택자 최적화는 실제로 언제 필요한가?프론트엔드선택자 매칭은 파이프라인의 스타일 계산 단계 비용이다 — 언제 병목이 되는지가 양쪽의 물음이다.