CRS vs SSR

CSR  

Client Side Rendering

클라이언트가 html과 JavaScript를 전달받아 랜더링

 

CSR의 웹페이지 동작 단계

1. User가 Website에 요청
2. CDN이 html파일과 JavaScript로 접근할 수 있는 링크를 클라이언트에 전달
3. 클라이언트는 html과 JavaScript를 다운받음 (다운받는 동안 사용자는 아무것도 볼 수 없음)
4. 다운로드가 완료된 JavaScript 실행
5. 데이터를 위한 API 호출 (실행과 호출되는 과정에서 사용자는 placeholder를 보게됨)
6. 서버가 API로 부터의 요청에 응답
7. API로 받아온 data를 placeholder에 채워주면서 본격적으로 웹페이지 상호작용 가능

CDN: 유저의 요청에 물리적으로 가까운 서버에서 요청에 응답하는 방식

CSR의 경우 자바스크립트 번들의 크기의 영향을 많이 받기 때문에 적극적인 코드 분할(code splitting)을 고려해야 하며, "필요한 것만 필요할 때만 제공"해야 한다.

 

SSR

Server Side Rendering

서버 쪽에서 랜더링을 모두 마치고 클라이언트에 전달

 

SSR의 웹페이지 동작 단계

1. User가 Website에 요청
2. 서버가 랜더링을 마친 html 파일을 만들어서 클라이언트에 전달
3. 이때 html은 즉시 렌더링
4. 클라이언트가 JavaScript를 다운받음
5. html이 랜더링 되고, 클라이언트가 JavaScript를 실행하기 전까지는 사이트 조작이 불가능 (단, 사용자의 조작을 기억하고 나중에 실행)
6. 브라우저가 JavaScript 실행
7. JavaScript까지 성공적으로 컴파일이 되었다면, 저장된 사용자의 조작을 실행시킴
8. 그리고 본격적으로 웹 페이지 상호작용

 

CSR vs SSR 차이점

웹페이지 로딩 시간

1. 첫 페이지 로딩 시간

CSR의 경우  html, css, JavaScript등 모든 것을 한번에 불러오는 반면,

SSR은 필요한 부분만 불러오기 때문에 평균적으로 SSR이 더 빠르다.

 

2. 나머지 로딩 시간

첫 페이지를 로딩한 후, 사이트의 새로운 곳을 조회하였을 때

CSR은 처음에 모든 부분을 구성하는 코드를 받아왔기 때문에 빠르다.

하지만 SSR은 첫 페이지를 로딩했을 때와 같이, 필요한 부분을 불러오는 과정을 동일하게 진행하기 떄문에 느리다.

 

SEO 대응

검색엔진 크롤링 봇이 사이트의 내용을 탐색하려 사이트를 방문하였을 때 

CSR은 방문 당시는 빈 페이지이기 때문에 페이지를 탐색하기에 어려움이 있다.

(구글 크롤링 봇은 JavaScript를 실행 시킬 수 있어 이런 부분을 개선 중이라고 한다)

그에 반해 SSR은 모든것이 만들어진 상태에서 크롤링 봇이 방문하기 때문에 SEO에 용이하다.

 

서버 자원 사용

SSR은 필요 시 매번 서버에 요청을 보내기 때문에 SSR이 서버 자원을 더 많이 사용한다.

반면 CSR은 클라이언트에게 일처리를 맡기기 때문에 서버의 부하가 적다.

 

클라이언트의 하드웨어 및 소프트웨어 성능의 영향

위의 서버 자원 사용과 상반 되는 내용인데,

SSR은 서버 자원을 잡아먹고 서버 측에서 모든 일처리를 하기 때문에 클라이언트의 하드웨어와 소프트웨어 성능의 영향을 받지 않지만,

클라이언트가 랜더링을하는 CSR의 경우 영향을 받는다.

 

보안

 SSR은 서버에서 쿠키, 주요API, 데이터 검증등이 이루어지기 때문에 더 안전하다.

 

 

 

적재적소

CSR

• 네트워크가 빠른 경우
• 서버의 성능이 좋지 않은 경우
• 사용자에게 보여줘야하는 데이터의 양이 많은 경우 (로딩 페이지를 띄울 수 있음)
• 메인 스크립트가 가벼운 경우
• 웹사이트와 사용자간 상호작용 요소가 많은 경우 (랜더링이 되지 않을 때 사용자의 행동을 막는 것이 오히려 사용자 경험에 유리함)

SSR

• 네트워크가 느린 경우
• SEO가 필요한 경우
• 최초 로딩이 빨라야하는 경우
• 메인 스크립트가 크고 로딩이 매우 느린 경우
• 웹사이트와 사용자 상호작용이 별로 없는 경우