[Next.js] 렌더링 동작 원리 with Hydration, use client

 

Next.JS는 CSR인 React를 SSR 방식으로 구현할 수 있도록 도와주는 프레임워크이다.

 

01. CSR과 SSR

#1. CSR

모든 렌더링이 클라이언트에서 발생한다.

초기 HTML은 거의 비어있고, 브라우저는 JavaScript를 로드하여 UI를 빌드한다.

자바스크립트를 비활성화하면 UI가 렌더되지 않는다.

 

#2. SSR

Next.JS는 기본적으로 SSR 방식을 사용한다.

모든 페이지와 컴포넌트가 서버에서 먼저 렌더링되고, 그 결과가 HTML로 변환되어 브라우저에서 전송된다.

이렇게 전송된 HTML은 정적이므로 자바스크립트를 활성화하지 않아도 UI가 보인다.

페이지를 이동할 때마다 서버에서 새 HTML을 받아오고, 브라우저에서 UI를 즉시 표시한다.

출처 : https://velog.io/@doeunnkimm_/Next.js%EC%9D%98-Hydration

1. 서버는 렌더링을 끝마친 HTML파일을 응답으로 보내며, 클라이언트는 이를 받아 바로 표시
2. 클라이언트는 렌더된 페이지를 보여주고, JS를 다운로드
3. 브라우저(클라이언트)는 리액트 컴포넌트를 실행
4. 웹페이지는 인터랙티브하게 됨

 

Next.js에서 SSR 렌더링 과정을 정리하면 다음과 같다.

서버가 전송한 HTML을 브라우저가 받아 화면에 바로 렌더링한다. 이 시점에 JS 파일이 아직 로드되지 않았더라도 페이지 콘텐츠를 볼 수 있다. JS 파일이 로드되면, 브라우저는 페이지의 상호작용 기능을 활성화 할 수 있다. JS가 실행되기 전에는 단순히 콘텐츠만 볼 수 있을 뿐, 사용자가 페이지를 조작할 수 없다. JS 파일이 다운로드되고 실행되면, 브라우저는 사용자 조작을 기억하고 있다가 그 조작을 실행한다. 이로써 웹 페이지가 완전히 상호작용 가능한 상태가 된다.

=> SSR은 서버에서 렌더링 된 HTML을 전송함으로써 사용자는 처음부터 빈 화면을 보지 않는다. JS가 로드되기 전에도 콘텐츠를 볼 수 있지만, 상호작용은 JS가 로드되고 나서 실행된다.

 

브라우저와 SSR 렌더링의 차이
브라우저의 렌더링 : HTML, CSS, JS 파일을 받아 파싱하고, 화면에 그려내는 과정을 의미
SSR에서의 렌더링 : 서버에서 클라이언트로 전송된 HTML 파일 내 콘텐츠가 미리 포함되어 있으면, 그것을 렌더링 완료로 간주. 즉, React 컴포넌트에서 작성된 JavaScript 함수를 브라우저가 이해할 수 있는 HTML로 변환하는 과정

 

 

 

#3. SSR과 CRS 차이 및 비교

◼︎ 웹 페이지 로딩 시간

1) 첫 페이지 로딩 시간

• CSR : HTML, CSS, 모든 자바스크립트 파일을 한 번에 받아와서 클라이언트에서 렌더링을 처리. 초기 로딩 시간이 느림
• SSR : 서버에서 필요한 HTML과 스크립트만 클라이언트로 전송하여, 브라우저가 즉시 콘텐츠를 보여줌. 초기 로딩 시간이 빠름

=> 첫 페이지 로딩에서 SSR이 더 빠르다.

 

2) 나머지 페이지 로딩 시간

• CSR : 첫 페이지 로딩시 필요한 자바스크립트를 모두 받아오기 때문에, 이후 페이지 이동시 로컬에서 빠르게 처리. 이후 페이지 이동 속도가 빠르다.
• SSR : 페이지 이동시마다 서버에서 HTML 파일을 받아오고, 이후에 자바스크립트를 로드하여 인터랙티브하게 만든다. 페이지 이동시마다 반복적인 렌더링이 발생하므로 느려질 수 있다.

