SSR vs CSR

SSR

SSR은 Server Side Rendering의 줄임말로, 서버로부터 완전하게 만들어진 html파일을 받아와 페이지 전체를 렌더링 하는 방식입니다. 웹 페이지를 브라우저에서 렌더링하는 대신에 서버에서 렌더링하게 됩니다. 클라이언트(브라우저)가 데이터를 요청하면 그림의 순서대로 브라우저=>프론트 서버=>백엔드 서버=>데이터베이스 를 거쳐 데이터베이스에서 데이터를 가져온 후 다시 브라우저에 데이터가 그려지는 형식입니다. 

 

먼저 클라이언트가 초기 화면을 로드하기위해 서버에 요청을 보냅니다.

그럼 서버는 화면에 표시하는데 필요한 데이터를 얻어와 모두 삽입하고 css 까지 모두 적용해서 렌더링 준비를 마친 HTML과 JS코드를 브라우저에 응답으로 전달합니다. 브라우저에서는 바로 전달 받은 페이지를 띄우고 이어, 브라우저가 JS 코드를 다운로드하고 html에 실행시킵니다. 

만약 여기서 페이지의 일부분만 변경하려면 어떻게 될까요? 그럼 이전과 마찬가지로 서버 html로 화면에 표시하는데 필요한 완전한 리소스를 응답합니다. 즉 일부분 뿐만 아니라 모든 요소들을 서버로부터 다시 다운받아 옵니다. 

이러한 이유로 요청을 보내고 응답을 받으면 새로고침되어 화면이 깜빡인 후에 표시됩니다. 

 

 

---

CSR

 

CSR은 Client Side Rendering 을 의미합니다. CSR은 클라이언트 사이드 렌더링이란 사용자의 요청에 따라 필요한 부분만 응답받아 렌더링 하는 방식입니다. CSR의 과정은 다음과 같습니다.

 

브라우저의 요청을 서버로 보내면 서버는 웹 페이지를 렌더링하는 대신, 웹 페이지의 골격이 될 단일 페이지(Single Page)를 클라이언트에 보냅니다. 이때 서버는 웹 페이지와 함께 JavaScript 파일을 보냅니다. 클라이언트가 웹 페이지를 받으면, 웹 페이지와 함께 전달된 JavaScript 파일은 브라우저의 웹 페이지를 완전히 렌더링 된 페이지로 바꿉니다. 웹 페이지에 필요한 내용이 데이터베이스에 저장된 데이터인 경우에는 어떻게 해야 할까요? 브라우저는 데이터베이스에 저장된 데이터를 가져와서 웹 페이지에 렌더링을 해야 합니다. 이를 위해 Fetch와 같은 API가 사용됩니다. 마지막으로, 브라우저가 다른 경로로 이동하면 어떻게 될까요? CSR에서는 SSR과 다르게, 서버가 웹 페이지를 다시 보내지 않습니다. 브라우저는 브라우저가 요청한 경로에 따라 페이지를 다시 렌더링합니다. 이때 보이는 웹 페이지의 파일은 맨 처음 서버로부터 전달받은 웹 페이지 파일과 동일한 파일입니다.

 

---

 

SSR, CSR의 차이

 

SSR과 CSR의 가장 큰 차이점은 페이지가 렌더링 되는 위치입니다. SSR은 서버에서 페이지를 렌더링하고, CSR은 브라우저(클라이언트)에서 페이지를 렌더링합니다.

 

SEO 대응

SSR은 애초에 서버 사이드에서 컴파일되어 클라이언트로 넘어오기 때문에 SEO(Search ENgine Optimization) 대응이 용이합니다.

반면 CSR에서 사용되는 html 파일은 대부분 텅텅 비어있기 때문에 검색엔진들이 CSR로 작성된 웹페이지를 분석하는데 많은 어려움이 있어, SEO 대응이 좋지 않습니다. 

 

 

CSR의 장점

• 후속페이지 로드 시간이 더 빠르다. 
• 별도의 API를 호출할 필요가 없는 페이지거나 지연 로딩 모듈이 필요하지 않다. 
• 이미 스크립트가 캐싱된 경우 인터넷이 없이도 해당 CSR 웹을 실행할 수 있다. 
• 서버를 호출할 때마다 전체 UI를 다시 로드할 필요가 없다. 

CSR의 단점

• 첫페이지의 로딩이 SSR보다 느릴 수 있다.
• SEO 대응이 썩 좋지 않다. 
• 페이지 메타데이터의 변경을 위한 추가적인 노력이 필요하다
• 페이지를 표시하기 전 HTML,JavaScript를 다운로드하고 프레임워크를 실행하는 동안 사용자가 빈페이지를 보게 되므로 User experience(UX)가 좋지 않을 수 있다.
• 클라이언트의 하드웨어 및 소프트웨어에 너무 많이 의존한다. 

CSR의 사용 (권장)

• 웹 어플리케이션에 사용자와 상호작용할 것들이 많을 때
• 네트워크가 빠를때
• 서버의 성능이 좋지 않을때
• 사용자에게 보여줘야 하는 데이터의 양이 많을 때.(로딩창을 띄울 수 있는 장점)
• 메인 스크립트가 가벼울 때
• SEO대응이 좋지 않아도 될 때

 

 

---

 

SSR의 장점

• CSR보다 첫페이지의 로딩이 빠르다.
• 모든 컨텐츠가 HTML에 담겨져 있기 때문에 SEO 대응이 좋다. 

SSR의 단점

• 깜빡임 이슈 
  사용자가 클릭을 하게 되면 전체 웹사이트를 다시 서버에서 받아 오는 것과 동일하기 때문에 썩 좋지 않은 User experience를 겪을 수 있습니다.
• 서버 과부하
  사용자가 많은 제품 일수록 사용자가 클릭할때마다 서버에서 필요한 데이터를 가지고와서 HTML을 만들어야 하므로 서버에 과부하가 걸리기가 쉽습니다.
• 클릭 무반응
  사용자가 빠르게 웹사이트를 확인할 수는 있지만 동적으로 데이터를 처리하는 자바스크립트를 아직 다운로드 받지 못해서, 여기저기 클릭해도 반응이 없을 수 있습니다. 

SSR의 사용 (권장)

• 웹 사이트가 상호작용이 별로 필요없을 때
• 네트워크가 느릴 때
• SEO가 필요할때
• 최초 로딩이 빨라야하는 사이트를 개발 할 때
• 메인 스크립트가 크고 로딩이 매우 느릴때

 

 

 

 

 

 

 

참조: mdn, 코드스테이츠, https://miracleground.tistory.com/165 , https://velog.io/@vagabondms/