CSR(클라이언트 사이드 렌더링)과 SSR(서버 사이드 렌더링)

CSR(Client Side Rendering)

사용자가 웹사이트에 방문하면 브라우저에서 서버에 콘텐츠를 요청하고, 서버로부터 받은 HTML, CSS, JavaScript 등의 페이지 리소스를 클라이언트 측에서 렌더링하는 방식

• 서버는 단지 빈 HTML과 JavaScript 링크를 보내주는 역할
• 클라이언트에서 JavaScript 코드를 통해 동적으로 DOM을 생성하여 화면을 그리는 역할

1. 사용자가 웹 사이트를 방문하면 브라우저는 프론트엔드 서버에 페이지 요청
2. 프론트엔드 서버는 뼈대만 있는 HTML 파일과 JS, CSS파일 클라이언트에 전달
3. HTML 파일을 파싱하면서 <script> 태그에 도달하면 연결된 JS 파일을 다운로드, 이때 사용자는 빈 화면만 볼 수 있음
4. JS파일이 다운로드되면 브라우저에서 JS가 실행되면서 DOM을 생성하고 페이지를 렌더링
5. 필요에 따라 API 서버와 통신하여 추가적인 데이터를 받아옴
6. 새로고침 하거나 이동할 경우 변경되는 부분만 렌더링

CSR의 장점

1. 부드러운 사용자 경험

• 필요한 데이터만 요청하고 변경하여 화면 전환이 빠르고 화면 깜빡임이 없어 부드러운 사용자 경험을 제공
• TTV와 TTI 사이 간극이 매우 짧거나 동일 = 화면이 보인 직후 사용자가 페이지의 모든 기능을 사용할 수 있음
  • TTV(Time To view) : 사용자가 콘텐츠를 볼 수 있는 시점
  • TTI(Time To Interactive) : 하이드레이션을 마친 후 사용자가 웹페이지와 상호작용이 가능해진 시점
    • Hydration : JS 코드가 실행되면서 정적인 웹페이지가 상태 관리, 이벤트 처리 등 동적인 작업을 수행할 수 있게 되는 과정

2. 서버 부하 감소

• 모든 렌더링 과정을 클라이언트 측에서 직접 수행, 서버는 필요한 데이터만 응답

CSR의 단점

1. SEO(Search Engine Optimization)에 취약

• SEO(Search Engine Optimization, 검색엔진 최적화) 는 서비스 노출을 높여 사용자를 효과적으로 유입, 서비스 운영 비용 절감을 위한 중요한 수단
• 브라우저의 웹 크롤러는 서버에 등록된 웹 페이지들의 HTML을 읽어 검색가능한 색인(index)을 생성, 그러나 CSR에서의 HTML은 뼈대만 있어 크롤링 시 아무것도 읽을 수 없음
  • 크롤링(Crawling) : 웹 상을 돌아다니며 웹페이지를 가져와 원하는 데이터를 추출하는 것
  • 웹 크롤러(Web Crawler) : 웹에서 조직적, 자동화된 방식으로 크롤링 결과물을 읽고 색인을 생성하는 프로그램. 검색엔진 봇, 또는 스파이더라고도 부름 Ex) 구글의 구글봇, 네이버의 yeti
• SEO 개선을 위해 사이트 맵 문서 작성, URL 구조 최적화, 외부 백링크 구축 등의 추가 작업으로 동적라우팅을 보완하고 있음

2. 느린 초기 로딩 속도

• JavaScript 코드를 통해 동적으로 DOM을 생성하는 과정을 거치기 떄문에 렌더링까지의 시간이 많이 소요됨

3.보안 이슈

• 사용자 정보가 클라이언트 기반 쿠키와 로컬 스토리지에 저장되어 XSS 공격 가능성이 있음
  • XSS(Cross-Site Scripting) : 악의적인 스크립트를 웹 페이지에 삽입하여 해당 페이지를 방문하는 사용자들의 브라우저를 감염시키는 공격
• 비즈니스 로직이 노출될 가능성이 있음

---

SSR(Server Side Rendering)

