SSR vs CSR

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

SSR과 CSR은 웹 페이지의 내용을 어디서 그리는지(렌더링하는지)에 대한 두 가지 다른 접근 방식입니다. 각각의 방식은 초기 로딩 속도, 검색 엔진 최적화(SEO), 사용자 경험(UX) 등에서 장단점을 가집니다.

---

🖥️ SSR (서버 사이드 렌더링)

SSR은 서버에서 사용자가 볼 페이지의 HTML을 모두 만들어서 브라우저로 보내는 방식입니다. 브라우저는 전달받은 HTML을 그대로 표시하기만 하면 됩니다.

• 동작 방식 : 브라우저 요청 → 서버가 HTML 전체를 생성하여 응답 → 브라우저가 페이지 표시
• 장점 :

> * 빠른 초기 로딩 속도: 브라우저는 완성된 HTML을 바로 보여줄 수 있어 사용자가 콘텐츠를 빨리 볼 수 있습니다. > * 검색 엔진 최적화(SEO)에 유리: 검색 엔진 봇이 완성된 HTML을 쉽게 분석하고 인덱싱할 수 있습니다.

• 단점 :

> * 느린 페이지 전환: 페이지를 이동할 때마다 서버에 새로운 페이지를 요청하고 다시 받아와야 해서 화면이 깜빡입니다. > * 서버 부하: 모든 렌더링을 서버가 책임져야 하므로 서버의 부담이 큽니다.

---

📱 CSR (클라이언트 사이드 렌더링)

CSR은 클라이언트(브라우저)에서 자바스크립트를 사용하여 페이지를 그리는 방식입니다. 서버는 처음에 텅 빈 HTML과 자바스크립트 파일만 보내주고, 이후 모든 렌더링은 브라우저가 담당합니다.

• 동작 방식 : 브라우저 요청 → 서버가 최소한의 HTML과 JS를 응답 → 브라우저가 JS를 실행하여 API를 호출하고, 받은 데이터로 페이지를 동적으로 그림
• 장점 :

> * 빠른 페이지 전환: 초기 로딩 후에는 필요한 데이터만 서버에 요청하여 페이지를 동적으로 업데이트하므로, 앱처럼 부드러운 사용자 경험을 제공합니다. > * 서버 부하 감소: 렌더링을 클라이언트가 담당하므로 서버는 API 제공에만 집중할 수 있습니다.

• 단점 :

> * 느린 초기 로딩 속도: 모든 자바스크립트 파일을 다운로드하고 실행해야 화면이 보이므로, 첫 페이지 로딩이 느릴 수 있습니다. > * 검색 엔진 최적화(SEO)에 불리: 검색 봇이 비어있는 HTML을 보게 되어 콘텐츠를 제대로 분석하기 어려울 수 있습니다. (최근에는 개선되고 있음)

---

💡 개발자 핵심 Point

• SSR은 블로그, 뉴스 기사, 이커머스 상품 페이지 등 콘텐츠의 첫 로딩 속도와 SEO가 중요한 사이트에 적합합니다.
• CSR은 대시보드, 관리자 페이지 등 사용자와의 상호작용이 많고, 풍부한 사용자 경험이 중요한 SPA(Single Page Application)에 적합합니다.
• 최근에는 두 방식의 장점을 결합한 하이브리드 렌더링 방식도 많이 사용됩니다. Next.js, Nuxt.js와 같은 프레임워크는 페이지별로 SSR과 CSR을 선택하거나, 초기 로딩은 SSR로 하고 이후 동작은 CSR로 하는 등의 유연한 전략을 제공합니다.