본문 바로가기

Back-End 공부/Spring

렌더링이란? CSR, SSR 그게 도대체 뭔데?

💡 CSR, SSR 그게 뭔데?

CSR과 SSR에 대해 알기 전에, (1)SPA와 MPA와 (2)브라우저 렌더링에 대해 알아야 한다.

 

 

📌 SPA, MPA

 

SPA == CSR

SPA(Single Page Application) : 하나의 페이지로 구성된 웹 애플리케이션이다. SPA로 개발된 웹사이트에서는 카테고리에 있는 각 메뉴를 선택하면 보통 헤더는 고정되어 있는 상태로 메인화면 혹은 클릭한 부분만 바뀐다.  

 

 MPA == SSR

MPA(Multi Page Application) : 탭을 이동할 때마다 서버로부터 새로운 HTML을 새로 받아와서 페이지 전체를 렌더링 하는 전통적인 웹 페이지 구성 방식이다.

 

 

 

📌 브라우저 렌더링 (Browser Rendering)

 

렌더링(Rendering)이란 화면에 표시할 웹 페이지를 만드는 과정을 의미한다.

 

 

렌더링 과정은 다음과 같은 과정을 거쳐서 이루어 이루어 진다.

1. Loader가 서버로 부터 HTML을 불러옴.
2. HTML을 분류((Phasing)하여 DOM트리를 만든다.
3. css 파일과, 스타일 요소를 분류하여 CSSOM트리를 만든다.
4. DOM트리와 CSSOM을 결합하여 렌더링트리를 만든다.
5. 렌더링트리의 요소들의 크기와 위치를 계산한다.
6. 계산된 크기와 위치에 맞게 화면에 출력된다.

이러한 렌더링은 Client와 Server중 어느 쪽에서 렌더링이 준비되느냐에 따라 Client Side Rendering Server Side Rendering으로 나뉘게 된다.

 

 

일반적으로 SPA에서는 CSR로 렌더링한다.

CSR은 클라이언트 측에서 렌더링 하는 방식을 말한다.

SPA는 웹 애플리케이션에 필요한 정적 리소스를 한꺼번에 모두 다운로드하고, 이후 새로운 페이지 요청이 왔을 때 필요한 데이터만 전달받아서 클라이언트에서 필요한 페이지를 갱신하기 때문에 CSR로 렌더링 한다.

 

CSR 동작 과정

1. 유저가 웹사이트에 방문하면, 브라우저가 서버에 콘텐츠를 요청한다.
2. 이에 서버는 빈 뼈대만 있는 HTML을 응답으로 보내준다. 
3. 브라우저가 연결된 JavaScript 링크를 통해 서버로부터 다시 JavaScript 파일을 다운로드한다. 
4. JavaScript를 통해 동적으로 페이지를 만들어 브라우저에 띄워준다. 

 

브라우저는 연결된 자바스크립트 링크를 사용하여 서버를 통해 자바스크립트 파일을 다운로드, 자바스크립트를 이용해 동적 페이지(DOM)을 생성한다.

자바스크립트 파일을 서버로 부터 다운로드 받아 동적으로 페이지를 생성해서 브라우저에 띄우는 과정을 CSR의 경우 기다려야 하기 때문에 초기 로딩 속도가 느리다는 단점이 있다.

단, 초기 로딩 이후에 페이지 일부를 변경할 때는 서버에 일부 데이터만 요청하면 되므로 이후의 로딩 속도는 SSR에 비해 빠르다.

클라이언트측에서 연산 및 라우팅을 직접 처리하기 때문에 반응속도가 빠르며 서버가 빈 뼈대만 있는 HTML을 브라우저에 넘겨주는 역할만을 수행하기 때문에 서버 부하를 줄일 수 있다.

하지만 빈 뼈대의 HTML안에는 검색 엔진이 색인을 할만한 컨텐츠가 존재하지 않는다. 때문에 CSR은 검색엔진 최적화에 불리하여 검색 노출에는 불리하다.

 

 

💡 프론트를 왜 분리할까?

화면을 완전히 분리하고, 프론트에 백엔드와 독립된, 다양한 프레임워크(react)를 적용할 수 있기 때문이다.

 

 

js를 통해 특정 부분만 고칠 경우는 서버 데이터가 필요 없기 때문에 (화면단 기술 구현) CSR 기술이 사용자 경험이 좋다.

velog 사이트를 예시로 들 수 있는데, 스크롤 내려서 게시글이 부분적으로만 업데이트됨을 볼 수 있다.

https://velog.io/

 

velog

 

velog.io

 

 

 

일반적으로 MPA에서는 SSR로 렌더링 한다.

SSR은 Server Side Rendering의 약자로, 서버 측에서 렌더링 하는 방식이다.

MPA는 새로운 요청이 있을 때마다 서버에서 이미 렌더링 된 정적 리소스를 받아오기 때문에 SSR로 렌더링 한다.

 

SSR 동작 과정

1. 유저가 웹사이트에 방문하면, 브라우저가 서버에 콘텐츠를 요청한다.
2. 이에 서버는 페이지에 필요한 데이터를 즉시 얻어와 모두 삽입하고, CSS까지 모두 적용해 렌더링 준비를 마친 HTML과 JavaScript코드를 브라우저에 응답으로 전달한다. 
3. 브라우저에서는 JavaScript코드를 다운로드하고 HTML에 JavaScript로직을 연결한다. 

모든 데이터가 이미 HTML에 담긴 채로 브라우저에 전달되기 때문에 검색엔진 최적화에 유리하다.

브라우저측의 자바스크립트 다운로드를 기다려야했던 CSR보다 초기 구동속도가 빠르다.

하지만 초기 로딩시에 사용자가 버튼을 클릭해도 아무 반응이 없는 현상이 발생할 수 있다. 결국 JS로직이 연결될 때 까지 사용자의 응답에는 아무런 반응을 할 수 없다.

이때문에 사용자 입장에서는 사이트의 뭔가를 눌렀는데 아무런 반응이 없는 경험을 하게 될 수도 있는데 이는 다시 말해 Time To View 와 Time To Interact의 시간차가 존재한다는 것을 말한다.

 

 

(+) SSR vs SSG

서버에서 HTML을 보내준다는 점은 SSR과 같지만 '언제' 만드느냐가 다른 Static Site Generation 렌더링 방식도 존재한다.

SSR은 요청 시 서버에서 즉시 HTML을 만들어 응답하기에 데이터가 달라지거나 자주 바뀌어서 미리 만들어 두기 어려운 페이지에 적합하고, SSG는 페이지들을 서버에 모두 만들어 둔 후에 요청 시 해당 페이지를 응답하는 것이므로 바뀔 일이 거의 없어 캐싱해 두면 좋을 페이지에 사용하면 적합하다.

 

 

따라서 SSR 방식은 새로운 요청이 있을 때마다 페이지 전체를 다시 불러온 후 띄워줘서 화면이 느리고, 순간적으로 깜빡거리게 된다.

여기에 프론트엔드 핵심 기술인 "상태 관리" 기술을 통해 이미 받아온 곳의 데이터는 가지고 있다가, 사용자의 재요청이 있으면 빠르게 데이터를 꺼내준다.

 

 

구글맵 사이트를 예시로 들 수 있는데, 확대하거나 위치를 움직임에 따라 데이터를 다시 받아오기 때문에 시간이 오래 걸리고, 화면 전체의 내용이 바뀌게 된다. 하지만, 한 번 데이터를 받은 동네를 다시 접근했을 때는 빠른 속도로 데이터를 받아볼 수 있다.

https://www.google.co.kr/maps/?hl=ko

 

Google 지도

Google 지도에서 지역정보를 검색하고 지도를 살펴보거나 운전경로 정보를 검색합니다.

www.google.co.kr

 

 

 

 

 

 

- References

https://dev-ellachoi.tistory.com/28

https://headf1rst.github.io/front_end/SSR-CSR/