→←↑↓
📌⚠️
토이플젝이든 팀 플젝이든 프로덕션 단계에 진입하면 코드 스플리팅이 꼭 거론된다.
이번 글에서는 코드 스플리팅이 뭐하는 놈인지 알아볼 예정이다.
📌 MDN은 이렇게 말한다.
코드 분할은 웹 애플리케이션이 의존하는 코드(자체 코드 및 서드파티 의존성 포함)를 서로 독립적으로 로드 가능한 별도의 번들로 나누는 방법입니다. 이를 통해 애플리케이션은 특정 시점에 필요한 코드만 로드하고, 다른 번들은 요청 시점에 로드할 수 있습니다. 이러한 접근 방식은 애플리케이션 성능, 특히 초기 로드 성능을 향상시키기 위해 사용됩니다.
- 원문을 번역
📌 React는 이렇게 말한다.
코드 분할(Code-splitting)은 애플리케이션을 더 작은 번들로 나누어, 필요할 때(on demand) 로드할 수 있도록 하는 과정입니다.
앱에 새로운 기능이나 의존성이 추가될수록 전체 코드 크기는 증가하게 되고
→ 이로 인해 앱 전체의 코드를 모두 전송해야만 실행 가능한 상황이 되어 초기 로딩 속도가 느려질 수 있습니다.이를 완화하기 위해 캐싱, 기능/의존성 줄이기, 일부 코드를 서버에서 실행하도록 이전하는 등의 방법을 사용할 수 있지만,
이러한 방법들은 기능에 제약을 주기에 완전한 해결책이 되기 어렵습니다.또한, 프레임워크 사용자들이 직접 코드 분할을 적용하도록 맡기면,
오히려 분할하지 않았을 때보다 로딩 속도가 더 느려지는 상황이 발생할 수 있습니다.
예를 들어, 차트를 지연 로딩(lazy load) 하면 차트를 렌더링하는 데 필요한 코드가 앱의 다른 코드와 분리되어, 코드 전송이 지연됩니다.
Parcel은 React.lazy를 통한 코드 분할을 지원하지만,
만약 차트가 렌더링된 후에 데이터를 가져온다면,
코드 전송 → 렌더링 → 데이터 요청 과정을 순차적으로 기다려야 하게 됩니다.이런 흐름은 흔히 워터폴(waterfall) 구조라고 불리며,
코드와 데이터를 동시에 가져오는 대신, 각 단계를 차례로 기다려야 하는 비효율적인 방식이 됩니다.그러나 라우트 단위로 코드를 분할하고, 번들링 및 데이터 패칭 로직과 통합하면,
앱의 초기 로딩 속도와 가장 큰 콘텐츠가 렌더링되는 시점(LCP)을 줄이는 데 도움이 될 수 있습니다.
위 문서를 읽고
잘 모르겠지만 대략적으로 위 문서에서 알 수 있는 내용을 정리해봤다.
- 코드 스플리팅을 적용하면 해당 코드는 번들에서 제외된다.
- 스플리팅이 적용된 코드는 필요 시에 비동기적으로 로드된다.
- 애플리케이션 성능, 특히 LCP를 향상시키는데 도움이 된다.
- 코드 스플리팅은 잘못 사용하면 오히려 역효과를 초래.
이렇게 정리했을 때 이제 어떤 상황에서 사용해야 할까를 고민해볼 수 있을거 같다.
