前者图片引入形式神演算

2017/01/11 · 基础技术 ·
图片

原文出处： 沐洒（@Musa沐洒）   

| 导语
本文只提供推理形式和分析方法，不有限支撑样本及计算的精准性，慎读！！！

先演说一下背景：

大家社团对此图片的行使办法有一个明文规定如下：

1. 大凡需求联合百事可乐图，或是编码base64的图片，均放入slice目录下对应模块目录里，gulp-postcss会统一编译处理。
2. 直接以单图格局引入页面的图纸，放在page/aaa/bbb/img目录下（aaa表示事情单元，bbb表示具体页面），使用相对路径./xxx.png直接引用。
3. 大局复用的单图，放入common/img目录下。

目录结构大体上是以此样子：

那就是大家前几天的议题。

旗帜明显，页面内图片的引入方式相似有那3种：7-Up图，base64内联，普通单图。（canvas,svg等格外格局不在此次议题里），先简单解析一下二种格局的优逆风局：

哦，几乎的景色是那般的，然后我来多少增添解释一下：

1.
base64图本身确实不可能缓存，可是base64图一般是存在于css里的，那么就足以随着css被缓存而落到实处直接缓存，所以它的缓存属性不是“无”。说它“差”是因为并不是一向被用作图片缓存。当然借使是一直写在html里的，那就无奈缓存了，这么些要留心。

2.
base64额外伸张html/css大小并不是任重而道远难题，难题是，因而造成的渲染堵塞有时候是致命的！而作为图片文件加载则不设有那一个难题，因为图片是不会堵塞到html和css加载的，因此也不会影响首屏渲染。（当然了，你非要把img标签写在style前面那我只能说，哥，我服~~~~）

打探了三种艺术的优逆风局之后，对于使用处境简单概括一下：

1. 页面自身独有的图片，全体合并成一张Sprite图。

2.
共用模块或者国有组件，假若含有多张图片，则分别为阵合并各自的Sprite图；假若唯有一多个图片，或者隐含有可以被其余模块、组件、页面复用的图纸，则应用灵活性好的单图格局或base64方式。

可是那种说法遗留了一个难题：例如所有页面都有些吊顶区域，要是那里有一个小图，注意，是一个喔（要是是过多的话就集合啦），那种时候是一直单图引入呢？如故base64内嵌到吊顶的css里？

好像二者都得以是吧，用单图的便宜就是自家在首页缓存后，逛其余页面时候就绝不再加载了，当然了首页就会多一个呼吁；而用base64形式，会少一个图纸请求，但会扩大吊顶css的文件大小，从而直接增添了首页的渲染堵塞时间。好啊，又TMD陷入了纠结。。。

别急！

下边我们再对base64方式做一个大约的解析：

先明了大家对此base64图片逆风局的控诉点在于，1：丫会增大原始图片文件；2：植入css之后会附加css文件大小。

做一个概括的试验，我把多少个全局平日出现的小图标，用base64编码，结果：

平均增大35%

但是！

gzip压缩后 —— 4%~40%，平均增大22%

理所当然样本少是一个难点，但大体的大家还是能看出来一些端倪：base64确实会叠加文件，而且就是做了gzip后步长依旧居高不下。那也是干吗大家一般不会对大图片进行base64编码的来头，即使对一张100KB的图形编码，将会增多20-30KB！那是蛮害怕的了。但我们现在说的是小图片呀，一个小图片1KB左右，即便增大30%也就扩张三百多字节而已。

大家想想的更进一步，究竟什么样的文件大小增幅，是我们可以接受的？

一个常识，普通人的肉眼可识其他视觉暂留是50ms。而根据连年前端实战经验，对于网页渲染速度，肉眼可敏感识其余渲染时长间隔是500ms，所以一般一个css3衔接效果，transition-duration
为0.3s和0.8s才会有举世瞩目不一致，而0.3s和0.5s的分别，除了号称“像素眼”的重构同学和有细节控的设计师能感知外，一般人很难显著感知。

