SSR 서버사이드 렌더링

---

~1990년 중반 : static sites

서버에 만들어진 html 파일들이 올라가있고, 홈페이지에 접속하면 서버에 이미 배포되어져 있는 html 문서를 받아와서 보여주는 형식.

페이지 내 다른 링크를 클릭하면 다시 서버에서 해당 페이지의 html을 받아오기 때문에 페이지 전체가 업데이트 된다.

1996 : iframe

문서내에서 또 다른 문서를 담을 수 있는 iframe 태그가 도입되었다. 페이지 내에서 부분적으로 문서를 받아와서 업데이트를 할 수가 있게 되었다. 지금도 간혹 쓰이고 있다.

1998 ~ : XMLHttpRequest (fetch API)

이제는 html 문서 전체가 아니라 json과 같은 포맷으로 서버에서 가볍게 필요한 데이터만 받아 올 수 있게 되었다. 그 데이터를 JS를 이용하여 동적으로 html 요소를 생성하여 페이지에 업데이트하는 방식.

2005 : AJAX

이러한 기능들이 공식적으로 AJAX라는 이름을 가지게 되었다.

(구글의 gmail, google map 등 웹 어플리케이션)

이것이 현재 많이 쓰이는 SPA (Single Page Application) 이다.

사용자가 한 페이지 내에 머무르면서 필요한 데이터를 서버에서 받아와 부분적으로만 업데이트하는 방식.

---

CSR (Client Side Rendering)

간단하게 설명하면 클라이언트측에서 다해먹는걸 이야기한다. 서버에서 인덱스라는 html 파일을 클라이언트에 보내주고, 그 html파일 내의 body 안에는 id="root"만 달랑 하나 들어가있고, 어플리케이션에서 필요한 자바스크립트의 링크만 들어가있다.

따라서 처음 사이트에 접속하면 빈 화면만 보이고, 링크된 어플리케이션 자바스크립트를 서버로부터 다운로드 받게 되는데, 여기 자바스크립트 파일 내에는 어플리케이션에서 필요한 로직들 뿐만 아니라 어플리케이션을 구동하는 프레임워크와 라이브러리의 소스코드들이 다 포함되어있다.

따라서 사이즈가 커서 다운로드 받는데에 시간이 소요될수 있다.

단점

1. 사용자가 첫 화면을 보는데 오래걸린다.
2. 좋지않은 SEO (Search Engine Optimization)
3. ⇒ 검색엔진 사이트등에서 자료를 찾을 때 html내의 내용을 바탕으로 검색 결과에 넣거나 하는데, 이는 html문서가 비어있기 때문에 검색엔진들이 CSR로 작성된 웹페이지를 분석하는데 어려움을 겪고 있다.

SSR (Server Side Rendering)

CSR과 다르게, 서버에서 필요한 데이터를 모두 가져와서 html 파일을 만들어두고, 이렇게 만들어진 html 파일을 동적으로 조금 제어할 수 있는 소스코드와 함께 클라이언트에게 보내준다.

그러면 클라이언트측에서는 잘 만들어진 html문서를 받아와 바로 사용자에게 보여줄 수 있게 되는 것이다.

장점

1. CSR에 비해 첫번째 페이지로딩이 빨라진다.
2. 모든 컨텐츠가 html에 담겨져있기 때문에 효율적인 SEO를 할 수 있다.

단점

1. Static Sites에서 발생했던 깜빡임 이슈
2. ⇒ 사용자가 페이지내에서 이동하면 전체적인 웹사이트를 다시 서버에서 받아 오는것과 동일하기 때문에 좋지않은 User experience를 겪을 수 있다.
3. 서버에 과부하가 걸리기 쉽다.
4. ⇒ 사용자가 많을수록, 사용자가 클릭을 할때마다 서버에 요청해서 서버에서 필요한 데이터를 가지고와서 html을 만들어야하므로 과부하가 걸리기 쉽다.
5. Need to wait before interacting
6. ⇒ 사용자가 빠르게 웹사이트를 확인할 수는 있지만 동적으로 데이터를 처리하는 자바스크립트를 아직 다운받지 못하여 여기저기 클릭했는데 반응이 없는 경우가 발생할 수 있다.

TTV (Time To View) / TTI (Time To Interact)

CSR은 빈 html에서 자료가 담긴 JS파일을 다운로드받아야 하기 때문에 사용자가 웹사이트를 볼 수 있음(TTV)과 동시에 클릭을 하거나 인터랙션이 가능(TTI)하게 된다.

반대로 SSR 은 사용자가 금방 웹사이트를 볼 수있지만(TTV) 인터랙션이 가능한 시간(TTI)과는 꽤 차이가 난다.

⇒ 따라서, CSR 에서는 첫번째로 사용자가 보기위해서 필요한 정말 필수적인 아이만 보낼 수 있을지 고민해보면 좋을 것이고, SSR 에서는 웹사이트가 보이는 시간과 인터랙션이 가능한 시간차를 어떻게하면 줄일 수 있을 지 고민해보면 좋을 것이다.

SSG (Static Site Generation)

React는 대표적인 CSR이지만, Gatsby라는 라이브러리와 함께 사용하면 React로 만든 웹어플리케이션을 정적으로 웹페이지를 생성해두어서 서버에 배포해놓을 수가 있다. 하지만 정적이기만 한게 아니라 JS를 통해서 동적으로도 이용 가능하다.

Next.js
리액트에서 많이 사용되는게 Next.js인데, Next.js는 강력한 SSR을 지원하는 라이브러리였는데 최근에는 CSR도 지원하고 CSR과 SSR을 잘 섞어서 조금 더 유연하게 우리의 목적에 맞게 사용할 수 있도록 지원해주고 있다.