렌더링 방식(CSR, SSG, ISR, SSR)과 Next.js의 Hybrid Web App

* 렌더링 방식

 

1) CSR(Client Side Rendering)
리액트만으로 만들면 발생
렌더링하는 주체자가 클라이언트(브라우저)

- 장점) 한번만 로딩되면, 빠른 UX 제공
           부분적으로 가져오니까 서버의 부하가 적음
- 단점) 페이지 로딩시간(TTV)이 길다(소스코드까지 다 다운-> FCP까지 오래걸림)
           js 활성화 필수
           SEO 최적화가 힘들다(크롤러들이 로드해서 확인하는게 아닌 이상은 빈페이지만 보여져서 확인하기 어려움)
           보안에 취약함(클라이언트에 모든 코드와 키를 다운 받아야함)
           CDN에 캐쉬가 안됨

=> 단점 해결 : SSG, SSR



2) SSG(Static Site Generation)
CSR의 문제로 인해 "옛날처럼 정적으로 배포하는게 어떨까?" 해서 나온 방법
렌더링하는 주체자가 서버, "언제 렌더링하냐"에 따라 SSG, SSR로 나뉘는 것
-> 배포해서 빌드할때 처음 렌더링

빌드할때 렌더링됨(ex. react코드를 html으로 변환)
사전에 미리 만들어두고 클라이언트에서 접속하면 html 보내줌 -> 다음 요청부터는 서버까지 가지 않아도 cdn에 캐시된 html파일을 빠르게 가져올 수 있음.

- 장점) 페이지 로딩시간(TTV)이 짧음(서버에서 미리 만들어둔 파일만 가져오면 되니까)
           js 필요 없음
           SEO 최적화가 좋음(웹 크롤러가 효율적으로 확인하고 인덱스 가능)
           보안이 뛰어남
           CDN에 캐쉬 됨
- 단점) 데이터가 정적임 -> 데이터가 가변적인 웹사이트라면 안좋음
사용자별 정보 제공의 어려움(모든 사용자들에게 동일 데이터를 주므로 사용자가 만명이라면 ..사용자별로 데이터 줄 것임? x)


=> 단점 해결 : ISR, SSR


3) ISR(Incremental Static Regeneration)
주기적으로 다시 만드는 방식
렌더링하는 주체자가 서버, 주기적으로 렌더링
-> 설정한 주기만큼 계속해서 다시 만들어줌

SSG와 동일한 원리이지만, 정해진 주기에 따라 페이지를 다시 렌더링하여 생성함

- 장점) 페이지 로딩시간(TTV)이 짧음(서버에서 미리 만들어둔 파일만 가져오면 되니까)
           js 필요 없음
           SEO 최적화가 좋음(웹 크롤러가 효율적으로 확인하고 인덱스 가능)
           보안이 뛰어남
           CDN에 캐쉬 됨
           데이터가 주기적으로 업데이트 됨
- 단점) 주기적이긴 하지만 여전히 실시간 데이터는 아님
           사용자별 정보 제공의 어려움


=> 단점 해결 : SSR



4) SSR(Server Side Rendering)
렌더링하는 주체자가 서버, 요청시 렌더링
클라이언트가 요청할때 새롭게 만들어 줌

- 장점) 페이지 로딩시간(TTV)이 짧음(서버에서 미리 만들어둔 파일만 가져오면 되니까)
           js 필요 없음
           SEO 최적화가 좋음(웹 크롤러가 효율적으로 확인하고 인덱스 가능)
           보안이 뛰어남
           실시간 데이터를 사용
           사용자별 필요한 데이터를 사용
- 단점) 비교적 느릴 수 있음
           서버에 과부하가 걸릴 수 있음(사용자별로 데이터 받아와서 페이지 만드니까, 오버헤드)
           CDN에 캐쉬 안됨(요청할때마다 다시 만드니까)

 

 

---

* Hybrid Web App

한 어플리케이션 내에서도 각기 다른 렌더링 방식을 혼합해서 웹앱을 만들 수 있음
심지어 한 페이지 내에서도, 페이지 부분별로 섞어서 만들 수 있음

=> 각각 렌더링 방식별로 특징/장단점이 다르므로, 페이지 별 특징에 따라서 데이터가 얼마만큼 바뀌는지 어떤데이터인지에 따라 성능 높이기 위해 선택



* Hydration
넥스트에서 사용하는 하이브리드를 가능하게 하는 Hydration

1. 클라이언트에서 서버에 요청 보냄
2. 넥스트는 필요한 것들을 받아와서 페이지를 구성, 여기서의 페이지는 정적인 html페이지(사용자에게 의미있는 데이터를 먼저 보여주기 위해 ui보여줌: pre-rendering)
3. 사용자에게 페이지를 보여주기 위해 서버에서는 정적인 html 먼저 클라이언트에 보내줌.
(사용자는 클릭을 해도 이걸 처리할 코드가 없음, 아무 반응이 일어나지 않음)
4. 그 이후에 페이지에서 interaction처리를 위해 필요한 react 코드와 js 코드를 클라이언트에 보내줌
5. 클라이언트에서 이 소스코드와 라이브러리들을 다 다운받은 이후에는 Hydration을 해줌.(리액트로 페이지를 가득 채움, 컴포넌트 렌더링을 해서 정적인 html페이지 대신에 실제 컴포넌트 쓸 수 있게 해준다는 뜻.)
6. 이제부터는 실제 리액트의 컴포넌트이기 때문에, 사용자가 클릭하면 내부로직이 실행되며 요청이 처리됨

+ 예전 버전 넥스트 페이지를 보면 웹페이지를 보다가 순간 깜빡임이 발생하는 경우가 있음.
이 깜빡임이 정적인 html페이지를 실제 리액트 컴포넌트로 대체