那就是说因而我们是或不是大约的汲取一个定论：对于首屏渲染时间的裁减或扩大，用户可显然感知的浮动范围是50ms-500ms之间，也就是说，即便你优化做得再好，小于50ms的变更，是不会被感知的，另一方面，借使你因为某个原因增加了首屏渲染时间500ms，就会爆发一个很大的感官变化。

好了，这么说来，大家能承受的文件大小增幅，所导致的首屏渲染时间净增，应该控制在500ms内。对于身处集团内网的大家而言，M/s的快慢显然不用理会那个细节，500ms可以轻松加载几MB的资源，就终于普通用户，现在宽带全体进程都6得飞起，500ms加载几百KB应该小难点吧。

唯独！我们不能这么想啊，做产品的会把用户作为小白，大家做开发优化是还是不是也相应若是用户还停留在拨号上网时代？哈哈哈，开玩笑了，那倒不至于，但大家真的可以即使用户网速很相似，100kb/s的网页加载速度，对友好够狠了呢我。

根据网速100kb/s的要是，500ms可以加载50kb的资源。。。。等等！总觉得哪个地方不对！

一个文件的加载，应该包罗了这个个进度:

故而大家理论上“500ms可以加载50kb的资源”，指的是download那里的进度而已，可是一个小图片从呼吁到渲染，必要经过请求排队，请求堵塞，等待响应，下载等诸多环节。。。那么500ms我们到底能加载多大的文件呢？那些题材本身实在回答不了，因为那关系到的环境变量太多了，请求堵塞，网速抖动，浏览器版本，服务器速度，dns解析等等都有可能影响到那个结果。那。。。小说写不下来了如何做。。。无法扬弃治疗啊！那么大家简直就越来越大约一点估价好了，就像果那500ms中，唯有250ms是给大家用来下载资源的，那么100kb/s的快慢大家可以下载25kb的资源，嗯。。。。看起来还蛮是言之有理的吗。。。。

我们多找几张小图看一下timing的遍布：（10kb以内）

有没有觉察一个法则？对于10kb以下的小图而言，下载时间莫过于大致能够忽略不计（1%左右），而真正占据贷款的是那三遍次伸手经历的长久的流水线（请求排队，请求堵塞，等待响应….）

增补表明：当图片大小增添到100kb以上时，下载耗时平均是总耗时的50%不到。

透过地点一大推的演绎和范本测试后，我们获取了一些对立合理的参数值，接下去要抛大招（统计公式）了！

到头来！我们得到了大家想要的测算结果！2.6倍base64图片总大小的下载时间，是大家增添的首屏负荷。在此以前大家早就说了，在不影响用户感官鲜明转变的情事下，大家仁义的同意多500ms的下载时间，在100kb/s的弱网条件下，最终统计出，允许内嵌的base64图片大小是20kb！20kb！20kb！那和大家恰好大致估摸的25kb很相近啊！看来有点时候总结无力的情景下推测还点可信的。。。

乖巧的自己经过一多元估摸后，得出了一个恶性但非常有意义的答案！意义在于，我到底了解什么大小的图形叫做小图片啦！！！不知情那几个历史性难点难倒了有些重构GG！

可以吗，别打我，我了然自家的臆度有点暴力。。。。

Anyway！我在篇章副标题里就说了，

本文只提供推理格局和分析方法，不保险样本及总结的精准性，慎读！！！

讲真，我的切入点和分析方法应该是尚未难题的对吧各位？只是那其间须要统计的数值实在涉及到太多不明显，我表示暂时受到那么一丢丢苦恼，所以就先预计之，感兴趣的同桌可以按照此措施重新总括哈。

做这么些蛋疼的商讨，终归如故要回归到事情上的，那么我们文章先导的疑难是还是不是曾经缓解了呢？经过我们一步步的推理和通俗，难点着力解决了。

上面不难归咎一下不比景色所应有选取的图纸引入格局：（正经脸 -_前端图片引入格局神演算，页面里有用武之地吗。- !!!）

