정리
언제부터 최적화를 해야 하는가?
성능 최적화 하면 좋을 것 같은데 싶을 때는 하지마라.
그래도 해야될 것 같으면 한 번만 더 생각해라!
진짜 해야 된다 싶으면 일단 프로파일링(측정)부터 하고 시작하자!
성능은 가장 안 좋은 상황에서 테스트해봐야 한다.
항상 모든 것에는 트레이드 오프가 있다. 최적화도 마찬가지다.
최적화로 사용자의 시간을 줄였다면, 코드의 양일 수도 있고 시간일 수도 있고 메모리일 수도 있고 무엇인가를 희생시켰다는 뜻이다.
그렇기 때문에 적절하게 선택해야 한다.
최적화 - 빠른 로딩 속도
- 초기 로딩 속도가 느린 이유로는
- 대역폭: 트럭의 크기 (4G, 5G)
- 지연 시간: 트럭의 속도
- 자바스크립트의 실행 시간
- 쌀 가마니를 옮기는 예를 들어보자.
- 자바스크립트 번들이라는 쌀 가마니를 옮겨야 한다.
- 옮겨야 하는 쌀 가마니를 줄일수록 일은 빨라진다.
- 쌀 가마니를 줄이거나 트럭을 늘리거나!
- 쌀을 한 톨로 줄여도 트럭이 느리면 오래 걸린다.
- 캐싱이 쌀 한 톨을 움직일 필요없이 내 앞에 두는 것과 같다.
- 또한 prefetch로 쌀 가마니를 미리 옮겨놓을 수도 있다.
- 화면에 꼭 보이는 순서대로 lazy loading?을 사용해도 좋다.
- 어떻게 쪼개는지도 중요하다.
최적화 - 런타임에서 반응성이 높다
Deus팀에서는 디자인 편집할 때 반응성이 높아야 한다.
어떻게 이 런타임 성능을 측정할 것인가가 중요하다.
초기 로딩이야 LightHouse가 있는데, 런타임의 경우 FPS(frame per secon)를 확인한다.
React 관점에서는 상태가 변화했을 때 얼마나 많은 렌더링이 일어나는가를 볼 수 있다.
Deus의 예를 들어보면 드래그 앤 드롭을 하는 동안 60fps가 유지되는지 보면서 개발한다고 한다.
여기서 60fps가 나오지 않는다면 개발자 도구로 프로파일러를 활용한다.
대체로 메인스크립트를 블록하는 js 코드가 실행될 때 fps가 끊긴다.
프로파일러에서 노란 막대를 확인하면 된다.
그 다음은 노란 막대를 작게 만드는 것이 중요하다.
체감 성능 vs 실제 성능
노란 막대의 길이를 줄이는 것이 실제 성능을 높이는 일이며,
노락 막대를 잘게 잘게 자르는 것이 체감 성능을 높이는 일이다.
리렌더링 최적화
useMemo
컴포넌트에 메모를 한다.
유저가 실제로 변경이 돼야 하는 부분만 컴포넌트가 재실행되게 리렌더링 해주어야 한다.
마무리
사실 나는 지금까지 성능 측정을 해본 적이 없다.
나는 실제 서비스를 운영해봤기 때문에 이 글의 도입부처럼 최적화는 오히려 시간 낭비였기 때문이다.
이 영상을 보니 성능을 측정하며 최적화해보는 공부도 해야 겠다.
추후에 예시 코드와 함께 이 글에 추가로 작성해봐야겠다.
