webpack有做过哪些优化和配置吗

⑴ webpack打包原理

webpack打包原理是根据文件间的依赖关系对其进行静态分析，然后将这些模块按指定规则生成静态资源，当 webpack 处理程序时，它会递归地构建一个依赖关系图(dependency graph)，其中包含应用程序需要的每个模块，然后将所有这些模块打包成一个或多个 bundle。

webpack有两种组织模块的依赖方式，同步、异步。异步依赖将作为分割点，形成一个新的块；在优化了依赖树之后，每一个异步区块都将作为一个文件被打包。

webpack有一个智能解析器，几乎可以处理任何第三方库。无论它们的模块形式是CommonJS、AMD还是普通的JS文件；甚至在加载依赖的时候，允许使用动态表require("、/templates/"+name+"、jade")。

(1)webpack有做过哪些优化和配置吗扩展阅读

在使用webpack构建的典型应用程序或站点中，有三种主要的代码类型：

1、团队编写的源码。

2、源码会依赖的任何第三方的library或"vendor"代码。

3、webpack的runtime和manifest，管理所有模块的交互。

runtime 包含：在模块交互时，连接模块所需的加载和解析逻辑；包括浏览器中的已加载模块的连接，以及懒加载模块的执行逻辑。

⑵ 开源了一个 webpack 插件，希望对大家有所帮助

最近，陆陆续续搞 了一个 插件(下面介绍)，这是自己第三个开源项目，希望大家一起来维护，一起 star 呀，其它两个：

用 uniapp开发小程序的小伙伴应该知道，我们在 uniapp 中要使用第三方 UI 库( vant-weapp ， iView-weapp )的时候 ，想要在全局中使用，需要在 src/pages.json 中的 usingComponents 添加对应的组件声明，如：

但在开发过程中，我们不太清楚需要哪些组件，所以我们可能会全部声明一遍（PS:这在做公共库的时候更常见)，所以我们得一个个的写，做为程序员，我们绝不允许使用这种笨方法。 这是第一个痛点 。

使用第三方组件，除了在 src/pages.json 还需要在对应的生产目录下建立 wxcomponents ，并将第三方的库拷贝至该文件下，这个是 uniapp 自定义的，详细就见：https://uniapp.dcloud.io/frame?id=%e7%9b%ae%e5%bd%95%e7%bb%93%e6%9e%84。

这是第二个痛点 。

第二痛点，我们将整个UI库拷贝至 wxcomponents ，但最终发布的时候，我们不太可能全都用到了里面的全局组件，所以就将不必要的组件也发布上去，增加代码的体积。

有的小伙伴就会想到，那你将第三方的库拷贝至 wxcomponents 时候，可以只拷使用到的就行啦。是这理没错，但组件里面可能还会使用到其它组件，我们还得一个个去看，然后一个个引入，这又回到了 第一个痛点了 。

有了这三个痛点，必须得有个插件来做这些傻事，处理这三个痛点。于是就有 插件，这个webpack 插件主要解决下面几个问题：

webpack 的插件体系是一种基于 Tapable 实现的强耦合架构，它在特定时机触发钩子时会附带上足够的上下文信息，插件定义的钩子回调中，能也只能与这些上下文背后的数据结构、接口交互产生 side effect，进而影响到编译状态和后续流程。

从形态上看，插件通常是一个带有 apply 函数的类：

Webpack 会在启动后按照注册的顺序逐次调用插件对象的 apply 函数，同时传入编译器对象 compiler ，插件开发者可以以此为起点触达到 webpack 内部定义的任意钩子，例如：

注意观察核心语句 compiler.hooks.thisCompilation.tap ，其中 thisCompilation 为 tapable 仓库提供的钩子对象； tap 为订阅函数，用于注册回调。

Webpack 的插件体系基于 tapable 提供的各类钩子展开，所以有必要先熟悉一下 tapable 提供的钩子类型及各自的特点。

到这里，就不做继续介绍了，关于插件的更多 详情可以去官网了解。