• 全局通用的，非特定页面或模块独有的图纸，采纳单图或base64形式引入，二者分别如下：
  • 若该图片在多处选择或图片本身较大（那类图完全积大于20kb），则使用单图情势
  • 若该图形唯有少数地方采纳且图片本身较小（那类图总体积小于20kb），则动用base64格局

• 国有模块/组件里的图样（若是该模块名为mod-prd）
  • 模块内有N(N>=3)个图片，则整体放入**slice/mod/prd**里，使用Coca Cola图方式，否则参照全局通用图片处理格局

• 页面自身独有的图样，全体联结成一张Pepsi-Cola图

装逼停止，轻喷~

2 赞 3 收藏
评论

图片资源 Base64 化在 H5 页面里有用武之地吗

2016/12/15 · HTML5 ·
Base64

初稿出处：
坑坑洼洼实验室   

将图纸资源转至base64格式后可径直放入页面作为首屏直出，也足以放入css文件中，裁减请求，以加快首屏的突显速度。
可是图片base64化，将拉动一个重合的html或css文件，是还是不是会影响页面的渲染质量，浏览器又帮助什么呢？

小编：刘轶斌，腾讯动用开发 工程师 商业转发请联系腾讯WeTest得到授权，非商业转载请申明出处。 原文链接：http://wetest.qq.com/lab/view/345.html

当今移动互连网已经占到整个互联网流量的一半，而随着HTML5业内的出台，作为前端工程师们很有要求研讨一下如何优化HTML5在运动设置上的特性表现。首先大家须求显然以下多少个原则：

什么样总计？

透过Navigation
提姆ing记录的关键时间点来总括页面完毕所用的时光，并因而Chrome开发工具来跟踪细节

JavaScript

var timing = window.performance.timing timing.domLoading
//浏览器初叶解析 HTML 文档第一批接受的字节 timing.domInteractive //
浏览器已毕解析并且有所 HTML 和 DOM
营造完毕timing.domContentLoaded伊芙ntStart //DOM
解析已毕后，网页内资源加载开头的时日 timing.domContentLoaded伊芙ntEnd
//DOM 解析完毕后，网页内资源加载成功的日子（如 JS 脚本加载执行完成）
timing.domComplete //网页上保有资源（图片等） 下载已毕,且准备妥当的年华

1 2 3 4 5

var timing = window.performance.timing timing.domLoading //浏览器开始解析 HTML 文档第一批收到的字节 timing.domInteractive // 浏览器完成解析并且所有 HTML 和 DOM 构建完毕timing.domContentLoadedEventStart //DOM 解析完成后，网页内资源加载开始的时间 timing.domContentLoadedEventEnd //DOM 解析完成后，网页内资源加载完成的时间（如 JS 脚本加载执行完毕） timing.domComplete //网页上所有资源（图片等） 下载完成,且准备就绪的时间

以上定义来自chrome官方文档，在其余环境下可能会有出入，从测试结果看，上边的build时间在android+微信环境中一向是0，对此可能是因为渲染机制差异，此处不做深切测试。除osx+chrome之外环境的多寡仅作参考。

JavaScript

build = timing.domComplete – timing.domContentLoaded伊芙ntStart
//间隔记录网页内资源加载和突显时间。 complete = timing.domComplete –
timing.domLoading //页面接收到多少开始到展现完结的总时间。

1 2	build = timing.domComplete – timing.domContentLoadedEventStart //间隔记录网页内资源加载和呈现时间。 complete = timing.domComplete – timing.domLoading //页面接收到数据开始到呈现完毕的总时间。

一、怎样优化

用户在访问网页时，
最直观的感想就是页面内容出来的快慢，大家要做的优化办事，
也重点是为了那几个目的。那么为了进步页面加载（或者渲染）速度吗？一般的话有七个方面：

