CSR (Client Side Rendering)
클라이언트 측에서 모든 것을 처리하여 렌더링하는 방식
클라이언트는 서버에서 HTML 파일을 받아온다
이 HTML 파일의 body 안에는 id가 root인 div 하나와 스크립트만 들어있다
(내용이 존재하지 않음)
HTML이 텅 비어있기 때문에 초기 로딩시 빈 화면만 보인다
클라이언트는 웹사이트에 필요한 모든 로직이 담겨있는 JS 파일을 서버에게 요청한다
이 JS 파일에는 어플리케이션에서 필요한 로직, 다양한 프레임워크와 라이브러리 코드들이 포함되어 있다
(사이즈가 크고 다운받는데 오랜 시간 소요)
서버로부터 JS 파일을 받아오면 이것들을 기반으로 한 동적 HTML을 생성하고
그 순간부터 사용자에게 최종적인 웹사이트가 보여지는 것이다
장점
-
초기 로딩 이후의 구동속도가 빠르다
-
화면 깜빡임 이슈가 없다
-
서버의 부하가 적다
(서버는 비어있는 HTML을 넘겨주는 역할만 수행) -
클라이언트 측에서 모든 일을 직접 처리하기 때문에 반응속도가 빠르고 UX가 우수하다
단점
-
초기 로딩 속도가 느리다
(사용자가 첫 화면을 보기까지 오랜 시간이 걸린다) -
SEO 에 불리하다
(HTML이 비어있기 때문에)
SEO Search Engine Optimization
검색엔진 최적화
검색엔진에서 찾기 쉽도록 사이트를 개선하는 프로세스이다
웹 크롤러가 웹사이트의 HTML문서를 분석하고
분석한 정보를 기반으로 검색어를 검색엔진에 등록해준다
그래서 우리가 검색할 때 웹사이트를 빠르게 검색할 수 있도록 도와준다
SSR (Server Side Rendering)
서버 측에서 렌더링하는 방식
1990년 중반쯤 사용했던 Static Sites에서 영감을 받아 탄생하였다
사이트에 접속 하게 되면
서버 측에서는 필요한 데이터를 모두 가지고 렌더링 준비를 마친 HTML 파일을 생성한다
클라이언트가 HTML 파일을 받아오면 사용자가 바로 웹사이트를 볼 수 있도록 렌더링한다
하지만 동적으로 제어할 수 있는 JS 파일은 받아오지 않은 상태이다
때문에 사용자가 클릭을 해도 반응이 없는 경우가 있다
클라이언트는 다시 서버에 JS 파일을 요청하고
서버는 HTML 파일을 동적으로 제어할 수 있는 소스코드를 클라이언트 측으로 전송한다
그때부터 사용자의 클릭을 처리할 수 있는 인터랙션이 가능해진다
장점
-
초기 로딩 속도가 빠르다
-
SEO 에 유리하다
(모든 컨텐츠가 HTML에 담겨있기 때문에)
단점
-
화면 깜빡임 이슈가 있다
(사용자가 클릭을 하면 전체적인 웹사이트를 서버에서 다시 받아 오는 것과 동일하기 때문에) -
서버 과부하
(사용자가 많은 어플리케이션일수록 사용자가 클릭을 할 때마다 서버에 요청을 하고
서버에서는 필요한 데이터를 활용해 HTML을 만들어야 한다) -
인터랙션이 안되는 경우가 있다
(동적으로 데이터를 처리하는 코드를 다운받지 못한 경우
여기저기 클릭해도 반응이 없는 경우가 발생할 수 있다)
SSG (Static Site Rendering)
SSG는 SSR과 거의 유사하지만 차이점이 존재한다
서버에서 HTML을 언제 만들어두는지에 따라 SSG와 SSR이 나뉘는 것이다
SSR은
요청 즉시 HTML을 만들어서 응답한다
때문에 데이터가 달라지거나 미리 만들어두기 어려운 페이지에 적합하다
SSG는
페이지를 서버에 모두 만들어둔 뒤에 요청시 해당 페이지를 응답한다
때문에 바뀔 일이 거의 없는 캐싱 해두면 좋은 페이지에 적합하다
TTV, TTI 측면에서의 CSR과 SSR
TTV (Time To View)
TTI (Time To Interact)
CSR은
웹사이트를 볼 수 있음(TTV)과 동시에 클릭 및 인터랙션(TTI)이 가능하다
SSR은
웹사이트를 볼 수 있지만(TTV) 클릭 및 인터랙션(TTI)에는 시간이 소요된다
사용자가 웹사이트를 볼 수 있는 시간과
클릭 및 인터랙션을 할 수 있는 시간 사이에 공백이 생기는 것이다
CSR, SSR, SSG 중 어느 것을 사용해야할지 고민이라면?
🔊 참고
