Rendering process

Jung Hyun Kim·2022년 10월 16일

렌더러 프로세스

프로세스 안에 여러 쓰레드가 있는데 그중 메인쓰레드가 브라우저로 전송된 대부분의 코드 처리 렌더러 프로세스의 주요 역할은 HTML과 CSS, JavaScript를 사용자와 상호작용을 할 수 있는 웹 페이지로 변환하는 것이다.

웹워커나 서비스워커를 사용하면 워커쓰레드가 JavaScript코드의 일부를 처리

https://blog.rhostem.com/posts/2021-01-03-image-load-by-web-worker

그래서 브라우저에서는 자바스크립트로 작성된 어플리케이션의 멀티스레딩을 위해 웹 워커 API를 제공한다. 웹 워커에서 실행되는 스크립트는 메인 스레드에서 분리되어 독립된 스레드에서 실행되므로 앱이 실행되는 머신의 CPU, 메모리 리소스를 더 효율적으로 활용할 수 있다.

서비스 워커는 연관된 웹 페이지/사이트를 통제하여 탐색과 리소스 요청을 가로채 수정하고, 리소스를 굉장히 세부적으로 캐싱할 수 있습니다. 이를 통해 웹 앱이 어떤 상황에서 어떻게 동작해야 하는지 완벽하게 바꿀 수 있습니다. (제일 대표적인 상황은 네트워크를 사용하지 못할 때입니다.)

미래의 서비스 워커는 웹 플랫폼이 네이티브 앱의 능력에 보다 근접하도록 여러 가지 유용한 기능을 수행할 수 있을 것입니다. 흥미롭게도 다른 명세에서도 서비스 워커 맥락을 사용할 수 있으며, 이미 다음과 같은 곳에서 사용하고 있습니다.

백그라운드 동기화: 아무 사용자도 사이트에 없을 때 서비스 워커를 가동해 캐시를 업데이트 하는 등의 작업을 수행.
푸시 메시지에 반응: 서비스 워커를 가동, 새로운 콘텐츠가 이용 가능하다는 메시지를 사용자에게 전송.
서비스워커의 수명 주기는 웹페이지와는 완전히 별개입니다. 웹 서비스와 브라우저 및 네트워크 사이에서 프록시 서버의 역할을 하며, 오프라인에서도 서비스를 사용할 수 있도록 합니다.웹 페이지 life cycle을 따르지 않습니다. 서비스워커는 웹페이지가 닫히더라도 자동으로 비활성화되지 않습니다

https://so-so.dev/web/service-worker/

웹 페이지를 효율적이고 부드럽게 렌더링하기 위해 별도의 컴포지터 스레드와 래스터 스레드가 렌더러 프로세스에서 실행된다.

The compositor thread is a thread in the browser that leverages the GPU to create the final version of the page seen on the screen.o the main thread is CPU intensive, right? You saw me peg the CPU at multiple times today, right? When we block it, nothing happens. The compositor thread is GPU intensive, right? There's, like, a hidden part here of everything that we can take away from that main renderer thread and pass it over to the GPU thread.

The Raster thread takes the bytes in dash.png, resizes the image (if needed), and then applies opacity, blend modes, blur, and so on, until it has the final pixels. The Raster thread then sends the resulting information to the graphics card, and, therefore, to the screen.

래스터는 Layer Tree를 받아 GPU와 통신하여 UI를 업데이트 합니다. Skia engine이 이 스레드에서 실행됩니다. 개발자는 Raster 스레드나 스레드의 데이터에 접근할 수 없습니다

파싱 DOM 구축

페이지를 이동하는 내비게이션 실행 메시지를 렌더러 프로세스가 받고 HTML 데이터를 수신하기 시작하면 렌더러 프로세스의 메인 스레드는 문자열(HTML)을 파싱해서 DOM(document object model)으로 변환하기 시작한다.

질문 : DOM은 브라우저가 내부적으로 웹 페이지를 표현하는 방법일 뿐만 아니라 웹 개발자가 JavaScript를 통해 상호작용을 할 수 있는 데이터 구조이자 API이다.?
The DOM is a browser's internal representation of the page as well as the data structure and API that web developer can interact with via JavaScript?

하지만 속도를 높이기 위해 '프리로드(Preload) 스캐너'가 동시에 실행된다. HTML 문서에 IMG 또는 LINK 와 같은 태그가 있으면 프리로드 스캐너는 HTML 파서가 생성한 토큰을 확인하고 브라우저 프로세스의 네트워크 스레드에 요청을 보낸다.

Pre-load Scanner란 무엇인가
모든 브라우저는 raw markup 상태의 파일을 토큰화 하고, 객체 모델로 처리하는 HTML 파서를 기본적으로 가지고 있다. 이 모든 작업은 이 파서가 또는 async defer가 없는

