이제는 알아야겠다! CSR과 SSR의 차이점과 장단점 (SPA, MPA, SSG, Universal Rendering 까지)
1. SPA와 MPA의 차이점
SPA
SPA는 Single Page Application의 약자로 하나의 페이지로 구성된 웹 어플리케이션 을 말한다.
헤더, 사이드바와 같은 공통 영역은 유지되면서 필요한 부분만 동적으로 갱신되는 애플리케이션들이다.
MPA
MPA는 Multi Page Application의 약자로, 탭을 이동할 때마다 서버로부터 새로운 HTML을 받아와 페이지 전체를 새로 렌더링하는 전통적인 웹 페이지 구성 방식이다.
MPA는 매번 새로운 HTML을 서버로부터 받아오기 때문에 페이지 전환시마다 화면 깜빡임이 존재한다는 단점이 있다.
따라서 AJAX가 등장한 이후부터 원하는 부분만 클라이언트에서 동적으로 갈아 끼울 수 있어 화면 깜빡임이 없는 SPA 방법을 사용하고 있다.
렌더링 방식의 종류
CSR과 SSR 개념은 어느 쪽에서 렌더링 준비하는지에 따라 나뉘는 개념이다.
일반적으로 SPA에서는 CSR 방식으로 렌더링하고, MPA에서는 SSR 방식으로 렌더링한다.
SPA는 웹 애플리케이션에 필요한 정적 리소스를 초반에 모두 다운로드하고, 이후에 새로운 페이지 요청이 있으면 페이지 갱신에 필요한 데이터만 전달 받아 클라이언트가 페이지를 갱신한다. 따라서 CSR 방식을 채용한다.
반면 MPA는 새로운 요청이 있을 때마다 서버에서 이미 렌더링된 정적 리소스를 받아오기 때문에 SSR 방식을 사용한다.
이러한 특징 때문에 SPA === CSR, MPA === SSR이라고 오해를 할 수 있지만, 두 개는 다른 개념임에 주의하자!
CSR(Client Side Rendering)
CSR은 Client Side Rendering의 약자로 클라이언트 측에서 렌더링하는 방식이다.
동작 과정
- 사용자가 웹사이트에 방문하면 브라우저가 서버에 콘텐츠를 요청한다.
- 서버는 빈 뼈대만 있는 HTML을 연결된 JS 링크에 응답으로 보내준다.
- 브라우저가 연결된 JS 링크를 통해 서버로부터 다시 JS 파일을 다운받는다.
- 브라우저가 JS를 이용해 동적으로 DOM을 생성하고 페이지를 렌더링해 브라우저에 띄워준다.
장단점
CSR 방식은 브라우저가 JS 파일을 다운로드 받고 동적으로 DOM을 생성하는 시간을 기다려야 하기 때문에 초기 로딩 속도가 느리다는 단점이 있다. 하지만 초기 로딩 이후 페이지 일부를 변경할 때에는 서버에 해당 데이터만 요청하므로 이후 구동 속도는 빠르다.
또한 서버는 빈 뼈대만 있는 HTML을 넘겨주는 역할만 수행하므로 서버 측의 부하가 적다. 뿐만 아니라, 클라이언트 측에서 연산과 라우팅을 직접 처리 하기 때문에 반응 속도가 빠르고 UX가 우수하다는 장점을 갖는다. 서버의 부하가 클라이언트로 분산된다고 생각하면 된다!
한편, 검색 엔진의 웹 크롤러는 HTML을 읽어서 검색 가능한 색인을 생성한다. 하지만 CSR은 초기 HTML이 거의 비어 있고, JavaScript 실행 후에야 콘텐츠가 렌더링되기 때문에 웹 크롤러 봇이 페이지 내용을 수집할 때에는 검색 엔진이 색인을 할 만한 콘텐츠가 존재하지 않는다. 이는 검색 엔진 최적화(SEO)에 치명적인 단점으로 작용한다.
단점 보완 방법
1. 초기 로딩 속도 개선하기
Code Splitting (코드 분할)
- 애플리케이션의 번들을 여러 개의 작은 청크로 분할하여 필요한 코드만 먼저 로드하는 방식이다.
- 번들의 크기를 줄임으로써 초기 DOM 생성 속도를 높일 수 있고, 초기 로딩 속도도 개선할 수 있다.
Tree Shaking
- 사용하지 않는 코드를 번들에서 제거하여 최종 파일 크기를 최적화하는 기법이다.
- Webpack, Rollup 등의 모듈 번들러가 ES6 모듈 시스템을 기반으로 자동으로 수행한다.
2. SEO 개선하기
pre-rendering
- 빌드 타임에 각 경로에 대한 HTML을 미리 생성해두는 방식이다.
- react-snap, prerender-spa-plugin 같은 라이브러리를 사용하면 크롤러가 방문했을 때 사전 렌더링된 HTML을 제공할 수 있다.
Dynamic Rendering
- User-Agent를 감지하여 일반 사용자에게는 CSR을, 크롤러에게는 서버에서 렌더링된 페이지를 제공하는 방식이다.
- Google의 Puppeteer나 Rendertron 같은 도구를 활용할 수 있다.
3. 하이브리드 렌더링 방식 도입하기
근본적인 해결을 위해서는 SSR이나 SSG를 결합한 하이브리드 방식을 사용하면 좋다.
Next.js: 페이지별로 SSR, SSG, CSR을 선택적으로 적용할 수 있는 프레임워크이다.
SSR (Server Side Rendering)
SSR은 Server Side Rendering의 약자로, 서버 측에서 렌더링하는 방식이다.
동작 과정
- 사용자가 웹사이트에 방문하면 브라우저는 서버에 콘텐츠를 요청한다.
- 서버는 페이지에 필요한 데이터를 얻어와 삽입하고 css까지 적용하여 렌더링 준비를 마친 HTML과 JS 코드를 브라우저에 응답으로 전달한다.
- 브라우저는 전달받은 HTML 페이지를 렌더링한다.
- 브라우저가 JS 코드를 다운로드 하고 HTML에 jS로직을 연결한다.
장단점
SSR 방식에서 서버는 브라우저에 렌더링 준비를 마친 HTML을 응답으로 주는데, 이는 모든 정보가 담겨져 있는 HTML을 의미한다. 따라서 JS를 실행할 수 없는 크롤러봇도 HTML을 읽어서 색인을 생성할 수 있기 떄문에 검색엔진 최적화에 유리하다.
뿐만 아니라, 자바스크립트 코드를 다운로드 받고 실행하기 전에, 사용자가 화면을 볼 수 있다는 장점도 있다. JavaScript 다운로드를 기다려야 했던 CSR보다 초기 구동속도가 빠르다.
하지만 JavaScript 코드를 다운받기 전에는 사용자가 버튼을 클릭하거나 이동하려고 할 때 아무 반응이 없을 수 있다. 클라이언트 측 JavaScript가 실행되고 이벤트 핸들러가 첨부되어 JS로직이 모두 연결될 때까지는 사용자가 상호작용 할 수 없다.
이렇듯 SSR에는 TTV(TIme To View)와 TTI(Time To Interact)간의 간 간격이 존재한다. 반면 CSR은 JavaScript가 동적으로 DOM을 생성하기 때문에 HTML은 JavaScript 로직이 모두 완전히 연결된 상태라 사용자가 보는 시점과 이용할 수 있는 시점이 동일하다.
SSG (Static Site Generation)
SSG는 Static Site Generation의 약자로, Static Rendering이라고도 한다. SSG 방식은 웹사이트를 빌드할 때 미리 static한 HTML 파일을 생성해 뒀다가 제공하는 방식이다.
장단점
서버에서 정적인 HTML을 미리 만들어두는 방식으로 배포 속도가 빠르고 서버 부하가 적다는 장점을 갖는다.
하지만, 데이터가 변경될 경우 다시 빌드해야 한다는 단점이 있다.
SSR과의 차이점
SSR과 비슷하지만 SSR은 요청을 보내면 동적으로 HTML을 생성하는 방식이기 때문에 미리 만들어두기 어려운 페이지에 적합한 반면, SSG는 정적인 HTML을 미리 서버에 모두 만들어둔 뒤에 요청 시에 해당 페이지를 응답하는 것이기 때문에 바뀔 일이 거의 없어 캐싱해두면 좋은 페이지에 사용하면 적합하다.
언제 어떤 렌더링 방식을 선택해야 할까?
CSR
- 유저와 상호작용이 많은 경우
- 대부분이 사용자의 개인 정보로 이루어진 페이지들인 경우 (이 경우 굳이 검색엔진에 노출될 필요 없기 때문에 SEO가 중요하지 않음!)
SSR
- 회사 홈페이지여서 SEO가 중요한 경우
- 누구에게나 항상 같은 내용을 보여주는 사이트인 경우
- 업데이트가 빈번해 해당 페이지의 데이터가 자주 비뀌는 경우
SSG
- 회사 홈페이지여서 SEO가 중요한 경우
- 누구에게나 항상 같은 내용을 보여주는 사이트인 경우
- 업데이트를 거의 하지 않는 경우
Universal
- 사용자에 따라서 페이지 내용이 달라지는 경우
- 빠른 인터렉션이 중요하고, 화면 깜빡임이 없어야 하는 경우
- SEO를 포기할 수 없는 사이트인 경우