# rendering

> 아래 소개들은 정적 페이지가 아닌 서버로부터 데이터를 패칭하는 페이지를 기준으로 작성되었습니다.

## SSR(Server Side Rendering)

ex) php, jsp, asp

### Flow

* 사용자가 웹 페이지에 방문한다(request)
* `request`를 받은 서버는 해당 페이지에 필요한 데이터를 패칭 하기위해 REST API 엔드포인트에 다시 `request`를 보낸다.
* 엔드포인트에서 `response`가 오면, 서버는 `html` 파일에 응답받은 데이터 정보를 포함해서 사용자에게 `response` 해준다.
* 사용자가 페이지를 이동할 경우 위 동작을 반복한다.

### SSR의 장점

#### SEO에 친화적이다

* 서버가 데이터를 다 그려서 응답해주기 때문에 검색 엔진이 웹 페이지 정보를 잘 수집해갈 수 있습니다.

#### CSR에 비해 클라이언트에 부담이 덜하다

* 런타임에 `JavaScript`를 이용해 콘텐츠를 그리는 `CSR`과 달리 `SSR`은 서버가 콘텐츠를 그려서 응답 해주기 때문에 기기 성능에 크게 영향을 받지않고 웹 페이지를 제공할 수 있습니다.

### SSR의 단점

#### 라우팅 시 TTFB(Time to First Byte)가 느리다

* 서버가 데이터를 패칭하고 해당 데이터를 기반으로 `html` 파일을 생성해서 사용자에게 응답 해주기 때문에 다른 렌더링 방식들보다 TTFB가 느립니다.

#### 서버 호스팅이 필요하다

* 클라이언트에서 `javaScript`를 이용해 렌더링하는 `CSR`와 미리 빌드 타임에 정적인 html파일을 생성한 뒤 응답해주는 `Static Rendering`에 비해 `SSR`은 서버 사이드에서 `html`파일 안 내용을 생성하기 때문에 서버 호스팅이 필요합니다.

## Client Side Rendering

ex) react, vue, angular

### Flow

* 사용자가 웹 페이지에 방문한다(request)
* `script`, `meta`, `link`등의 태그를 포함하고 있는 빈 콘텐츠의 `index.html`을 `response`한다.
* 브라우저가 `index.html`에 있는 `javaScript` 번들 파일을 패칭한 뒤 파싱하고 실행해서 콘텐츠를 렌더링한다.
* 해당 페이지에 필요한 데이터를 패칭 하기위해 REST API/gql 엔드포인트에 `request`를 보낸다.
* 엔드포인트에서 `response`가 오면, 해당 데이터를 기반으로 콘텐츠를 브라우저에 렌더링한다.
* 사용자가 페이지를 이동할 경우 서버에 추가족안 `html`파일 요청 없이 이미 받은 `javaScript`를 이용해 렌더링합니다.

### CSR의 장점

#### 페이지 간의 이동 속도(반응성)가 빠르다

* 라우팅시 api를 제외하고 추가적인 서버 요청 없이 클라이언트단에서 `javaScript`로 렌더링하기 때문에 `SSR`에 비해 라우팅 속도(반응성)가 빠릅니다.

### 별도의 웹용 서버가 필요 없다

* 클라이언트단에서 라우팅을 처리하기 때문에 s3와 같은 스토리지에 빌드된 파일만 올려놓으면 별도의 서버 호스팅 없이 웹 사이트를 사용자에게 제공 가능합니다.

### CSR의 단점

#### 초기 로딩이 느리다

* `javaScript`로 웹 페이지를 렌더링하기 때문에 콘텐츠를 표시 해주기위해선 html을 다 불러온 뒤 추가적으로 `javaScript`를 이용해 콘텐츠를 렌더링하는 작업이 필요합니다.

#### SEO에 친화적이지 않다

* 크롤러가 요청을 보냈을 때 빈 콘텐츠의 `html` 파일을 응답 해준 뒤 클라이언트에서 `javaScript`를 이용해 웹 페이지를 렌더링하기 때문에 구글을 제외한 나머지 검색 엔진들은 빈 페이지로 인식하게 됩니다.

#### 사용자의 기기 성능에 영향 받는다

* 클라이언트에서 `javaScript`를 이용해 웹 페이지를 렌더링하기 때문에 저 성능 기기의 경우 초기 로딩 시 성능 이슈가 있을 수 있습니다.

## Universal Rendering

ex) Next.js, Nuxt.js, Angular Universal

### Flow

* 사용자가 웹 페이지에 방문한다(request)
* `request`를 받은 서버는 해당 페이지에 필요한 데이터를 패칭 하기위해 REST API/GraphQL 엔드포인트에 다시 `request`를 보낸다.
* 엔드포인트에서 `response`가 오면, 서버는 `html` 파일에 응답받은 데이터 정보를 포함해서 사용자에게 `response` 해준다.
* 이 상태에서 초기 콘텐츠들은 다 렌더링 되었지만 아직 `javaScript` 번들이 패칭중이기 때문에 인터렉션이 불가능합니다.(Dehydrate 상태)
* `javaScript` 번들이 다 파싱되면 hydration을 진행하고 그 이후 부터는`CSR`와 동일하게 동작합니다.

### Universal Rendering의 장점

* 초기 로딩시에는 `ssr`처럼 작동하고, 그 이후에는 `csr`처럼 작동해서 `ssr`과 `csr` 장단점을 보안할 수 있습니다.

### Universal Rendering의 단점

* Universal Rendering을 직접 구현하기보다는 프레임워크를 사용해야하는 경우가 많으므로, 해당 프레임워크에 대한 러닝커브가 있습니다.
* 서버 호스팅이 필요 없는 `Static Rendering`, `Client Side Rendering`과 달리 `Server Side Rendering`과 같이 별도의 서버 호스팅이 필요합니다

## Static Rendering

ex) Gatsby, Next.js, Hugo, Jekyll

### Flow

* 빌드 타임에 REST API/GraphQL 엔드포인트에 `request`를 보내서 데이터를 받아온 뒤 `html`파일로 프리렌더링 해놓는다.
* 사용자가 웹 페이지에 방문한다(request)
* 미리 만들어 놓은 `html`파일을 제공해준다.

### Static Rendering의 장점

* 빌드 타임에 프리렌더링 해놓기 때문에 페이지 로딩/응답 속도가 빠르다.

### Static Rendering의 단점

* 빌드 타임에 프리렌더링 해놓기 때문에 빌드 타임 이후에 진행되는 데이터 변경을 페이지에 반영하지 못합니다(프리렌더링 시 api을 호출 할 때 기준)

### Reference

* <https://dev.to/kefranabg/demystifying-ssr-csr-universal-and-static-rendering-with-animations-m7d>
* <https://developers.google.com/web/updates/2019/02/rendering-on-the-web>
