요즘 리펙토링과 최적화를 진행하면서 어떻게 하면 좀 더 업그레이드할 수 있는지 고민하고 있었다.
그러던 중
계기
토스ㅣSLASH 22 - 잃어버린 유저의 시간을 찾아서 : 100년을 아껴준 SSR 이야기
를 보다가 자극을 받았다.
어떤 내용이었냐면
기존의 CSR 방식에서
SSR로 미리 데이터를 받아오는 방식을 통해
LCP를 단축 시켰다는 이야기였다.
LCP(Largest Contentful Paint) : LCP는 페이지가 처음으로 로드를 시작한 시점을 기준으로 뷰포트 내에 있는 가장 큰 이미지 또는 텍스트 블록의 렌더링 시간을 보고합니다.
나도 여기서 자극을 받아 바로 도입을 하기로 하였다.
현재 상황
기존 코드에서는 CSR 방식으로
데이터를 미리 받아오는 방식이 아니었다.
이유는 useSWRInfinite을 사용하는 것이 컸다.
인피니티 스크롤을 편리하게 구현하기 위해서 사용한 훅인데,
SWR을 이미 사용하고 있기때문에 활용도를 높이고자 도입하였고,
가독성과 유지보수에도 유리해서 사용하였다.
그리고 시간이 지난 지금 첫화면을 앞당기는 것의 중요성을 느껴
SSR과 인피니티 스크롤을 연결하고자하였다.
도입을 위한 시도와 문제점
플랜은 SSR로 먼저 데이터를 받아오고
이후에 useSWRInfinite를 사용하는 것이었다.
그런데 문제가 있었다.
useSWR과 달리, infinite는 값을 받아주는 기능이 없어서
연결이 어려웠고, 직접 로직을 구현해야만 했다.
2가지 방법으로 시도를 해보았는데,
1.첫번째 시도 : SSR로 데이터를 받아오고 이후 업데이트하는 방식이었다.
- 문제점 : 첫화면에는 문제없이 잘돌아갔지만,
검색이나, sort 버튼을 누르면 SSR 데이터가 없기때문에 문제가 되었고,
useSWRInfinite를 훅으로 사용하고 있는데 다른 페이지에서는 토큰이 필요하다는 것이었다.
클라이언트 세션스토리지에서 토큰을 관리하고 있어서, 서버에서는 토큰을 인식할 방법이 없다는 것이었다.
(찾아보니, 쿠키를 통해 관리하면 사용할 수 있다고 한다.)
-> 그래서 프로젝트 막바지에 수정하는 비용이 더 크다고 생각해서 철회하였다.
2.두번째 시도 : SSR로 데이터를 받아오고 이후 기존 로직은 유지하는 것이었다.
이렇게 작성하면 CSR보다 먼저 업데이트 되고, 이후 CSR 데이터로 바꾸는 방식이었는데,
수정 전
수정 후
페인팅 비용이 더 발생해서 철회하였다.
결론
고민 끝에 도입을 포기하기로 결정하였고, 다음 프로젝트에 이 경험을 참고하여 더 나은 설계를 할 예정이다.
어떻게 보면 next.js 쓰는 이유가 이 첫화면을 앞 당기기 위해서인데,
처음 이 프로젝트를 시작할 때, 이 부분에 신경을 쓰지 못한 것이 아쉬웠다.
