현재 서비스에서 UX를 개선하기 위해서 가장 첫번째로 해야하는 부분은 로딩이 늦는 문제(중요 ⭐)였다.
가장 처음으로 보여지는 페이지인 만큼 빠른 반응성이 중요하다는 생각과, 재미요소가 중요한 서비스의 특징으로 인해 로딩 속도가 느리다면 사용자가 이탈할 가능성이 높다는 생각이 들었다.
로딩이 늦는 문제
현재 상황
우측 비디오를 통해 확인할 수 있지만, 로딩 속도가 굉장히 느리다고 느껴졌다.

- get channel를 기준으로 701ms
- get posts의 경우 641ms
개선 방향
data fetching 속도가 느리다는 것이 확연하게 보였고, 팀 내에서 data fetching속도를 줄이기 위한 고민을 하게 되었다.
만일 data fetching 속도를 줄일 수 없다면 사용자에게 빠르다는 인상을 주는 방식이 중요하다고 느꼈다. 우리 프로젝트의 성격을 고려했을 때, 애니메이션이 많기때문에 눈속임에 유리할 것이라는 생각이 들었다. UX를 개선하기 위해서 사용자에게 노출되는 시간을 속이기 위한 목적으로 낙관적 업데이트를 고려하고 있었다.
data fetching을 더욱 빠르게
시도 1. vercel을 제거하자
vercel을 왜 사용했나?
프로젝트의 보안 문제로 인해 요청하는 BASE URL을 감추는 과정이 필요했다.
따라서 우리 서버로 api 요청을 보내고, 서버에서 api를 재요청하는 방식으로 BASE URL를 감추었다.
- 보안 문제가 해결되어 vercel을 제거해 호출을 줄이는 방식이 가능해졌고, 요청을 직접 발송하는 방식으로 변경을 진행하였다.
- get channel + get posts를 기준으로 각각 17ms, 74ms에 해당, 약 600ms 단축

시도 2. react-query를 통한 캐시된 data 노출하자
항상 api요청으로 새 응답을 보여줘야하나?
내 개인 정보나 나의 작성내역과 같이 특정한 이벤트가 발생하지않는 이상 response가 변경되지않는 정보에 대해서 불필요한 재호출을 하는 것이 의미가 없다는 생각이 들었다.
해당 케이스에 대해서는
staleTime: Infinity
을 통해서 불필요한 호출을 막고, 단 한 번의 호출로 이후에 발생하는 접근에 대해서는 data를 지연없이 제공해줄 수 있겠다는 생각을 하였다.- 하지만,, 마침 내가 작업하는 API를 사용하는 페이지에서는(채널리스트, 채널, 알람 등) 항상 현재 상태가 fresh상태임을 보장할 수 없기때문에 적용할 수 없었다. 따라서 유경님의 코드를 통해 예시 코드를 가져왔습니다!
//useUserFollowList.ts function useUserFollowList(followList: Follow[], queryKey: string) { return useSuspenseQueries({ queries : { ... staleTime: Infinity ... } ... export default useUserFollowList;
위 개선 작업을 통해서 data fetching 속도가 급격하게 줄은 것을 확인할 수 있었고, 로딩 속도가 더는 문제가 아니게 되어 Optimistic UI를 적용하지 않게되었다. ( 네트워크 환경이 좋지 못한 상황에 대해서는 문제가 될 수 있지만, 짧은 개발기간인 만큼 다른 작업들이 더 우선순위가 높다는 생각이 들었다. )
뿐만 아니라 나의 작업 영역에서는 Suspence를 통한 부분 로딩 처리를 이용하지 못했지만, 해당 기법을 사용한다면 로딩이 필요한 범위만 로딩처리를 진행하므로 UX이 개선될 것 이라는 생각이 들었다. 다음 프로젝트에서는 꼭 적용해볼 수 있는 기회가 생겼으면 좋겠다.
20000 !