SSR(Server Side Rendering)이란?
SSR(Server Side Rendering)과 CSR(Client Side Rendering)에 대하여
Next.js를 비롯한 다양한 프레임워크에서 SSR을 쉽게 구축 할 수 있도록 도와주고 있다. 과연 SSR은 무엇이고 이 아키텍처를 사용하여 기대할 수 있는 효과는 무엇이 있는지 알아보자.
SSR(Server Side Rendering)이란?
SSR이란 Server Side Rendering의 약자로 기존의 CSR(Client Side Rendering) 방식의 문제점을 보완하기 위해 나온 아키텍쳐이다.
직역하면 화면의 렌더링이 서버에서 이루어지는 아키텍처를 의미하는데 일반적으로 현대의 SSR은 “첫 HTML 렌더링을 서버에서 처리하고, 이후의 렌더링 사이클은 클라이언트에서 처리”하는 하이브리드 형태의 SSR을 말한다.
SSR의 구동 방식
SSR은 “첫 HTML 렌더링을 서버에서 처리”하기 때문에, 사용자의 화면에 컨텐츠가 로드되는데 걸리는 시간(FCP, First Contentful Paint)가 더 짧다.
이전에 자주쓰던 방식인 CSR(Client Side Rendering) 아키텍처는 사용자의 화면에 JavaScript 번들이 모두 다운로드된 다음 첫 렌더링을 실행하면서 인증, 데이터 요청 등의 과정을 거치다보니 화면이 렌더링되는 시간이 상대적으로 긴 경우가 많다.
토스(toss)에서 작성한 아래 사진을 보고 SSR 방식을 도입 후 차이를 알아보자
토스의 SSR 아키텍처 도입 전1
토스의 SSR 아키텍처 도입 후1
위 사진과 같이 인증과 데이터 처리의 첫 과정이 서버에서 먼저 모두 이루어진 다음 사용자는 완성된 HTML을 받아보면 로딩 속도를 상당히 감축한 것을 볼 수 있다.
SSR의 장점
1. 빠른 초기 로딩 속도
- 서버 측에서 이미 렌더링된
HTML을 보내기 때문에 사용자는 브라우저에서JavaScript가 실행되기 전에도 즉시 콘텐츠를 볼 수 있다. 특히 네트워크 속도가 느리거나 저성능 기기에서도 체감 속도가 빠른 장점이 있다.
2. SEO(검색 엔진 최적화)에 유리
- 사용자가 웹 사이트에 방문하는 순간 서버는
HTML,CSS,JavaScript리소스를 브라우저에 전달하는데 CSR의 경우에는 빈HTML화면만 표시되어 검색 엔진 크롤러가 인식하지 못하게 된다. 하지만 SSR은 서버에서 완성된 HTML을 반환하므로, 검색 엔진 크롤러가 콘텐츠를 바로 읽을 수 있다.
3. 보안 측면에서 유리
- 데이터 렌더링을 서버에서 처리하기 때문에, 클라이언트로 민감한 로직이나 데이터가 그대로 노출될 위험이 줄어든다.
SSR의 단점
1. 서버 부하 증가
모든 요청마다 서버가 렌더링을 수행해야 하므로 서버에 굉장한 부하가 된다. 트래픽이 많을수록 서버 자원 사용량이 커지고 응답 속도가 느려지는 등의 위험이 있다.
서비스의 규모가 클수록 서버의 개수를 늘리거나 최적화를 하는 등 유연한 대처가 필요하다. 캐싱, CDN, 정적 페이지 미리 렌더링(SSG) 등을 함께 사용하는 하이브리드 전략을 사용하기도 한다.
2. 개발 복잡도 증가
- 서버와 클라이언트 양쪽에서 코드를 실행해야 하므로 코드 구조가 복잡해진다. 또한 상태 관리, API 호출 타이밍, hydration(서버 렌더링 후 클라이언트에서 재활성화) 등의 이슈도 발생한다.
3. 서버 렌더링 시간 지연
- 사용자가 페이지를 요청할 때마다
HTML을 생성해야 하므로, 초기 응답까지 시간이 더 걸릴 수 있다. 특히 데이터 fetching 과정이 길면 TTFB(Time To First Byte)가 느려진다.
SSR과 CSR의 차이
| 구분 | SSR | CSR |
|---|---|---|
| 렌더링 위치 | 서버 | 클라이언트(브라우저) |
| 초기 로딩 속도 | 빠름 | 느림 |
| SEO | 유리 | 불리 |
| 서버 부하 / 비용 | 큼 | 적음 |
| 개발 난이도 | 복잡 | 단순 |
| 데이터 최신화 | 요청 시마다 갱신 | 클라이언트에서 관리 |
SSR 로직2
CSR 로직2