CSR과 SSR

SPA와 MPA

SPA (Single-page Application)

SPA는 싱글페이지 어플리케이션은 하나의 페이지로 구성된 어플리케이션을 의미

 

MPA (Multi-page Application)

사용자의 클릭과 같이 인터렉션이 발생할 때마다 해당 링크로 이동하여

앱이 다시 새로고침 되는 전통적인 방식으로 작동한다.

 

 

SPA가 채택하고 있는 CSR, MPA가 채택하고 있는 SSR

---

CSR과 SSR

CSR(Client Side Rendering) : 클라이언트에서 모든 것을 처리하는 방식

사용자의 요청에 따라 필요한 부분만 응답받아 렌더링하는 방식

 

처음에 접속하면 빈 화면만 보인다.

 

다시 링크 된 어플리케이션 자바스크립트를 서버로부터 다운로드 받게 되는데 

이 JS에는 어플리케이션에서 필요한 로직들 뿐만 아니라 

어플리케이션을 구동하는 프레임워크와 라이브러리의 소스코드들도 다 포함이 되어있다.

→ 사이즈가 커서 다운로드 받는데 시간이 소요된다.

 

추가로 필요한 데이터가 있다면 서버에 요청해서 데이터를 받아온 다음에 

JSON(Data) + JS(app.js)를 기반으로 해서 동적으로 HTML을 생성해서

사용자에게 최종적인 어플리케이션을 보여주게 된다.

 

 

 

 

SSR(Server Side Rendering) : 

서버로부터 완전하게 만들어진 html 파일을 받아와 페이지 전체를 렌더링 하는 방식

 

서버에서 필요한 데이터를 모두 가져와서 HTML 파일을 만들게 되고

HTML 파일을 동적으로 조금 제어할 수 있는 소스코드와 함께 (index.html + JS) 

클라이언트에게 보내주게 된다.

 

그러면 클라이언트 측에서는 잘 만들어진 HTML 문서를 받아와서 바로 사용자에게 보여줄 수 있게 되는 것이다.

 

 

---

렌더링 과정

클라이언트에서 초기 화면을 로드하기 위해서 서버에 요청을 한다.

서버는 html로 화면에 표시하는데 필요한 완전한 리소스를 응답한다.

 

* CSR : 모든 JS파일을 다운 받아야 하기 때문에 초기 로딩 시간이 더 오래 걸린다.

 

 

화면을 구성하는 요소 중에 일부만 변경을 한다고 하면

 

CSR은 서버는 변경된 부분인 나무와 관련된 리소스만 응답한다.

(화면이 깜빡이지 않고 바로 수정된 데이터가 표시된다.)

 

SSR은 화면의 전체 요소들을 모두 서버로부터 다시 다운받아 온다.

이런 이유로 앱이 다시 시작되고 화면이 깜빡인 후에 표시된다.

 

 

 

	CSR	SSR
장점	빠른 속도 및 서버 부하 감소 사용자 친화적	SEO(검색 엔진 최적화)에 유리 빠른 초기 로딩 속도
단점	SEO(검색 엔진 최적화)에 불리 느린 초기 로딩 속도	불편한 사용자 경험  서버 부하 증가

 

 

빠른 속도 및 서버 부하 감소 : 변경된 부분과 관련된 데이터만 가져오므로

사용자 친화적 : 페이지 안의 컨텐츠를 클릭하여 다음 단계로 전환하는 과정에서
링크가 없기 때문에 깜빡임 없이 부드러운 이동을 경험할 수 있다.

 

SEO(Search Engine Optimization)에 불리 : SPA는 JS를 사용하여 사용자와 상호작용 후에
페이지 내용을 로드하기 때문에 웹 크롤러가 페이지를 색인화 하려고 하면 내용의 빈 페이지처럼 보이게 된다.

느린 초기 로딩 속도 : 초기에 모든 JS파일을 다운받아와야 하기 때문에 

 

 

 

SEO(검색 엔진 최적화)에 유리 : 모든 컨텐츠가 HTML에 담겨져 있기 때문

 

불편한 사용자 경험 : 매번 페이지를 요청할 때마다 새로고침 됨

서버 부하 증가 : 페이지를 요청할 때마다 서버에서 페이지를 구성하는 모든 리소스를 준비해서 응답

(사용자가 클릭을 할 때 마다 서버에 요청해서 서버에서 필요한 데이터를 가지고 와서 HTML을 만들어야 하므로)

 

치명적인 단점으로는 사용자가 빠르게 웹사이트를 확인할 수는 있지만

동적으로 데이터를 처리하는 자바스크립트를 아직 다운로드 받지 못해서 여기저기 클릭했는데

반응이 없는 경우가 발생할 수 있다. 

 

 

---

TTV(Time To View) , TTI(Time To Interact)

CSR

CSR은 사이트에 접속하게 되면 서버에게서 index 파일을 받아오며,

이 index 파일은 텅텅 비어있기 때문에 사용자에게는 아무것도 보여주지 않는다.

 

이 HTML 파일에 링크 되어져 있는

이 웹사이트에서 필요한 모든 로직이 담겨 있는 자바스크립트를 요청하게 된다.

 

그리고 최종적으로 동적으로 HTML을 생성할 수 있는

(웹 어플리케이션 로직이 담긴) 자바스크립트 파일을 받아오게 된다.

 

그리고 이 순간 사용자에게 보여지게 되고 사용자가 클릭이 가능하게 된다. 

 

즉, CSR은 TTV, 사용자가 웹 사이트를 볼 수 있음과 동시에 

TTI, 클릭을 하거나 인터랙션이 가능하게 된다. 

 

❓ 어떻게 하면 효율적으로 많이 분할해서

첫번째로 사용자가 보기 위해서 필요한 필수적인 것만 보낼 수 있을지 

 

 

 

SSR

SSR은 사이트에 접속하게 되면 서버에서 이미 잘 만들어진 index 파일을 받아오게 되고 

사용자가 웹 사이트를 볼 수가 있다.    

 

하지만 아직 동적으로 제어할 수 있는 js 파일은 받아오지 않았으므로 

사용자가 클릭을 해도 아무 것도 처리할 수가 없게 된다.

 

그래서 최종적으로 js 파일을 서버에서 받아와야지만 

그 때부터 사용자의 클릭을 처리할 수 있는 인터랙션이 가능해진다.

 

그래서 서버사이드 렌더링은 사용자가 사이트를 볼 수 있는 시간과 

실제로 인터랙션을 할 수 있는 시간의 공백 기간이 꽤 긴편이다. 

 

그래서 웹 사이트의 성능을 분석할 때 TTV와 TTI도 중요한 매트릭으로 사용할 수 있다.

 

 

❓ 사용자가 보고, 인터랙션 하는 이 시간의 단차를 줄이기 위해서 어떤 노력을 할 수 있을까?

 

출처  

서버사이드 렌더링 (개발자라면 상식으로 알고 있어야 하는 개념 정리 ⭐️)

[10분 테코톡] 🍻주모의 SPA