브라우저 메인 스레드가 비싼 이유
The Browser's Main Thread Is Expensive
프론트엔드 최적화하면 네트워크 요청 줄이기, 번들 크기 줄이기, 캐시 활용 등을 떠올리지만, 정작 화면이 멈추는 원인은 메인 스레드가 막혀서일 때가 많다. 이 글은 메인 스레드가 하는 일(JavaScript 실행과 렌더링)과 16.6ms라는 프레임 예산을 설명하고, 메인 스레드를 효율적으로 쓰는 네 가지 방법(분할, 일괄 처리, 우선순위, 지연)을 제시한다. 특히 분할의 핵심인 yield 기법을 setTimeout과 requestAnimationFrame을 이용해 구현하는 방법을 코드와 데모로 보여준다.
코드가 느린 것이 아니다. 단지 메인 스레드를 잡고 있는 코드일 뿐이다.
HN 토론
80- nerdralph
글의 대부분에 동의하지만, 다음 부분은 명확히 하고 싶습니다:
> 화면이 부드럽게 보이려면 프레임이 디스플레이의 재생률에 맞춰 그려져야 합니다. 가장 흔한 60Hz 디스플레이에서는 초당 60프레임, 즉 프레임당 약 16.6밀리초를 의미합니다.
디스플레이 재생률과 정확히 일치시킬 필요는 없습니다. 144Hz 모니터에서 72FPS는 대다수의 사람들에게 부드럽게 보일 것이고, 48FPS조차도 대부분의 사람들에게 부드럽게 보일 것입니다. 더 높은 FPS가 더 좋다는 점에는 동의하지만, 한계 효용이 체감합니다.
- martinald
좋은 글이고, 이것이 더 널리 알려졌으면 합니다.
문제는 상호작용성에 너무 초점을 맞추고 있다는 점입니다. 실제로 느린 사이트의 90% 이상은 상호작용성 때문에 느린 것이 아니라, 거대한 react/nextjs 번들을 제공하고 매우 무거운 하이드레이션 작업을 수행하기 때문에 느립니다.
수많은 사이트가 다운로드, 파싱, 하이드레이션해야 하는 10MB가 넘는 번들을 가지고 있습니다.
심지어 여러 개의 SPA가 그 안에 겹겹이 쌓인 사이트도 (많이) 봤습니다.
인터넷 연결이 느리거나 CPU가 느린 경우, 페이지는 수십 초 동안 기본적으로 사용할 수 없으며, 번들 하이드레이션 후 양보(yielding)를 아무리 많이 해도 그 문제를 실제로 해결하지 못합니다.
- gwbas1c
참고: 이것은 브라우저에만 해당되는 것이 아닙니다. 모든 플랫폼(Windows, Mac, iOS, Android)은 일반적으로 단일 스레드 UI를 가지고 있습니다.
- jkhdigital
이 글은 다음 진술로 결론을 맺습니다:
> 개발의 많은 부분이 트레이드오프이며, 상황에 따라 선택해야 하고, 궁극적으로는 개발자의 경험과 판단에 달려 있습니다.
훌륭한 글이지만, 스케줄링 문제를 '경험과 판단'의 문제로 구성하는 것은 시대에 뒤처진 느낌이 있습니다. 희소한 자원에 작업을 할당하는 문제는 컴퓨터 과학 전체에서 가장 오래되고 가장 잘 연구된 문제 중 하나입니다. 바퀴를 다시 발명하려고 하기 전에 교과서를 참고하는 것이 합리적일 것입니다.
- larodi
훌륭한 글입니다. 박수를 보냅니다! 이전에 이러한 기법 중 일부를 적용해 본 적이 있는데, 실제로 큰 차이를 만듭니다. 문제는 JS를 배우거나 가르칠 때 이러한 주제를 다룰 시간이 일반적으로 제한적이며, 보이는 것보다 훨씬 필수적이라는 점입니다.
협동 멀티태스킹의 핵심은 때때로 (실행자에게) 양보하여 그리기를 처리할 수 있게 하는 것입니다. 게다가 60fps에서는 매 N 프레임마다 한 번만 계산해도 되는 것이 많으며, 눈이 그것을 인지하지 못하고 애니메이션이 흐릅니다.
webgpu가 관련되면 훨씬 더 흥미로워지지만, CSS 애니메이터는 확실히 매우 빠릅니다.
참고: 제 최근 작업 중 일부 (newskool 디지털 플라이어 사이트) -> bsf.hmsu.org // nouveauxhivers.dub4powder.xyz