这里推荐 Tecvan 大佬写的 《Webpack 插件架构深度讲解》

插件主要用到了三个 compiler 钩子。

第一个钩子是 environment :

这个钩子主要用来自动引入其下的原生组件，这样就无需手动配置。 解决第一个痛点 。

第二个钩子 thisCompilation ，这个钩子可以获得 compilation ，能对最终打包的产物进行操作：

所以这个勾子用来将 node_moles 下的第三库拷贝到我们生产 dist 目录里面的 wxcomponents ， 解决第二个痛点 。

ps：这里也可直接用现有的 -webpack-plugin 插件来实现。

第三个钩子 done ，表示 compilation 执行完成：

执行完成后，表示我们已经生成 dist 目录了，可以读取文件内容，分析，获取哪些组件被使用了，然后删除没有使用到组件对应的文件。这样就可以解决我们 第三个痛点了 。

PS：这里我判断只有在生产环境下才会 剔除，开发环境没有，也没太必要。

安装

然后将插件添加到 WebPack Config 中。例如：

NameType Description patterns{Array}为插件指定相关

moleprefix 模块名组件前缀

mole 是指 package.json 里面的 name ，如使用是 Vant 对应的 mole 为 @vant/weapp ，如果使用是 iview，刚对应的 mole 为 iview-weapp ，具体可看它们各自的 package.json 。

prefix 是指组件的前缀，如 Vant 使用是 van 开头的前缀，iview 使用是 i 开头的前缀，具体可看它们各自的官方文档。

PS: 这里得吐曹一下 vant，叫别人使用 van 的前缀，然后自己组件里面声明子组件时，却没有使用 van 前缀，如 picker 组件，它里面的 JSON 文件是这么写的：

picker-column 和 loading 都没有带 van 前缀，因为这个问题，在做 自动剔除 功能中，我是根据 前缀来判断使用哪些组件的，由于这里的 loading ， picker-column 没有加前缀，所以就被会删除，导致最终的 picker 用不了。为了解决这个问题，增加了不少工作量。

希望 Vant 官方后面的版本能优化一下。

本文通用自定义 Webpack 插件来实现日常一些技术优化需求。主要为大家介绍了 Webpack 插件的基本组成和简单架构，通过三个痛点，引出了 uni-using-components-webpack-plugin 插件，并介绍了使用方式，实现思路。

最后，关于 Webpack 插件开发，还有更多知识可以学习，建议多看看官方文档《Writing a Plugin》进行学习。

⑶ webpack 性能优化怎么做

送到这个直接去优化行动中应该能搞定优化生活，我认为这应该是小孩儿为什么还是凉的。

⑷ webpack 打包怎么优化的

解决webpack打包的文件体积过大的问题：
确实，每次打包从入口开始，会parse所有的依赖，多的时候竟然打包一次要2秒多，简直不能忍。然而，有几个解决方案，最有效的，是使用weboack的watch，只有文件md5变化时，才会重新打包，并且只parse有变化的文件，其他没变化的文件是使用缓存的。这样子，打包时间迅速降到200ms以内。 再优化下去的话，我们要知道webpack打包的过程中做了啥，首先是解析依赖啦，然后就是各种各样的loader。从解析依赖的角度入手，我们可以bower install一些打包好的文件，然后通过设置别名让依赖指向这个文件，这样就减去了第三方库的依赖解析时间。 然后各种各样的loader也是很耗时的，一种办法是在loader里面配include，让loader只针对特殊资源。

⑸ webpack承担了哪些工作原理功能

