减少生产应用程序的捆绑包大小

时间:2019-08-18 08:08:00

标签: javascript npm webpack-production

我有一个生产应用程序,其捆绑包大小为 8.06MB

# Console log from npm build
File sizes after gzip:

  1.67 MB    build/static/js/3.73cf59a2.chunk.js
  794.29 KB  build/typescript.worker.js
  131.13 KB  build/css.worker.js
  104.68 KB  build/html.worker.js
  104.02 KB  build/static/css/3.01bcafd3.chunk.css
  67.03 KB   build/static/js/main.6acf560d.chunk.js
  49.64 KB   build/json.worker.js
  25.12 KB   build/editor.worker.js
  7.99 KB    build/static/js/54.afc981d1.chunk.js
  ...

在构建应用程序并运行source-map-explorer

npm run build
source-map-explorer 'build/static/js/*.js'

我从build得到警告:

  

捆绑包的尺寸明显大于建议的尺寸。

my-source-map

  

您可以inspect the source map

我想减小捆绑包的大小,从我所做的研究得出的结论是:

  • 寻找大型图书馆的替代品。
    • 为我的需要制作一个“苗条”的库。
  • 导入按需的单个组件:
import Button from 'antd/es/button'; 
import { Button } from 'antd'; // Imports all library

我对以下问题有疑问

  1. 为什么小捆束很重要?
  2. 推荐的捆绑包大小是多少?
  3. 我了解,代码拆分会将您的代码分成多个捆绑包,然后可以按需或并行加载。
  4. 我如何确定图书馆是否需要成为devDependencies的一部分
  5. 还有其他方法吗?

1 个答案:

答案 0 :(得分:2)

  

为什么小捆束很重要?

因为这将通过减少用户必须传输的数据量来减少用户加载您的应用程序/站点所需的时间。这对于使用低带宽连接(包括修补的蜂窝连接)的用户而言尤其重要。

  

推荐的捆绑包大小是多少,为什么?

尽可能小。我认为实际上不可能给出确切的答案,因为每个应用程序都不同,但是通常您希望“关键”路径上的资源尽可能小,以减少初始加载时间,然后根据需要动态加载更多资源。

  

我知道,代码拆分会将您的代码分成多个捆绑包,然后可以按需或并行加载。

虽然它可能不会减少整体捆绑包的大小,但可以减少单个用户所需的数据量。例如,如果仅在应用程序的特定部分中使用monaco-editor,则只有在用户激活该功能时才延迟加载它才有意义。

  

如何确定库是否需要成为devDependencies的一部分

devDependencies应该包括开发项目时仅需要的所有依赖项。这将包括工具(例如:webpack,eslint,gulp)和测试框架(mocha,chai,sinon)。

这与服务器端项目更相关,因为即使错误地将真正的devDependencies放在捆绑的代码中,也不应将它们放到捆绑的代码中。

  

还有其他方法吗?

从根本上讲,您应该专注于摇树和代码拆分/延迟加载。

例如,moment-timezone本身占用了将近1mb的空间-您实际上需要吗?对于许多应用程序来说,只需在浏览器的时区和utc中工作就足够了,而该时区不需要moment-timezone

对于antd库,确保所有导入都是可摇树的(例如:如示例中那样导入单个组件)可能会大大减少导入代码的大小(其他类似lodash的库可能与故事,尽管如果您的依赖项没有使用可摇树的导入,那么整个内容都会包括在内)

对于vismonaco-editor,请考虑是否可以按需加载它们,而不是始终在启动时加载它们。考虑一下您是否同时需要codemirrormonaco-editor-它们看起来似乎可以满足类似的目的。

参考: https://webpack.js.org/guides/tree-shaking/
https://webpack.js.org/guides/lazy-loading/