亚洲必赢官网，1、代码逻辑：杰出的代码逻辑结构可以使得压缩渲染页面使用的内存和进程（比如虚拟DOM），此方面不在本文切磋范围内。

2、SSR服务器渲染，也就是所谓的“直出”。将首屏所有内容在劳务器端渲染成html静态代码后，直接出口给浏览器，可以使得加快用户访问站点时首屏的加载时间。然而此方面也不在本文商讨范围内。

3、提高静态文件的加载速度，这是本文种商量的点，而那方面大略又可分为下面几点：

— 加速静态文件下载速度

— 裁减静态文件的文件大小

—
收缩静态文件请求数量，从而减弱发起呼吁的次数（对于活动端页面来说，请求的付出比网速的开发要大）

• PC优化手段在Mobile侧同样适用；

场景1，内嵌至css文件中

（一）代码压缩

最健康的优化手段之一。

大家在平日付出的时候，JS脚本文件和CSS样式文件中的代码，都会基于一定的代码规范（比如javascript-standard-style）来增加项目的可维护性，以及社团之间同盟的频率。

只是在项目揭露现网后，
这几个代码是给客户端（浏览器）识其他，此时代码的命名规范、空格缩进都已没有须要，大家得以应用工具将那些代码进行模糊和削减，收缩静态文件的深浅

此间大家采纳选取 Webpack，具体会在前面介绍。

1. 在Mobile侧大家提议三秒种渲染落成首屏目的；
2. 据悉第二点，首屏加载3秒完毕或选择Loading；
3. 按照联通3G互连网平均338KB/s(2.71Mb/s)，所以首屏资源不应当先1014KB；
4. Mobile侧因手机配置原因，除加载外渲染速度也是优化重点；
5. 按照第五点，要客观处理代码收缩渲染损耗；
6. 据悉第二、第五点，所有影响首屏加载和渲染的代码应在拍卖逻辑中前置；
7. 加载成功后用户交互使用时也需注意品质。

1、原生引入图片链接做背景图

一张大小为50kb的jpg格式图形，应用到9×15=135个dom做背景图，模拟Pepsi-Cola图的方式，四个节点引用同一张图片做背景，（示例）如图。

测试环境：Mac OS X EI Capitan 10.xx + Chrome 48.xx
其它辅助测试机器： iPhone 6 plus iOS 9.xx； 魅族Note Android 4.xx

其实运用进程中，其余版本和机型的Android手机还有待测试

关门缓存状态下，build:150ms | complete:
200ms（总时间受网络状态等因素影响，数据做比较用）

翻开缓存状态下，build: 7ms | complete:
59ms（包含以下稳定景况下往往测试的平均值，截图为最相近平均值的景色，默许数据出自Mac+Chrome[48.XX版本]）

测试环境	build(单位:ms)	complete(单位:ms)
OS X+Chrome	7	59
iOS+微信	45	90
OS X+Safari	50	100
Android+微信	0	120

（二）文件合并

在npm流行的前几日，前端在展开项目支出的时候，往往会选取过多第三方代码库，比如jQuery，axios，weixin-js-sdk，lodash，bootstrap等等，每个库都有属于自己的剧本或者样式文件。

安分守己最老的办法的话，大家会用<script> 标签或者<style>标签分别引入那么些库文件，导致在开辟一个页面的时候会发起几十个请求，那对于活动端的话是不足接受的。

在调减文件请求数量方面大略有以下三方面：

1、合并js脚本文件

2、合并css样式文件

3、合并css引用的图纸，使用sprite百事可乐图。

对于 雪碧图 ，大家得以把页面上用到的多少个繁缛的小图片合并成一个大图片，把N个图片请求合并成了一个。然后在css样式中指定图片偏移，来贯彻突显不一样的图片，如下图：

那里大家继承拔取使用Webpack，具体会在后面介绍。

上面大家就从地方8点出手分多少个方面对活动端的HTML5属性举行优化：

2、引入base64格式图片做背景图

将上边50kb大小的jpg图片转换为base64格式，加在css文件中。

