[FE] SSR과 CSR 이란?

CSR(Client Side Rendering)과 SSR(Server Side Rendering)은 대척관계로 장단점이 뚜렷하다. 프론트엔드 개발을 하면서 프로젝트에 성향에 따라 어느 방식으로 구현해야할 지 생각하는 것이 중요하다. 

 

실제로 데이터가 많이 사용되는 프로젝트에서 이런 방식을 생각하면 구현하고, 또 변경한 적이 있어 정확한 개념을 숙지하는 것이 중요할 것 같아 글로 작성해본다. 

 

글의 목차 

1. 기본적인 브라우저 동작 방식
2. SSR 이란?
3. CSR 이란?
4. 각각의 차이
5. 각각 사용한 적절한 예시

1. 기본적인 브라우저 동작 방식

브라우저는 어떻게 동작할까? 브라우저 동작방식은 자세하게 알아보려면 브라우저 동작원리를 알아야하니 그 부분은 따로 글을 작성해야겠다. 우선 기본적으로 브라우저의 동작 단계는 크게 2단계로 나뉘어진다. (굉장히 크게)

 

서버와의 통신 -> 브라우저 렌더링 -> 스크립트 실행

SSR과 CSR은 동일한 단계를 거치는데 컨텐츠를 그려주는 과정과 시점이 다르다. 각각의 정의와 차이를 알아보자.

 

2. SSR 이란 ?

Server Side Rendering 의 약자 
말 그대로 서버 쪽에서 렌더링 준비를 마친 상태로 클라이언트에 전달하는 방식 
: 서버로부터 어느 정도 완성된 HTML 파일을 받은 뒤, 렌더링 하는 방식

SSR의 단계

서버와의 통신

1. 브라우저가 서버로 요청을 보냄
2. 서버는 요청에 따른 어느정도 완성된 HTML 파일을 응답

1. User 가 Website 요청을 보냄

2. 서버는 'Ready to Render'. 즉시 렌더링 가능한 html 파일을 만든다. 

(리소스 체크, 컴파일 후 완성된 HTML 컨텐츠로 만든다.)

3. 클라이언트에 전달되는 순간, HTML은 즉시 렌더링 된다.

4. 클라이언트가 자바스크립트를 다운받는다.

5. 유저는 컨텐츠를 볼 수 있다. 

6. 브라우저가 Javascript 프레임워크를 실행한다. 

7. JS까지 성공적으로 컴파일 되었기 때문에 기억하고 있던 사용자 조작이 실행되고 이제 웹페이지는 상호작용이 가능해진다. 

 

 

즉. 서버에서 이미 '렌더 가능한' 상태로 클라이언트에 전달되기 때문에, JS가 다운로드 되는 동안 사용자는 무언가를 보고 있을 수 있다.

 

3. CSR 이란 ?

Client Side Rendering 의 약자 
말 그대로 SSR과 달리 렌더링이 클라이언트 쪽에서 일어난다.
: 서버로부터 css, js 링크만 있는 빈 HTML파일을 전송받아 클라이언트 사이드에서 렌더링하는 방식

CSR 단계

CSR은 SSR과의 동작 과정은 전반적으로 비슷하며, 컨텐츠를 그려주는 과정과 시점만 다르다!

서버와의 통신

• 브라우저가 서버로 요청을 보냄
• 서버는 요청에 따른 css,js 링크만 있는 빈 HTML 파일을 응답

1. User 가 Website 요청을 보냄

2. CDN이 HTML 파일과 JS로 접근할 수 있는 링크를 클라이언트로 보낸다.

3. 클라이언트는 HTML과 JS를 다운로드 받는다.
(이때 SSR과 달리 유저는 아무것도 볼 수 없다.)

4. 브라우저는 JS를 다운받는다.

5. 다운이 완료된 JS가 실행된다. 데이터를 위한 API가 호출된다.
(이때 유저들은 placeholder를 보게된다. )

6. 서버가 API로부터의 요청에 응답한다.

7. API로부터 받아온 data를 placeholder 자리에 넣어준다. 이제 페이지는 상호작용이 가능해진다.

 

즉, 서버에서 처리 없이 클라이언트로 보내주기 때문에 자바스립트가 모두 다운로드 되고 실행이 끝나기 전까지 사용자는 볼 수 있는게 없다.

 

4. 각각의 차이

