SSR 도입을 통한 게시판 최적화 사례
1. 도입 배경
기존에는 CSR(Client-Side Rendering) 방식으로 게시판을 구현했다. 이 방식은 클라이언트에서 모든 데이터를 가져와 렌더링하는 구조로, 초기 로딩 속도가 느리다는 단점이 있다. 하지만 데모 서비스의 특성상 많은 데이터를 경험하기에는 역부족이었다. 5000개의 데이터 기준으로는 초기 렌더링 속도에 큰 문제를 경험하기 힘들었다.
2. 목적
사이트의 최적화를 위해 @next/bundle-analyzer를 적용하여 번들 사이즈를 분석해본 결과, 게시판 관련 페이지가 유독 다른 페이지에 비해 번들 사이즈가 크다는 사실을 인지하게 되었다. 따라서 해당 부분의 번들 사이즈를 최소화하기 위해 SSR(Server-Side Rendering)과 코드 스플릿(Code Splitting)을 적용해보았다.
3. SSR 적용
게시판 페이지의 경우, 데이터가 없는 상태에서 렌더링하는 것이 큰 의미가 없다고 판단되었다. 데이터가 없는 상태에서는 볼 수 있는 화면이 없기 때문이다. 또한 게시판의 데이터 관리 핵심은 최대한 빠르게 최신의 데이터를 보장해야 한다는 점에서 SSR 도입은 필수적이라고 생각되었다.
4. 가설
현재 React Query를 사용하고 있으므로, 캐싱 부분을 활용하는 것이 핵심이었다. 원래라면 React Query의 호출 작업은 클라이언트 사이드에서 발생하지만, 서버사이드에서 미리 호출하고 클라이언트 사이드에서는 캐싱된 데이터를 사용한다면 비교적 빠른 속도로 신선한 데이터를 접근할 수 있을 것이라고 생각했다. 또한 서버사이드에서 컴포넌트의 렌더링 준비를 마치고 화면에 렌더링하는 것보다는, 데이터가 캐싱된 상태에서 유저의 화면에 빠르게 렌더링하는 것이 더 효율적이라고 판단되어 Dynamic 로딩을 적용하고 ssr: false로 하여 클라이언트 사이드에서 필요 시점에 렌더링하는 형태를 취해주었다.
5. 결론
초기 렌더링 속도의 경우는 큰 차이는 없었지만, 번들 도구 기준으로 6KB가 줄어들었다. 코드 스플릿을 적용한 덕분에 5KB의 번들 사이즈가 1KB로 줄어드는 결과를 얻었다.
발생한 이슈
서버사이드에서 쿠키 접근 문제
적용하는 과정에서 게시판의 경우는 API요청시 토큰이 필요하지 않아 큰 문제 없이 동작하였다. 하지만 게시판 상세보기에서는 API요청시 토큰이 필요한데, 헤더에 토큰을 담아주는 로직이 동작하지 않는 듯하여 authorization 오류가 발생하였다.
해당 문제를 파악한 결과, 쿠키를 접근하는 방식은 클라이언트 사이드에서 이루어지기 때문에 서버에서는 클라이언트 내의 저장된 쿠키에 접근할 수 없었던 것이다. 서버사이드에서 쿠키에 접근하려면 쿠키를 파싱하여 접근해야 하는데,
이 과정이 복잡하다. 다행히도 cookie라는 라이브러리에서 쿠키를 파싱하는 기능을 지원하여 간편하게 getServerCookie라는 유틸 함수를 만들어 context와 접근 쿠키 키 값을 인자로 넘기면 원하는 쿠키 값을 반환해주는 형태로 해결하였다.
