이전 포스팅에서 대표적인 렌더링의 종류로 간략하게 CSR과 SSR에 대한 개념을 이야기했다.
그러면 이 녀석들은 언제 어떨 때 써야 하는 걸까?
우선 렌더링에 대해 설명하기 전에 MPA와 SPA에 대해서 알아야 한다.
SPA(Single Page Application)
SPA(싱글 페이지 어플리케이션)이란 싱글 페이지 즉 하나의 페이지로 이루어진 홈페이지이다. 우리가 알고 있는 VUE, ANGULA, REACT 프레임워크로 만든 홈페이지들이 대부분 여기에 속한다.
MPA(Multiple Page Application)
MPA(멀티 페이지 어플리케이션)이란 말 그대로 여러 개의 페이지들로 이루어진 홈페이지이다. PHP나 JAVA가 여기에 속한다.
CSR(Client Side Rendering)
CSR의 구동방식은 초기 로드 시 빈 html과 모든 로직이 담겨 있는 js를 다운로드한다. 그 후 빈 html의 동적으로 js를 사용해 돔으로 그려 내게 됩니다. 때문에 원하는 내용만 업데이트를 할 수 있다. 예를 들어 링크 이동을 클릭했을 때 헤더와 푸터와 같이 중복되는 내용은 고정으로 두고 안에 컨텐츠만 업데이트하여 로드할 수 있어서 SPA에 적합한 환경이다. 하지만 html 파일을 하나만 받아와서 작동하다 보니 각각 페이지에 대한 정보를 담기 힘들어 seo의 취약하다. 또한 첫 로드 시 모든 로직이 담겨있는 js를 다운로드하다 보니 첫 진입 시 로딩 속도가 길다는 단점이 있다.
CSR 동작 방식
일반적으로 아래와 같이 동작한다.
- 사용자가 웹 페이지를 방문하면(request), 브라우저는 최소한의 HTML 파일을 다운로드(response) 한다. 이 HTML 파일은 script, meta, link 등의 태그를 포함하며, 빈 컨텐츠의 index.html 파일이라고 보면 된다.
- 브라우저는 index.html에 있는 자바스크립트 번들 파일을 다운로드한 다음 AJAX를 통해 API 요청을 수행하여 동적 컨텐츠를 가져오고 파싱하여 최종 컨텐츠를 렌더링한다.
- 사용자가 페이지를 이동할 경우, 서버에 추가 HTML파일을 요청하지 않고 이미 받은 자바스크립트를 이용하여 렌더링 한다.
CSR 장점
- 후속 페이지 로드 시간이 더 빠르다. CSR을 위해 이미 모든 지원 스크립트가 사전에 로드되었기 때문에 CSR의 로드 시간이 줄어든다.
- 별도의 API를 호출할 필요가 없는 페이지이거나 지연 로딩 모듈이 필요하지 않다, 이미 스크립트가 캐싱된 경우 인터넷 없이도 해당 CSR 웹 애플리케이션을 실행할 수 있다.
- CSR은 서버를 호출할 때마다 전체 UI를 다시 로드할 필요가 없다.
CSR 단점
- 초기 페이지 로드 시간이 SSR에 비해 느리다. CSR을 사용하면 브라우저는 브라우저에서 사용 가능한 컨텐츠로 HTML을 컴파일하기 전에 기본 HTML, CSS 및 모든 필수 스크립트를 로드하기 때문이다.
- SEO에 친화적이지 않다. 검색 엔진 크롤러가 해당 페이지에 처음 방문했을때는 빈 페이지이기 때문에 이해할 수가 없다. 물론 자바스크립트를 실행시킬 수 있는 구글 크롤러와 같은 검색엔진 크롤러가 등장하고 있긴하지만, 아직 많은 검색 엔진 크롤러들이 지원되지 않는다.
- 또한 페이지 메타데이터의 변경을 위한 추가적인 노력이 필요하다. 한 페이지에서 다른 페이지로 변할 경우 이를 인지 시켜주기 위해 각 페이지에 대한 메타 데이터를 설정하고 클라이언트에서 렌더링하기 위해 추가 노력이 필요하다.
- 브라우저가 페이지를 표시하기 전에 HTML 및 JavaScript 파일을 다운로드하고 프레임 워크를 실행하는 동안 사용자는 빈페이지를 보게 되므로 사용자 경험(UX)가 좋지 않다.
- 클라이언트의 하드웨어 및 소프트웨어에 너무 많이 의존한다. 사용자 기기에 따라, 하위 지원되는 하드웨어 및 소프트웨어 사용자라면, 최적의 시간에 페이지를 렌더링하지 못하게 될 확률이 크다. 페이지의 이탈률은 페이지 로드시간에 정비례한다. 또한 이탈률이 높을수록 검색엔진 순위도 낮아 질 수 있다.
SSR(Server Side Rendering)
SSR은 서버에서 렌더링을 하여 완성된 html 파일을 로드해 준다. 클라이언트에서 요청을 할 때마다 각 상황에 맞는 html 파일을 넘겨주기 때문에 페이지가 여러 개일 수밖에 없어서 MPA 구동방식과 밀접한 관계가 있다.
CSR은 모든 로직이 담겨 있는 js 파일을 다운로드했지만 SSR은 클라이언트에서 요청한 페이지의 html을 다운로드하기 때문에 CSR보다 초기 진입 시 로딩이 빠르다. 서버에서 렌더링 후 각각 페이지를 넘겨받는 것이므로 각각 페이지에 대한 정보를 입력하기 쉬어 SEO에 좋다. 그러나 링크 이동 클릭 시 새로운 html 파일 자체를 서버에서 받아오기 때문에 화면 깜빡임 현상이 있다. 부분 업데이트하는 CSR과는 달리 클릭했을 때마다 헤더나 푸터처럼 중복되는 내용도 다시 렌더링 하여 새로운 html을 받아오기 때문이다. 그래서 초기 진입은 CSR보다 빨라도 페이지 이동은 SSR이 더 느린 편이다. 또한 SSR은 완성된 html을 js 파일 보다 먼저 받아오기 때문에 완성된 html로 화면은 확인되지만 js 다운로드가 늦어 진다면 기능이 먹통인 경우가 있다.
SSR 동작 방식
- 사용자가 웹 페이지를 방문하면(request), 서버는 리소스를 확인하고 페이지 내에 있는 서버측 스크립트를 실행 후 HTML 컨텐츠를 컴파일 및 준비한다.
- 컴파일된 HTML은 추가 렌더링 및 표시를 위해 클라이언트 브라우저로 전송된다(response).
- 브라우저는 HTML을 다운로드하고 최종 사용자가 사이트를 볼 수 있도록 한다.
- 브라우저는 자바스크립트를 다운로드하고 실행하면서 페이지를 대화형(interactive)으로 만든다.
- 사용자가 페이지를 이동할 경우, 위 동작을 반복한다.
SSR 장점
- 초기 페이지 로드시간이 빠르다(FP 및 FCP가 빠르다). 렌더링이 준비된 HTML 파일을 브라우저에서 로드하기 때문에 CSR에 비해 더 빠르다.
- 서버에서 페이지 로직 및 렌더링을 실행하면 많은 자바스크립트를 클라이언트에 보내지 않아도 되므로 TTI(Time to Interactive)를 빠르게 수행할 수 있다.
- SEO에 친화적이다.이미 다 만들어진 페이지를 검색엔진 크롤러가 요청에 대한 응답으로 받기 때문이다.
- 클라이언트 하드웨어 및 소프트웨어 성능에 영향을 덜 받는다. 일반적으로 서버는 더 높은 컴퓨팅 성능과 훨씬 더 높은 네트워킹 속도를 가진 시스템이다. 클라이언트에서는 서버에서 완성된 페이지만 렌더링해 주면 된다. 즉 클라이언트의 부담이 CSR에 비해 덜하다.
SSR 단점
- 페이지 이동시마다 서버에서 페이지를 생성하는데 시간이 걸리기 때문에 TTFB(Time to First Byte)가 느리다.
- 페이지 로드가 너무 무겁다면, 오히리 사용자 경험을 개선하는게 아니라 해칠 수 있다. 초기 페이지 로드시 데이터가 많이 필요한 대시 보드가 예가 될 수 있다.
- 서버는 항상 각 요청이 올때마다 HTML파일을 생성하기 때문에 CDN 수준에서의 컨텐츠 캐시가 되지 않는다.
- 서버의 호스팅이 필요하다. 클라이언트에서 자바스크립트를 이용해 렌더링하는 CSR에 비해 서버 사이드에서 HTML파일과 안에 내용을 생성해야 하기 때문에 서버 호스팅이 필요하다.
- CSR에 비해 더 많은 개발 노력이 필요하며, SSR 프레임워크를 사용한다면 추가적인 러닝 커브에 대한 비용이 발생한다.
SSR은 항상 SSG보다 항상 별로인가?
Universal Rendering
Univeral Rendering 장점
Univeral Rendering 단점
- 별도의 서버가 필요하며, 구현 또는 구현을 위한 프레임워크 학습에 들어가는 비용이 크다.
- 페이지가 빨리 로드되며 인터렉션이 가능한 것처럼 보이지만, 실제로 클라이언트에서 자바스크립트가 실행되고 이벤트 핸들러가 적용될 때까지 입력에 응답할 수 없어, 사용자 경험이 안 좋아질 수 있다.
'TIL > 웹의 이해' 카테고리의 다른 글
| 프레임워크와 라이브러리 (Framework & Library) (0) | 2022.12.15 |
|---|---|
| 브라우저 저장소(Web Storage) - 쿠키, 세션스토리지, 로컬스토리지 (2) | 2022.12.03 |
| 대표적인 렌더링의 종류 (0) | 2022.11.21 |
| HTTP란? (0) | 2022.11.14 |
| HTTP (0) | 2022.08.31 |