성능최적화 (...ing)
CRA를 사용하지 않은이유는 어떠한 도움 없이 개발환경을 설정해보고자 했던것도 있었지만,
사실 필요한 설정만 가볍게 함으로써 성능도 더 좋아질 거라는 기대가 있었다.
하지만 간과했던 점은, CRA에서 해주던 여러가지 최적화 옵션이 빠짐으로써(Code Splitting을 위한 옵션 등)
따로 설정해주지 않으면 훨씬 더 심각한 성능문제가 발생한다는 것이었다.
데이터베이스 모델링 관련 글에서도 언급되었지만
프로젝트가 끝나갈 무렵, 극단적인 수치의 데이터를 넣고 데모를 돌려보았다.
결과는 대 참 사 였다.
로딩을 하는데 약 20초가 걸렸고, 그런 결과물을 내놓을 수는 없었다.
확인해보니 하나의 번들파일이 약 12메가를 넘어가고 있었다.
데드라인이 다가오고 있었지만, 최대한의 노력으로 최적화를 하고자 공부해서 적용하였다.
먼저, 웹 서비스의 대표적인 성능 측정기인 Light House를 이용하여 진단하였다.
Performance 측면에서 심각한 점수를 받은 상태였다.
가장 큰 문제는 우선 번들파일을 하나로 받는데, 그 파일마저 압축되지 않은 상태였고, 개발단계에서만 필요한 모듈들이 그대로 들어가있었기 때문인다.
Light House의 지적에 따라 하나하나씩 성능 개선을 하기 시작하였다.
개발단계에서만 필요한 대표적인 모듈은 SourceMap이다.
배포된 서비스에서 오류를 굳이 노출시켜줄 이유는 없다.
이외에도 지워주어야할 모듈들이 더 있을지 모르겠지만, 급한대로 SourceMap 모듈만 지워주었는데
이것만으로도 빌드파일이 훨씬 가벼워졌다.
번들링 된 파일을 gzip형태로 압축할 수 있었다.
단, 이것은 웹팩 설정만으로는 해결할 수 없고 사용하는 웹 서버가 gzip형태로 압축할 수 있게 해야했다.
우리는 nginx를 웹 서버로 사용하고 있었기 때문에, nginx.conf파일에서 gzip관련된 옵션을 추가해주었다.
아래쪽에 보면 Content-Encoding방식이 gzip형태로 바뀐것을 볼 수 있다.
이정도의 설정만으로도 Light House에서 위험수준은 벗어날 수 있었다.
코드 스플리팅은 하나의 번들파일을 여러개로 나누어 받는 작업이다.
물론 하나로 번들링하여 받은것은 의도된 작업이었지만,
프로젝트의 규모가 커지면서 그 하나의 번들링파일이 너무 커지면 여러개로 나눈다고 한다.
우리는 프로젝트의 규모가 그리 크지않지만, 할 수 있는 부분에서 일부 적용해 보기로 하였다.
우리가 적용한 부분은 각 page에 대한 부분을 React가 제공하는 Lazy를 이용하여 import하도록 하는 것이었다.
이렇게만 처리 해 주어도, 현재 보이는 페이지만 import하여 사용하도록 처리되기 때문에 Light House의 점수가 개선되는 것을 볼 수 있었다.
-
react-router-dom 모듈에서 코드 스플리팅을 지원해준다.
-
위에서 작업한 lazy를 통한 import는 동적으로 import를 하는데 초점을 두어야겠다.
그 외에도 개선할 점은 많았지만, 아직 전부 적용하지는 못하였다.
하지만, 위험수준의 성능 점수에서 일반적인 상태까지 끌어올린 것에 대해 의의를 가졌고 최적화 작업에 대해 학습할 수 있는 것에 감사했다.
이후에도 계속 개선해나갈 프로젝트 이기 때문에
chunkFile을 나누는 작업과, render-blocking resource를 제거하는 등의 작업등을 해보아야 겠다.
비록 로컬에서 진행하긴 했지만, 차트 애니메이션에 렌더링 최적화 할 수 있는 부분을 발견하여 개선하였다.
Table Chart의 경우 width를 변경하는 애니메이션을 사용하였는데,
width의 변화는 렌더링 과정중 Layout을 변경시키게 되어 Reflow를 발생시킨다.
이에따라 약간의 쟁크현상이 발생하는 것을 관찰할 수 있었다.
이것을 개선하기 위해 기존에 width값을 변경하는 작업을 transform을 통해 대체하였고, Performance탭을 통해 개선된 것을 확인할 수 있었다.
아래 사진에서 보라색 부분이 CPU의 사용량인데 같은 부분의 애니메이션 작업시, 그 사용량이 현저하게 줄어든 것을 확인할 수 있다.
개선전
개선후
