[TIL] CSR과 SSR

🔗 CSR(Client Side Rendering)

말 그대로 렌더링이 클라이언트 쪽에서 일어난다.
즉, 서버는 요청을 받으면 클라이언트에 HTML과 JS를 보내준다. 클라이언트는 그것을 받아 렌더링을 시작한다.

💡 Rendering 이란,
요청받은 내용을 브라우저 화면에 표시하는 것

클라이언트 사이드 렌더링은 쉽게 말하면 클라이언트 측에서 모든 걸 다 한다는 뜻이다. 서버에서 인덱스라는 html 파일을 클라이언트에 보내주면 body안에는 아이디 루트만 달랑하나만 들어있다. 어플리케이션에서 필요한 자바스크립트의 링크만 들어져 있다. 그래서 html은 텅텅 비어져 있기 때문에 처음에 접속하면 빈 화면만 보인다. 다시 링크된 어플리케이션 자바스크립트를 서버로부터 다운로드 받게 되는데 여기 자바스크립트에는 어플리케이션에서 필요한 로직들 뿐만 아니라 어플리케이션을 구동하는 프레임워크나 라이브러리의 소스 코드들도 다 포함이 되어 있다. 그렇기 때문에 사이즈가 커서 다운로드 받는데도 시간이 소요될 수 있다. 추가로 필요한 데이터 있다면 서버에 요청해서 데이터를 받은 다음에 이것들을 기반으로 해서 동적으로 html을 생성해 드디어 사용자에게 최종적인 어플리케이션을 보여주게 된다.

장점 >

• SSR 보다 조금 더 빠른 인터랙션이 가능
  클라이언트 사이드 렌더링은 사용자의 행동에 따라 필요한 부분만 다시 읽어들이기 때문

• 모바일 네트워크에서도 빠른 속도로 렌더링 가능
  page 전체를 요청하지 않고 페이지에 필요한 부분만 변경하게 하기 때문

문제점 >

• Initial Loading may take too long
  사용자가 첫 화면을 보기까지 시간이 오래 걸릴 수 있다는 점

• Low SEO(Search Engine Optimization)
  좋지 않은 SEO

🔗 SSR(Server Side Rendering)

서버쪽에서 렌더링 준비를 끝마친 상태로 클라이언트에 전달하는 방식이다.

웹 사이트에 접속하면 서버에서 필요한 데이터를 모두 가져와서 html 파일을 만들고 잘 만들어진 html 파일을 동적으로 조금 제어할 수 있는 소스코드와 함께 클라이언트에 보내준다. 그러면 클라이언트 측에서는 잘 만들어진 html 문서를 받아와서 바로 사용자에게 보여줄 수 있다.

SSR 장점 >

• Initial page load is faster
  페이지 로딩이 빨라짐

• Great SEO
  모든 컨텐츠가 html에 담겨져 있기 때문에 효율적인 SEO를 할 수가 있다.

🤔 그렇다면 SSR이 모든 것에 솔루션이 될 수 있나?

답은 No!

SSR 문제점 >

• Blinking issue, Non-rich site interactions
  Static Sites에서 존재했던 깜박임 이슈가 존재함
  클릭을 하게 되면 전체적인 웹사이트를 다시 서버에서 받아 오는 것과 동일하기 때문

• Server side overhead
  서버에 과부하가 걸리기 쉬움
  사용자가 클릭을 할 때마다 서버에 요청해서 서버에서 필요한 데이터를 가지고 와 html을 만들어야 하므로

• Need to wait before interacting
  사용자가 빠르게 웹사이트를 확인할 수는 있지만 동적으로 데이터를 처리하는 자바스크립트를 아직 다운로드 받지 못해서 반응이 없는 경우가 발생할 수 있음

이번 프로젝트를 진행하면서 React 로도 SSR 이 가능하도록 하는 프레임워크를 사용해보았다.
Netx.js : 서버사이드 렌더링 프레임워크
이후에 Next.js 정리를 해볼 것이다.

참조 >
https://www.youtube.com/watch?v=iZ9csAfU5Os