[Next.js] next/dynamic 2. 효율적으로 활용하기

https://puenti.tistory.com/100

[Next.js] next/dynamic 1. 사용법과 빌드 과정

 

이전 글과 이어지는 내용입니다.

이전 글에서는 기본적이고 원론적인 사용법과 빌드 과정에 대해서 포스팅을 했는데요.

이번 글은 실무에서 적용시키면서 생긴 의문과 적절하게 적용시키는 방법에 대해 포스팅해보겠습니다.

 

next/dynamic은 동적 로드를 지원합니다.

근데 만약 해당 컴포넌트가 한 개가 아니라 여러 개일 경우 어떻게 적용시키면 좋을까에서 시작했습니다.

A 컴포넌트가 5곳에서 사용되고, 2곳에서만 next/dynamic을 적용한 경우:

1. 동적 로드가 적용된 2곳:
   • 이 경우, A 컴포넌트는 초기 번들에서 제외됩니다.
   • 해당 페이지가 클라이언트에서 렌더링될 때, A 컴포넌트는 네트워크 요청을 통해 로드됩니다.
   • 이로 인해 초기 로드 속도가 개선될 수 있지만, A 컴포넌트를 사용하는 시점에 추가 네트워크 요청이 발생합니다.
2. 동적 로드가 적용되지 않은 3곳:
   • 이 경우, A 컴포넌트는 초기 번들에 포함됩니다.
   • A 컴포넌트가 필요한 페이지를 방문하면 즉시 렌더링됩니다.
   • 네트워크 요청 없이 바로 사용 가능하므로 클라이언트 사이드 성능이 더 좋습니다.

빌드 시 처리 방식:

• Next.js는 동적 로드가 적용된 경우와 그렇지 않은 경우를 개별적으로 처리합니다.
  • 동적 로드를 사용하는 2곳에서는 A 컴포넌트를 별도의 청크(chunk)로 분리합니다.
  • 나머지 3곳에서는 A 컴포넌트를 각 해당 페이지의 번들에 포함합니다.
• 따라서, A 컴포넌트는 두 가지 방식으로 빌드됩니다:
  • 동적 로드용 청크 (사용되는 페이지마다 네트워크 요청으로 로드)
  • 초기 번들에 포함된 형태 (해당 페이지를 로드할 때 함께 로드)

주의사항:

• A 컴포넌트가 크거나 자주 사용되지 않는다면 next/dynamic을 사용하는 것이 이점이 될 수 있습니다.
• 하지만 A 컴포넌트가 매우 작거나, 앱에서 자주 사용되는 경우라면 next/dynamic은 불필요한 네트워크 요청을 초래해 오히려 성능에 부정적인 영향을 줄 수 있습니다.
• 동일한 컴포넌트를 동적 로드와 정적 로드로 혼용하면, 코드 스플리팅 전략이 복잡해질 수 있으니 관리에 유의해야 합니다.

고려사항:

1. 컴포넌트의 크기

• 컴포넌트가 크고 복잡한 경우:
  • 큰 컴포넌트(예: 복잡한 그래프 라이브러리, 무거운 UI 요소)를 next/dynamic으로 분리하면 초기 번들 크기를 줄일 수 있습니다.
  • 초기 페이지 로딩 속도가 개선되고, 컴포넌트가 필요한 시점에만 로드되므로 효율적입니다.
    
• 컴포넌트가 작거나 경량인 경우:
  • next/dynamic으로 분리해도 성능 이점이 크지 않습니다.
  • 오히려 네트워크 요청 오버헤드가 발생해 성능 저하가 생길 수 있습니다.

2. 사용 빈도

• 자주 사용되지 않는 컴포넌트:
  • 예: 특정 조건에서만 렌더링되는 모달, 설정 페이지에서만 사용하는 요소.
  • 이러한 컴포넌트는 next/dynamic을 적용하면 초기 로드 시 불필요한 코드를 줄일 수 있어 효과적입니다.
• 자주 사용되는 컴포넌트:
  • 예: 대부분의 페이지에서 사용되는 공통 UI 컴포넌트(헤더, 푸터).
  • 이런 경우 next/dynamic을 사용하면 매번 네트워크 요청을 해야 하므로 불필요한 오버헤드가 발생합니다.

3. 초기 로드 시간 개선 필요 여부

• 초기 로드 속도에 민감한 경우:
  • 사용자 첫 화면에 표시되는 주요 콘텐츠가 빠르게 로드되어야 하는 경우, 불필요한 컴포넌트를 분리하면 효과가 큽니다.
  • 이를 통해 "First Contentful Paint (FCP)"와 "Largest Contentful Paint (LCP)" 메트릭을 개선할 수 있습니다.
• 로드 속도보다 인터랙티브 경험이 더 중요한 경우:
  • 동적 로드로 인해 필요한 순간에 컴포넌트가 지연 로드된다면 사용자 경험이 나빠질 수 있습니다

4. 코드 스플리팅 효과

• Next.js는 next/dynamic을 활용해 코드를 스플리팅합니다.
  • 동적 로드된 컴포넌트는 별도의 청크로 분리되며, 초기 번들 크기가 감소합니다.
  • 따라서 페이지 크기가 크게 줄어드는 경우 next/dynamic의 효과가 매우 큽니다.
  • 하지만 컴포넌트를 너무 많이 동적으로 로드하면 요청 횟수가 증가해 HTTP/2 환경이 아닌 경우 성능 저하가 있을 수 있습니다.

권장 사항:

• 컴포넌트를 사용하는 모든 곳에 대해 next/dynamic을 적용하거나, 모든 곳에서 적용하지 않는 일관된 접근을 사용하는 것이 관리 측면에서 더 효율적일 수 있습니다.
• 필요하다면 dynamic의 ssr: false 옵션이나 loading 옵션을 사용해 성능을 세부적으로 조정하는 것이 좋습니다.

효과가 큰 시나리오

1. 페이지 전환 후 렌더링되는 컴포넌트:
   • 예: 특정 페이지에서만 사용하는 무거운 컴포넌트.
   • dynamic(import('...'))으로 처리하면 다른 페이지 로드에 영향을 주지 않음.
2. SSR이 필요 없는 컴포넌트:
   • 클라이언트에서만 동작하는 요소(예: 브라우저 전용 애니메이션).
   • ssr: false 옵션으로 서버사이드 렌더링을 비활성화해 더 빠른 렌더링이 가능.

결론:

• 자주 사용하는 컴포넌트라면 next/dynamic 사용하지 않는게 성능에 더 좋을 수 있음.
• 만약 사용할 것이라면 dynamic 옵션을 조정할 것!!
• 자주 사용하는 공통 컴포넌트를 분리할 때는 효과가 미미할 수 있음.