브라우저 입장에서 Input event
- any gesture from the user
- 글 입력, 마우스 클릭
- 마우스 휠 스크롤, mouse over, touch, …
Browser process
- 처음 이벤트를 알아챔
- renderer process에게 이벤트 타입 전달
Compositor thread
- main thread와 독립적으로 composite frame 제작
- 하지만 만약 페이지에 이벤트 리스너가 달려있었다면???????
Event Target 찾기
- main thread
- paint records를 보고 이벤트가 발생한 좌표에 뭐가 그러져있는지 찾음
최적화
Non-fast Scrollable Region
- compositor thread
- 페이지를 composite 할 때 이벤트 핸들러들이 ‘non-fast scollable region’에 있는지 표시함
- 이 영역에서 이벤트 발생 시 main thread에 이벤트 전달
- 아니면 main thread를 기다리지 않고 다음 frame 만듦
- 주의!
- 이벤트 핸들러를 달 때 이벤트 위임을 이용하려고 상위에 달면 훨씬 더 넓은 범위가 non-fast scrollable region으로 지정됨
- 불필요한 main thread와의 소통 발생으로 성능 저하 가능성
- 이벤트 리스너에 passive: true 옵션으로 compositor가 핸들러 완료를 기다리지 않고 새 frame 만들도록 지시 가능
Event Cancel
- e.cancelable && e.preventDefault()
- CSS touch-action
- 불필요한 브라우저 이벤트 핸들러의 동작을 막기
Main thread로 가는 이벤트 줄이기
- touchmove 같은 연속적인 이벤트는 발생할 때마다 메인 스레드를 부른다면 부하가 너무 큼
- 크롬은 연속적인 이벤트를 합쳐서 다음 requestAnimationFrame 직전에 전달함
- keydown, keyup 같은 이산(discrete)적인 이벤트들은 발생할 때마다 즉시 전달함
- 만약 그림그리기처럼 이벤트 합쳤을 때 문제가 있을 수 있는 경우는
event.getCoalescedEvents로 합쳐지기 전 정보를 받아올 수 있음
브라우저 성능 개선을 위한 다른 도구들
- Lighthouse
- Chrome DevTools
- Feature Policy