承担了很多前端代码的自动化生成的工作。
搭配很多loader，可以完成不同的事情。
比如说把繁杂的项目中用到的js打包并压缩成你设定的一个或多个文件去发布到生产环境。
比如把react中引用的图片压缩并抽出来项目中引用到的。没引用到的，不会拿过来。
比如CSS Moles，单个组件开发时用单独的css定义，最终打包成一个css文件里，而没用到的css不会打包。而且通过设置，不用担心各个文件中的同名css打包到一个css里后重复。
less转css
sass转css
PostCSS转css
es6写的js，通过babel转成浏览器可执行的es5
......
原理，其实就是用程序代替人的工作。比如我们开发的时候经常是css写到一个或几个文件，随着迭代，里面肯定就产生很多垃圾不再用的代码，而用人去识别很累，如果用CSS Moles，把css也模块化，随着迭代，不再引用到的，就不会再打包进去，不用人来识别了。同理，浏览器是不识别sass这种的，程序来帮你转成浏览器可读的css。不管用什么程序，其实都可以开发这样的一个解释器，其实就是一个翻译转化的过程。只不过当前前端的发展需要和node的便捷加上npm方便的分发，所以在node中，大量的工具出现了。
其实原理和功能，就是用程序代替人做那些事，由程序翻译成普通浏览器可执行的代码。

⑹ 2020年Web前端性能优化需要做哪些

今天小编要跟大家分享的文章是关于2020年Web前端性能优化需要做哪些?性能优化一直以来都是前端工程领域中的一个重要部分。很多资料表明，网站应用的性能优化对于提高用户留存、转化率等都有积极影响。可以理解为，提升你的网站性能，就是提升你的业务数据(甚至是业务收入)。

性能优化广义上包含前端优化和后端优化。后端优化的关注点更多的时候是在增加资源利用率、降低资源成本以及提高稳定性上。相较于后端，前端的性能优化会更直接与用户的体验挂钩。从用户体验侧来说，前端服务
5s的加载时间优化缩减80%(1s)与后端服务50ms的响应优化缩减80%(10ms)
相比，用户的体验提升会更大。因此很多时候，与体验相关的性能的瓶颈会出现在前端。下面就来和小编一起看一看吧!


一、html文档结构标签语义化


1、首先什么是语义化呢?


语义化是指用合理HTML标记以及其特有的属性去格式化文档内容。机器在需要更少的人类干预的情况下能够研究和收集信息,让网页能够被机器理解,最终让人类受益。即用正确的标签做正确的事。


2、语义化的好处或者说存在的意义


①有利于搜索引擎抓取


②结构清晰的HTML在团队合作中的作用：代码可读、便于维护、提高开发效率、快速达成共识、利于二次开发。


③有利于盲人屏幕阅读器


二、css、js文件数量及大小


优化一般对于css、js是建议使用外联式来进行导入。我们可以对css、js做相应的规划也可以减少css、js的个数以减少http请求。同时也要注重减少重复代码，注重代码重复利用，以达到用最少的代码干最多的事。同时当项目要投入上线使用的时候，可以对css、js文件进行压缩，文件的减小可以加速文件的链接导入，以便加速网页的加载渲染。


可通过使用Webpack，gulp等工具对Js文件进行合并。


三、图片的数量和大小


多个服务器请求会对站点的性能产生显着的影响。对一张图片进行导入又是一个http请求，因此我们应该减少图片的导入数量以便减少http请求。此处，我们必须提到一个名词“css精灵spirit”。css精灵是指包含多个不同的图标、按钮或图形的单个图像。因此我们可以把多张背景图片合并为一张然后对背景图片进行相应的定位。同时使用PNG8格式的图片相对于GIF来说比较少。而对于内容图片，可以对其进行适当的压缩，可以加快文档内容加载，或者如果是需要用户下载的图片，小的图片可以加快用户下载的速度。


使用较为广泛的Web图片格式有：JPEG/JPG、PNG、WEBP、Base64、SVG。


1.JPEG/JPG


特点是有损压缩，体积小，加载快，不支持透明。


使用场景：JPG适合用于呈现热菜丰富的图片，在日常的开发中，JPG图片经常作为大的背景图、轮播图或是Banner图。比如两大电商网站对大图片的处理，就是对JPG图片应用场景的最佳写照。用JPG来呈现大图片，既可以保留图片的质量，又不会担心图片的体积，是一种比较广泛使用的方案。


