티스토리 뷰

용어 설명

웹 브라우저란 동기적으로 HTML, CSS ,JS 언어를 해석하여 내용을 화면에 보여주는 응용 소프트웨어이다.

 렌더링 엔진은 HTML, XML, 이미지 등 요청받은 내용을 브라우저에 화면에 표시하는 엔진입니다.( 브라우저마다 렌더링 엔진이 다름)

 렌더 트리 - DOM요소를 기반으로 만들어지지만 완전 1:1대응 구조는 아닙니다. DOM 트리가 문서의 구조를 나타낸다면 렌더 트리는 "문서의 시각적 구조"를 나타냅니다.

웹 브라우저 동작원리 설명

사용자가 어떤 사이트에 접속할 때, 브라우저(클라이언트)는 사이트의 주소로 네트워크 요청을 보냅니다.

해당 요청은 DNS(domain name server)서버에 들려 도메인(사람이 이해하기 쉬운 영문 주소)과 매핑되는 IP주소로 HTTP 요청을 보내게 됩니다. 사용자가 홈페이지에 접속하면 브라우저 엔진이 서버에 필요한 리소스를 요청해서 받아옵니다.

이때 받아오는 리소스는 HTML, CSS, JS등이 있습니다. 렌더링 엔진이 해당 리소스 중 HTML과 CSS를 파싱하여 DOM과 CSSOM을 형성하고 결합하여 렌더 트리를 생성합니다. (HTML에서 script태그를 만나면 브라우저 렌더링 엔진은 제어권한을 자바스크립트 엔진으로 넘깁니다.) 가져온 리소스 중 자바스크립트는 자바스크립트 엔진에서 파싱하여 실행시킵니다. 이렇게 만들어진 렌더 트리의 각 노드에 대해 화면 상에서 배치할 곳을 결정합니다. (렌더 트리 배치(reflow), 레이아웃) 이후 렌더 트리의 각 노드를 그립니다.(렌더 트리 paint)  렌더 트리가 페인팅된 것이 우리가 보는 웹사이트의 디스플레이입니다.

Reflow

브라우저 렌더링이 끝난 이후에 html 요소의 크기나 위치등 레이아웃이 변경되면 그에 영향받는 모든 요소들이 Layout단계를 거친 뒤 Repaint과정을 수행하게 된다. Layout단계는 노드의 위치나 크기를 계산하는 단계이다.

Reflow가 일어나는 상황?

  • 새로운 요소(엘리먼트=노드)가 추가되거나 요소가 지워지거나, 요소의 위치가 변경 or 크기가 변경 등등
  • 윈도우 리사이징
  • 노드 추가 또는 제거
  • 내용 변화 e.g.) input 입력
  • JS를 통한 DOM 변화
  • 요소의 위치, 크기 변경
Reflow는 Repain의 상위 과정이기 때문에 Reflow가 발생하면 자연히 Repaint도 발생합니다. -> reflow와 repaint를 줄여 성능을 높이고 불필요한 성능을 줄여야 합니다.

Repaint?

Reflow가 발생하지 않고도 Repaint만 발생하는 경우도 있습니다. Reflow가 레이아웃, 포지션에 대한 변화 때문에 일부 혹은 전체를 다시 구성하고 그리는 반면, 만약 레이아웃에 영향을 주지 않는 엘리먼트 개별의 변화에서는 Reflow가 발생하지 않고 Repaint만 발생합니다. e.g.) color, background-color, visibility 같은 스타일 속성

-> 해결방안: Virtual DOM (리액트:^^)

 

reflow & repaint 관련 추가 정보

🌷  DOM의 속성을 얻거나 갱신하는 것은 거의 같은 비용을 발생시킬 뿐 딱히 DOM객체가 느린 것은 아닙니다. 
문제는 DOM을 건드리면 브라우저가 렌더링 트리를 재계산하고 그에 맞춰 렌더링을 일으킨다는 점입니다. 즉, 느려진다는 것은 렌더링 부분입니다. 되도록 DOM의 속성을 건드리지않으려는 것은 렌더링이 느리기 때문입니다.
예를 들어, onClick의 이벤트리스너를 재설정하는 것은 렌더링에 큰 영향을 주지않기 때문에 굳이 가상돔을 경유할 이유가 없습니다. 

🌷 일반적인 통념과 다르게 reflow보다 repaint의 부하가 더 큽니다. 단지 리플로우가 일어나면 많은 부분에 리페인트를 유발하기 때문에 리플로우를 최소화하려는 것입니다. 하지만 리플로우를 최소화했다고 해도 원래 부하가 큰 리페인트가 있다면 소용없습니다. (페인팅 비용이 가장 많이 비용이 많이드는 공정)

 

 

 

댓글