2.4. 프리페칭

1. 프리페칭(Pre-fetching)

• 프리페칭(Pre-fetching): Pre(사전에, 미리) + fetching(불러온다)
• 현재 페이지에서 이동할 가능성이 있는 페이지들을 모두 미리 불러와서 신속한 페이지 이동이 가능하게 만드는 기능입니다.

2. 프리페칭이 필요한 이유

• 하지만 지난 시간에 넥스트는 초기요청 이후부터는 서버 요청 없이 클라이언트 사이드에서 필요한 페이지를 교체하는 방식으로 페이지 이동이 이루어진다고 했습니다.
• 그런데 왜 이런 프리페칭이라는 과정이 추가적으로 필요한 것일까요?
• 왜냐하면, 넥스트는 우리가 만들어 둔 모든 리액트 컴포넌트들을 자동으로 페이지별로 스플리팅해서 저장하고 보관하기 때문입니다.
• 서버에서 브라우저로 전달하는 자바스크립트 번들은 우리가 만들어 둔 모든 리액트 컴포넌트가 아니었습니다.
• 특정 페이지와 관련된 컴포넌트들만 묶어서 번들링한 것이었습니다.
• 따라서 넥스트에서 서버는 현재 페이지에 필요한 자바스크립트 번들만 전달합니다.
• 용량 경량화되어 수화 시간이 단축되는 이점이 있습니다.
• 그렇게 하지 않으면, 즉 모든 페이지의 번들 파일을 전달할 경우 용량이 너무 커지게 되어 수화(Hydration) 작업이 지체되기 때문입니다.

3. 프리페칭 확인해보기

프로젝트를 빌드해서 프리페칭이 일어나는 과정을 확인해봅니다:

npm run build

• 시간이 지나면 각 페이지 별 크기를 터미널에서 확인할 수 있습니다.
• 즉 페이지별로 번들링된 것을 알 수 있습니다.

npm run start

• 프로덕션 모드로 전환합니다.

4. 네트워크 탭 확인

• 이제 인덱스 페이지로 넘어가서 네트워크 탭을 확인해봅니다.
• 리스트를 보면 search 페이지와 관련된 자바스크립트 파일이 있습니다.
• search 페이지를 요청하지 않았는데도 로드된 것입니다.
• 이는 인덱스 페이지에서 필요한 페이지들을 프리페칭한 결과입니다.
• 이 상태에서 search나 book 페이지로 이동해봅시다.
• 네트워크 탭에서는 아무런 변화도 일어나지 않습니다.
• search, book 페이지는 이미 인덱스 페이지에서 프리페칭되었기 때문에 추가적인 네트워크 요청이 필요하지 않기 때문입니다.
• 혹시 시간이 경과된 후 페이지를 요청했을 때 네트워크 탭에 그 페이지가 새로 나타날 수도 있습니다.
• 이는 캐시가 만료되어 새로운 요청을 보낸 것이므로 프리페칭과는 무관합니다.

5. Link vs Programmatic Page

5-1) 프리페칭의 대상: Link 컴포넌트

• search, book 페이지는 Link 컴포넌트이고, test 페이지는 버튼 태그에 클릭 이벤트로 연결된 프로그래매틱 페이지 연결입니다.
• 이 경우 인덱스 페이지에서 test 페이지를 요청하는 경우 프리페칭이 일어나지 않아 네트워크 탭에 새로운 요청이 확인됩니다.
• 즉, Link 컴포넌트만 프리페칭의 대상이 되는 것입니다.
• 하지만 이 test 페이지의 경우에도 프리페칭을 할 수 있는 방법이 있습니다.

5-2) Programmatic Page의 프리페칭

useEffect(() => {
  router.prefetch('/test');
}, []);

• test 페이지도 프리페칭이 되는 것인지 확인해봅니다.
• 코드가 바뀌었으니 Ctrl + C로 프로젝트를 종료하고, npm run build, npm run start를 다시 실행합니다.
• 이제 인덱스 페이지에서 네트워크 탭을 확인하면 test 페이지가 프리페칭된 것을 확인할 수 있습니다.
• 즉, 프로그래매틱 페이지의 프리페칭을 원한다면 router 객체의 prefetch 메서드를 통해 명시적으로 프리페칭하도록 설정할 수 있습니다.

5-3) Link 컴포넌트의 프리페칭 해제

• 만약 Link 컴포넌트로 명시된 페이지가 프리페칭의 대상이 되게 하고 싶지 않은 경우는 어떻게 할까요?
• Link 컴포넌트로 작성해두기는 했지만, 사용자의 요청이 없을 것 같아 프리페칭이 불필요하겠다고 여겨지면 Link 컴포넌트의 prefetch 속성을 false로 해제하면 됩니다.