React Scan - FrontOverflow
FrontOverflow
React를 처음 배우며 실무 진행했던 프로젝트가 있었습니다.
1년 정도 타 팀으로 갔다가 돌아오며 유지보수 업무를 맡게되었는데요.
기능이 많이 추가되며 성능 이슈가 생겨 성능 향상을 위한 리팩토링을 진행했습니다.
오래전에 짠 코드라 미흡한 점이 많이 보였습니다.
시간이 많지는 않아 하루만 사용했습니다.
성능 점수 측정은 간단히 크롬 브라우저에서 제공하는 라이트하우스를 사용했습니다.
모든 페이지를 성능 측정을 진행하고, 느린 4G로 네트워크를 맞춰서 레이아웃 렌더링을 확인했습니다.
React Scan툴도 있지만, 급하니 다음에 확인해보고 써보기로 했습니다.
https://www.frontoverflow.com/magazine/16/React%20Scan
성능 검사를 해보니 첫 페이지 혹은 새로고침시 전부다 로드하기에 FCP(사용자가 첫번째 콘텐츠를 볼수 있는 시점)가 2초 정도로 느리더군요.
초기 로드 속도 향상을 위해 코드 스플릿을 라우터 페이지별로 적용하고, 자주 사용하지 않지만 조금 무거운 라이브러리들은 추가로 코드 스플릿을 적용해서 사용하지않는 자바스크립트 양이 줄였습니다.
코드 스플릿을 적용하면 해당 컴포넌트가 사용될 때 로드됩니다. 한번 로드되면 다시 들어갈때는 재사용됩니다.
다음으로 레이아웃 쉬프트 현상을 몇개의 컴포넌트에서 발견해서 디폴트 값을 넣어주고, 이미지 크기를 지정 해줬습니다.
CLS 점수는 레이아웃 쉬프트의 빈도와 크기를 합산하여 점수로 나타냅니다.
좋음: 0.1 이하
개선 필요: 0.1 ~ 0.25
나쁨: 0.25 이상
이미지 크기를 개선하는건 시간이 오래걸릴 듯하여 다음 일정으로 미루었습니다.
네트워크를 찬찬히 보니 API 호출이 많고 같은 API 호출 횟수가 많았습니다.
Config한 데이터들이 여러 컴포넌트에서 호출되고 있었고 한번만 받아서 캐싱해둔 다음 필요한 컴포넌트에서 사용하게 수정했습니다. 예방차원에서 캐싱데이터가 없다면 서버로 호출되도록 로직을 만들었습니다.
특정 컴포넌트 경우 여러 API가 호출되고 있는데 API호출 함수에 await 개별로 적용되어 있었습니다. 이럴 경우 응답 받고 다음 호출, 받고 다음 호출이 되어 앞단의 API 요청-응답이 다 될때까지 뒤에 있는 API함수 호출은 대기 하게 됩니다.
Promise.all을 사용해 병렬로 API가 한번에 호출되도록 수정했습니다.
여기까지 성능 개선을 진행했습니다.
하루 치고는 API 호출 횟수를 줄이고 로드 데이터 양을 조절함으로 프론트단 성능은 많이 개선되었습니다.
하루만 해도 가능하니 레거시한 코드를 살펴보는것도 괜찮은 것 같습니다.
성능향상은 프론트 뿐만 아니라 백엔드 쪽에서도 각자의 파트에서 개선해 줘야합니다.
쿼리문을 최적화 한다던가.. 서버에서 캐싱해두었다가 내보낸다던가..
저희 팀은 각 파트에서 조금씩 개선을 하고 서로 공유했는데 재밌었습니다.
이 후 성능 개선에 정확한 데이터를 얻을 수 있는 편하고 간단한 모니터링 시스템이 없을까 고민하며 글을 마칩니다.
다음 내용이 궁금하다면?
이미 회원이신가요?
2024년 12월 3일 오전 7:28