缺点：在处理一些矢量图形和logo等这些线条感很强、颜色对比强烈的图片时，认为压缩就导致图片模糊非常明显。另外，JPG图像不支持透明度处理，透明图片只能用PNG来呈现了。


2.PNG-8和PNG-24


特点是无损压缩、质量高、体积大、支持透明


优点：无损压缩的高保真图片格式。8和24都是二进制数的位数，8位的PNG支持256中颜色，24位的PNG可以支持1600万种颜色。在不考虑文件大小只在乎最佳的显示效果时，推荐使用PNG-24。但是在适合使用PNG时会优先选择PNG-8


应用场景：主要用PNG来呈现小的LOGO、颜色简单对比强烈的图片或是背景。


3.SVG


特点是文本文件，体积小，不失真，兼容性好


优点：SVG是一种基于XML语法的图像格式。SVG对图像的处理不是基于像素，而是基于对图像的形状描述。


和JPG、PNG相比较，SVG文件体积更小，可压缩性更强。SVG作为矢量图最大的优点在于图片可以无限放大还不失真，一张SVG图片可以适配多种分辨率。另外SVG是文本文件，可以像写代码一样定义SVG，放在HTML中称为DOM的一部分。也可以把对图像的描述写入以.svg为后缀的文件中，在img标签中引入即可。


4.WebP


优点：WebP是一款比JPG、PNG等在压缩方面更加优越的图片格式，同时也不会影响其图片质量，使用该格式时最好将同名文件格式化，当检测浏览器不兼容时自动切换jpg格式


缺点：是一个相对较新的技术，所以对于目前市面上的浏览器能否完美的兼容，其可用和实用性就变得很现实了，再好的东西如果没有好的兼容性，也是非常难以普及和被广泛使用的


5.Base64


优点：减少请求，加快首屏数据显示。对于jpg格式的图片，每一个图片相当于一次http请求，图片多了的话，服务器耗性能比较严重。而将jpg转化成base64格式的图片，则极大地减少了请求数，因为Base是文本格式。


缺点：base64格式图片比原图大，占用更多存储空间，同时，浏览器不会对该资源缓存。


使用方法：background:url(data:image/png;base64,{img_data})


应用场景：一般对于小于10KB大小的图片进行base64转码。


至于动态图有GIF与APNG：后者APNG这东西是mozilla搞出来的，
它是24位的，而且也是动图，可以容纳1680万种颜色，也是为了取代GIF，但是....也就火狐支持，IE10和chrome，safari全部不行，
如果说gif图片是卡片机的话，APNG就是单反


四、有效性验证


除了根据语义加标记之外，HTML文档还需要用有效的代码来编写，如果代码是无效的，浏览器会尝试解释标记本身，有时候会产生错误的结果。更糟的是，如果发送具有正确的MIME类型的XHTML文档，理解XML的浏览器将不显示无效的页面。因为浏览器需要知道要使用什么DTD(文档类型定义)才能正确地处理页面，所以对页面进行有效性验证要求有DOCTYPE声明。


有效性验证工具径：


①
W3C验证器(bookmarklet)，这是一小段可以存储在浏览器的书签或收藏夹中的Javascript。单击这个书签就会触发Javascript动作。


②可以访问http://validator.w3.org/，通过输入自己的URL来对自己的站点来进行在线验证。


③使用firefox浏览器的可以下载插件FirefoxWebDeveloperExtension


五、雅虎的Web优化最佳实践


1、内容优化


①尽量减少HTTP请求：常见方法包括合并多个CSS文件和JavaScript文件，利用CSSSprites整合图像，Image
map(图像中不同的区域设置不同的链接)，内联图象(使用data:URLscheme在实际的页面嵌入图像数据)等。


②减少DNS查找，一般dns查找需要花费20-120ms，Windows的DNS缓存，可以通过ipconfig/displaydns
这个命令来查看。


③避免重定向


④使Ajax可缓存


⑤延迟加载组件：考虑哪些内容是页面呈现时所必需首先加载的、哪些内容和结构可以稍后再加载，根据这个优先级进行设定。


