나는 개인적으로 html canvas를 활용한 서비스는 프론트엔드의 정수라고 생각한다. 아마 극한으로 프론트엔드에서 극한까지 사용하게 된다면 figma와 같은 궁극의 결과물이 나오지 않을까.. 생각해서 찍먹해보지 않을 수 없었다. 그래서 새롭게 프로젝트를 시작하는 과정에서 나는 마인드맵을 캔버스로 그려주는 서비스를 만들려고 했는데, 여기서 고민이 하나 있었다.
html 캔버스는 그래픽 요소를 그리기 위한 html 내장 콘텐츠로, 원하고자 하는 것을 비트맵 기반으로 그려낼 수 있다. 하지만 사실 다이어그램같은 요소들을 그려내는 과정에서 캔버스는 굳이 필수사항이 아니라고 생각한다.
당장 react-flow만 보아도 각 다이어그램들을 모두 div로 표현하면서, 여기서 CSS를 붙여 사용하는 방식인데, 캔버스로 굳이 할 필요가 없다는 생각도 들었다. 하지만 canva와 excalidraw와 같은 서비스들은 모두 canvas 기반으로 작동하는 서비스들이었기 때문에, 문득 이 html 요소들과 canvas 중에 무엇이 더 성능에 좋을까? 하는 의문이 들었다.
이에 대해서는 보다 브라우저의 렌더링에 대해 이해해야지 이유를 찾을 수 있을 것 같다고 판단하여 브라우저의 렌더링에 대해 간략하게나마 정리해보았다.
우리는 브라우저가 어떻게 보여지는지에 대해서 말해보라는 질문을 받으면 아마 간단하게 'HTML를 해석해서 DOM Tree로 파싱하고 CSS도 파싱한 담에 그려냅니다'라고 말할 수 있다. 하지만 이 '그려냅니다'라는 말은 많은 과정이 함축되어 있는 말이다.
브라우저는 Rendering Engine, Javascript Engine, Graphics Library 3가지 요소로 렌더링이 처리된다. 각 요소들은 가지는 한계가 명확하기 때문에 각자의 역할만을 담당한다.
렌더링 엔진의 경우 자바스크립트를 읽을 수 없기 때문에 html의 렌더링만 담당한 후, 구글의 V8 자바스크립트 엔진을 통해 자바스크립트를 해석하고 그래픽 라이브러리를 통해 우리가 보는 화면을 그려낸다. 이 일련의 과정은 모두
메인 쓰레드
에서 작동한다.
하지만 이 DOM 요소를 만들고 자바스크립트를 해석하여 화면을 그리는 과정 자체가 16ms를 넘다 보니까 모니터의 주사율 60Hz의 관점에서도 프레임 드랍이 발생한다.