关门缓存状态下，build:80ms | complete: 280ms

敞开缓存状态下，build: 160ms | complete: 210ms

测试环境	build(单位:ms)	complete(单位:ms)
OS X+chrome	160	210
iOS+微信	35	100
OS X+Safari	9	90
Android+微信	12	150

（三）gzip

大家的文书在缩减合并之后，文件大小和文件数量都有了客观的缩减。可是即使站点业务逻辑多了，或者引入的第三方库多了后头，对于移动端的话，文件大小仍然不太乐观。

这一个时候就是gzip压缩登场的时候呀~我们在webpack的配置中伸张gzip压缩配置：

下面代码会对文件大小大于10240，并且压缩率好于0.8的js、css文件举行gzip压缩，执行打包代码后生成结果文件如下：

咱俩可以见见除了原有的js和css文件外，大家还得到了压缩后的gz文件。

把富有这一个文件一起陈设到服务器上。（当然也足以间接nginx或其余web
server配置gzip压缩）

大家可以观望vendor.[hash].js文件的大大小小分明滑坡，从318kb收缩到了不到100kb。

第一步：加载优化

---

• 减少HTTP请求。
  　因为手机浏览器同时响应请求为4个请求（Android援救4个，iOS
  5后可支撑6个），所以要尽量减弱页面的呼吁数，首次加载同时伸手数不可能超越4个。
  　a) 合并CSS、JavaScript；
  　b) 合并小图片，使用百事可乐图（CSS SPRITE）；

• 缓存。
  　使用缓存可以减去向服务器的哀求数，节省加载时间，所以具有静态资源都要在服务器端设置缓存，并且尽量利用长Cache（长Cache资源的创新可拔取时间戳）。
  　a) 缓存一切可缓存的资源；
  　b) 使用长Cache（使用时间戳更新Cache）；
  　c) 使用外联式引用CSS、JavaScript；

• 压缩HTML、CSS、JavaScript。
  　减弱资源大小可以加速网页突显速度，所以要对HTML、CSS、JavaScript等举办代码压缩，并在服务器端设置GZip。
  　a) 压缩（例如，多余的空格、换行符和缩进）；
  　b) 启用GZip；

• 保障无阻塞。
  　写在HTML尾部的JavaScript（无异步），和写在HTML标签中的Style会阻塞页面的渲染，因而CSS放在页面尾部并应用Link格局引入，防止在HTML标签中写Style，JavaScript放在页面尾部或应用异步情势加载

• 行使首屏加载。
  　首屏的高效呈现，可以大大升高用户对页面速度的感知，因而应竭尽针对首屏的快捷彰显做优化。

• 按需加载。
  　将不影响首屏的资源和当前显示器资源不用的资源放到用户必要时才加载，能够大大升级主要资源的来得速度和低落全体流量（PS：按需加载会造成大气重绘，影响渲染品质）。
  　a) LazyLoad；
  　b) 滚屏加载；
  　c) 通过Media Query加载；

• 预加载。
  　大型重资源页面（如游戏）可接纳增多Loading的点子，资源加载成功后再展现页面。但Loading时间过长，会招致用户流失。对用户作为分析，可以在此时此刻页加载下一页资源，提高速度；
  　a) 可感知Loading(如进入空间游戏的Loading)；
  　b) 不可感知的Loading（如提前加载下一页）；

• 调减图片。
  　图片是最占流量的资源，由此尽量避免使用她，使用时精选最合适的格式（落成必要的前提下，以大小判断），合适的轻重缓急，然后拔取智图压缩，同时在代码中用Srcset来按需出示（PS：过度压缩图片大小影响图片彰显效果）。
  　a) 使用智图（Coca Cola图）；
  　b) 使用别的方法取代图片
  　　　1. 使用CSS3
  　　　2. 使用SVG
  　　　3. 使用IconFont；
  　c) 使用Srcset；
  　d) 拔取适当的图纸
  　　　1. webP优于JPG
  　　　2. PNG8优于GIF；
  　e) 接纳适宜的深浅
  　　　1. 首次加载不高于1014KB
  　　　2. 不宽于640（基于手机屏幕一般宽度）；