서버측에서 HTML, CSS, JavaScript 등의 페이지 리소스를 렌더링 하고 이를 브라우저에 전달하여 바로 사용자 화면에 보여주는 방식

• 서버는 페이지에 필요한 데이터를 모두 수집하고 이를 삽입한 후 CSS까지 적용된 렌더링 준비를 마친 HTML 파일(정적 페이지)과 JS 파일을 클라이언트에 전달
• 자주 사용되는 HTML, CSS, JS 등의 페이지 리소스를 HTTP 캐시에 캐싱하여 성능 향상
• 클라이언트는 JS파일을 다운로드하고 HTML과 연결(상태와 이벤트 처리 추가)해 동적페이지로 하이드레이션

1. 사용자가 웹 사이트를 방문하면 브라우저는 프론트엔드 서버에 페이지 요청
2. 프론트엔드 서버는 필요한 데이터를 모아 즉시 렌더링 가능한 HTML파일을 클라이언트에 전달
3. 클라이언트에 전달된 HTML 파일은 브라우저에 즉시 렌더링, 아직 사용자와 상호작용은 할 수 없음
4. 클라이언트는 JS파일을 다운로드하고 HTML과 연결하여 상호작용을 가능하게 함
5. 새로고침 하거나 이동할 경우 위 동작 반복

SSR의 장점

1. SEO(Search Engine Optimization)

• 검색엔진이 크롤링할 때 쉽게 읽고 인덱싱 할 수 있음

  2. 빠른 페이지 렌더링

• 서버로부터 HTML파일을 전달받은 즉시 페이지를 렌더링하여 초기 페이지 로드 시간이 빠름
• 서버 측에서 이미지나 스타일시트 등을 미리 로드하기 때문에 사용자는 시각적으로 완성된 페이지를 더 빨리 볼 수 있음
• 사용자와 상호작용이 별로 없거나 콘텐츠 도달 시간이 중요한 애플리케이션에서 유리
• 클라이언트 측의 하드웨어나 소프트웨어 성능에 의존하지 않음

SSR의 단점

1. 사용자 경험 저하

• 화면 깜빡임(Blinking Issue) 발생
• 사용자가 콘텐츠를 시각적으로 볼 수 있은 시점은 빠르지만 JS 파일을 다운로드하고 실행하는 시간이 추가로 필요하기 때문에 상호작용이 가능한 시점과 차이가 있음

2. 서버 부담 증가

• 페이지 변경 사항이 있을 때마다 매번 서버에 요청을 보내고 서버는 다시 페이지 생성 과정을 거쳐야 함
• 트래픽이 늘어날수록 서버의 자원을 더 많이 사용하여 과부하될 수 있음

---

CSR과 SSR 비교

	CSR	SSR
초기 로딩 속도	느림	빠름
조작 가능 시점	사용자가 완성된 페이지를 보는 시점과 동일	사용자가 완성된 페이지를 먼저 마주하고, 자바스크립트가 연결되는 과정을 거친 후
SEO	취약	유리
서버 자원 사용	서버의 부담 적음	서버 부하가 큼

CSR과 SSS는 각각의 장단점을 가지고 있다. 사용자에게 전달해야 하는 데이터의 양이 많거나, 사용자와 상호작용이 많은 경우 CSR을 선택하는 것이 적합하다. 반면 모든 사용자엑 동일한 내용을 보여주는 경우 페이지 로딩 속도가 빠른 SSR을 선택하는 것이 유리하다. 결국 렌더링의 방식은 주된 타깃 사용자와 서비스 특성에 맞게 선택해야 한다.
그러나 꼭 하나의 방식을 선택해야만 하는 것은 아니다. 서비스의 특성과 방향에 따라 부분적으로 다른 렌더링 방식을 사용하거나 두 방식을 조합할 수도 있다.

---

참고
1 프론트엔드 개발자가 알아야 할 브라우저 렌더링의 모든 것: CSR과 SSR의 이해와 기술 및 최적화 전략 - weniv
2 요즘IT SSR 시작하기 전 알아야 할 것들(feat. CSR)-zwoo