Granular Chunking

💡 이 글을 번역 및 해석한 글 입니다.

크롬은 자바스크립트 오픈소스 생태계의 프레임 워크 및 도구들과 협력하고 있습니다. 최근에, Nextjs와 Gatsby의 로딩 속도를 향상시키기 위해 수많은 신규 최적화가 추가되었습니다. 이 글은 두 프레임워크에서 차용 중인 향상된 granular Chunking 전략에 대해 다룹니다.

Introduction

많은 웹 프레임워크와 같이, Next.js와 Gatsby는 웹팩을 주요 번들러로 사용하고 있습니다. 웹팩 v3에서는 서로 다른 entry point 간 공유되는 모듈(e.g 해석자 주석 - 서로 다른 페이지이지만 서로 공유하는 모듈로 예를 들어 react와 같은 모듈)을 단일(또는 일부)의 “common” chunk로 만들 수 있도록 CommonChunkPlugin 을 소개하였습니다. 공유되는 코드는 각각 다운받을 수 있고, 브라우저 캐시에 저장되어 결과적으로 로딩 속도 개선에 기여합니다.(e.g 해석자 주석 - 공유하는 모듈을 미리 다운받고 저장하고 있으면, 다음 entry point에 진입할 때 따로 다운받지 않아도 되기 때문)

이런 패턴은, 다음과 같은 번들링 설정을 채택한 많은 SPA 프레임워크에서 도입되었습니다.

비록 실용적이지만, 모든 공유 모듈을 하나의 chunk로 공유한다는 컨셉은 제약이 있습니다. 모든 entryPoint에서 공유되지 않는 모듈도 해당 모듈이 필요없는 경로에서도 결과적으로 다운로드 되는 결과가 초래됩니다. 예를 들어 page1에서 common chunk를 다운받을 때, page1이 moduleC를 사용하지 않음에도 해당 코드를 다운로드 받게 됩니다. 이런 이유로, 웹팩 v4는 해당 플러그인 제거하고 새로운 플러그인을 도입했습니다 : SplitChunksPlugin

Improved Chunking

SplitChunksPlugin의 기본 설정은 대부분의 사용자에게 잘 동작합니다. 다수의 경로에 걸쳐서 중복된 코드를 fetching하지 않도록 하기 위한 조건을 기반하여 다수의 분할된 chunk들이 생성됩니다.

하지만, 해당 플러그인을 사용하는 다수의 웹 프레임워크들은 여전히 chunk 분할을 위해 “단일 commons” 전략을 취하고 있습니다. 예를 들어 Next.js는 50% 이상의 페이지에서 사용하는 모듈과 모든 프레임워크 의존성 모듈(react, react-dom 등)을 포함하는 단일 commons 번들을 생성합니다.

