브라우저의 메인 스레드는 비싸다
https://kciter.so/posts/the-expensive-main-thread/

프론트엔드 성능에 관해서 대단히 포스트인데 메인 쓰레드는 매우 바쁘니 병목을 줄이는 케이스와 방법을 예제와 함께 잘 설명되고 있다.
한글 내용이 있는지 몰라서 gpt에게 번역과 요약을 맡겼는데 나중에 알고보니 한글 블로그였다. ㅎㅎ

정리한다면 다음과 같다고 한다.


저라면 이 글을 다음처럼 기억하겠습니다.

                 Main Thread가 바쁘다
                         │
            ┌────────────┴────────────┐
            │                         │
       Main Thread 사용          Main Thread 피하기
            │                         │
     ┌──────┼──────┐             ┌────┴────┐
     │      │      │             │         │
 Splitting Batching Priority   Compositor Worker
     │      │      │
     └──── Deferring
             │
        Work 제거
             │
    Drop / Merge / Skip

그리고 실제 문제를 만났을 때는 이런 순서로 생각하면 꽤 좋습니다.

  1. 이 작업 자체가 필요한가?
  2. 지금 해야 하는가?
  3. 여러 번 할 필요가 있는가?
  4. 작은 단위로 나눌 수 있는가?
  5. 우선순위를 조절할 수 있는가?
  6. compositor나 worker로 보낼 수 있는가?

이게 사실상 이 글의 사고방식입니다.

특히 사용자가 체감하는 성능은 전체 작업 완료 시간이 아니라 “사용자의 입력과 다음 프레임이 얼마나 빨리 끼어들 수 있는가” 와 굉장히 밀접합니다. 그래서 총 계산 시간이 조금 길어지더라도 메인 스레드를 자주 양보하는 편이 더 빠르게 느껴질 수 있다는 게 중요한 포인트입니다.

그리고 이 글은 일반적인 웹사이트보다는 실시간 데이터가 많거나, 인터랙션이 복잡하거나, 캔버스/이미지 편집처럼 화면이 계속 움직이는 앱에서 가치가 훨씬 큰 내용입니다. 저자가 마지막에서도 이미지 에디터·지도·게임 같은 애플리케이션을 대표적인 사례로 들고 있습니다.

메타데이터

조회수
2
좋아요
0

0개의 댓글

등록된 댓글이 없습니다.