2. 服务器端开启gzip压缩
3. 如果你是3个单独的JS，那么你可以合成1个文件，减少请求次数
4. 将你的<script>标签写在页面底部<body>标签结束之前
5. 检查你的js中是否存在特别耗时的逻辑，因为脚本加载时阻塞式的，它会加载完并执行完之后，才会加载其它资源，因此慢并不一定是文件大，也可能是文件执行花了很长时间
6. 如果还是觉得很慢，你可以使用动态加载，不要直接在页面中写<script>标签，而是动态创建一个<script>将该脚本引进来，这样的加载方式是非阻塞式的，不会影响其它资源加载。
7. 上面方法全用了，还是觉得很慢，那你应该检查你的服务器和网络情况，因为按理来说100多kb的脚本不至于慢到不可接受的地步。
8. 将页面中的资源分散到多个一级或二级域名，因为浏览器对同一个域名同时加载的资源数量是有限制的
9. 如果你还是觉得很慢，那就玩些高级玩意儿吧（如使用CDN加速等）
10. 上面方法都试过，还是不奏效？那我也没辙了，除非能现场分析。
当然会比较大，因为不光打包了自己开发的JavaScript文件，还把依赖(就是那些第三方的库文件)也都打包进去了，确实会比较大。webpack的好处有几项
解决依赖关系
多模块化标准支持
多功能插件支持
相比这些在软件工程中急需解决的问题，“大”这个小事儿可以通过其他方式解决。
譬如，
uglify，可以很大程度上压缩源代码，使之体积减小。
或者通过nginx的gzip_comp_level选项可以设置1 ~ 9不同的压缩级别，以降低网络传输压力。
两者混用效果奇佳，而且也是最常见最有效的方式
例如React.js的源文件有610k左右，uglify之后已经不到200k了，再通过nginx压缩一把，用户在浏览器下载时，只有40k左右了。
以当今的网络环境，除非自己有精确测试结果，否则真心没必要一开始就考虑什么文件大小的问题，咱们已经不是那个时代了
