가수면
쓰곰그리곰 프로젝트 최적화 작업 본문
1. 최적화에 대한 필요성 인지
몇 주전 유저 테스트 중에 글 목록 조회하는 부분에서 로딩이 조금 느린 것 같다는 피드백이 있었다.
계속 추가되는 달력 기능으로 인해 달력 로직이 상당히 무거워졌었고, 달력은 글 목록 조회하는 부분에 있었기 때문에 당시엔 나의 달력으로 인한 문제인 줄 알았다.
그리고 피드백이 있고 몇 주가 지나 드디어 여유가 조금 생긴 나는 다른 팀원들을 기다리며 내가 맡은 파트들을 먼저 조금씩 리팩토링해보기로 했다.
그렇게 라이트하우스를 돌려본 결과, 점수는 처참했다.
사용하지 않는 자바스크립트가 너무 많다며 bundle.js의 용량도 비대했다.
달력도 달력이지만 레이아웃 등 하나의 컴포넌트로 묶어서 사용할 수 있는 것을 팀원들 각자 만들어 무분별하게 중복 사용하고 있다는 것도 개선해야 할 점일 것이다.
2. 메모이제이션 작업 실시
우선 달력을 손 보는 작업에 돌입했다.
컴포넌트를 분리하여 불필요한 렌더링을 방지하고자 React.memo를 사용하였고, 재사용되는 값과 함수들은 useMemo와 useCallback을 사용하여 필요할 때만 읽히도록 조치했다.
할 수 있는 작업을 다하고 난 뒤, 성능의 개선을 기대했었는데 이상하게도 유의미한 점수 변화가 없었다.
(이후 알게 된 사실이지만, 메모이제이션 작업은 오히려 초기 렌더링을 지연시켜 라이트하우스의 성능 점수에 악영향을 끼칠 수 있는 거였다.)
https://react.dev/learn/you-might-not-need-an-effect#how-to-tell-if-a-calculation-is-expensive
https://jhchoi1182.tistory.com/221
3. 컴포넌트 리팩토링
프로젝트 마감일을 앞두고 시간에 쫓기던 차, 나는 밤을 새워서라도 지저분한 컴포넌트들을 최소한이라도 정리를 해두고 싶었다.
자주 쓰이는 모달과 인풋 등을 재사용 가능하도록 컴포넌트화하고 레이아웃과 헤더를 만들어 모든 컴포넌트에 적용을, 함수들은 훅으로 정리하였다.
사실 이때 디자인 패턴이라든가 배운 것들을 적용해 보는 시간이었어서 밤을 새면서도 굉장히 재밌게 진행했었다.
그리고 리팩토링의 부수효과로 성능이 미미하게 개선된 효과를 얻을 수 있었다.
4. 코드 스플리팅
나는 여러 최적화 작업을 거쳤음에도 사용하지 않는 자바스크립트가 여전히 많다는 진단에 의문을 가졌다.
코드를 줄인다고 줄인 것 같은데도 여전히 bundle.js가 '비상식적'으로 크다는 것이 의아했기에 검색에 들어갔고, 그 결과 코드 스플리팅이라는 개념을 접할 수 있었다.
Loadable Components라는 라이브러리는 서버 사이드 렌더링에도 적용할 수 있다는데 우리에겐 해당 사항이 없었기에 리액트 자체에서 제공하는 React.lazy훅을 사용하였다.
그 결과,
사용하지 않는 자바스크립트가 2.3초에서 0.6초대로 줄며 성능이 대폭 상승하는 결과를 얻을 수 있었다.
배포 후 최종 점수
모든 점수는 전체 글 조회 목록 페이지를 기준으로 하였으며, 접근성은 전체글 조회 페이지에선 디자인 컨셉 상 일부러 표기를 하지 않는 것들이 있었기에 낮게 나왔다.
아래는 다른 페이지의 점수
아쉬운 점
최적화를 신경쓴다 해놓고, 리액트 쿼리를 썼는데 cacheTime이나 staleTime 등을 우선순위 미루다가 프로젝트 마감일 내 끝까지 지정해주지 못한 게 아쉽다.
(마감일 이후에 작업 완료함)
'일지' 카테고리의 다른 글
useNavigate에 대한 고찰 (?) (0) | 2023.02.23 |
---|---|
실전 프로젝트 회고 (0) | 2023.02.13 |
프로젝트 마무리는 어디로... (1) | 2023.02.05 |
전역 상태 관리 Redux Vs React Query (0) | 2023.02.02 |
기능 마무리 (0) | 2023.01.29 |