전통적인 웹페이지 방식
서버에 각각의 static 페이지들이 html 파일들로 저장 되어 있고 새 페이지를 열면 클라이언트 쪽에 매번 새 페이지 전체를 서버에서 받아와서 업데이트 하는 방식.
SPA(Single Page Application) 방식
서버에서 JSON포맷으로 필요한 정보만 받아와서 JS파일을 이용하여 동적으로 HTML 생성해 페이지에 업데이트 하는 방식.
CSR (Client Side Rendering)
서버에서 index.html 파일을 하나 클라이언트에 보내주면 index.html 안에 링크된 app.js를 서버로부터 다운 받는다.
이 app.js 안에는 로직, 프레임워크 구동 등에 필요한 소스코드들도 포함되어 있어 크기가 크고 받아오는 데 시간이 걸린다.
추가로 필요한 자료가 있다면 서버에 요청하여 해당 자료를 app.js와 함께 기반으로 삼아 동적으로 html 파일을 생성해 페이지를 업데이트한다.
동작원리
1. 사이트에 접속
2. 서버에서 텅 빈 index 파일을 받아옴. 텅 비어있기 때문에 사용자에게는 아무것도 보이지 않는다.
3. 이 index.html에 링크 되어 있는 웹사이트에 필요한 모든 로직이 담겨있는 JS 파일을 요청
4. 동적으로 html을 생성할 수 있는 웹 어플리케이션 로직이 담긴 JS 파일을 받아옴. 이때부터 사용자에게 화면이 보여지고 클릭 시 정상적으로 동작한다.
=> CSR은 사용자가 화면을 볼 수 있음과 동시에 (TTV (Time To View)), 클릭을 하거나 인터랙션이 가능하게 된다 (TTI (Time To Interact)) .
단점
1. 클라이언트한테 화면 제공되기 까지 시간 오래 걸린다.
2. CSR에서 사용되는 html 바디는 비어져 있어 html을 분석하여 검색하는 SEO 성능이 떨어진다.
고민점
사용자에게 최종적으로 보내지는 JS 파일을 어떻게 분할해서 사용자가 첫번째로 보기 위해 필수적인 파일만 보낼 수 있을지.
SSR (Server Side Rendering)
웹사이트에 접속시 필요한 자료를 전부 받아와서 html 파일을 생성하여 이 html파일을 동적으로 제어할 수 있는 소스코드(JS)와 함께 클라이언트에게 보낸다. 클라이언트 상에서는 잘 만들어진 html 파일을 받아와서 화면을 볼 수 있다.
장점
1. CSR에서 보다 빠른 페이지 로딩.
2. 모든 컨텐츠가 html에 담겨져 있어 좀 더 효율적인 SEO 가능.
그렇다면 이런 장점만 있는가? 동작원리를 살펴보자.
동작원리
1. 사이트에 접속
2. 이미 서버에서 잘 만들어진 index.html을 받아옴
3. 사용자에게 화면이 보여지지만(TTV) 동적으로 제어할 수 있는 JS파일은 아직 받아오지 않았으므로 클릭 시 동작하지 않는다.
4. 서버로부터 JS 파일을 받아와야지만 사용자의 클릭을 처리하는 인터랙션이 가능해진다.(TTI)
=> SSR은 사용자가 화면을 볼 수 있는 TTV 시간과, 실제로 사이트를 사용할 수 있는 TTI 시간 사이에 공백기간이 긴 편이다.
단점
1. 클릭 시 전체적인 웹사이트를 서버에서 받아오는 것과 동일하기 때문에 깜빡임 현상 남아있어서 좋지 않은 UX를 경험할 수 있다.
2. 서버에 과부하가 걸리기 쉽다.
사용자가 클릭 할 때마다 서버에 요청해서 전체 데이터를 가져와 html을 만들어야 하기 때문에 사용자가 많은 제품일수록 서버에 과부하가 걸릴 가능성이 커진다.
3. 빠르게 웹사이트를 보여줄 수는 있지만 동적으로 데이터를 처리하는 JavaScript 파일은 다운로드 받지 못해서 클릭 시 반응이 없을 수 있다.
고민점
TTV와 TTI 사이의 시간차를 줄이기 위해서 어떻게 수정할 수 있을지
SSG (Static Site Generation)
리액트는 CSR에 특화된 라이브러리지만 Gatsby라는 라이브러리를 사용하면 리액트로 만든 어플리케이션을 정적인 페이지로 생성하여 서버에 배포해둘 수가 있다. (정적인 페이지만 가능한 것은 아니고 JS 파일을 함께 둘 수 있어 동적인 요소도 추가 가능하다.)
Next.JS
리액트와 자주 함께 쓰이는 라이브러리로 SSR 지원 뿐만 아니라 SSG와 CSR, SSR을 적절하게 조합하여 목적에 맞게 사용 가능하도록 지원하고 있다.
