만약 박스를 좌우로 움직이도록 어떻게 해야 할까?
CSS 로 keyframe 을 만져서 동작하도록 만들었을 것이다.
하지만 10000개라면?
엄청 버벅일거다 -> JANK, JANKY 하다 라고 한다.
left를 쓰지 않고 transform 으로 쓴다면 더 부드러워진다!
어디서 이런 차이가 발생할까?
Rendering Pipeline
브라우저가 페이지를 화면에 그리는 과정
Loading Parsing
Network 에서 받은 HTML 파일을 읽고, parsing 을 시작함.
DOM
DOM 트리를 만든다.
Style
각 DOM node 에 적용될 style 을 계산
Layout
위치, 너비, 높이 등 기하학적 요소 계산해 레이아웃 트리를 만듦
요소의 속성에 따라 레이아웃 트리에는 속하지 않을 수도 있음 : {display: none}
모두 한 레이어라면 배경부터 스마일까지 매번 전부 다시 그려야 한다.
이 그림을 움직이는 부분과 움직이지 않는 부분을 분리하면 어떨까?
그럼 다시 그려야 하는 부분이 엄청 줄어든다
실제 웹 서비스도 많은 레이어로 이뤄져있습니다.
Paint
각 요소를 그리기 위한 페인팅 명령들을 기록
즉, 아직 눈에 보이는 픽셀은 아니다
Layer
함께 그릴 단위
요소의 선언 순서와 paint 순서는 또 다를 수 있다 : z-order
Composite
레이어는 만들어졌지만, 아직 픽셀로 만들어지지 않는 상태
각 레이어의 Paint ops 를 실행하면서 픽셀을 뽑아냅니다. (Rasterize)
뽑아낸 레이어의 이미지들을 위치에 맞게 놓고 합성 (Composite)
Layer들을 픽셀로 만들고, 픽셀화된 레이어를 합성해 만든 최종 이미지를 만들어냄
Hardware Acceleration
Rasterize와 Composite은 GPU 를 이용하기 때문에 훨씬 빠릅니다.
하드웨어 가속
일반적으로 프로세싱 유닛이 일을 처리하는 방식 : 순차적으로 들어온 순서대로
처리할 픽셀이 많을수록 느려진다
GPU 는 많은 픽셀을 한번에 처리해버림
어느 단계부터 다시 시작하느냐에 따라 비용이 천차만별
x,y? opacity?
Layout 부터 다시 하는 것을 Reflow
Paint 부터 다시 하는 것을 Repaint
left 와 transform 은 각각 어디서부터 시작할까?
left 는 Layout, transform 에서는
css-triggers.com 에 가시면 여러 속성이 어떤 단계를 유발하는지 알 수 있다.
JS가 충돌하면
얘는 뭐든 할 수 있다. 반복적인 유의해야 한다. 그래서 JS 는 작고 빠르게 해야 한다.
그러면 얼마나 빨라야 할까요? -> FPS Frame Per Second 초당 이미지를 뽑아내는 속도
일반적인 모니터 주사율이 60Hz
60fps > 60hz
16.6ms 안에 랜더링 파이프라인 다 돌아야 함
100fps > 60hz
모니터보다 빠르게 생성되는 거라, 무의미하게 찍어내는 짓
60fps = 60hz 로 해야 한다.
Devtools > Performance 패널에서 녹화
어떤 단계가 가장 많이 실행되는지 확인
setTimeout(), setInteral()
requestAnimationFrame(), requestIdelCallback()
스케쥴링 할 때 써볼만한 것들
OffscreenCanvas
Service Worker
Web Worker
무거운 작업을 해야할 때 써볼만한 것들
Make it work, Make it right, Make it fast. - Kent Beck