=> 이후 페이지 이동시 CSR이 더 빠르다.

 

 

◼︎ SEO(검색 엔진 최적화)

• CSR : 클라이언트에서 자바스크립트를 로드한 후에야 HTML이 동적으로 렌더링되므로, 초기 HTML 파일은 비어있다. 웹 크롤러가 사이트를 방문했을 때, 비어있는 root만 읽게 되어 색인화가 어렵다.
• SSR : 서버에서 미리 렌더링 된 HTML 파일을 전송하기 때문에, 크롤러가 즉시 페이지 내용을 읽고 색인화할 수 있다.

=> 서버에서 완성된 HTML을 제공하여 검색 엔진이 더 쉽게 페이지를 색인화 할 수 있어 SSR이 SEO에 더 유리하다.

 

 

◼︎ 서버 자원 사용

• CSR : 클라이언트가 대부분의 렌더링을 처리하므로, 서버에 부담이 적다.
• SSR : 서버에서 HTML을 매번 렌더링하고, 페이지 이동시에도 서버 요청을 반복해야 하므로 서버 자원이 많이 소모된다. 페이지를 이동할 때마다 서버에서 HTML을 제공하고, 인터랙티브한 데이터는 서버에서 다시 요청하여 가져오는 과정을 반복한다. 이로 인해 서버 부하가 발생할 수 있다.

=> SSR은 서버 부하가 크고, CSR은 클라이언트 측에서 렌더링을 처리해 서버 부담이 적다.

 

 

 

02. Hydration

Hydration은 서버에서 렌더된 정적 HTML을 동적인 React 컴포넌트로 변환하는 과정이다.

서버에서 제공된 HTML은 상호작용이 불가능한 상태로 클라이언트에 전달되고, 브라우저가 이를 받으면 클라이언트에서 JavaScript가 로드되어 해당 HTML을 상호작용 가능한 React 컴포넌트로 전환한다.

useState, onClick과 같은 동작을 하는 부분을 클라이언트 측에서 처리할 수 있도록 만드는 것이 바로 hydration이다.

 

=> SSR로 생성된 정적 HTML이 클라이언트에서 동적이 되고 상호작용 할 수 있는 상태가 되기 위해서 hydration이 필요

 

 

 

03. use client

Next.js 13 이상에서는 클라이언트 컴포넌트와 서버 컴포넌트를 구분한다.

use client는 클라이언트에서만 렌더링해야 하는 컴포넌트를 지정하는 지시어이다.

• 서버 컴포넌트 : 서버에서만 동작하며, 자바스크립트 동작 없이 HTML만 전달
• 클라이언트 컴포넌트 : 서버에서 HTML로 렌더된 후, 자바스크립트를 로드하여 상호작용이 가능한 상태로 hydration된다

 

use client 선언이 없으면 해당 컴포넌트는 서버 컴포넌트로 간주되어 상호작용 기능이 작동하지 않는다.

use client는 아래와 같이 사용할 수 있다.

'use client';

import { useState } from 'react';

export default function Counter() {
  const [count, setCount] = useState(0);

  return (
    <div>
      <p>Count: {count}</p>
      <button onClick={() => setCount(count + 1)}>Increase</button>
    </div>
  );
}

 

 

 

 

🔎 Questions

Q1. Hydration은 클라이언트에서만 발생하는가?

Hydration은 서버에서 제공된 HTML을 리액트 컴포넌트로 전환하여 상호작용 기능을 활성화하는 작업이므로 클라이언트에서만 발생한다. 

 

Q2. 페이지를 이동할 때마다 서버에서 렌더된 HTML을 받아오고 Hydration이 반복되는가?

페이지 이동시, 서버에서 렌더된 HTML을 받아오고, 클라이언트에서 다시 hydration이 이루어진다.

use client로 선언된 컴포넌트는 클라이언트 측에서 자바스크립트를 로드하여 상호작용 기능을 추가한다.