얼마 전 다녀온 면접에서 프로젝트할 때 SSR을 왜 썼는지에 대해 질문을 받았다.
그 질문에 대해 대답을 하면서도 스스로 SSR의 특징과 CSR의 특징을 완벽하게 이해하고 있지 않다는 생각을 했고 지금까지도 그 질문에 제대로 된 대답을 하지 못한 게 아쉽다.
그러다 원티드 프리온보딩 챌린지 사전과제가 CSR과 SSR에 대한 것임을 알게 되었고 나중에 같은 질문을 받았을 때 CSR과 SSR을 헷갈리지 않고 멋지게 대답할 수 있도록 정리하고자 한다.
Server-Side Rendering
SSR은 navigation에 대한 응답으로 페이지의 전체 HTML을 생성한다.
이 과정은 브라우저가 응답을 받기 전에 처리되기 때문에 클라이언트에서 템플릿이나 데이터를 가져오기 위한 추가적인 왕복 과정을 줄여준다.
SSR은 빠른 FP(First Paint)와 FCP(First Contentful Paint)를 제공한다.
그러니까, 픽셀이 처음 사용자에게 표시되는 것도 빠르고 요청한 콘텐츠가 표시되는 시간도 빠르다는 것이다.
여기서 잠깐 헷갈릴 수 있는데 SSR이 서버를 이용해 페이지를 구성하기 때문에 CSR보다 페이지를 구성하는 속도가 늦어지는 것은 맞다.
하지만 전체적으로 사용자에게 보여주는 콘텐츠 구성이 완료되는 시점은 CSR보다 빠르다.
초기 렌더링이 빠른 이유는 서버에서 페이지를 만들면 많은 양의 자바스크립트를 클라이언트로 보내는 것을 방지할 수 있기 때문이다.
또한 SSR은 CSR과 달리 HTML 파일에 모든 내용이 담겨져 있는 상태이기 때문에 SEO(Search Engine Optimization)를 쉽게 구성할 수 있다.
다만 SSR은 페이지를 요청할 때마다 새로 만들기 때문에 서버에서 페이지를 만드는 데 시간이 걸리고 이로 인해 TTFB(Time to First Byte)가 느려질 수 있다.
또한 서버에 부하가 생길 수 있다.
Static Rendering
정적 렌더링은 build-time에 페이지를 생성한다.
클라이언트 측의 JS 양이 제한되어 있다고 가정할 때 빠른 FP와 FCP, TTI(Time To Interactive)를 제공한다.
즉, 초기 렌더링도 빠르고 페이지가 대화형이 되는 시간도 빠르다는 것이다.
또한 SSR처럼 요청할 때마다 페이지를 생성하지 않기 때문에 일관적으로 빠른 TTFB를 제공한다.
일반적으로 정적 렌더링은 미리 각 URL에 대해 별도의 HTML 파일을 생성하는 것을 말한다.
이렇게 미리 생성해두면 CDN에 캐싱하여 사용할 수 있다.
하지만 페이지의 URL이 무엇인지 예측할 수 없을 경우 정적 렌더링이 어렵다는 단점이 있다.
Client-Side Rendering
CSR은 브라우저에서 자바스크립트를 사용하여 직접 페이지를 렌더링하는 것을 말한다.
CSR은 브라우저가 서버에 HTML과 JS 파일을 요청한 후 로드되면 사용자의 상호작용에 따라 자바스크립트를 사용해 동적으로 렌더링한다.
서버에서 페이지를 만드는데 필요한 파일을 로드받기 때문에 초기 렌더링이 느리지만 그 이후부터는 동적으로 빠르게 렌더링할 수 있다.
또한 페이지를 만든 이후에는 페이지를 만들기 위해 서버에 요청할 필요가 없으므로 서버의 부담을 줄여준다.
하지만 응용프로그램이 커질 수록 필요한 파일의 양이 많아지며 이 파일들이 로드되어야 페이지를 만들 수 있기 때문에 초기 렌더링이 느려진다.
또 검색엔진의 검색 봇이 크롤링을 할 때 어려움을 겪을 수 있다. (SEO에 좋지 않다.)
관련 링크
