[Next.js] Pages Router의 장단점

 

✅ Page Router의 장점

 

1. 파일 시스템 기반의 간편한 페이지 라우팅을 제공한다.

→ 추가적인 코드가 필요없이 폴더 구조만으로 자유롭게 페이지의 라우팅을 설정할 수 있다.

이미지 출처 : 한 입 크기로 잘라먹는 Next.js 강의

 

 

 

 

2. 다양한 방식의 사전 렌더링을 제공한다.

→ React 앱의 단점인 느린 FCP를 효과적으로 보완할 수 있는 SSR, SSG, ISR이라는 3가지의 사전 렌더링 방식을

페이지별로 다르게 설정이 가능해 대부분의 케이스에 쉽게 대응할 수 있다.

 

- SSR (서버사이드 렌더링) : 요청이 들어올 때마다 사전 렌더링을 진행.

- SSG (정적 사이트 렌더링) : 빌드 타임에 미리 페이지의 사전 렌더링을 진행.

- ISR (증분 정적 재생성) : SSG 페이지를 일정 시간마다 재생성.

 

❗각 사전 렌더링 방식별 자세한 내용은 이전 포스팅 참고

2024.09.11 - [개발공부/⬛ Next.js] - [Next.js] data fetching 및 사전 렌더링 방식 3가지

[Next.js] data fetching 및 사전 렌더링 방식 3가지

 

 

 

 

 

 

 

✅ Page Router의 단점

 

1. 페이지별 레이아웃 설정이 번거롭다.

→ 페이지별로 설정할 레이아웃이 많아지게 되면 코드의 중복도 발생하고 복잡해진다.

 

App Router에서는 layout.tsx라는 파일 하나로 손쉽게 페이지별 레이아웃을 설정할 수 있다.

 

 

 

 

2. 데이터 페칭이 페이지 컴포넌트에 집중된다.

→ 서버에서 불러온 모든 데이터는 Page 컴포넌트에게 Props로 전달되는 구조이기 때문에

만약 Page 컴포넌트의 자식 컴포넌트가 많아지면 데이터를 Props로 계속 내려줘야하는 과정이 번거로워진다.

(redux 등의 상태관리 도구를 사용한다면 어느정도 보완할 수 있겠지만 애초에 구조 자체가 좋은 구조는 아니다.)

이미지 출처 : 한 입 크기로 잘라먹는 Next.js 강의

 

 

 

 

 

3. 불필요한 컴포넌트들도 JS Bundle에 포함된다.

→ 상호작용이 없는 컴포넌트들은 서버 측에서 한번만 실행되고 하이드레이션 과정에서는 다시 실행될 필요가 없다.

하지만 Page router에서는 상호작용 유무에 대한 구분없이 현재 페이지에 필요한 모든 컴포넌트를 JS Bundle에 묶어서 브라우저에게 전달한다.

그러면 JS 번들의 용량이 불필요하게 커질 수 있고 그에 비례해서 하이드레이션이 완료되는 시간도 오래 걸리게 될 것이다. (TTI가 늦어진다.)

 

App Router에서는 상호작용이 없는 컴포넌트를 서버 컴포넌트라고 따로 구분 짓고, JS 번들에 포함되지 않도록 설정할 수 있다.

 

 

 

 

 

 

 

참고자료

🔗 [이정환] 한입 크기로 잘라먹는 Next.js(15+)