1. Client-Side-Rendering (CSR)
빈 화면을 사용자의 브라우저에서 JavaScript가 직접 그리는 방식
사용자가 페이지를 요청할 때, 먼저 서버가 비어있는 HTML을 브라우저 전달하고 사용자에게 보여준다. 그 뒤에 서버에서 JS Bundle을 브라우저에 전달하고 실행해서 화면에 그려준다.
대표적인 장점은 빠른 페이지 전환 가능, 서버 부하 감소가 있다.
반면 단점은 받아오는 데이터량이 많을 경우에는 초기 로딩 시간(First Contentful Paint)이 오래 걸린다.
2. Server-Side Rendering (SSR)
사용자가 웹페이지를 요청하면 서버가 미리 HTML을 완전히 구성해 브라우저로 전달하고, 브라우저는 이를 바로 표시하는 렌더링 방식.
자세히 설명하자면, 사용자가 접속 요청을 보내면 서버가 HTML을 사전 렌더링을 진행하여 즉각적으로 브라우저로 전달한다. 하지만, 이 것은 이벤트와 같은 상호작용이 없는 상태이다. 그러므로 서버는 JS 번들을 브라우저에 전달하고 HTML에 Hydration을 통해 클라이언트에서 인터렉션한다.
장점은 앞서 설명했던 CSR의 단점인 초기 로딩 시간(First Contentful Paint)을 효과적으로 줄일 수 있다.
단점은 수많은 데이터를 불러올 때는 시간이 오래 걸린다는 것이다.
3. Static Site Generation (SSG)
서버(또는 빌드 서버)가 빌드 시점에 미리 HTML을 만들어 놓고,
사용자 요청 시 서버는 정적 파일 그대로 전달하는 렌더링 방식.
사용자 요청 전에 빌드 도구(Next.js, Nuxt 등)가 데이터를 미리 가져와 페이지별 HTML을 미리 생성 함(빌드 타임) 그 뒤에 사용자 요청 시, 미리 만든 HTML을 제공하고 SSR과 동일하게 JS번들등을 브라우저에 제공하여 HTML에 Hydration을 통해 클라이언트에서 인터렉션한다.
장점은 빌드 타임을 통해 미리 대량의 데이터를 받기 때문에 서버로 대량의 데이터를 받아와도 로딩 시간이 오래 걸리지 않는다.
단점은 아무리 데이터가 새롭게 업데이트해도 최신버전으로 반영이 안된다는 것이다.
4. Incremental Static Regeneration (ISR)
SSG의 확장 개념으로 SSG처럼 빌드 타임에 HTML을 미리 생성 특정 주기에 따라 요청 시, 서버에서 다시 HTML을 재생성해 점진적으로 업데이트를 하는 방식
초기에는 SSG와 동일하게 정적 HTML로 먼저 빌드한다. 그 다음 사용자가 페이지를 접속하면 기존에 캐싱된 HTML을 그대로 응답한다. 그러나 만약 재생성 주기(revalidate)를 초과한 이후에 접속을 했다면 백그라운드에서 새 HTML을 저장하고, 다음 요청부터는 새로 제공된 HTML을 제공한다.
장점은 SSG처럼 빠르게 대량의 데이터를 받을 수 있으면서도, SSG의 단점인 최신 버전으로 반영되지 않는 점을 보완할 수 있다.
반면 단점은 설정한 주기에 따라서 업데이트가 되기 때문에 게시글 등록과 같은 즉각적인 데이터 반영이 필요한 페이지에서는 적합하지 않는다.
