[20240813TIL] 성능 최적화

박요셉·2024년 8월 13일

TIL

목록 보기
60/60

성능 최적화 작업을 진행을 했음

  1. useBookmark를 CardSlider내부의 AreaCard 컴포넌트에서 각자 호출한다.
    -> useQuery가 속한 useBookmark 훅에서 데이터 페칭을 굉장히 많이 반복하게 되어 이를 한칸 상위인 CardSlider로 올림
    -> 하지만 렌더링이 줄긴했어도 생각보다 줄진 않음 한번 렌더링시 약 5~6회정도 되길레 크게 문제인 듯 하여 튜터님께 질문을 하러감
    -> Q : 렌더링이 이렇게 일어나고 있습니다 문제가 클까요?
    A : 이정도 렌더링은 괜찮다, 물론 더 줄일 수 있겠지만 크게 성능상의 문제를 초래하진 않아보인다, 그리고 props로 depth 2정도 까진 내려줘도 아무런 문제없다 왜냐? 연관이 되어있는 컴포넌트니까, 그리고 북마크를 클릭할 때마다 데이터를 패칭해줘야할까요? 사용자는 북마크 표시여부만 바뀌면 되는 것 아닐까요?
    -> 위의 말을 듣고 내가 프롭스를 쓰는 방식을 생각해봤는데 depth 2여도 잘 내려줬으면서 여기서만 안내려주고 있었음, 그리고 마지막 말을 듣고 머리에 번개가침 난 멍청함.

  2. 성능 개선은 잘 되었나?

  • memoization을 해야 할 컴포넌트는 하고 너무 간단한 것들, 또는 렌더링 시 당연히 렌더링 되어야 하는 부분을 제하곤 모두 해주었다.
  • lazy 로딩을 적용하여 눈에 보이지 않는 컴포넌트들은 늦게 js로 바뀌도록 했음
  • SSR로 페이지들을 수정했음
    그래서 아래와 같은 결과가 나왔음



    등등 많지만 위의 결과와 엇비슷한 결임

라이트 하우스 상에서 79점이 나와 크게 문제가 되는 걸까?란 생각이 들었지만 앞서서 UX상에 크게 걸림이 없으면 그건 최적화가 잘 되어있다고 느껴진다라는 말을 들은적이 있음

고로 사람들에게 이정도 속도면 어떤가요? 하고 물어보러댕김

2분에게 물어봤고 꽤나 호평을 들어서 더 이상의 최적화는 프로젝트 시간 상 진행하지 않도록 하였음

느낀점

솔직히 최적화도 틀이 다 있겠지란 생각에 진행하지않고 나중에 다 하면 금방 할거야라는 막연한 생각에 코드를 짤 때 대충 짠 것들이 매움 많음

하지만 3일간 최적화를 하고있는 나의 모습을 보고 메모이제이션만큼이라도, SSR 페이지라면 초기부터, 그에 맞는 코드를 작성하는 것이 낫다 느꼈던 경험이 되었음

profile
개발자 지망생

0개의 댓글