자바스크립트 코드 분할

왜 나누나

브라우저가 JS를 받고, 파싱하고, 컴파일하고, 실행하는 동안 메인 스레드는 다른 일을 못 한다. 화면이 보여도 누르면 반응이 없다. 사용자는 로딩 중에 자주 누르기 때문에 이 시간이 그대로 INP의 입력 지연이 된다. 로딩 중 메인 스레드 차단을 재는 TBT가 INP와 상관이 높은 이유다.

• Lighthouse는 JS 실행 시간이 2초를 넘으면 경고하고, 3.5초를 넘으면 실패로 본다.
• 파싱 비용의 감각: 고급 휴대폰에서도 JS 1MB 파싱에 150ms 정도 든다(지연 시간 숫자).

무엇을 떼어 낼까

코드 분할은 번들을 둘로 나누는 일이다.

시작에 꼭 필요한 JS   → 첫 번들 (미룰 수 없다)
나머지 JS            → 별도 청크, 필요할 때 (대개 사용자 상호작용 뒤)

동적 import()로 나누기

<script>는 시작할 때 요청된다. 정적 import는 부모 모듈이 실행되기 전에 의존 모듈을 모두 받고 실행한다. 동적 import()는 그 줄이 실행될 때 비로소 요청한다.

// 폼 검증 코드는 사용자가 처음 입력란을 벗어날 때 받는다
document.querySelectorAll('#myForm input').forEach((input) => {
  input.addEventListener('blur', async () => {
    const { validateForm } = await import('/validate-form.mjs')
    validateForm()
  }, { once: true })
})

const Chart = lazy(() => import('./Chart'))
// <Suspense fallback={<Spinner />}><Chart /></Suspense>

lazy는 모듈의 default export만 컴포넌트로 받는다. named export라면 lazy(() => import('./charts').then((m) => ({ default: m.LineChart })))처럼 default로 바꿔 넘기거나, 다시 내보내는 작은 모듈을 둔다.

• 라우트 단위 분할은 대부분의 프레임워크 라우터가 기본으로 한다. 그 다음 후보는 모달·에디터·차트처럼 누른 뒤에만 쓰는 큰 기능이다.

미리 받기: 나눈 청크의 첫 클릭 비용

나눈 청크는 필요할 때 받기(네트워크) → 평가(메인 스레드) → 실행을 거친다. 첫 화면은 빨라지지만 그 기능을 처음 쓰는 순간 앞의 두 단계만큼 늦다. 곧 쓸 게 확실하면 실행 직전까지 미리 해 둔다. 같은 import()를 다시 부르면 모듈 캐시에서 바로 돌려주므로, 미리 한 번 불러 두기만 하면 된다.

// lazy 컴포넌트에 preload를 붙이는 팩토리
function lazyWithPreload(factory) {
  const Component = lazy(factory)
  Component.preload = factory
  return Component
}
 
const ImageModal = lazyWithPreload(() => import('./ImageModal'))
 
<button onMouseEnter={ImageModal.preload} onClick={() => setOpen(true)}>사진 보기</button>

react-lazy-with-preload 패키지가 같은 모양을 제공한다. Next.js <Link>·React Router의 prefetch 옵션처럼 라우터가 화면 진입·호버 때 자동으로 해 주는 경우가 많다.

청크를 얼마나 잘게

정답은 없고 캐시, 압축, 평가 시간의 균형이다. 번들러는 이 균형을 맞추는 도구이기도 하다. 번들 없이 모듈 수백 개를 그대로 보내면 모듈마다 요청이 생겨 큰 모듈 트리에서 상호작용 가능 시점이 늦어진다. modulepreload로 트리를 일찍 받을 수는 있지만 로딩 성능은 번들 쪽이 낫다.

webpack의 SplitChunksPlugin

• 기본 설정에서는 정적으로 가져온 모듈은 초기 청크에, 동적으로 가져온 모듈은 비동기 청크에 들어가고, 비동기 청크는 조건이 맞을 때만 받는다.
• chunks: 'initial'로 바꾸면 미루려던 코드가 시작 번들에 합쳐져 첫 로딩이 나빠진다.
• maxSize로 큰 청크를 더 쪼개면 평가가 나뉘어 긴 작업이 준다.
• splitChunks: false로 끄면 공유 모듈이 여러 청크에 중복으로 들어간다.

PRPL 패턴

코드 분할을 로딩 전략 전체로 넓힌 이름이 PRPL이다. 네 단계는 서로 독립적으로도 쓸 수 있다.

2016년 Polymer 팀이 처음 낸 PRPL의 첫 P는 Push(HTTP/2 서버 푸시)였다. 서버 푸시는 이미 캐시된 리소스까지 밀어 넣는 문제로 거의 쓰이지 않았고 Chrome 106에서 제거됐다. 그래서 지금은 Preload로 읽는다. 서버가 먼저 힌트를 주고 싶으면 103 Early Hints를 쓴다.

정리

• 시작 때 받는 JS는 그만큼 메인 스레드를 막는다. 커버리지로 안 쓰는 코드부터 찾는다.
• 나중에 필요한 코드는 동적 import()로 떼어 내고, 번들러가 별도 청크로 만든다.
• 상호작용 뒤 받는 코드는 첫 클릭을 늦추니, 확실하면 미리 받아 둔다.
• 청크 크기는 캐시·압축·평가 시간의 균형이다. 너무 크지도, 너무 잘지도 않게.

관련 노트: 모듈: export와 import, 번들러의 역사와 Vite, INP 최적화, 책임감 있는 자바스크립트, 웹 성능 지표와 Lighthouse