const splitChunksConfigs = {
  …
  prod: {
    chunks: 'all',
    cacheGroups: {
      default: false,
      vendors: false,
      commons: {
        name: 'commons',
        chunks: 'all',
        minChunks: totalPages > 2 ? totalPages * 0.5 : 2,
      },
      react: {
        name: 'commons',
        chunks: 'all',
        test: /[\\/]node_modules[\\/](react|react-dom|scheduler|use-subscription)[\\/]/,
      },
    },
  },

비록 framework-dependent code(react 등)를 하나의 공유된 chunk로 포함한다는 건 어떤 entryPoint 든지 다운받은 다음 캐시될 수 있는걸 의미하지만, 절반 이상의 페이지 이상에서 하용되는 공통 모듈을 포함하는 사용 기반(usage-based)의 접근법(학습법)은 매우 효율적이지 못합니다. 이 비율을 조정하는 것은 다음 두 결과를 야기합니다.

• 비율을 줄인다면, 더욱 불필요한 코드가 다운받아진다.
• 비율을 올리면, 다수의 routes(entrypoints)에 걸친 중복된 코드가 포함된다.

이 문제를 해결하기 위해서, Next.js는 불필요한 코드를 줄이기 위해 SplitChunksPlugin을 위한 다른 설정을 채택했습니다.

• (160KB가 넘는) 충분히 큰 서드파티 모듈의 경우 별도의 chunk로 분리한다.
• 프레임워크 관련된 모듈(react 등)은 framworks 라는 이름의 개별 chunk로 분리한다.
• 필요한 만큼의 많은 공유 chunks를 만든다 (최대 25개)
• 생성되는 chunk의 최소 사이지는 20KB로 변경되었다.

이런 granular Chunking 전략은 다음과 같은 이점을 제공합니다.

• 페이지의 로딩 시간이 향상되었습니다. 한 개 대신 여러 개의 공유된 chunk를 만들게 되면서, 중복되거나 불필요한 코드의 양을 최소화하였습니다.
• 페이지간 이동(navigation) 중에 캐싱이 향상되었습니다. 큰 용량의 라이브러리들과 프레임워크들을 여러 chunk로 분리하는 것은, 해당 모듈들이 업그레이드 되기 전까지 변경될 가능성이 적으므로 캐시 무효화의 가능성을 줄였습니다.
  • granular webpack config (Link)

    ...
    prodGranular: {
          chunks: 'all',
    			// chunk 단위를 명시 
          cacheGroups: { 
            default: false,
            vendors: false,
    				// framework 관련 모듈
            framework: {
              name: 'framework',
    					// 'all' | 'async' | 'initial' 
    					// 어떤 chunks가 최적화를 위해 선택될지를 명시 
              chunks: 'all',
              test: /[\\/]node_modules[\\/](react|react-dom)[\\/]/,
              priority: 40,
            },
    				
            lib: {
    					// 160KB 이상 넘는지 체크
              test(module: { size: Function }): boolean {
                return module.size() > 160000
              },
    					// 160KB 이상 넘는 모듈들의 chunk 이름 지정 
              name(module: { identifier: Function }): string {
                let nodeModuleNameResults = /node_modules\/(.*)/.exec(
                  module.identifier()
                )
                return nodeModuleNameResults
                  ? nodeModuleNameResults[1]
                  : module.identifier()
              },
              priority: 30,
              minChunks: 1,
              reuseExistingChunk: true,
            },
            commons: {
              name: 'commons',
              chunks: 'all',
              minChunks: totalPages, // entryPoints의 개수 
              priority: 20,
            },
            shared: {
              name: false,
              priority: 10,
              minChunks: 2,
              reuseExistingChunk: true,
            },
          },
          maxInitialRequests: 20,
        },
    ...

More HTTP requests

granular chunking을 위한 SplitChunksPlugin 설정과 Nextjs와 같은 프레임워크에서 이를 적용하는 접근법은 완전히 새로운 컨셉은 아닙니다. 하지만 여전히 많은 프레임워크에서 몇 가지 이유 때문에 단일 “common” 번들 전략을 유지하고 있습니다. 이런 이유에는 많은 HTTP 요청이 사이트 성능에 부정적인 영향을 줄 수 있다는 우려가 포함되어 있습니다.

브라우저는 하나의 origin 으로부터 제한된 수의 TCP 연결(Chrome은 6개)이 가능하기 때문에, 번들러에 의해서 여러 개의 chunk로 나누는 것은 이런 제약 상황(제한된 TCP 연결 개수) 에서 총 요청 수의 증가로 이어진다는 것을 확신할 수 있습니다. 하지만 이는 오직 HTTP/1.1 의 경우에만 유효합니다. HTTP/2의 멀티플렉싱(Multiplexing)은 하나의 origin간의 단일 connection을 이용해 병렬적으로 다수의 요청들이 처리되는 것(be streamed)을 허용합니다. 다른 말로 말하자면, 우리는 일반적으로 번들러에 의해 생성된 chunk 개수를 제한하는 것과 관련해 우려할 필요가 없다는 말입니다.

대부분의 주요 브라우저는 HTTP/2를 지원하고 있습니다. 크롬과 Next.js 팀은 어떤 방식으로든지 Next.js의 단일 common chunk를 여러 개의 chunk로 분할함으로서 증가하는 요청의 개수가 로딩 성능에 영향을 주는지 확인하고 싶었습니다. 그들은 maxInitialRequests 속성을 사용하여 병렬 요청의 최대 개수를 변경하면서 단일 사이트의 성능을 측정하기 시작했습니다.

평균적으로 여러 번 시도하는 과정에서, load, start-render, FCP 시간이 최대 초기 요청 개수의 변화(5 to 15)를 줄 때에 비슷한 수치를 유지하였습니다. 흥미롭게도, 우리가 수백개의 요청을 하기 위해 공격적으로 splitting한 이후에 성능상 약간의 overhead가 발생한다는 점을 알게 되었습니다.

이 결과는 신뢰할 수 있는 임계값(20~25개의 요청) 내에서 로딩 성능과 캐싱 효율성 사이에 적절한 균형을 유지할 수 있음을 보여줍니다. 몇 번의 테스팅 이후, maxInitialRequests 값으로 25번이 선택되었습니다.

요청의 최대 개수를 변경하는 것과 entry point에 따라 적절히 번들을 분할하는 것은 같은 페이지에서 불필요한 코드 양을 줄입니다.

이 실험은 단순히 페이지 로드 성능에 부정적인 영향을 줄 수 있는지 확인하기 위해 요청 개수를 변경하는 것만이 아닙니다. 이 결과는 maxInitialRequests 값을 25로 설정하는 것이 페이지 속도 감소 없이 자바스크립트 payload 사이즈를 줄일 수 있기 때문에 적절하다는 것을 제안하고 있습니다. 해당 페이지를 hydrate하기 위해 필요한 자바스크립트의 총 사이즈는 여전히 비슷한 것도 볼 수 있는데, 이는 왜 전체 코드 규모가 줄어들어도 페이지 로드 속도가 반드시 함께 향상되지 않는다는 걸 의미합니다. (실제로 React가 HTML을 생성하고, 이벤트 리스너를 등록(hydrate)하기 위해 필요한 자바스크립트 용량은 총 자바스크립트 payload 용량을 줄이는 것과 무관할 수 있음을 의미하는 것 같습니다)

웹팩은 chunk 당 최소 30KB를 기본 용량으로 사용하고 있습니다. 하지만, maxInitialRequests 를 25로 설정함과 동시에 기본 용량 설정을 20KB로 설정하는 것이 더 좋은 캐싱을 할 수 있도록 합니다.

Size reductions with granular chunks

Next.js를 포함한 많은 프레임워크들은 모든 route 변경 시,새로운 script 태그(chunk를 다운 받기 위한 script)를 삽입하기 위해 cliet-side routing(CSR)에 의존하고 있습빈다. 하지만 어떻게 빌드 타임에 미리 시시각각 변하는 chunk 삽입(dynamic chunk)을 결정할 수 있을까요?

Next.js는 server-side build manifest 파일을 사용하여 각 entry point에서 어떤 chunk가 사용되는지 결정하고 있습니다. 이런 정보를 client에도 주기 위해서, 모든 entry point와 dependencies 를 맵핑하기 위해 축약된 client-side build manifest가 생성됩니다.

// 특정 route(경로)에 해당하는 dependecies 정보를 가진 promise를 반환한다. 
getDependencies (route) {
  return this.promisedBuildManifest.then(
    man => (man[route] && man[route].map(url => `/_next/${url}`)) || []
  )
}

Conclusion

granular chunking을 도입하는 전략은 Next.js, Gatsby 만 아니라 심지어 웹팩에게 독특한 것은 아닙니다. 만약 어플리케이션이 번들러나 프레임워크를 사용함에도 하나의 큰 ‘commons’ 번들 전략을 따르고 있다면, 당신의 어플리케이션 chunking 전략을 향상시키도록 고려해 봐야 합니다.

✅ 참고

• Next.js 9.2 Code Splitting 관련 블로그 글