SSR (Server Side Rendering)
웹 페이지를 브라우저에서 렌더링하는 대신, 서버에서 렌더링합니다. 브라우저가 서버의 URI로 GET 요청을 보내면, 서버는 정해진 웹 페이지 파일을 브라우저로 전송합니다. (웹 페이지가 브라우저에 도착하면 완전 렌더링 됩니다. 서버에서 완전 렌더링했기 때문에 SRR이라고 합니다.)
- 사용자가 다른 경로로 이동할 때 마다 서버는 작업을 다시 수행합니다.
CSR (Client Side Rendering)
클라이언트에서 페이지를 렌더링합니다. 브라우저의 요청을 서버로 보내면 서버는 웹 페이지를 렌더링하는 대신, 웹 페이지의 골격이 될 단일 페이지를 클라이언트에 보냅니다. JS 파일을 보내고, 클라이언트가 웹 페이지를 받고 렌더링하기 시작합니다.
차이점
렌더링되는 위치의 차이입니다. SSR은 서버에서 페이지를 렌더링하고, CSR은 브라우저에서 페이지를 렌더링합니다.
SSR 사용해야 하는 경우
- SEO가 우선순위인 경우, 일반적으로 SSR을 사용합니다.
- 웹 페이지 첫 화면 렌더링이 빠르게 필요한 경우 적절합니다.
- 웹 페이지가 사용자와 상호작용이 적은 경우, SSR 활용할 수 있습니다.
CSR 사용해야 하는 경우
- SEO가 우선순위기 아닌 경우, CSR을 사용합니다.
- 사이트에 풍부한 상호 작용이 있는 경우, CSR은 빠른 라우팅으로 강력한 사용자 경험을 제공합니다.
- CSR은 더 나은 사용자 경험을 제공할 수 있습니다.
정적 웹사이트
- HTML 파일(코드) 자체로 배포되는 사이트 (CSR)
동적 웹사이트
- 서버에 의해 HTML 파일이 동적으로 생성되는 사이트 (SSR)
렌더링 방식의 변천
기술의 발전으로 서버 부하가 줄어들게 됐습니다. 따라 서버는 JSON과 같은 순수한 데이터 포맷만 제공해주는 형태로 흐름이 바뀌기 시작했으며, CSR, JS, AJAX 기술을 이용한 보다 고도화된 웹 앱, Single Page Application으로 변모하기 시작합니다.
성능 향상을 극대화하기 위해 SSR, CSR 하이브리드 형태로 구성하는 경우도 있습니다.
정적 웹사이트 빌드
고도화된 클라이언트 웹 앱은 수 많은 모듈로 이뤄져 있습니다. 수 많은 모듈을 하나로 묶어주는 작업을 번들링(bundling)이라고 합니다.
이런 과정을 "소프트웨어 빌드"라고 부르며, 소스코드를 실행 가능한 결과물로 변환하는 작업을 의미합니다.
다양한 모듈은 결과물로 만들어져야만 하며, 이런 빌드 과정은 배포에 필수적입니다. 정적 파일을 호스팅하는 서비스에 결과물만 업로드하면 됩니다.
