그림으로 보는 CSR, SSR, SSG with Next.js

잘못된 내용이 있다면 댓글로 달아주세요!

CSR (Client Side Rendering)

클라이언트 쪽에서 페이지 렌더링

렌더링 과정

1. 클라이언트는 FE 서버에게 페이지를 구성하는데 필요한 리소스를 요청합니다.
2. FE 서버는 빈 HTML 파일을 응답으로 보내줍니다. 이 HTML 파일을 파싱하는 과정에서 <link> 태그를 마주치면 CSS 파일을, <script> 태그를 마주치면 JS 파일을 요청하여 FE 서버에게 받습니다.
3. 클라이언트 쪽에서 페이지를 렌더링하는 동안 필요한 데이터가 있다면 BE Server에게 요청합니다.
4. BE Server는 DB에 있는 데이터로 응답합니다.
5. 응답 온 데이터로 페이지를 렌더링합니다.

장점

• 첫 페이지를 로드한 이후, 구동 속도는 빠릅니다.
  • 변경하는 부분에 필요한 리소스만 서버에게 요청하여 페이지의 일부만 리렌더링하기 때문에 구동 속도는 빠릅니다.
• 서버 쪽에서 페이지를 렌더링 할 필요가 없으므로 부하가 적어집니다.
• 동적으로 DOM을 만들기 때문에 Time To View와 Time To Interact 사이의 간극이 없습니다.

단점

• 성능: JS 파일 크기가 커질수록 다운로드 시간이 길어지므로 사용자가 빈 화면을 오랫동안 보게 됩니다.
  • 기본적으로 JS 파일은 모든 페이지에 대한 코드가 들어있습니다. 즉, JS 파일에는 현재 페이지에 필요하지 않은 코드들이 포함되어 있습니다.
  • 현재 사용할 코드들만 JS 파일에 포함하는 코드 스플리팅을 적용하여 JS 크기를 줄일 수 있습니다.
• SEO 친화적 x: 검색 엔진 크롤러가 빈 HTML에서 얻을 수 있는 정보가 없기 때문에 SEO에 친화적이지 않습니다.
  • JS를 실행하는 크롤러가 등장하고 있지만 완벽하지 않고, 아직 JS를 실행하는 크롤러들이 있습니다.
• 보안: 클라이언트에서 모든 코드를 실행하기 때문에, 중요한 로직이나 key 값이 노출될 수 있습니다.

SSR (Server Side Rendering)

렌더링 과정

서버 쪽에서 페이지 렌더링

1. 클라이언트는 FE 서버에게 리소스를 요청합니다.
2. FE 서버는 BE 서버에게 데이터를 요청합니다.
3. BE 서버는 DB에 있는 데이터로 응답합니다.
4. 응답 온 데이터로 페이지를 렌더링합니다.
5. 렌더링 된 HTML과 CSS, JS를 클라이언트에게 보냅니다.
6. 클라이언트는 DOM과 interaction 할 수 있도록 hydration 과정을 수행합니다.

hydration

여기서 hydration이란 서버에서 렌더링된 HTML을 클라이언트에서 JS와 결합하여 상호작용할 수 있도록 하는 과정입니다. 서버에서 렌더링 된 HTML에 핸들러나 이벤트를 붙여 클라이언트와 상호작용할 수 있는 완전한 웹 페이지를 만들어냅니다.

장점

• 보통 최초 페이지 진입이 빠릅니다.
  • 모든 경우 SSR이 CSR보다 최초 페이지 진입이 빠르다고 볼 수 없지만, HTML이 HTTP 요청에 의존적이거나 렌더링 해야 할 HTML 파일이 커질 경우 상대적으로 빠를 수 있습니다.
• SEO 최적화: 서버에서 이미 컨텐츠가 담긴 HTML을 보내주어 이를 보고 검색 엔진 크롤러는 정보를 수집합니다.
• 보안: 토큰, key와 같은 민감한 정보는 서버에서 관리하여, 클라이언트에 노출할 위험이 줄어듭니다.

단점

• 서버가 HTML을 렌더링해야 하기 때문에 서버 부하가 증가됩니다.
• hydration 과정으로 인해 Time To View와 Time To Interact 사이의 간극이 있습니다.
• SSR가 지연된다면, 렌더링이 끝나기 전까지 사용자는 빈 화면을 보게 됩니다.

How to Set In Next.js

page router에서 getServerSideProps를 async 함수로 export하면 SSR로 페이지가 렌더링 됩니다.

SSG (Static Site Generators)

렌더링 과정

next.js 공식 문서 - SSG

build할 때 서버에서 미리 페이지를 렌더링

SSG 방식은 build time 때 미리 페이지를 렌더링합니다. SSG 렌더링 과정을 build time과 client request time으로 나눠보겠습니다.

At build time

아래 과정은 build time 때 일어납니다.

1. FE 서버는 BE 서버에게 데이터를 요청합니다.
2. BE 서버는 DB에 있는 데이터로 응답합니다.
3. FE 서버는 응답 온 데이터로 페이지를 렌더링합니다.

At client request time

아래 과정은 client가 요청할 때 일어납니다.

1. Client가 페이지를 요청합니다.
2. Client는 At build time의 3번 과정에서 렌더링 된 페이지를 받습니다.

At build time에서 렌더링 된 페이지가 CDN에 캐시될 수 있습니다.

How to Set In Next.js

page router에서 SSG를 설정하는 방법은 공식문서에 자세히 나와있는데요.

SSG를 이용하여 외부 데이터를 받아올 경우 getStaticProps를 사용해줍니다. build time 때 서버에서 딱 한 번 실행합니다.

만약 동적 라우터를 사용해서(pages/posts/[id].js) 데이터를 불러와야 하는 경우라면, getStaticPaths를 사용해서 미리 렌더링해야하는 path를 명시해줍니다.