• 压缩Cookie、幸免重定向以及异步加载第三方资源。
  　Cookie会影响加载速度，所以静态资源域名不应用Cookie。别的，重定向也会影响加载速度，所以在服务器正确安装避免重定向。最终，第三方资源不足控会影响页面的加载和浮现，因而要异步加载第三方资源。

3、调整图片体积

调整方面图片的（压缩品质）体积，base64化后，对应的css文件大小也随即变动

图片大小	10kb	20kb	45kb	100kb	180kb
对应css文件大小	27kb	42kb	76kb	150kb	260kb
Rendering时间	30ms	46ms	81ms	156ms	258ms

（四）CDN和缓存

干什么选用CDN?
CDN
是一个海内外（或者唯有国内，具体看供应商）分布式网络，它把网站内容更快地传递给服务范围内的一个具体地方，而频仍那一个具体的义务离实际的始末服务器距离很远。举个极端点的事例，你的网站主机在爱尔兰（四川），而你的用户则在澳大圣Pater罗苏拉（漠河）访问。那时当您的用户访问你的网站的时候，延迟会很大，把您的（静态）数据用
CDN 放到澳大莱切斯特（漠河）则会很大程度上增强用户访问网站的经验。

假诺没有CDN服务，大家得以添加Expires头，减弱DNS查找，配置ETag，使AjaX可缓存。

第二步：脚本执行优化

---

剧本处理不当会卡住页面加载、渲染，由此在行使时需当注意：

• CSS写在头顶，JavaScript写在尾部或异步。
• 幸免图片和iFrame等的空Src。
  　　空Src会重新加载当前页面，影响进度和效用。
• 尽量防止重设图片大小。
  　　重设图片大小是指在页面、CSS、JavaScript等中反复重置图片大小，数次重设图片大小会引发图片的往往重绘，影响属性。
• 图片尽量幸免使用DataURL。
  　　DataURL图片并未利用图片的压缩算法文件会变大，并且要解码后再渲染，加载慢耗时长。

4、调整引用次数

50kb大小的图纸，base64化后，调整引用图片做背景图的dom的个数

引用次数	10	20	50	100	135
Rendering时间	15ms	19ms	44ms	74ms	83ms

（五）安全地方: CSP

web前端对于xss安全漏洞一定不陌生。我们通晓Javascript语句甚至是css表明式都可能引致xss攻击，现在广大前端会利用CSP策略来进展脚本源的限量防御。

而大家是因为使用的cdn域名和工作域名不一样等：
cdn域名：https://cdn.xxx.qq.com
事情域名：https://xxx.qq.com

大家可以：

1. 在index.html静态入口文件的meta http-equiv头中做布置；

服务器端直接回到相应的HTTP response header头音讯；

例如：

那边除了指定了cdn的域名源，告诉浏览器从这一个域名加载的js文件都是可相信的。同时因为我们接纳的webpack打包压缩代码后的片段特征，大家还必要加上’unsafe-inline’标识。

选取CSP策略大家能够指定浏览器安全解析script、css、fonts、media等资源的源与方法。

参考资料有：

Content Security Policy
Reference

Content Security Policy
入门教程

第三步：CSS优化

---

剖析和总括：

在OSX+Chrome环境下，将50kb的图样base64后放入样式中，build进程增加了约20倍，使用提姆eline工具得以见见，总括样式阻塞了全体过程。

