서버 렌더링

Next.js 공식 사이트에서 말하는 서버 렌더링의 장점은 아래와 같다.

 

1. 데이터 페칭 속도: 서버에서 데이터를 요청하기 때문에 클라이언트에서 해야 하는 요청이 줄어들어 시간이 절약된다.

2. 보안: 토큰이나 API 키 같은 정보를 클라이언트에 노출시키지 않고 사용할 수 있다.

3. 캐싱: 서버에서 렌더링된 결과를 캐싱하기 때문에, 유저에게서 요청이 올 때마다 매번 렌더링하지 않아도 된다.

4. 성능: 필요한 자바스크립트 코드의 양을 줄여서 클라이언트 경험에 도움이 된다. 특히 느린 인터넷, 오래된 기기 등에서 효과적이다.

5. 초기 페이지 로딩 및 FCP: 서버에서 미리 렌더링해서 보내주기 때문에 클라이언트가 자바스크립트를 다운로드하고, 파싱하고, 실행할 때까지 기다릴 필요가 없기 때문에 초기 페이지 로딩 및 FCP가 빠르다.

6. SEO: HTML이 미리 만들어져 있기 때문에 검색 엔진 봇이 인덱싱해가기 쉽다.

7. Streaming: Streaming을 사용하면 완성된 전체 페이지를 보여주는 대신, 렌더링 작업을 여러 개로 나눠서 준비되는 것부터 보여줄 수 있다.

 

Next.js의 컴포넌트는 기본적으로 모두 서버 컴포넌트이다. Next.js에서의 서버 컴포넌트 렌더링은 React와 다르지 않은데, 대략 아래와 같은 과정으로 이루어진다.

서버 측:

1. 서버 컴포넌트를 RSC Payload(React Server Component Payload)라는 특별한 형태로 변환한다.

2. 초기 페이지 HTML을 렌더링하기 위해서 서버 컴포넌트의 RSC Payload와 클라이언트 컴포넌트 자바스크립트를 사용한다.

클라이언트 측:

1. 상호작용 불가능한 HTML을 먼저 보여줘서 초기 페이지 로딩을 빠르게 한다.

2. RSC Payload를 사용해서 서버 컴포넌트와 클라이언트 컴포넌트의 관계를 맺어 주고, DOM을 업데이트한다.

3. Javascript를 사용해서 클라이언트 컴포넌트에 hydrate를 해 주어 상호작용이 가능하게 해 준다.

 

Next.js의 서버 렌더링 방식은 세 가지가 있다.

1. Static Rendering

기본값이며, 빌드 타임 혹은 data revalidation 후에 렌더링되고 이를 재사용한다. 개인정보 등이 아니라 누구나 같은 페이지를 보여주어야 할 때 빠르고 유용하다. 결과는 캐시되며 CDN에 넣을 수도 있다. 추후 ISR(Incremental Static Regeneration)을 통해 데이터가 업데이트될 수 있다.

2. Dynamic Rendering

클라이언트가 요청할 때마다 렌더링된다. Dynamic API나 { cache: 'no-store' } 옵션과 함께 fetch를 사용하면 자동으로 Dynamic Rendering으로 바뀐다. Dynamic API에는 connection, draftMode, searchParams, unstable_noCache 등이 있다. Dynamic Rendering이라고 해서 캐싱되지 않는다는 뜻은 아니며, 선택할 수 있다. 보통은 Static Rendering을 사용할 것이냐, Dynamic Rendering을 사용할 것이냐를 개발자가 고민하고 결정할 필요는 없으며 필요에 따라 개발하다보면 Next.js가 알아서 결정해줄 것이다.

3. Streaming

전체 완성된 페이지를 보여주는 것이 아니라 조각조각 잘라 완성되는 대로 클라이언트에게 보여준다. 여러 컴포넌트 중 느린 network call을 하는 컴포넌트가 있다면, 다른 컴포넌트들은 이 느린 컴포넌트와 관계 없이 먼저 보여줌으로써 유저에게 빠르다는 느낌을 줄 수 있다.  app router에서 loading.js와 React Suspence를 사용하면 적용된다. 

 

Static은 속도가 빠르나 개인화된 데이터를 보여주는 데 사용할 수 없고, Dynamic은 속도가 느리나 개인화된 데이터를 보여주는 데 사용할 수 있다. Streaming은 Dynamic Rendering을 써야 하는데 점진적인 렌더링을 적용함으로써 느린 속도를 보완한 것으로 보인다.