⑥
预加载组件：预加载是在浏览器空闲时请求将来可能会用到的页面内容(如图像、样式表和脚本)。当用户要访问下一个页面时，页面中的内容大部分已经加载到缓存中了，因此可以大大改善访问速度。


⑦减少DOM元素数量：页面中存在大量DOM元素，会导致JavaScript遍历DOM的效率变慢。


⑧根据域名划分页面内容：把页面内容划分成若干部分可以使你最大限度地实现平行下载。但要确保你使用的域名数量在2个到4个之间(否则与第2条冲突)。


⑨最小化iframe的数量：iframes
提供了一个简单的方式把一个网站的内容嵌入到另一个网站中。但其创建速度比其他包括JavaScript和CSS的DOM元素的创建慢了1-2个数量级。


⑩
避免404：HTTP请求时间消耗是很大的，因此使用HTTP请求来获得一个没有用处的响应(例如404没有找到页面)是完全没有必要的，它只会降低用户体验而不会有一点好处。


2、服务器优化


①使用内容分发网络(CDN)：把你的网站内容分散到多个、处于不同地域位置的服务器上可以加快下载速度。


添加Expires或Cache-Control信息头：对于静态内容，可设置文件头过期时间Expires的值为“Never
expire(永不过期)”;对于动态内容，可使用恰当的Cache-Control文件头来帮助浏览器进行有条件的请求。


②Gzip压缩


③设置ETag：ETags(Entity
tags，实体标签)是Web服务器和浏览器用于判断浏览器缓存中的内容和服务器中的原始内容是否匹配的一种机制。


④
提前刷新缓冲区：当用户请求一个页面时，服务器会花费200到500毫秒用于后台组织HTML文件。在这期间，浏览器会一直空闲等待数据返回。在PHP中，可以使用flush()方法，它允许你把已经编译的好的部分HTML响应文件先发送给浏览器，这时浏览器就会可以下载文件中的内容(脚本等)而后台同⑤时处理剩余的HTML页面。


⑥
对Ajax请求使用GET方法：当使用XMLHttpRequest时，浏览器中的POST方法会首先发送文件头，然后才发送数据。因此使用GET最为恰当。


⑦避免空的图像src


3、Cookie优化


①减小cookie大小：去除不必要的coockie，并使coockie体积尽量小以减少对用户响应的影响


②
针对Web组件使用域名无关的Cookie：对静态组件的Cookie读取是一种浪费，使用另一个无Cookie的域名来存放静态组件是一个好方法，或者也可以在Cookie中只存放带www的域名。


4、CSS优化


①将CSS代码放在HTML页面的顶部


②避免使用CSS表达式：CSS表达式在执行时候的运算量非常大，会对页面性能产生大的影响


③使用来代替@import


④避免使用Filters：IE独有属性AlphaImageLoader用于修正IE
7以下版本中PNG图片的半透明效果，但它的问题在于浏览器加载图片时它会终止内容的呈现并且冻结浏览器。


5、JavaScript优化


①将JavaScript脚本放在页面的底部


②
将JavaScript和CSS作为外部文件来引用：在实际应用中使用外部文件可以提高页面速度，因为JavaScript和CSS文件都能在浏览器中产生缓存。


③缩小JavaScript和CSS


④删除重复的脚本


⑤最小化DOM的访问：使用JavaScript访问DOM元素比较慢


⑥开发智能的事件处理程序


6、图像优化


①优化图片大小


②通过CSSSprites优化图片


③不要在HTML中使用缩放图片


④favicon.ico要小而且可缓存


7、针对移动优化


①保持组件大小在25KB以下：主要是因为iPhone不能缓存大于25K的文件(注意这里指的是解压缩后的大小)。


②将组件打包成为一个复合文档：把页面内容打包成复合文本就如同带有多附件的Email，它能够使你在一个HTTP请求中获取多个组件。


