CSR
클라이언트 측에서 렌더링을 담당합니다.
첫 로딩에 빈 HTML 파일에 필요한 번들파일을 모두 다운로드 받습니다.
사용자가 해당 웹 사이트에 접속을 하면 해당 브라우저는 웹사이트의 정보를 가진 서버에 리소스를 요청합니다.
해당 서버는 js, css 를 불러올 수 있는 빈 html 파일을 전송해 주고 브라우저는 받은 정보들을 바탕으로 js 코드를 다운로드 합니다.
그 다음에 사용자에게 페이지를 제공해 줍니다.
👍 TTFB(Time to First Byte)
요청을 보내고 응답의 첫번째 바이트가 도착하기까지의 시간
👎 FCP (Frist Contentful Paint)
사용자가 화면에서 콘텐츠를 볼 수 있는 페이지 로드 타임라인의 첫번째 지점
위에 사진은 JS, CSS 를 불러올 수 있는 빈 HTML 파일입니다.
SSR
서버 측에서 렌더링 될 페이지를 그려 클라이언트로 내려주는 방식입니다.
여기서도 요청 시 즉시 HTML 파일을 만드느냐 vs 미리 다 만들어둔 정적 페이지를 제공하느냐에 따라
SSR , SSG(Static Site Generation) 로 나누어 집니다.
예를 들어 SSG 는 모든 사용자가 같은 화면을 공유하는 사이트일 때 좋습니다.
즉 기술 블로그, 어떤 기사 사이트 같은 경우가 해당됩니다.
SSR에서는 초기에 사용자에게 정적인 페이지를 제공하고, 사용자의 상호 작용에 따라 필요한 경우에 동적으로 페이지를 업데이트합니다.
예를 들어, 사용자가 웹 페이지를 방문하면 서버는 미리 정적인 HTML을 생성하여 사용자에게 제공합니다. 이 HTML에는 페이지의 기본 구조와 내용이 포함되어 있습니다. 사용자는 이 HTML을 받아 웹 페이지를 빠르게 로드할 수 있습니다.
그런 다음, 사용자가 버튼을 클릭하거나 다른 상호 작용을 할 때, 클라이언트 측에서 JavaScript가 실행되어 동적으로 페이지를 업데이트합니다. 이때, 클라이언트에서는 필요한 데이터를 요청하고, 이를 받아와서 페이지를 업데이트합니다.
그림에서 보면 미리 만들어진 HTML 파일을 서버에서 res.sendFile 을 통해 브라우저로 보내주는데
이러한 부분이 렌더링 된 HTML 파일을 준비하다 브라우저에서 가져오면 바로 볼 수 있다는 뜻입니다.
👍FCP (Frist Contentful Paint)
사용자가 화면에서 콘텐츠를 볼 수 있는 페이지 로드 타임라인의 첫번째 지점
👎TBT (Total Blocking Time)
FCP 로부터 TTI(Time To Interact) 사이의 시간
TTI
사용자가 페이지에서 상호작용이 가능하기까지의 시간
CSR vs SSR
SEO 란?
Search Engine Optimization
웹사이트 검색 결과가 더 잘 보이도록 최적화 하는 과정
검색봇이 웹사이트를 크롤링하면 더 상단에 잘 뜹니다.
👍 장점
CSR
화면 깜빡임이 없어 좋은 사용자 경험을 제공, 초기 로딩 이후 구동 속도가 빠름
SSR
초기 로딩속도가 빠름, SEO 가 쉬움
👎 단점
CSR
초기 구동 속도가 느림
SEO 어려움
SSR
페이지를 이동할 때 화면이 깜빡여 사용자 경험 저하
매번 요청을 보내기 때문에 과부하 될 수 있음
결론
SSR에서는 사용자가 페이지를 요청할 때마다 서버에서 해당 페이지에 대한 HTML을 동적으로 생성하여 보내줍니다. 따라서 사용자가 페이지를 이동할 때마다 새로운 HTML을 받아와야 합니다.
반면에 CSR에서는 초기에 모든 페이지의 HTML, CSS 및 JavaScript 파일이 브라우저로 다운로드됩니다. 사용자가 애플리케이션을 로드할 때 모든 리소스가 다운로드되므로 초기 로딩 속도는 느려질 수 있습니다. 그러나 페이지를 이동할 때는 서버에 새로운 HTML을 요청하지 않고 클라이언트 측에서 JavaScript를 사용하여 페이지를 업데이트합니다.
따라서 SSR은 페이지 이동할 때마다 서버로부터 HTML을 받아오지만, CSR은 초기에 모든 페이지의 HTML 파일을 받아온 후에 페이지를 업데이트합니다.