1. 比起一向引入图片地址，css文件中引入base64格式的图形对体制渲染的性质消耗分明，即便大气行使，会推动功耗和发热的标题，需谨慎使用。
2. Rendering消耗的时刻同css文件大小、引用次数大约成正比（未测试此外极限状态），在网络条件优质的4G环境，50~70ms的RTT(往返时延）处境下，常常活动互联网的景色会更差，对于首屏优化，合适的行使依旧很值得的。
3. 图片转成base64编码后，文档大小较原文件大了一部分，而由此 gzip
   后双方大致平素不区分。

二、webpack2.0

选取webpack2最敬重的地点就是使用它tree-shaking的特征。那些特点对于ES6的module管理有着卓殊赏心悦目的优化，大致能压缩30%左右的包体积。

ES
module和CommonJS的require模块管理不一致，前者是基于静态的，而后者是动态的。

CJS：

同意动态同步 require()

导出仅在模块执行后才知道

导出可以在模块先导化后添加，替换和删除

ES module：

只同意静态同步 import

在模块执行从前，导入和导出已经涉嫌

导入和导出是不可变的

后天大家来看一下怎么着利用webpack：

一、尽量幸免写在HTML标签中写Style属性。

• 幸免CSS表明式CSS表明式的实践需跳出CSS树的渲染，因而请防止CSS表明式
• 移除空的CSS规则空的CSS规则扩大了CSS文件的大大小小，且影响CSS树的施行，所以需移除空的CSS规则
• 不错采用Display的品质Display属性会潜移默化页面的渲染，由此请合理使用
  　　a)
  display:inline后不应有再选用width、height、margin、padding以及float
  　　b) display:inline-block后不应有再使用float
  　　c) display:block后不应有再选拔vertical-align
  　　d) display:table-*后不应该再利用margin或者float
• 不滥用Float。
  　　Float在渲染时总括量比较大，尽量裁减使用
• 不滥用Web字体。
  　　Web字体必要下载，解析，重绘当前页面，尽量裁减使用
• 不注明过多的Font-size。
  　　过多的Font-size引发CSS树的功用
• 值为0时不必要别的单位。
  　　为了浏览器的包容性和性质，值为0时绝不带单位
• 规格各个浏览器前缀。
  　　a) 无前缀应放在最后
  　　b) CSS动画只用 （-webkit- 无前缀）三种即可
  　　c) 别的前缀为 -webkit- -moz- -ms- 无前缀
  八种，（-o-Opera浏览器改用blink内核，所以淘汰）
• 幸免让选拔符看起来像正则表明式。
  　　高级采用器执行耗时长且不易读懂，幸免使用

场景2，内嵌至js文件中

代码压缩

俺们温馨写的代码因为在付出时索要根据一定的代码规范，所以会有广大剩下的换行和空格字符，甚至是便民阅读的长变量名，那个实际对于机器（浏览器）来说，都不是必备的。所以我们得以把那个都干掉。比如大家写的代码可能是这么的：

进而大家就选取Webpack来展开压缩。首先，要求在工程根目录的package.json（相信使用过npm包管理的前端同学肯定不陌生）文件中添加webpack的看重配置：

逐一工程应该按需引入需要的loader和webpack-plugin库。有某些亟待注意的是：webpack本身是未曾对各样档次的文本举行剖析处理的能力的，这一个时候大家须要利用种种第三方库的loader，比如css-loader等（当然大家也可以友善编辑loader）。同时webpack也有强有力的第三方Plugin插件供大家对文本进行更为处理。

接下去我们就足以在scripts中针对的剧本文件里编写webpack对应的营造代码了。

比如在webpackConfig配置中的plugins属性数组中，大家可以添加以下配置：

而最终生成的公文结构如下：

我们得以见见有着样式代码被压缩后抽离到了一个app.[hash].css文件中，所有js逻辑代码根据业务逻辑和第三方库被抽离到了app.[hash].js和vendor.[hash].js文件中。

被打包文件的内容也早已被webpack压缩混淆，减弱了加载文件的Content Size。

关于任何的webpack用法配置，可以查询官方文档和国语文档，那里就不一一详细表达了

现阶段webpack3
和webpack4使用了新的措施打包代码，可以越发升级js在浏览器中的执行作用。

第四步：JavaScript执行优化

---

