🧭 배경: 최적화 시도해보기
기존 CSR로 구성된 프로젝트에서 SSR + prefetch를 적용하며 성능 개선을 시도했습니다.
이 과정에서 sessionStorage를 기반으로 동작하던 클라이언트 측 리다이렉트 방식에서 서버 측에서 쿠키를 활용한 middleware 리아티렉트 방식으로 전환하게 되었습니다.
이 글에서는 그 구조 변경의 흐름과 성능 비교 결과를 공유하고자 내용을 정리해보았습니다.
🔄 SSR 적용을 위한 리다이렉션 방식 변경
기존 방식: CSR + sessionStorage
기존에는 사용자가 메인 페이지에 최초 진입했을 때 sessionStorage 값을 확인하여 랜딩 페이지로 리다이렉트하는 방식이었습니다.
하지만 이 방식에는 다음과 같은 문제들이 있었습니다.
- 메인 페이지가 잠깐 보였다가 랜딩 페이지로 전환
: useEffect 내부에서 sessionStorage를 확인하다 보니 리다이렉트 지연됨 - 이를 해결하기 위해 return 문에 조건문 사용
- 랜딩 -> 메인 페이지 재진입 시 hydration error 발생
: 클라이언트 조건문으로 인해 서버와 클라이언트 렌더링 결과가 불일치 - Next.js 공식 가이드에 따라 해당 문제를 CSR 방식으로 처리
결과적으로, 모든 페이지가 CSR 방식으로 처리되는 구조가 되었습니다.
변경 방식: SSR + Cookie
SSR을 적용하기 위해 아래와 같은 구조로 리다이렉션 방식을 변경했습니다.
- sessionStorage -> 쿠키 기반 확인 방식으로 변경
- layout.ts 내 리다이렉트 로직 -> middleware로 이동
단, 이 과정에서 사용자가 창을 닫고 재진입했을 때도 랜딩 페이지로 이동하도록 하던 UX는 포기해야했습니다.
-> 대신 쿠키 만료일을 적절히 설정하여 유사한 제어를 시도했습니다.
⚡ 성능 측정
성능 측정 환경
성능 측정은 아래 환경에서 진행되었습니다.
- DevTools -> Performance 탭
- Network 탭 -> Disabled cache 활성화
- Chrome 시크릿 모드
- 측정 기준: 페이지 요청을 시작 시점부터, frames 영역에 첫 UI 이미지가 표시될 때까지의 시간
성능 테스트 결과
Middleware
예상과 달리 첫 요청(Cold Start)에는 middleware 방식이 CSR보다 느렸습니다.
하지만 그 이후 요청(Warm Start)부터는 CSR보다 조금 빠른 속도를 보여주었습니다.
이는 Vercel 환경에서 발생하는 Cold Start 현상 때문이었습니다.
-
Cold Start 시 응답
-
Warm Start 시 응답
CSR
CSR 환경 테스트는 Vercel 무료 플랜의 preview 배포 환경에서 진행했습니다.
첫 요청에는 인증 절차가 포함되어 있어 시간 측정이 다소 왜곡되었지만, 인증 시간을 제외하고 middleware와 동일한 기준으로 측정했습니다.
- CSR 응답
평균 측정 결과
warm start 기준으로 middleware 방식이 CSR보다 약 15ms 빠르게 동작함을 확인할 수 있었습니다.
| Redirect 방식 | 평균 응답 시간 |
|---|---|
| middleware (Cold Start) | 1.1s |
| middleware (Warm Start) | 395.16ms |
| CSR | 409.7ms |
마치며
이번 구조 변경을 통해 서버 측에서의 middleware를 통한 redirect 제어할 수 있게 되었습니다. 더불어, SSR 기반 prefetch 전략 적용이 가능해졌습니다.
처음에는 middleware가 무조건 더 빠를 것이라 생각했지만, 실제로 Cold Start 상황에서는 CSR보다 느릴 수 있다는 점을 확인할 수 있었습니다.
이번 경험을 통해 클라이언트 중심 로직을 개선하는 방향에 대해 고민해보는 계기가 되었습니다.
이후에는 SSR + prefetch와 기존 CSR 구조 간의 데이터 로딩 체감 속도를 비교해볼 예정입니다.
