webpack生成bundle.js文件为什么那么大，会影响加载速度吗
2个回答
2017-03-19 · 做真实的自己 用良心做教育
千锋教育
千锋教育专注HTML5大前端、JavaEE、Python、人工智能、UI＆UE、云计算、全栈软件测试、大数据、物联网+嵌入式、Unity游戏开发、网络安全、互联网营销、Go语言等培训教育。
向TA提问
关注
![]()
展开全部
当然会比较大，因为不光打包了自己开发的JavaScript文件，还把依赖(就是那些第三方的库文件)也都打包进去了，确实会比较大。
webpack的好处有几项
解决依赖关系
多模块化标准支持
多功能插件支持
相比这些在软件工程中急需解决的问题，“大”这个小事儿可以通过其他方式解决。
譬如，
uglify，可以很大程度上压缩源代码，使之体积减小。
或者通过nginx的gzip_comp_level选项可以设置1 ~ 9不同的压缩级别，以降低网络传输压力。
两者混用效果奇佳，而且也是最常见最有效的方式
例如React.js的源文件有610k左右，uglify之后已经不到200k了，再通过nginx压缩一把，用户在浏览器下载时，只有40k左右了。
以当今的网络环境，除非自己有精确测试结果，否则真心没必要一开始就考虑什么文件大小的问题，咱们已经不是那个时代了
webpack的好处有几项
解决依赖关系
多模块化标准支持
多功能插件支持
相比这些在软件工程中急需解决的问题，“大”这个小事儿可以通过其他方式解决。
譬如，
uglify，可以很大程度上压缩源代码，使之体积减小。
或者通过nginx的gzip_comp_level选项可以设置1 ~ 9不同的压缩级别，以降低网络传输压力。
两者混用效果奇佳，而且也是最常见最有效的方式
例如React.js的源文件有610k左右，uglify之后已经不到200k了，再通过nginx压缩一把，用户在浏览器下载时，只有40k左右了。
以当今的网络环境，除非自己有精确测试结果，否则真心没必要一开始就考虑什么文件大小的问题，咱们已经不是那个时代了
已赞过
已踩过<
评论
收起
你对这个回答的评价是？
2018-06-27 · 百度知道合伙人官方认证企业
育知同创教育
1【专注：Python+人工智能|Java大数据|HTML5培训】 2【免费提供名师直播课堂、公开课及视频教程】 3【地址：北京市昌平区三旗百汇物美大卖场2层，微信公众号：yuzhitc】
向TA提问
关注
![]()
展开全部
当然会比较大，因为不光打包了自己开发的JavaScript文件，还把依赖(就是那些第三方的库文件)也都打包进去了，确实会比较大。
webpack的好处有几项
解决依赖关系
多模块化标准支持
多功能插件支持
相比这些在软件工程中急需解决的问题，“大”这个小事儿可以通过其他方式解决。
譬如，
uglify，可以很大程度上压缩源代码，使之体积减小。
或者通过nginx的gzip_comp_level选项可以设置1 ~ 9不同的压缩级别，以降低网络传输压力。
两者混用效果奇佳，而且也是最常见最有效的方式
例如React.js的源文件有610k左右，uglify之后已经不到200k了，再通过nginx压缩一把，用户在浏览器下载时，只有40k左右了。
以当今的网络环境，除非自己有精确测试结果，否则真心没必要一开始就考虑什么文件大小的问题，咱们已经不是那个时代了
webpack的好处有几项
解决依赖关系
多模块化标准支持
多功能插件支持
相比这些在软件工程中急需解决的问题，“大”这个小事儿可以通过其他方式解决。
譬如，
uglify，可以很大程度上压缩源代码，使之体积减小。
或者通过nginx的gzip_comp_level选项可以设置1 ~ 9不同的压缩级别，以降低网络传输压力。
两者混用效果奇佳，而且也是最常见最有效的方式
例如React.js的源文件有610k左右，uglify之后已经不到200k了，再通过nginx压缩一把，用户在浏览器下载时，只有40k左右了。
以当今的网络环境，除非自己有精确测试结果，否则真心没必要一开始就考虑什么文件大小的问题，咱们已经不是那个时代了
本回答被网友采纳
已赞过
已踩过<
评论
收起
你对这个回答的评价是？
推荐律师服务：
若未解决您的问题，请您详细描述您的问题，通过百度律临进行免费专业咨询