以上就是小编今天为大家分享的关于2020年Web前端性能优化需要做哪些的文章，希望本篇文章能够对正在从事Web前端工作的小伙伴们有所帮助，想要了解更多Web前端知识记得关注北大青鸟Web培训官网。最后祝愿小伙伴们工作顺利，成为一名优秀的Web前端工程师。

⑺ 前端构建工具webpack有什么缺陷

1. 配置多入口时，没有glob的方式，需要额外处理。

2. 目录结构复杂时，file-loder里面的path功能太弱，很多时候无法自定义构建后的目录结构，只能放在一个目录下。

3. 源码比较复杂，遇到问题看源码，要花很长时间。

4. 如果没有 babel， webpack 对 ES2015+ 的语法是不接受的，会提示用指定 loader。这意味着，在支持部分 ES2015 语法的 firefox 与 chrome 浏览器中能直接跑的代码，无法用 webpack 编译。
   

⑻ webpack到底有什么用

1. 为什么用 webpack?
他像 Browserify, 但是将你的应用打包为多个文件. 如果你的单页面应用有多个页面, 那么用户只从下载对应页面的代码. 当他么访问到另一个页面, 他们不需要重新下载通用的代码.
他在很多地方能替代 Grunt 跟 Gulp 因为他能够编译打包 CSS, 做 CSS 预处理, 编译 JS 方言, 打包图片, 还有其他一些.
它支持 AMD 跟 CommonJS, 以及其他一些模块系统, (Angular, ES6). 如果你不知道用什么, 就用 CommonJS.
2. Webpack 给 Browserify 的同学用
对应地:
browserify main.js > bundle.js

webpack main.js bundle.js

Webpack 比 Browserify 更强大, 你一般会用 webpack.config.js 来组织各个过程:
// webpack.config.js
mole.exports = {
entry: './main.js',
output: {
filename: 'bundle.js'
}
};

这仅仅是 JavaScript, 可以随意添加要运行的代码.
3. 怎样启动 webpack
切换到有 webpack.config.js 的目录然后运行:
webpack 来执行一次开发的编译
webpack -p for building once for proction (minification)
webpack -p 来针对发布环境编译(压缩代码)
webpack --watch 来进行开发过程持续的增量编译(飞快地!)
webpack -d 来生成 SourceMaps
4. JavaScript 方言
Webpack 对应 Browsserify transform 和 RequireJS 插件的工具称为 loader. 下边是 Webpack 加载 CoffeeScript 和 Facebook JSX-ES6 的配置(你需要 npm install jsx-loader coffee-loader):
// webpack.config.js
mole.exports = {
entry: './main.js',
output: {
filename: 'bundle.js'
},
mole: {
loaders: [
{ test: /\.coffee$/, loader: 'coffee-loader' },
{ test: /\.js$/, loader: 'jsx-loader?harmony' } // loaders 可以接受 querystring 格式的参数
]
}
};

要开启后缀名的自动补全, 你需要设置 resolve.extensions 参数指明那些文件 Webpack 是要搜索的:
// webpack.config.js
mole.exports = {
entry: './main.js',
output: {
filename: 'bundle.js'
},
mole: {
loaders: [
{ test: /\.coffee$/, loader: 'coffee-loader' },
{ test: /\.js$/, loader: 'jsx-loader?harmony' }
]
},
resolve: {
// 现在可以写 require('file') 代替 require('file.coffee')
extensions: ['', '.js', '.json', '.coffee']
}
};

5. 样式表和图片
首先更新你的代码用 require() 加载静态资源(就像在 Node 里使用 require()):
require('./bootstrap.css');
require('./myapp.less');

var img = document.createElement('img');
img.src = require('./glyph.png');

