![[그림 4-1] CSR과 SSR의 렌더링 과정 비교](https://s3-us-west-2.amazonaws.com/secure.notion-static.com/ba8dc4c7-e3fa-4e89-bd45-a6e0186ca4ef/%EB%B9%84%EA%B5%90.png)
서버로부터 페이지 리소스를 받아 클라이언트 측에서 렌더링하는 CSR과 서버 측에서 페이지 리소스를 렌더링하여 전달하는 SSR은 서로 반대되는 개념으로 두 개념이 갖는 특징 또한 엇갈립니다. 렌더링 속도와 SEO 두 방식에서 가장 대비되는 특징으로 설명할 수 있으며, 그 외에 서버 자원 사용과 보안 영역에서도 차이를 보입니다.
다음 표는 CSR과 SSR의 차이를 간략하게 정리한 내용입니다.
| CSR | SSR | |
|---|---|---|
| 초기 로딩 속도 | 자바스크립트 파일까지 모두 다운로드 받은 후에 화면이 띄워지기 때문에 초기 로딩 속도가 느리다. | 브라우저는 서버로부터 받은 렌더링 준비가 완료된 HTML 파일을 화면에 바로 띄우기 때문에 초기 로딩 속도가 빠르다. |
| 이후 구동 속도 | 초기 로딩 시 필요한 모든 파일이 연결되어 있기므로 구동 속도가 빠르다. | 화면을 띄운 후 자바스크립트 로직을 연결하기 때문에 사용 가능한 시점이 뒤늦다. |
| 조작 가능 시점 | 사용자가 페이지를 볼 수 있음과 동시에 입력 및 조작이 가능하다. | 사용자가 페이지를 볼 수는 있지만 조작은 불가능한 로딩 시간이 존재한다. |
| SEO | 빈 HTML 파일이 전달되어 SEO에 취약하다. | 데이터가 포함된 렌더링 준비된 HTML 파일이 전달되어 SEO에 유리하다. |
| 서버 자원 사용 | 클라이언트가 연산, 라우팅 등을 직접 처리하여 서버의 부담이 적다. | 매번 서버에 로딩을 요청해야 하기 때문에 서버 부하가 크다. |
| 보안 | 쿠키 외에 사용자 정보를 저장할 공간이 마땅치 않아 보안에 취약할 수 있다. | 렌더링 시, 서버에서의 필터링이나 이스케이핑 등 선조치를 통해 보안 공격에 대응할 수 있다. |
[표 4-1] CSR과 SSR의 특징 비교
[그림 4-1] CSR과 SSR의 렌더링 과정 비교
사용자가 웹 사이트에 방문하면 브라우저는 서버에 콘텐츠를 요청합니다. CSR 방식에서 서버는 빈 HTML 파일과 자바스크립트 링크를 브라우저에 전달합니다. 이때 브라우저가 전달받은 HTML 파일에는 내용이 들어 있지 않기 때문에 사용자는 페이지를 볼 수 없습니다. 이후 받은 링크를 통해 서버로부터 자바스크립트 파일을 다운로드 받고 동적으로 페이지를 만들어 브라우저에 띄우면 그제야 사용자는 조작 가능한 웹 페이지를 마주하게 됩니다. 따라서 CSR은 사용자가 페이지를 볼 수 있는 시점이 버튼을 클릭하거나 이동하여 조작할 수 있는 시점과 동일합니다. 다만, 브라우저가 자바스크립트 파일을 다운로드 받고 동적으로 DOM을 생성하는 시간을 기다려야 하기 때문에 초기 로딩 속도가 느리다는 단점이 있습니다. 초기 로딩 시에 화면의 콘텐츠들을 불러오고 나면 페이지의 일부를 변경할 때는 이미 자바스크립트 파일을 모두 다운로드 받은 상태이므로 서버에 해당 데이터만 요청하면 되기 때문에 이후 구동 속도가 빠른 편입니다.
반면 SSR 방식에서는, 서버가 페이지에 필요한 데이터를 모두 가져와 삽입하고 CSS까지 적용하여 렌더링 준비가 완료된 HTML 파일과 자바스크립트 코드를 브라우저에 전달합니다. 브라우저는 먼저 전달받은 HTML을 화면에 띄우고 자바스크립트 코드를 다운로드합니다. 이후에 HTML에 자바스크립트 로직을 연결합니다. 이때 서버가 전달한 HTML 파일에는 이미 페이지에 필요한 모든 데이터가 담겨있으므로, 사용자는 자바스크립트 코드가 전부 다운로드 되기 전에도 화면을 볼 수 있습니다. CSR보다 초기 구동 속도가 빠른 것입니다. 하지만 이것이 사용자가 즉시 사용할 수 있다는 의미는 아닙니다. 사용할 수 있는 페이지처럼 보이지만, 이 시점에는 사용자가 버튼을 클릭하고 이동하는 것이 불가능할 수 있습니다. 내용과 스타일만 입혀진 그림에 불과하기 때문에 실제로 자바스크립트 로직과 이벤트 핸들러가 모두 연결될 때까지 사용자의 입력에 응답할 수 없습니다.
위와 같은 특징들은 사용자 경험에도 영향을 미칩니다. SSR은 페이지를 요청할 때마다 매번 서버에 로딩을 요청해야 하기 때문에 서버 부하가 크고, 화면이 사용자에게 보이는 시점에서 사용자의 입력에 응답할 수 있는 상태, 즉 TTI(Time To Interactive)까지의 간격이 다소 길어 안 좋은 사용자 경험을 일으킵니다. CSR은 초기 로딩 시간이 필요하지만, 사용자가 화면을 볼 수 있음과 동시에 화면을 조작할 수 있고 화면 깜빡임이 없어 우수한 사용자 경험을 줄 수 있습니다.
SEO 또한 렌더링 방식 선택에 있어서 고려해야 할 사항입니다. 렌더링 방식이 SEO에 영향을 미치기 때문입니다. 앞서 살펴보았듯이 CSR은 SEO에 취약한 데 비해 SSR은 SEO에 친화적입니다. 이 차이는 서버로부터 받는 HTML이 어느 정도의 정보를 담고 있는지에 기인합니다. 검색 엔진이 크롤링하며 인덱싱할 수 있는 내용이 있어야 SEO를 고려할 수 있습니다.
구글 크롤러 봇이 JavaScript 파일을 해석할 수 있게 되면서 CSR 방식의 웹 페이지 또한 크롤링할 수 있게 되었습니다. 그렇지만 구글 크롤러 봇이 JavaScript 파일을 읽어나가는 것이 아직 완벽한 단계가 아닐뿐더러 다른 브라우저의 크롤러 봇은 JavaScript 파일을 실행할 수 없다는 한계가 있습니다. 여전히 SSR 방식의 웹 페이지에 대한 크롤링 속도가 더 빠르기 때문에 구글에서는 SEO를 위해 SSR 방식을 사용할 것을 권장하고 있습니다.[1]
이처럼 SEO 측면에서 렌더링 방식을 선택하는 것에는 명확한 답이 존재한다고 볼 수 있습니다. 그러나 먼저 SEO가 서비스에 꼭 필요한지 생각해 보아야 합니다. SEO는 서비스 유입에 효과적이며 서비스 노출을 높여 서비스 운영에 대한 리소스를 절감시키는 중요한 수단입니다. 이 때문에 많은 서비스에서 SEO를 중요하게 생각하고 이를 고려한 작업을 진행합니다. 그러나 모든 서비스가 SEO를 필요로 하는 것은 아닙니다.
SEO 효과는 단기간에 나타나지 않습니다. 구글의 설명에 따르면 SEO 효과가 나타나기까지는 보통 4개월에서 1년 정도가 소요됩니다.[2] 단기간만 운영하는 마케팅 페이지 같은 경우에는 렌더링 방식 선택에 있어 SEO를 고려할 필요가 없을 것입니다.