1) 웹페이지를 로딩하는 시간

웹 페이지 로딩의 종류는 두 가지로 나눌 수 있다.
하나는 웹 사이트의 가장 첫 페이지를 로딩하는 것.
다른 하나는 나머지를 로딩하는 것

• 첫 페이지 로딩시간.

CSR의 경우 HTML, CSS와 모든 스크립트들을 한 번에 불러온다. 반면 SSR은 필요한 부분의 HTML과 스크립트만 불러오게 된다. 따라서 평균적으로 SSR이 더 빠르다.

• 나머지 로딩 시간

첫 페이지를 로딩한 후, 사이트의 다른 곳으로 이동하는 식의 동작을 가정하자. CSR은 이미 첫 페이지 로딩할 때 나머지 부분을 구성하는 코드를 받아왔기 때문에 빠르다.
반면, SSR은 첫 페이지를 로딩한 과정을 정확하게 다시 실행한다. 그래서 더 느리다.

2) SEO 대응

검색 엔진은 자동화된 로봇인 '크롤러'로 웹 사이트들을 읽는다. CSR은 자바스크립트를 실행시켜 동적으로 컨텐츠가 생성되기 때문에 자바스크립트가 실행 되어야 meatadata가 바뀌었다.
(이전 크롤러들은 자바스크립트를 실행시키지 않았었기에 SEO 최적화가 필수적이었다. 구글이 그 트렌드를 바꾸고 있다고 한다.)

SSR은 애초에 서버 사이드에서 컴파일되어 클라이언트로 넘어오기 때문에 크롤러에 대응하기 용이하다.

3) 서버 자원 사용

SSR이 서버 자원을 더 많이 사용한다. 매번 서버에 요청을 하기 때문이다.

리엑트로 구현할 때는 다음과 같은 문제가 생기기도 한다.

renderToStrng은 React에서 서버사이드 렌더링을 구현하는데 사용되는 메소드다. 그런데 이게 스택을 막고 동기적으로 처리된다. 이게 실행될 동안 서버는 멈춘다. 😢 참고 renderToString은 리액트가 버전업이 되면서 '클라이언트에서'의 퍼포먼스가 개선되었다.

반면 CSR은 클라이언트에 일감(?)을 몰아주기 때문에 서버에 부하가 적다.

 

5. 각각 사용한 적절한 예시

SSR을 사용하자

• 네트워크가 느릴 때 😓
  (CSR은 한번에 모든 것을 불러오지만 SSR은 각 페이지마다 나눠불러오기 때문)
• SEO(serach engine optimization : 검색 엔진 최적화)가 필요할 때.
• 최초 로딩이 빨라야하는 사이트를 개발 할 때
• 메인 스크립트가 크고 로딩이 매우 느릴 때 CSR은 메인스크립트가 로딩이 끝나면 API로 데이터 요청을 보낸다.
• 하지만 SSR은 한번의 요청에 아예 렌더가 가능한 페이지가 돌아온다.
• 웹 사이트가 상호작용이 별로 없을 때.

CSR을 사용하자

• 네트워크가 빠를 때
• 서버의 성능이 좋지 않을 때
• 사용자에게 보여줘야 하는 데이터의 양이 많을 때.
  (로딩창을 띄울 수 있는 장점이 있다.)
• 메인 스크립트가 가벼울 때
• SEO 가 상관업을 때
• 웹 어플리케이션에 사용자와 상호작용할 것들이 많을 때. (아예 렌더링 되지 않아서 사용자의 행동을 막는 것이 경험에 오히려 유리함.)

다음은 SSR CSR의 Application - SPA 와 MPA의 차이를 알아보자.

 

출처 

• https://velog.io/@surim014/CSR-%EB%A0%8C%EB%8D%94%EB%A7%81-SSR-%EB%A0%8C%EB%8D%94%EB%A7%81-%EA%B3%BC%EC%A0%95%EC%9D%98-%EC%B0%A8%EC%9D%B4%EC%A0%90%EC%9D%84-%EC%95%8C%EC%95%84%EB%B3%B4%EC%9E%90
• https://hyothorhyo.tistory.com/19
• https://velog.io/@vagabondms/%EA%B8%B0%EC%88%A0-%EC%8A%A4%ED%84%B0%EB%94%94-SSR%EA%B3%BC-CSR%EC%9D%98-%EC%B0%A8%EC%9D%B4