내가 만든 HTML 파일이 브라우저가 있을 때 DOM Tree로 변환되어
브라우저 웹페이지상에서 나에게 보이게 되고 자바스크립트로 DOM Tree의
각 요소(예, HTMLDivElement - 브라우저가 이해할 수 있도록 변환된 Object 형태)에 접근하여 요소를 수정, 삭제, 추가 등을 할 수 있습니다.
HTML 파일에만 있는 것들은 그냥 태그이고,
브라우저 위에 있는 HTML 태그들은 HTMLElement가 되어지고,
이 모든 HTMLElement들은 Element이면서 Node이고,
즉, 아래와 같은 상속 구조 형태를 갖고 있습니다.
(EventTarget <- Node <- Element <- HTMLElement <-...)
DOM은 HTML 태그를 자바스크립트로 제어할 수 있는 자바스크립트 오브젝트 형태로 를 말하여 DOM Tree는 이런 DOM이 어떤 구조로 생성되었는지를 정의하는 것이라고 할 수 있습니다.
Node 인터페이스는 추상 클래스이며,
Node 기능을 구현하는 모든 객체는 그 하위 클래스 중 하나를 기반으로 합니다. 그렇기 때문에 Element의 부모 개념인 Node로 간주해서 요소들을 조작하는 경우는 흔하지 않습니다. 주로 Node를 상속받은 Element 클래스를 통해 APIs 를 사용합니다.
예) querySelector로 받아온 요소들은, 즉 모든 태그들의 부모는 Element이므로 Element 클래스가 가지고 있는 메서드를 이용해서 조작
requests/response -> loading -> scripting -> rendering -> layout -> painting(paint + composition)
1) requests/response : 브라우저가 서버에게 html 파일을 요청, 서버에 request를 하면 가장 먼저 index.html을 받아오고 CSS, JS, 필요한 리소스(이미지, 폰트)들을 순차적으로 서버에서 받아옴
2) loading : html 파일을 서버에서 받아 로딩
3) scripting : html 파일을 읽어 DOM 요소로 변환(DOM Tree 생성)
CSS 스타일을 모두 계산해서 DOM 속성과 결합하여 CSSOM Tree 생성
4) rendering : DOM Tree + CSSOM Tree -> 브라우저에 표기될 요소들만 선별하여 Render Tree 생성 (display : none 제외, head 내 제외, meta 등 )
5) layout : 각 요소들의 위치와 크기를 계산
6) paint : 레이어 별로 묶어서 준비 (포토샵 레이어와 유사)
7) composition : 차곡차곡 브라우저 위에 그림 그리기
Request Animation Frame(RAF):
WebAPI 중에 하나인 API 이며, 다음에 브라우저가 업데이트가 되기전에
실행되는 callback 들을 정의할 수 있습니다.
보통 다음 프레임에 업데이트 하고자 하거나, 프레임 마다 업데이트 해야 하는 애니메이션, 게임 등 사용
사전에 알아야 할 것
다른 Main 으로 시작해서 Main이 끝나면 종료되는 프로그램과 다르게
자바스크립트 런터임 환경에서는 사용자가 프로그램을 종요하지 않는 이상
계속 실행되고 있는 상태이기 때문에 콜스택(Call Stack)이 비었다고 해서 프로그램이 종료되지 않음
- 큐 -> 콜스택 이동 방법
이벤트 루프 이기 때문에 빙글빙글 순회하면서 가져온다고 설명했지만
실제로는 Queue(큐)에 있는 것들을 Call Stack 으로 직접 이동해서 넣는 것이 아니라 단순히 API를 호출해서 해당하는 콜백함수를 Call Stack 으로 넣어주는 것 (Ex. 배열에서 push 라는 API라는 호출해서 데이터를 넣는 것처럼)
이벤트 루프
1초에 60 fps (16.7ms)
- fps(프레임) : 1초 동안 컴터에서 보내는 영상(장면)의 수.
- Hz(헤르츠/주사율) : 1초 동안 모니터를 통해 출력된 영상(장면)의 수. ex. 1초 동안 3개의 화면이 출력되었다면 3Hz
1부터 120까지를 1초만에 출력하는 화면이 있다면 120fps의 성능을 내는 컴퓨터에서 출력을 쏘더라도 144Hz 모니터에서는 1부터 120까지 모든 숫자를 다 볼 수 있지만 60Hz 모니터에서는 홀수만 볼 수 있거나 짝수만 볼 수 있거나 그 중간만 볼수 있거나 한다고 합니다.
이벤트루프(event loop)는 한바퀴도는데 1ms 조차 걸리지 않습니다.
이벤트루프는 순회하다가 Call Stack 이 다 비어질 때까지 콜스택에 머물러있다가
(콜스택에서 무거운 연산등을 실행하면 업데이트를 할 수 없게 되는 현상이 발생)다 비어지면 다시 순회하고 업데이트가 필요해 질때(16.7ms 를 지키려고 함) Render Sequence(렌더시퀀스)에 가서 위에 그림 처럼 실행하여 업데이트합니다.
이후 또 무한히 순회하고 Microtask Queue(MQ)에 promise then, mutation observer(web api 중 한가지 이며 이 api 에 등록된 callback) 있다면 MQ 머무르면서 하나씩 Call Stack 으로 가져와서(내부적으로 위와 같이 큐 -> 콜스택 이동방법처럼 가져오기 때문에)실행하고 MQ가 비어져 있지 않다면 또 가져와서 실행하고 MQ가 다 비어질 때까지 이벤트 루프는 순회하지 않고 MQ가 다 비어질때까지 머무르면서 가져와서 실행되게 됩니다. MQ가 다 비어졌으면 다시 순회하고 순회하다가 Task Queue(TQ)에 callback 이 있다면 Call Stack 으로 하나를 가져와서 실행하고 루프를 순회하고 이후에 다시 와서 하나를 가져와서 실행하고 다시 루프를 순회합니다. 이런식으로 자바스크립트 런타임 환경이 동작하게 됩니다.
TQ 와 MQ 가 다른점
TQ에 있는 것들은 하나씩 가져와서 실행하고 루프를 순회해서 다시가져 오는데
MQ에 있는 것들은 하나씩 가져와서 실행하고 또 있으면 루프를 순회해서 가져오는 것이 아니라 머무르면서 하나씩 가져와서 MQ가 비어질때까지 실행 함)
리액트 측면에서 보기
React에서의 상태 업데이트는 일반적으로 한 프레임 내에서 처리됩니다.
React는 상태나 속성이 변경될 때 해당 컴포넌트를 다시 렌더링하고, 이 과정이 한 프레임 안에 처리됩니다.
간단한 상태 업데이트는 한 프레임 내 처리되지만 복잡한 렌더링 로직이나 연산이 많은 경우 한 프레임에 처리하기 어려울 수 있습니다.
React는 내부적으로 상태 업데이트와 컴포넌트 렌더링을 효율적으로 처리하여 성능을 최적화하려고 노력 합니다.
이는 React의 가상 DOM 및 재조정 과정 통해 가능하며 변경된 부분만을 최소한으로 업데이트하여 효율적으로 렌더링을 구현합니다.
대부분의 경우 React에서의 상태 업데이트는 한 프레임 내에서 처리되며, 이러한 방식으로 빠르게 컴포넌트를 업데이트하고 화면을 갱신할 수 있습니다.상태값 업데이트 :
상태값이 업데이트는 리액트 컴포넌트의 렌더링 주기와 무관하게 발생할 수 있습니다.
리액트 컴포넌트 내에서 setState 함수 등을 사용하여 상태값을 업데이트하면, 이 업데이트는 해당 코드 블럭이 실행되는 즉시 반영됩니다.
이 업데이트 작업은 일반적으로 자바스크립트 이벤트 핸들러 함수나 다른 리액트 라이프사이클 메서드 내에서 콜하고 발생하게됩니다.
브라우저 렌더링 주기 :
브라우저는 일반적으로 초당 60프레임(60fps)으로 렌더링되도록 노렵합니다.(브라우저가 화면을 갱신하는 속도)
브라우저 렌더링 주기는 브라우저의 자체의 렌더링 엔진에 의해 제어되며 개발자가 직접 조잘할 수 없습니다. 각 프레임에서 브라우저는 DOM을 업데이트 하고 스타일 계산, 레이아웃 계산 그리기 등의 단계를 거쳐 화면을 업데이트 합니다.
따라서 상태값 업데이트와 브라우저 렌더링은 별개의 프로세스이며 상태값 업데이트는 언제든지 발생할 수 있지만 브라우저 렌더링 주기는 일반적으로 60fps로 제어됩니다. 상태값이 업데이트되면 해당 컴포넌트가 다시 렌더링되고, 이 렌더링 결과가 브라우저의 다음 렌더링 주기에 반영이 됩니다.
요약하면, 상태가 업데이트되면 리액트는 컴포넌트를 다시 렌더링하고 화면을 업데이트 하려고 합니다. 하지만 실제로 화면이 업데이트되는 시점은 브라우저의 다음 프레임을 그릴때 이며 이는 브라우저의 성능, 현재 시스템 부하 등에 따라 다를 수 있습니다. 컴포넌트의 렌더링이 60fps 안에 실행되는 것은 최적의 상황이지만 환경에 따라 다를 수 있습니다.
React는 가능한 한 빠르게 렌더링을 처리하려고 노력할 것이지만 실제 렌더링 속도는 브라우저와 시스템의 성능에 의존합니다.
1) 상태 및 속성 업데이트: React 컴포넌트의 상태나 속성이 업데이트되면 React는 Virtual DOM을 통해 변경된 부분을 식별합니다.
2) Virtual DOM 업데이트: 변경된 부분을 반영하여 새로운 Virtual DOM을 생성하고, 이전 Virtual DOM과 비교하여 실제 변경 사항을 찾습니다.
3) DOM 및 CSSOM 업데이트: 변경된 사항은 DOM과 CSSOM에 적용됩니다. 이 과정에서 최소한의 실제 DOM 조작과 CSSOM 업데이트만 수행하여 최적화됩니다.
4) 화면 그리기: 변경 사항이 DOM에 적용되면 브라우저가 화면을 그립니다. 브라우저는 업데이트된 DOM과 CSSOM을 기반으로 실제 화면에 UI를 렌더링합니다.
이 과정에서 React는 Virtual DOM을 활용하여 변경 사항을 효율적으로 추적하고, 최적화된 방식으로 DOM 및 CSSOM을 업데이트하여 브라우저가 효율적으로 화면을 그릴 수 있도록 돕습니다. 그러나 최종적으로 화면을 실제로 그리고 관리하는 것은 브라우저의 역할입니다.
DOM :
https://developer.mozilla.org/en-US/docs/Web/API/Document_Object_Model/Introduction
DOM API :
https://developer.mozilla.org/en-US/docs/Web/API/HTML_DOM_API
EventTarget :
https://developer.mozilla.org/en-US/docs/Web/API/EventTarget
Node :
https://developer.mozilla.org/en-US/docs/Web/API/Node
Performance :
https://developer.chrome.com/docs/devtools/performance/reference/
perfomance tab : command + shift + p
