[TIL] Next.js 란?

Next.js는 리액트 프레임워크이다.

 

Next.js는 React 기반의 SSR(서버 사이드 렌더링)을 지원하는 프레임워크이자 CSR(클라이언트 사이드 렌더링)만 지원하는 React와는 다른점이 있다.

 

일반적으로 Next.js를 채택할 때 주요한 의사결정은 

1) App router를 쓸 것인가 ?

2) Pages router를 쓸 것인가? 

와 연관되어 있다.

 

왜 router를 기반으로 속성을 분류할까?

- 웹사이트를 기획/설계할 때, 어떤 페이지가 존재하게 할지, 라우팅은 어떻게 하게 할지를 항상 먼저 고려한다. 

- React 기반의 SSR(서버 사이드 렌더링) 을 지원하는 프레임워크 & CSR(클라이언트 사이드 렌더링) 만 지원하는 React와는 차이가 있다.

 

Next.js 사용 시 가장 중요한 핵심 개념 - 렌더링 기법

 

1.  CSR (클라이언트 사이드 렌더링)

브라우저에서 자바스크립트를 사용해 동적으로 웹페이지를 직접 렌더링하는 방식.

렌더링의 주체는 클라이언트이고, 최초 한번 로드가 끝나면 유저와 상호작용이 빠르고 부드럽다. 

하지만 첫 페이지 로딩 시간(Time To View)이 길 수 있고, 자바스크립트가 로딩되고 실행될 때까지 페이지가 비어있어서 SEO (검색 엔진 최적화)에 불리하다.

 

 

2. SSR (정적 서버 사이드 렌더링)

서버에서 페이지를 렌더링해 클라이언트에게 HTML을 전달하는 방식.

최초 빌드시에만 생성된다.

이 방식은 준비된 상태로 전송하다 보니 첫 페이지 로딩 시간이 매우 짧고(TTV) 검색 엔진이 콘텐츠를 더 잘 이해할 수 있게 해준다.

CDN(Content Delivery Network) 캐싱이 가능하다.

하지만 정적인 데이터에만 사용할 수 있고, 유저와의 상호작용이 서버와의 통신에 의존하고, 클라이언트에서 페이지를 이동할 때마다 새로운 요청이 계속해서 발생해 CSR에 비해 상대적으로 좀 느릴 수 있음.

마이페이지처럼 데이터에 의존해 화면을 그려주는 경우에는 사용이 불가하다.

 

3. ISR(Incremental-Static-Regeneration)

SSG처럼 정적 페이지를 제공하는데, 설정한 일정 시간마다 특정 페이지만 다시 빌드해 페이지를 새로 업데이트한다.

만약 주기가 5분이라면? => 5분마다 DB 또는 외부 영향 때문에 변경된 사항을 반영하는 역할을 한다.

정적페이지를 먼저 보여주고, 필요에 따라 서버에서 페이지를 재생성하는 방식이다.

정적 페이지를 먼저 제공해 콘텐츠가 변경되었을 대 서버에서 페이지를 재생성하므로 최신 상태를 유지할 수 있다.하지만 동적인 콘텐츠를 다루기에 한계가 있을 수 있다.  블로그와 같이 콘텐츠가 동적이지만 자주 변경되지 않는 사이트인 경우 ISR을 사용하는 것이 좋다. 

 

 

4. SSR

빌드 시점에 모든 페이지를 미리 생성해 서버 부하를 줄이는 방식.

SSG, ISR처럼 렌더링 주체가 서버이다.

클라이언트의 요청 시 렌더링된다.

빠른 로딩 속도(TTV)와 높은 보안성을 제공한다. SEO 최적화에 좋고, 실시간 데이터를 사용한다. 

마이페이지 처럼 데이터에 의존한 페이지 구성이 가능하고, CDN 캐싱은 불가하다.

하지만 사이트의 콘텐츠가 변경되면 전체 사이트를 다시 빌드해야 하는데, 이 과정이 요청할 때마다 페이지를 만들어야해서 서버 과부하로 시간이 오래 걸릴 수 있다. 

 

	CSR	SSR	SSG	ISR
빌드 시간	짧다	짧다	길다	길다
SEO	나쁨	좋음	좋음	좋음
페이지 요청에 따른 응답 시간	보통	길다	짧다	짧다
최신 정보인가?	맞음	맞음	아님	아닐 수 있음

 

 

Hydration

 

• TTV, TTI 그리고 Hydration

우리가 Next.js를 이해할 때는 위 언급한 세 개념. TTV, TTI, Hydration의 개념이 상당히 중요하다.

 

1. CSR

React에서 CSR로만 컴포넌트 렌더링을 할 때는 TTV가 오래걸렸다. 모든 React 소스 파일을 다운로드 받아야만 화면을 볼 수 있기 때문.

여기에서 Hydration 개념이 들어간다. 최초 서버에서는 index.html 파일만 제공하지만 이후 React 소스파일을 바탕으로 한 자바스크립트 파일이 모두 다운로드 돼야만(즉, Hydration이 돼야만) 최종 소스코드를 볼 수 있는 것이다.

하지만 CSR의 과정에서의 Hydration 과정을 Hydration으로 볼 것이냐 하는것은 이견이 있을 수 있다. 

 

2. SSR 

서버에서는 사용자의 요청이 있을 때마다 페이지를 새로 그려서 사용자에게 제공한다.

- pre-rendering : 사용자와 상호작용하는 부분을 제외한 껍데기만을 먼저 브라우저에게 제공한다. TTV가 빠르다.

- hydration : 이 과정이 일어나기 전까지는 껍데기만 있는 html 파일이기 때문에 사용자가 아무리 버튼을 click 해도 아무 동작이 일어나지 않는다. 인터렉션에 필요한 모든 파일을 다운로드 받는 과정 즉, hydration 과정이 끝나야 그제서야 인터렉션이 가능하다. 이 간극인 TTI를 줄이는 것이 관건이라 할 수 있다.