当你引用 CSS(或者 LESS 吧), Webpack 会将 CSS 内联到 JavaScript 包当中, require() 会在页面当中插入一个 ｀<style>标签. 当你引入图片, Webpack 在包当中插入对应图片的 URL, 这个 URL 是由require()` 返回的.
你需要配置 Webpack(添加 loader):
// webpack.config.js
mole.exports = {
entry: './main.js',
output: {
path: './build', // 图片和 JS 会到这里来
publicPath: 'http://mycdn.com/', // 这个用来成成比如图片的 URL
filename: 'bundle.js'
},
mole: {
loaders: [
{ test: /\.less$/, loader: 'style-loader!css-loader!less-loader' }, // 用 ! 来连接多个人 loader
{ test: /\.css$/, loader: 'style-loader!css-loader' },
{test: /\.(png|jpg)$/, loader: 'url-loader?limit=8192'} // 内联 base64 URLs, 限定 <=8k 的图片, 其他的用 URL
]
}
};

6. 功能开关
有些代码我们只想在开发环境使用(比如 log), 或者 dogfooging 的服务器里边(比如内部员工正在测试的功能). 在你的代码中, 引用全局变量吧:
if (__DEV__) {
console.warn('Extra logging');
}
// ...
if (__PRERELEASE__) {
showSecretFeature();
}

然后配置 Webpack 当中的对应全局变量:
// webpack.config.js

// definePlugin 接收字符串插入到代码当中, 所以你需要的话可以写上 JS 的字符串
var definePlugin = new webpack.DefinePlugin({
__DEV__: JSON.stringify(JSON.parse(process.env.BUILD_DEV || 'true')),
__PRERELEASE__: JSON.stringify(JSON.parse(process.env.BUILD_PRERELEASE || 'false'))
});

mole.exports = {
entry: './main.js',
output: {
filename: 'bundle.js'
},
plugins: [definePlugin]
};

然后你在控制台里用 BUILD_DEV=1 BUILD_PRERELEASE=1 webpack 编译. 注意一下因为 webpack -p 会执行 uglify dead-code elimination, 任何这种代码都会被剔除, 所以你不用担心秘密功能泄漏.
7. 多个进入点(entrypoints)
比如你用 profile 页面跟 feed 页面. 当用户访问 profile, 你不想让他们下载 feed 页面的代码. 因此你创建多个包: 每个页面一个 "main mole":
// webpack.config.js
mole.exports = {
entry: {
Profile: './profile.js',
Feed: './feed.js'
},
output: {
path: 'build',
filename: '[name].js' // 模版基于上边 entry 的 key
}
};

针对 profile, 在页面当中插入 <script src="build/Profile.js"></script>. feed 页面也是一样.
8. 优化共用代码
feed 页面跟 profile 页面共用不要代码(比如 React 还有通用的样式和 component). Webpack 可以分析出来他们有多少共用模块, 然后生成一个共享的包用于代码的缓存.
// webpack.config.js

var webpack = require('webpack');

var commonsPlugin =
new webpack.optimize.CommonsChunkPlugin('common.js');

mole.exports = {
entry: {
Profile: './profile.js',
Feed: './feed.js'
},
output: {
path: 'build',
filename: '[name].js'
},
plugins: [commonsPlugin]
};

在上一个步骤的 script 标签前面加上 <script src="build/common.js"></script> 你就能得到廉价的缓存了.
9. 异步加载
CommonJS 是同步的, 但是 Webpack 提供了异步指定依赖的方案. 这对于客户端的路由很有用, 你想要在每个页面都有路由, 但你又不像在真的用到功能之前就下载某个功能的代码.
声明你想要异步加载的那个"分界点". 比如:
if (window.location.pathname === '/feed') {
showLoadingState();
require.ensure([], function() { // 语法奇葩, 但是有用
hideLoadingState();
require('./feed').show(); // 函数调用后, 模块保证在同步请求下可用
});
} else if (window.location.pathname === '/profile') {
showLoadingState();
require.ensure([], function() {
hideLoadingState();
require('./profile').show();
});
}

Webpack 会完成其余的工作, 生成额外的 chunk 文件帮你加载好.
Webpack 在 HTML script 标签中加载他们时会假设这些文件是怎你的根路径下. 你可以用 output.publicPath 来配置.
// webpack.config.js
output: {
path: "/home/proj/public/assets", // path 指向 Webpack 编译能的资源位置
publicPath: "/assets/" // 引用你的文件时考虑使用的地址