크롬은 멀티 프로세스 아키텍처를 사용한다.
브라우저 프로세스는 다수의 렌더 프로세스를 관리한다.
웹 브라우저 구성
*주요 요소만 정리
- 브라우저 프로세스 - 모든 렌더 프로세스들과 UI를 그리는데에 책임
- ui(메인) 스레드 - 웹 페이지를 렌더링 하는데에 책임이 있는 스레드
- 네트워킹 스레드 - 네트 워크 요청하는 스레드
- 저장 스레드 - 로컬, 세션 스토리지 브라우저 내부 저장소를 관리하는 스레드
- 렌더 프로세스 (탭)
- render view - 화면
- 렌더링 엔진 - webkit/Blink/Gecko
- webcore - 레이아웃 계산 및 렌더링 진행
- js엔진 - js해석 및 실행
렌더 프로세스와 스레드
렌더 프로세스의 역할
HTML과 CSS, JavaScript를 사용자와 상호작용을 할 수 있는 웹 페이지로 변환하는 것
- 메인 스레드: 렌더링 엔진을 이용해 브라우저로 전송된 대부분의 코드를 처리
(HTML,CSS, JS로드와 파싱 후 크리티컬 렌더링 패쓰 진행) - 컴포지터, 래스터 스레드: 웹 페이지를 효율적이고 부드럽게 렌더링하기 위해 별도의 스레드
컴포지터 스레드의 장점
메인 스레드와 별개로 작동할 수 있다는 점이다. 컴포지터 스레드는 JavaScript 실행이나 스타일 계산을 기다리지 않아도 된다. 이것이 합성만 하는 애니메이션이 성능상 가장 부드럽다고 보는 이유
웹 페이지 로드 과정
브라우저 프로세스
- UI스레드가 주소창에 입력된 값이 url인지 검색어 인지 확인 후 요청할 곳 결정
- 네트워킹 스레드를 통해 서버에 요청을 보냄
- 응답이 오면 네트워킹 스레드는 content-type을 확인해 html인지 다운받을 파일인지 확인
- html이라면 UI스레드를 통해 담당 렌더 프로세르를 알아내 render process에 전달
렌더링 프로세스
- 렌더링엔진이 작동
- html을 파싱하면서 링크를 읽으면 css와 여러 파일을 비동기적으로 임포트함(프리로드 스캐너)
- script태그를 만났는데, defer이거나 module이라면 js파일도 비동기로 임포트함
- html파싱이 끝나면 js파일이 실행되고 DOM트리 구축을 완료함
- 이후 css파싱해 CSSOM 구축 후 둘을 합쳐 Remder트리를 구축함
- flow-paint-composition과정을 거치며 화면을 그림
리렌더링 과정
첫 렌더링 후 이벤트 발생이나 애니메이션등의 이유로 레이아웃이나 스타일이 변경될 때 발생한다.
브라우저의 렌더링 과정 중에서 가장 많은 비용을 소요하는 작업은 레이아웃(플로우)과 페인팅작업이다.
Reflow
돔 조작 및 화면 크기 조정 시 진행 시점
- 레이아웃이 변경 될 때 발생 (돔 트리부터 다시 생성될 수도 있음)
- DOM 추가, 삭제
- window.resize 이벤트시 영향 받는 여러 DOM들
- DOM의 위치, 크기, 패딩, 마진 등 기하적인 속성을 변경하는 CSS속성 사용 시
- 폰트 변경, 이미지 변경
- 레이아웃이 변경되는 애니메이션
-> position: absolute, fixed을 적용하면 reflow의 영향을 줄일 수 있다
Repaint
Reflow가 일어나거나 특정 css 속성이 변화할 시 진행 시점
- 레이아웃 변경이 아닌 스타일만 변경 될 때 발생
-opacity, background-color, visibility, outline등
Composition
Repaint과정 없이 이미 그려진 layer를 조합하면 되는 경우
js실행과 리렌더링
- js코드 실행 결과의 변경 사항들을 받아서 모아놓았다가 1초에 60프레임에 맞게 렌더링을 한다. (대략 16.7ms에 한번씩 화면 업데이트)
- 한 함수 실행 완료 될 때마다 렌더링을 보장하진 않지만 함수 실행 중에 렌더링되지는 않는다.
- 한 함수에서 변경한 코드들의 결과가 하나의 변경 단위가 된다.
- 그렇기에 한 함수에서의 변경 코드 순서는 상관이 없다.
Virtual DOM은 왜 빠른 것인가
js로 DOM을 직접 조작하여 수정을 할 경우, 이 레이아웃과 페인팅 작업을 다시하게 된다.
많은 양의 DOM을 직접 조작하는 것은 많은 비용을 초래한다.
가상 DOM은 실제로 렌더링되지는 않았지만, 실제 DOM 구조를 반영한 상태로 메모리에 있는 가상의 DOM이다.
실제 화면에 그려야할 필요는 없기 때문에 실제 DOM보다는 연산 비용이 적다.
가상 DOM은 변경 사항들을 한 번에 묶어서 실제 DOM에 반영한다.
레이아웃 단계와 페인트 단계에서 한 번에 변경되어야 하는 사항은 많아지지만 단 한 번의 계산만으로도 바뀐 DOM을 적용할 수 있기 때문에 연산의 횟수는 최소한이 된다.
크롬 브라우저 엔진 구성과 동작 방식
최신 브라우저의 내부 살펴보기
브라우저 렌더링 과정
자바스크립트 로드 실행 순서
reflow? Repaint
