프론트엔드
마이리얼트립 SSR 최적화
두줄요약
SSR 도입 후 발생한 중복 API 호출과 성능 저하의 원인을 분석하고 구조를 개선한 사례를 다뤘습니다. queryKey 통일, 캐시 설정, 메서드 선택으로 FCP와 LCP를 크게 개선했습니다.
문제 상황
- 숙소 도메인 주요 페이지에 SSR 도입 후 초기 로딩 지연, hydration 이후 로딩 스피너 잔존, FCP/LCP 악화, 동일 API 중복 호출 발생
- SSR 적용 목적이었던 클라이언트 요청 감소와 반대로 서버 로그상 호출 수가 늘어나는 역효과 발생
원인 분석
- fetchQuery, prefetchQuery, 다시 fetchQuery로 이어지는 구조적 중복 호출
- SSR QueryClient의 staleTime 미설정과 resetQueries() 오용으로 인한 캐시 소실
- SSR/CSR 간 queryKey 생성 방식 불일치로 캐시 재사용 실패
- 데이터 검증이 필요한 흐름에 prefetchQuery를 사용한 메서드 선택 문제
해결 방법
- 최초 1회 fetchQuery로 핵심 데이터만 가져오고 이후 getQueryData()로 재사용
- 데이터 검증·분기 로직은 fetchQuery와 try…catch로 처리, 불필요한 prefetchQuery 제거
- SSR용 QueryClient에 staleTime 명시, resetQueries() 대신 영향 범위가 좁은 캐시 조작 사용
- SSR과 CSR의 queryKey 생성 로직 통일, 불필요한 맵 API는 클라이언트로 이동
