답변
CSR은 클라이언트 측에서 JavaScript로 페이지를 렌더링하는 방식이며, 초기 로딩이 느릴 수 있으나 이후 상호작용이 빠릅니다. 반면, SSR은 서버에서 HTML을 미리 렌더링해 보내므로 초기 로딩이 빠르고 SEO에 유리합니다. CSR은 SPA에 적합하고, SSR은 SEO가 중요한 서비스에 주로 사용됩니다.
CSR
서버에서 인덱스라는 HTML 파일을 클라이언트에 보내주면 클라이언트에서 알아서 처리하는 방식
심플한 CSR 예제 index.html을 보면 body 안은 위와 같이 심플하게 생겼다.
따라서 처음에 접속하면 빈 화면만 보이고, 링크된 app.js를 서버로부터 다운로드 받게 된다.
이때 해당 js에는 해당 애플리케이션에서 필요한 로직들 뿐만 아니라 애플리케이션을 구동하는 프레임워크와 라이브러리의 소스 코드들도 다 포함되어 있음
→ 따라서 다운로드 받는데에도 제법 시간이 소요될 수 있음
추가로 필요한 데이터가 있다면 서버에 요청해서 데이터를 받아온 다음, 이것들을 기반으로 해서 동적으로 HTML을 생성해서 사용자에게 애플리케이션을 보게됨
→ 사용자가 첫 화면을 보기까지 시간이 오래 걸릴 수있음
→ 뿐만 아니라 SEO, 즉 검색 엔진에 노출되는데 불리할 수 있음
검색 엔진은 서버에 등록된 웹사이트를 하나하나씩 돌아다니면서 웹사이트의 HTML 문서를 분석해서 사용자가 웹 사이트를 검색할 수 있도록 도와줌
이때 CSR에서 사용하는 HTML은 비어있어 검색 엔진들이 해당 웹페이지를 분석하기 어려울 수 있음
SSR
렌더링을 클라이언트에서 처리하는 것이 아닌 사용자가 웹 사이트에 접근했을 때 서버에서 필요한 데이터를 모두 가져와서 HTML 파일을 만들고
잘 만들어진 HTML 파일을 동적으로 제어할 수 있는 소스코드와 함께 클라이언트에 보내줌
→ 클라이언트는 서버에서 HTML을 받아 바로 화면에 보여주면 된다.
이렇게하면 첫 로딩이 빠르고 검색엔진 노출에도 유리하다.
그럼 SSR이 무조건 더 유리한가?
그건 아니다. 아래에서 단점을 알아보자
- 화면 깜밖임
- 사용자가 클릭하면 전체적인 웹사이트를 서버에서 받아오는 것과 동일하기 때문에 화면 깜밖임이 존재할 수 있고, 이건 사용자 경험 저하로 이어질 수 있다.
- 서버에 과부하가 걸리기 쉽다.
- 특히 사용자가 많은 제품일 수록 사용자가 클릭을 할 때마다 서버에 요청하여 서버에서 필요한 데이터를 가지고와서 HTML을 만들어야 하므로 서버에 과부하가 걸리기 쉽다.
- 동적으로 처리하는 자바스크립트를 아직 다운 받지 못한 상태이기에 사용자와의 상호작용이 느릴 수 있다.→ 아래의 개념에서 더 알아보자
- 사용자가 웹 사이트를 빠르게 확인할 수는 있으나, 동적으로 데이터를 처리하는 자바스크립트를 아직 다운로드받지 못해서 여기저기 클릭했는데 반응이 없는 경우가 발생할 수 있음
TTV(Time To View)와 TTI(Time To Interact)
CSR과 SSR을 시간이 흘러가는 순서대로 분석해보자.
CSR 흐름
CSR은 사이트에 접속하게 되면 서버에게서 인덱스 파일을 받아오고, 해당 인덱스 파일은 텅텅 비어져 있기 때문에 사용자에게는 아무것도 보이지 않음
이 HTML 파일에 링크되어져 있는 웹 사이트에서 필요한 모든 로직이 담겨 있는 자바스크립트를 요청함
이후 최종적으로 동적으로 html을 생성할 수 있는 웹 애플리케이션 로직이 담긴 자바스크립트 파일을 받아옴 → 이때부터 사용자에게 화면이 보여지며 사용자가 클릭이 가능하게 됨
즉 CSR은 사용자가 웹 사이트를 볼 수 있음(TTV)와 동시에 클릭하거나 인터랙션이 가능하게 됨(TTI)
SSR 흐름
SSR은 사이트에 접속하면 서버에서 이미 잘 만들어진 인덱스 파일을 받아 오게 되고 사용자가 웹사이트를 볼 수가 있음
하지만 아직 동적으로 제어할 수 있는 자바스크립트 파일은 받아오지 않았으므로 사용자가 클릭해도 아무런 것도 처리할 수 없음
그래서 최종저긍로 자바스크립트 파일을 서버에서 받아와야지만 사용자의 클릭을 처리할 수 있는 인터랙션이 가능해짐
그래서 서버사이드 렌더링은 사용자가 사이트를 볼 수 있는 시간과 실제로 인터렉션을 할 수 있는 시간의 공백 기간이 꽤 긴편이다.
따라서 웹사이트의 성능을 분석할 때 TTV와 TTI도 중요한 매트릭으로 사용할 수 있음
CSR에서는 최종적으로 번들링해서 사용자에게 보내주는 자바스크립트 파일을 어떻게하면 효율적으로 많이 분할해서 첫 번째로 사용자가 보기 위해서 필요한 정말 필수적인 부분만 보낼 수 있을지 고민해보면 좋을듯
SSR에서는 사용자가 보고, 인터렉션 하는 이 시간의 단차를 줄이기 위해서 어떤 노력을 할 수 있을지, 어떻게하면 더 매끄러운 UI UX를 제공할 수 있을지 고민해보면 좋을듯
요즘날에는 CSR이나 SSR 뿐만 아니라 SSG라는 것도 있음
SSG(Static Site Generation)
- 빌드 시점에 서버에서 미리 HTML 파일을 생성하여 배포하는 방식
- SSR과 CSR의 장점을 모두 챙길 수 있음
- 단 동적 콘텐츠 처리에는 불리함
React는 Gatsby라는 라이브러리와 함께 사용하면 react로 만든 웹 애플리케이션을 정적으로 웹 페이지 생성을 미리 해두어서 서버에 배포해 놓을 수가 있음
이렇게 만들어진 웹 사이트는 모두 정적이라기보단 동적인 요소도 포함할 수 있음
아니면 next.js를 활용하면 SSG나 CSR과 SSR을 유연하게 사용할 수 있다.
'Web > Frontend 기본 CS 정리' 카테고리의 다른 글
불변성을 유지하려면 어떻게 해야하나요? (2) | 2024.12.24 |
---|---|
브라우저 렌더링 과정을 설명해주세요. (0) | 2024.12.24 |
렉시컬 환경(Lexical Environment)에 대해 설명해주세요. (0) | 2024.12.24 |
CORS는 무엇인지, 이를 처리를 해본 경험을 말씀해주세요. (0) | 2024.12.24 |
이벤트 버블링과 캡처링에 대해 설명해주세요. (0) | 2024.12.24 |