CSR vs SSR 정확히 집고 넘어가자

CSR(Client-Side Rendering) vs SSR(Server-Side Rendering)

사람들은 최근 웹 개발에서 "CSR과 SSR의 차이"는 꼭 알고 넘어가야 할 핵심 주제라고 말합니다.

Web 2차 세미나에서 팟장님이 설명해주신 CSR, SSR에 대해 개인적으로 조금 더 정리하고 확장해서 설명해보고자 합니다.

 

CSR ?

CSR ( Client-Side Rendering ) : 브라우저에서 html을 실시간으로 만드는 방식입니다.

즉, HTML, CSS, JavaScript 파일을 받아온 후 브라우저에서 자바스크립트가 동작하면서 화면을 그리는 방식입니다.

말 그대로 "클라이언트(브라우저)가 렌더링을 담당" 하는 구조입니다.

 

장점

- 부드러운 화면 전환 ( 페이지를 새로고침 없이 자연스럽게 이동 가능합니다. ) -> SPA 구조 ( 싱글 페이지 어플리케이션)

- UX에서 뛰어남 ( 사용자와의 상호작용이 많고 동적인 앱에 적합 ) -> React, Vue 기반 앱

 

하지만.

 

단점

- 초기 로딩이 느립니다. JS 파일을 모두 불러온 후에야 페이지가 그려지므로 첫 화면이 늦게 뜰 수 있습니다.

- SEO에 불리합니다. 검색 엔진이 JS 실행 전의 빈 HTML만 읽게 될 수 있어서 검색 노출이 어렵습니다.

 

결국,, 초기 투자 대비 실질적인 유입(수입) 지표가 낮을 수 있습니다.

 

그래서??!

 

 

SSR?

SSR ( Server-Side Rendering ) : 서버에서 이미 완성된 HTML을 만들어서 브라우저로 보내주는 방식입니다.

즉, 사용자가 브라우저로 접속했을 떄 HTML이 서버에서 미리 준비되어 오기 때문에 빠르게 내용을 볼 수 있습니다.

 

장점

- 빠른 첫 로딩 : 사용자 입장에서는 내용이 바로 보이므로 체감 속도가 훨씬 빠릅니다.

- SEO 친화적 : 검색 엔진이 바로 HTML을 읽을 수 있으므로 검색 결과에 잘 노출됩니다.

 

단점

- 서버 부담 증가 : 매 요청마다 HTML을 만들어야 하므로 서버 리스소가 많이 듭니다.

- 화면 전환시 새로고침 필요 : CSR에 비해 사용자 경험이 다소 뒤처질 수 있습니다.

 

한때 웹 개발 트렌드는 CSR이었습니다.

React, Vue 등 SPA의 등장으로 빠르고 부드러운 화면 전환을 구현하는게 혁신처럼 여겨졌었습니다.

하지만 시간이 지나면서 CSR의 단점도 명확해져서 최근에는 SSR 또는 하이브리드 렌더링 ( SSR + ISR ) 방식이 다시 부각되고 있다고 합니다.

 

그래서!

페이지 단위로 설정이 가능한 Next.js 프레임워크를 통해 SSR과 CSR을 자유롭게 섞어가며 쓰면 딱이겠네요!