夏总啊，为啥每次看你的心得都有一种缘木求鱼的感觉？

先说 bundle 大小，这里面有两个问题：

首先是为什么会有1MB那么大？你需要用 webpack-bundle-analyzer 去找出来问题在哪里。比如一个典型的情况是，你只使用了 lodash 的几个函数，或者是一个 ui 框架里的几个组件，却把整个库/框架都打包进来了。主流的库都提供了按需引入的功能，lodash 这种流行的既有 babel 的插件又有 webpack 的插件，然而 lodash 整个打包进来也只有70k+而已

其次，如果使用 webpack，那么生产服务器的 response 应该传输的是 gz 版本。对于 minify 之后不是太小（<20k?）的 js 文件来说，典型的压缩率在30%左右。换句话说，按照经验数值，你的1MB实际上传输的应该在300k左右才对。比如你清空一下浏览器缓存，随便找个 cdn 返回个 lodash.min.js，网络传输显示的应该是24k。

此外，目前还有各种 link rel=preload/prefetch 等等的技术，哪怕你自己在手写把 js 文件先 get 一下，浏览器也会把你的 js 缓存下来的。


接着再来看 chunks 是用来解决什么问题的。

首先是理论知识，google 这几年每年都在重复讲，应该很容易搜到中文版本。对于浏览器来说，同样是300k大小的文件，png 的加载时间跟 js 完全不是一个量级的。因为 js 引擎需要从头 parse，生成中间码，优化，等等一大堆的工作。然后就是从 google 的用户统计上看，你不能假设手机端客户都是用的苹果最新旗舰机，中位用户大量在使用的，还是速度很慢的老机型

接下来，是在很多 client routes 的 spa 里面，当前页面并不会使用全部的 js 代码。典型的情况是，只有在登录后才能使用功能的网站，那么在登录页面让浏览器去加载用不到的代码，是降低用户体验的非常不经济的行为。


直接说结论，chunks 是当你的整个网站已经快要发布的时候，才需要根据页面的功能和对加载时间的观察的基础之上，做的最后一步优化工作。如果你的用户是以使用 pc 为主，那么你不做这个优化，影响恐怕也没多大。

从工程管理的角度来看，不论做什么项目，过早优化都是错误的。而且从大公司的技术文章来看，网站的加载速度优化是一个长期持续的工作，从来没听过哪个公司，功能都没做出来呢就开始研究加载速度的问题了。感觉你这技术选型都没怎么定下来呢，怎么就开始研究这个东西了，完全是本末倒置啊

如果你觉得 bundle size 太大，你应该做的是 tree shaking。这项工作其实也没多重要，只要论证能做到就够了。等后面快上线了，就是加几个插件，最多稍微改改代码的事儿。当然，养成按需引用的习惯也并不是什么坏事，只是对于像 vue 上个 ui 框架之类的来说，项目刚开始的时候，每个 vue 文件里都按需引用还是挺累人的。

【 在 xiatianup (李 ，只是期待夏天！！) 的大作中提到: 】
: 今天认真研究，并实践了一下这个内置选项，先说结论，太阔怕了。。。
: 当选项只有一个chunks: "all"的时候，这时打包出来的js文件（总大小，后面相同）假设为0.98M
: 然后我加了cacheGroups，在里面自定义一些提取项，也加了reuseExistingChunk:true，是慢慢增加自定义提取项的数目。
: ...................
--
修改:eGust FROM 125.237.49.*
FROM 125.237.49.*

膜拜
【 在 eGust (十年) 的大作中提到: 】
: 夏总啊，为啥每次看你的心得都有一种缘木求鱼的感觉？
: 先说 bundle 大小，这里面有两个问题：
: 首先是为什么会有1MB那么大？你需要用 webpack-bundle-analyzer 去找出来问题在哪里。比如一个典型的情况是，你只使用了 lodash 的几个函数，或者是一个 ui 框架里的几个组件，却把整个库/框架都打包进来了。主流的库都提供了按需引入的功能，lodash 这种流行的既有 bab
: ...................
--
FROM 58.42.245.*