프로젝트에서 React를 실제로 사용하고 있어서 React의 장점에 대해서는 어느 정도 파악하고 있다고 생각했다.
그런데 갑자기 의문이 들었다..!
화면 깜빡임 없이 변경사항만 부드럽게 화면에 표시해주는게 사용자 경험이 향상되는데 도움을 주는 건 알겠어,
근데 Virtual DOM은 왜 쓰는거지?
실제 DOM 조작이 왜 비효율적인거지?
어떤 부분 때문에 비효율적인거지?
등등..
브라우저 작동원리에 대한 이해도가 부족함에서 오는 의문들이었다.
그래서 이번 기회에 React의 작동원리도 제대로 짚고 넘어갈겸
브라우저 작동 원리 그리고 왜 DOM을 직접 조작하는게 비효율적인지에 대해서 공부해보려고 한다.
ps. 다른 분들이 잘 정리해놓은 글을 스스로 공부하기 위해 요약한 정도의 글이라
부족할 수 있다는 점 참고해주세요!
🔺 chrome 브라우저 렌더링 엔진 workFlow
렌더링 엔진의 역할은 요청받은 내용을 브라우저 화면에 나타내는 일
HTML, CSS, JavaScript 등의 파일을 브라우저가 화면에 표시할 수 있도록 변환하여 픽셀 단위로 나타냄
렌더링 엔진은 브라우저마다 다르다. 그래서 같은 소스임에도 불구하고 브라우저마다 다르게 그려지는 크로스 브라우징 이슈가 발생하는 것이다.
ㄴ 렌더링 엔진말고도 자바스크립트 엔진이 달라 발생할 수도 있긴 함
알면 좋은 지식
크로미움
- 오픈소스 웹 브라우저
- v8 자바스크립트 엔진과 Blink라는 렌더링 엔진을 사용하는 브라우저
- 크롬이 크로미움 기반으로 만들어진 브라우저?
즉, 오픈 소스인 크로미움 브라우저 코드 위에 살을 덧붙여 개발되었다는 의미
- Edge도 EdgeHTML 렌더링 엔진을 포기하고 크로미움 기반의 브라우저로 변경됨
async
는 스크립트 리소스 다운로드가 완료된 시점에 스크립트가 실행되지만, defer
는 HTML 파싱 하는 동안에 스크립트 다운로드하고 HTML 파싱이 완료되면 스크립트가 실행됩니다.async
(default 값인 async=true
일 경우)는 다운로드가 완료된 시점에 스크립트가 실행되어 스크립트 실행 순서를 보장할 수 없지만, defer
의 경우 정의된 순서대로 스크립트가 실행됩니다.Virtual DOM이 필요한 이유
DOM에 변화가 생기면 랜더트리를 생성하고
복잡한 SPA는 DOM 조작이 많이 발생된다
각 조작이 레이아웃 변화, 트리 변화와 렌더링을 일으킨다.
→ EX) 30개의 노드를 하나하나 수정하면 → 30번의 (잠재적인) 레이아웃 재계산과 30번의 (잠재적인) 리렌더링을 초래한다는 말이다.
반면에, Virtual DOM을 이용하면,
→ 인터렉션 발생 시 virtual DOM에서 먼저 적용시키고 최종 변화를 딱 한번만 실제 DOM에 적용시키는 것이다.
Virtual DOM이 없이도 가능하긴 하다. 하지만 불편하다.
→ DOM fragment를 적용 후 실제 DOM에 주면 되지만
→ DOM fragment를 관리하는 과정을 수동으로 하나하나 다 작업해야하는데
virtual DOM은 어떤게 바뀌었는지, 어떤게 바뀌지 않았는지 자동으로 해준다
SPA로 사용자와의 인터렉션(상호작용)이 일어났을 때 화면 깜빡임 없이 변경사항만 부드럽게 화면에 표시해주는 사용자 인터페이스를 만들기 위한 JavaScript 라이브러리이다.
데이터가 변경됨에 따라 적절한 컴포넌트만 효율적으로 갱신하고 랜더링한다.
위에 말했던 Virtual DOM 을 이용해서 갱신하다.
인터렉션이 있을 때마다 DOM을 조작하면 브라우저의 연산 양이 늘어나기 때문에,
React는 실제 DOM의 복제본으로 virtual DOM을 생성하여 인터렉션이 일어나면 Virtual DOM에서 먼저 데이터 갱신 여부를 체크하고, 변경된 사항을 반영한 후, 한번에 실제 DOM에 전달한다.
📝 참고