브라우저엔 preload scanner(= 사전 로드 스캐너)라는 것이 있다. 이 사전 로드 스캐너는 HTML에 우선 순위가 높은 리소스들 (로 연결된 CSS 파일 이라던가, 웹 폰트라던가)와 같은 것들을 HTML parser에 의해 생성된 토큰들을 보고 알아차린다 (출처). 그런 다음에, 미리 해당 리소스들에 대한 요청을 해놓는다. 이 사전 로드 스캐너 덕분에, parser가 리소스를 참조하는 부분에 도달해서 요청을 보내고 할 때까지 기다릴 필요가 없어진다. HTML parser가 외부 리소스가 있는 부분에 도착한 시점엔, 리소스가 다운되고 있거나 이미 준비 완료가 되는 아름다운 시츄에이션이 펼쳐지는 것이다!

웹 개발자가 브라우저에 리소스 로딩에 대한 힌트를 보내는 방법에는 여러 가지가 있다. JavaScript에서 document.write() 메서드를 사용하지 않는다면

스크립트 태그에 async 속성이나 defer 속성을 추가할 수 있다. 이 속성이 있으면 브라우저가 JavaScript 코드를 비동기적으로 로딩하고 실행하면서 HTML 파싱을 막지 않는다. JavaScript 모듈을 사용할 수도 있다. <link rel="preload">는 현재 내비게이션을 실행하기 위해 리소스가 반드시 필요하다는 것을 브라우저에 알려서 리소스를 가능한 한 빨리 다운로드하려는 경우에 사용할 수 있다.

질문 : 그럼 로딩을 빨리하려면 다 속성을 추가해서 파싱을 계속 이어나가야 하는거 아닌지?

메인쓰레드가 css파싱하고 각 dom node에 computed style확정

display: none 속성이 적용된 요소는 레이아웃 트리에 포함되지 않는다(그러나 visibility: hidden 속성이 적용된 요소는 레이아웃 트리에 포함된다). 이와 비슷하게 p::before{content:"Hi!} 속성과 같은 의사 클래스(pseudo class)의 콘텐츠는 DOM에는 포함되지 않지만 레이아웃 트리에는 포함된다.

layout tree와 dom tree의 차이?
The DOM tree is essentially the tree containing all of your HTML elements (nodes), whereas the render tree is a culmination of the DOM and CSSOM trees. The render tree is the one that is actually rendered onto the page.
속성 트리(property tree)를 만드는 작업이다. 속성 트리는 clip, transform, opacity등의 속성 정보만 가진 트리이다. 기존에는 이런 정보를 분리하지 않고 노드마다 가지고 있었다. 그래서 특정 노드의 속성이 변경되면 해당 노드의 하위 노드에도 이 값을 다시 반영하면서 노드를 순회해야 했다. 최신 Chrome에서는 이런 속성만 별도로 관리하고 각 노드에서는 속성 트리의 노드를 참조하는 방식으로 변경되고 있다.

그래서 transform 통해서 하지말라는것인가?

그림 10 DOM 트리 및 스타일, 레이아웃 트리, 페인트 트리의 순서로 생성된다

requestAnimationFrame setInterval대신 애니메이션 컨트롤 할때 같은 결과지만, 그 interval을 딱 지켜준다.

https://www.youtube.com/watch?v=vBvV2c-x1MA&ab_channel=DailyTuition

Compositing 합성

브라우저는 이제 웹 페이지를 어떻게 그릴까? 이 정보를 화면의 픽셀로 변환하는 작업을 래스터화(rasterizing)라고 한다.
가장 단순한 래스터화는 아마 뷰포트 안쪽을 래스터하는 것일 것이다. 사용자가 웹 페이지를 스크롤하면 이미 래스터화한 프레임을 움직이고 나머지 빈 부분을 추가로 래스터화한다. 이 방식은 Chrome이 처음 출시되었을 때 래스터화한 방식이다. 그러나 최신 브라우저는 합성(compositing)이라는 보다 정교한 과정을 거친다.합성은 웹 페이지의 각 부분을 레이어로 분리해 별도로 래스터화하고 컴포지터 스레드(compositor thread)라고 하는 별도의 스레드에서 웹 페이지로 합성하는 기술이다. 스크롤되었을 때 레이어는 이미 래스터화되어 있으므로 새 프레임을 합성하기만 하면 된다. 애니메이션 역시 레이어를 움직이고 합성하는 방식으로 만들 수 있다.
https://www.slideshare.net/deview/125-119068291?from_action=save

질문 컴포지터 스레드를 별도로 유지하는 것이 오히려 부담이 더 클 때에는 싱글 스레드에서 합성을 실행하기도 한다. 브라우저의 UI 부분(chrome)을 담당하는 컴포지터는 싱글 스레드로 작동한다.??

메인 스레드는 레이아웃 트리를 순회하며 레이어 트리를 만든다(이 부분은 개발자 도구의 Performance 패널에서 Update Layer Tree라고 되어 있다). 뷰포트로 미끄러져 들어오는 들어오는 슬라이드인 메뉴처럼 별도의 레이어여야 하는 웹 페이지의 어떤 부분이 별도의 레이어가 아니라면 CSS의 will-change 속성을 사용해 브라우저가 레이어를 생성하게 힌트를 줄 수 있다.
use transform and opacity
질문 보통 하는지?