Next.js의 Page Router는?
React Router 처럼 특정 조건을 기준으로 웹 서비스 내에 페이지를 분할하고 분할된 페이지 간의 이동을 처리하는 등의 페이지 라우팅을 처리해주는 기능을 제공해준다.
기본 파일
프로젝트를 생성하면 pages 폴더 안에 _app.tsx, _document.tsx 파일이 자동으로 생성된다.
_app.tsx
- App 컴포넌트는 root 컴포넌트로서 모든 페이지 컴포넌트의 부모 컴포넌트가 된다.
- 전체 페이지에 공통적으로 포함되는 컴포넌트를 렌더링 하거나 비즈니스 로직들을 작성할 수 있는 공간이다.
_document.tsx
- 모든 페이지에 공통적으로 적용되어야 하는 메타 태그 또는 폰트와 같은 HTML 태그를 설정하는 곳이다.
Page Routing
useRouter 훅
- 쿼리스트링의 값이나 URL 파라미터를 컴포넌트에서 직접 꺼내서 사용하려면 useRouter라는 훅을 불러와서 사용하면 된다.
- useRouter 훅은 router라는 객체를 컴포넌트 내부에서 사용할 수 있도록 반환하는 함수다.
동적 경로
- URL 파라미터를 사용하는 동적 경로를 갖는 페이지를 생성하려면 폴더명이나 파일명을 대괄호로 묶어서 작성하면 된다.
- 모든 세그먼트를 포함하는 페이지를 생성하려면 대괄호 안 이름 앞에 …을 붙이면 된다.
- URL 파라미터가 없는 경로(index 페이지)도 포함하려면 이중 대괄호로 묶으면 된다.
Navigating
- a 태그는 CSR 방식으로 페이지를 이동하는 게 아닌 서버에게 새로운 페이지를 매번 다시 요청하는 방식으로 페이지를 이동하기 때문에 비교적 느리다.
- Next.js에서는 a 태그보다는 자체적으로 제공하는 내장 컴포넌트인 Link 컴포넌트를 이용하는 것을 권장하고 있다.
- 버튼을 클릭했을 때 함수 내부에서 페이지를 이동시키는 기능을 구현하고 싶다면 useRouter 훅을 불러와서 router 객체를 꺼내고 router의 push 메서드를 호출한 다음 인수로 경로를 작성하면 된다.
Prefetching
현재 사용자가 보고 있는 페이지 내에서 이동할 가능성이 있는 모든 페이지들을 사전에 미리 다 불러와 놓는 기능이다.
페이지 이동 시 Prefetching이 필요한 이유
- Next.js는 작성한 모든 React 컴포넌트를 자동으로 페이지별로 splitting을 해서 저장을 미리 해둔다.

- 만약 초기 접속 요청이 있을 때마다 모든 페이지에 해당하는 JS 코드를 다 번들링 해서 전달하게 되면 전달되는 파일의 용량이 매우 커지게 돼서 다운로드 속도도 느려지게 되고 결국 TTI가 늦어지게 되는 문제가 발생한다.
- Next.js는 초기 접속이 완료된 이후 곧바로 Prefetching이 발생을 해서 현재 페이지에서 이동할 수 있는 모든 페이지의 JS 코드를 사전에 불러와 놓기 때문에 페이지를 이동할 때는 추가적인 데이터를 서버에게 요청할 필요가 없어진다.
Prefetching 사용법
- Link 컴포넌트로 경로를 명시하면 자동으로 Prefetching이 적용된다.
- Link 컴포넌트 외에 함수로 페이지를 이동시키면 Prefetching이 적용되지 않는데 그때는 페이지가 화면에 마운트 되었을 때 router 객체의 prefetch 메서드를 호출해 이동할 페이지의 경로를 작성하면 된다.
useEffect(() => {
router.prefetch("/test");
}, []);
API Routes
- API를 구축할 수 있게 해주는 기능이다.
- 마치 백엔드 API 서버가 하는 일과 동일하게 간단한 API를 구축해서 클라이언트로부터 요청을 받아 데이터베이스에서 데이터를 꺼내오거나 다른 서드파티의 데이터를 불러와서 전달해주는 동작을 직접 만들어 볼 수 있다.
- api 폴더 안에 파일을 만들면 웹 페이지가 아닌 API Routes로써 자동으로 설정이 된다.
Layout 설정
- 공통적으로 사용되는 레이아웃을 적용하고 싶으면 페이지 컴포넌트에 getLayout 메서드를 추가하면 된다.
export default function Home() {
...
}
Home.getLayout = (page: ReactNode) => {
return <TestLayout>{page}</TestLayout>;
};
- 사용자가 페이지로 접속 요청을 보내게 되면 App 컴포넌트가 실행되면서 App 컴포넌트에게 Component props로 해당 페이지 컴포넌트가 전달된다. 그때 getLayout 메서드까지 함께 전달된다.
사전 렌더링
- 컴포넌트가 마운트 될 때 백엔드 서버에게 데이터 요청을 보내면 데이터를 불러오는 시점이 늦어지기 때문에 FCP도 늦어지게 된다. 그래서 Next.js는 이 문제를 해결하기 위해 사전 렌더링 방식을 사용한다.
- 사전 렌더링이란 브라우저가 초기 접속 요청을 보냈을 때 Next.js 서버 측에서 해당 페이지에 필요한 JS 코드를 모두 실행시켜서 React 컴포넌트들을 HTML로 렌더링을 마친 다음 브라우저에게 응답해주는 방식이다.
- 사전 렌더링 과정 중에 데이터 페칭까지 동시에 수행하도록 만들어 줄 수 있기 때문에 데이터를 요청하는 시점이 빨라지게 되어 사용자에게 데이터 페칭이 이미 완료된 웹 페이지를 추가적인 로딩 없이 한 번에 보여줄 수 있다.
Next.js의 다양한 사전 렌더링
서버 사이드 렌더링(SSR)
- 가장 기본적인 사전 렌더링 방식
- 요청이 들어올 때마다 사전 렌더링 진행
정적 사이트 생성(SSG)
- 빌드 타임에 미리 사전 렌더링 진행
증분 정적 재생성(ISR)
- 단순히 SSG 방식으로 생성된 정적 페이지를 일정 시간을 주기로 다시 생성하는 방식
자세한 사전 렌더링 방식은 이전 게시글에 작성
출처 : 한 입 크기로 잘라먹는 Next.js
'정리 > Web' 카테고리의 다른 글
| [Web] 브라우저 렌더링 (0) | 2024.11.27 |
|---|---|
| [Web] Next.js의 App Router (2) | 2024.10.20 |
| [Web] CSR, SSR, SSG (0) | 2024.08.19 |