렌더링 방식들(CSR, SSR , SSG , ISR)
CSR(Client Side Rendering)
유저와의 티키타가가 잦은 경우 적합하다
csr은 유저가 접속했을떄 로딩 과정을 거쳐 데이터를 불러온후 페이지를 보여주기 때문에 초기로딩속도는 느릴 수 있지만
렌더링 후에는 js 사용이 가능한 동적 html 을 생성해 보여주기 때문에 부드러운 사용자 경험을 제공할 수 있다
하지만 번들사이즈가 커지면 로딩속도가 현저히 느려질 수 있고 미리 html 을 만드는것이아니고 요청이 들어온 다음 html을 생성하는 방식이기 때문에
SEO 대응이 어렵다
CSR 확인할부분
- 검색엔진에 노출되지 않아도되는 페이지인가?
- 유저와의 인터렉션이 잦은가?
- 화면 업데이트/렌더링이 잦은가?
- 초기 로딩이 조금 느리더라도 부드러운 사용자 경험이 중요한가?
SSR(Server Side Rendering)
비교적 인터렉션이 적고 데이터가 요청마다 한 번만 처리되어도 충분한 경우에 적합하다
ssr은 유저가 접속했을때 서버에서 필요한 데이터를 모두 가져와서 html 파일을 만들고 화면에 띄우기 때문에 SEO에 좋다
하지만 서버에서 정적 html 을 생성하기 떄문에 js를 다운받아야 해서 렌더링과 동시에 인터렉션할 순 없고
서버로부터 문서를 받아오기 때문에 상대적으로 과부하에 걸리기 쉽다
SSR 확인할부분
- 검색엔진 노출이 필요한 페이지인가?
- 사용자의 요청에 따라 고정되지 않은 데이터를 불러와야하는가?(= 화면 구성에 유저마다 다른 데이터 패치가 필요한가)
- 렌더링 후 사용자와의 즉각 인터렉션보다 화면 구성을 보여주는 것이 우선되는가?
- 너무 잦은 인터렉션은 없는가?
SSG(Static Site Generation)
고정된 데이터를 사용하는 페이지에 적합하다
build 시 고정된 데이터들을 모두 담은 정적 html 파일을 생성하여 재활용한다
CSR & SSR과 비교했을 때 렌딩 속도도 빠르고,
굳이 업데이트가 잦지 않은 페이지에 대해서 불필요한 통신과 리렌더링을 줄여준다
SSG 확인할부분
- 업데이트가 없거나 현저히 적은가?
ISR(Incremental Static Regeneration)
revalidate가 필요한 SSG 페이지에 적합하다
SSG는 정적 페이지를 생성하여 보여주는 데이터의 변화가 적거나 없는 페이지에 적합한 방식이다
ISR은 revalidate 옵션으로 설정한 시간이 지나면 자동으로 re-build하고 데이터를 업데이트한다
ISR 확인할부분
- 페이지의 방문자의 수요에 맞추어 업데이트가 필요한가?
- revalidate에서 업데이트 되는 데이터의 양이 너무 많지는 않은가?