• 收缩重绘和回流。
  　a) 防止不必要的Dom操作
  　b) 尽量改变Class而不是Style，使用classList代替className
  　c) 防止接纳document.write
  　d) 减少drawImage
• 缓存Dom接纳与计量。
  　每一趟Dom选拔都要计算，缓存它
• 缓存列表.length。
  　每趟.length都要总计，用一个变量保存那么些值
• 尽量选拔事件代理，避免批量绑定事件
• 尽心尽力利用ID接纳器。
  　ID接纳器是最快的
• TOUCH事件优化。
  　使用touchstart、touchend代替click，因快影响进程快。但应注意Touch响应过快，易引发误操作

1、原生格局直接加载多张图纸

大小10~70kb共9张图纸。总大小约300kb

关门缓存：build: 300ms | complete: 310ms

敞开缓存：build: 110ms | complete: 120ms

测试环境	build(单位:ms)	complete(单位:ms)
OS X+Chrome	110	120
iOS+微信	50	100
OS X+Safari	148	150
Android+微信	50	100

 

第五步：渲染优化

---

• HTML使用Viewport。
  　Viewport可以加快页面的渲染，请使用以下代码<meta name=”viewport”
  content=”width=device-width, initial-scale=1″>
• 减少Dom节点。
  　Dom节点太多影响页面的渲染，应尽量缩短Dom节点
• 动画片优化。
  　a) 尽量使用CSS3卡通
  　b) 合理使用requestAnimationFrame动画代替setTimeout
  　c) 适当采用Canvas动画
  5个要素以内使用css动画，5个以上使用Canvas动画（iOS8可使用webGL）
• 屡次事件优化。
  　Touchmove、Scroll 事件可导致多次渲染
  　　a)
  使用requestAnimationFrame监听帧变化，使得在科学的年月开展渲染
  　　b) 伸张响应变化的时间距离，裁减重绘次数
• GPU加速。
  　CSS中以下属性（CSS3 transitions、CSS3 3D
  transforms、Opacity、Canvas、WebGL、Video）来触发GPU渲染，请靠边施用（PS：过渡使用会掀起手机过功耗扩大）

2、转换成base64格式，合并请求

将方面的图纸转成base64后，放在js文件中，加载进来。

关闭缓存：build: 0ms | complete: 400ms

翻开缓存：build: 0ms | complete: 80ms

测试环境	build(单位:ms)	complete(单位:ms)
OSX+Chrome	110	120
iOS+微信	0	35
OS X+Safari	7	70
Android+微信	0	250

3、比较不一致网速下一同请求和归并请求的加载功效

采取上述1、2的测试demo分别在3G、4G网速条件下测试结果如下：

• 在网络环境差的情况下，合并请求显明减少了全体加载时间；
• 在网络环境较好的WIFI和4G下则差异不大。

测试环境	图片直接加载 complete(单位:ms)	base64合并请求 complete(单位:ms)
3G	6000	4500
4G	450	400
WIFI	320	340

解析和小结：

base64后的的js资源达381kb，在一个线程里加载，消耗多量时刻，从统计结果看，在渲染质量差距上并没有场景1那么肯定。
但有缓存的事态下，页面渲染落成的快慢照旧更快。
从Timeline里观望细节，解析这一个近400kb的js文件对一切渲染进程导致了自然压力，不过总共40ms的解析时间是截然可以接受的。

1. 从html里直直接引用图片链接和base64图片对渲染品质的熏陶大致从不分别，在网络条件差的事态下，合并请求却能大大升高加载功能；
2. 直接引用至html，不能够缓存，将base64后的图形资源放在js文件中管理，方便设置缓存。
3. 有一个败笔就是图形资源base64化必要扩张创设工具来支撑。

选拔提出

1. 图表资源的base64编码进css文件会拉动一定的性质消耗，需谨慎使用。

2. 将图纸资源编码进js文件中，管理和预加载H5应用的图纸资源，合理的联结请求可以大大提升页面体验。

   1 赞 1 收藏
   评论