RequestEntityTooLargeException:
Request must be smaller than 69905067 bytes for the UpdateFunctionCode operation
69905067byte가 약 70mb라 이부분에서 왜 최대 할당량이 늘었는지 궁금했는데, 빌드 파일을 포함한 요청(request)이 총 70mb 를 넘으면 안된다고 한다. 따라서 빌드 zip 파일 자체는 50mb 이하로 줄여야 배포가 가능하다.
Webpack 빌드 파일 중 어떤 부분이 큰지 확인하고 해당 부분을 줄여야 한다.
Webpack 은 프로젝트의 구조를 분석하고 자바스크립트 모듈을 비롯한 관련 리소스들을 찾은 다음 이를 브라우저에서 이용할 수 있는 번들로 묶고 패킹하는 모듈 번들러(Module bundler)다. (출처: 웹팩(Webpack) 이란, 웹팩 간단 정리 및 리액트(React) 기본 개발환경 세팅. [1])
@next/bundle-analyzer
를 사용해서 빌드 크기 확인 후 용량을 줄여보자.
로컬 환경에서 빌드 파일 확인할 수 있는 @next/bundle-analyzer를 사용해서 빌드 상태를 볼 수 있다.
yarn add @next/bundle-analyzer
const withBundleAnalyzer = require('@next/bundle-analyzer')({
enabled: process.env.ANALYZE === 'true',
})
module.exports = withPlugins([
[withBundleAnalyzer],
// your other plugins here
])
ANALYZE=true yarn build
.next/analyze/client.html 파일에서는 node module 관련 정보를 보여준다. parsed size를 보면 되는데 각 번들(파일)당 500kb 이하가 되는 것이 좋다고 한다. (인터넷 속도가 빠른 곳에서는 1mb 정도도 괜찮다고 한다.) 번들 파일이 큰 모듈은 실제로 사용하는 모듈만 로딩하는 tree shaking을 하면 된다.
모듈별로 tree shaking이 되는것도 있고, 안되는것도 있다고 하는데, 번들 사이즈가 큰 모듈 위주로 tree shaking 검색해서 진행하면 된다.
ex) moment.js tree shaking 방법: https://github.com/jmblog/how-to-optimize-momentjs-with-webpack#bonus
ex2) lodash tree shaking: https://blog.jungbin.kim/web/2019/02/16/js-decreaing-webpack-bundle.html#lodash-%EC%9A%A9%EB%9F%89-%EC%A4%84%EC%9D%B4%EA%B8%B0
왼쪽 상단 메뉴를 클릭하면 parsed와 Gzipped 크기를 볼 수 있다.
Stat, Parsed, Gzipped 세 가지 옵션이 나는데, 이 옵션은 각 번들의 사이즈 측정 기준이라고 한다. Stat은 빌드된 그대로의 상태, Parsed는 웹팩이 트리셰이킹을 마친 결과물, Gzipped는 결과적으로 서빙을 위해 압축된 사이즈이다. Parsed를 줄이면 자연스레 Gzipped는 비례하여 줄어듦으로, Parsed size를 기본으로 줄이기를 시도하는 것이 좋다고 한다. (출처: 쉽게 따라하는 프론트엔드 웹 어플리케이션 패키지 최적화)