数据采集系统方案【性能优化】前端性能优化⽅案都帮你整理好了（全⾯系统）！
前⾔
前端是庞⼤的，包括 HTML、 CSS、 Javascript、Image 、Flash等等各种各样的资源。前端优化是复杂的，针对⽅⽅⾯⾯的资源都有不同的⽅式。那么，前端优化的⽬的是什么 ?
1. 从客户端⾓度⽽⾔，优化能够让页⾯加载得更快、对⽤户的操作响应得更及时，能够给⽤户提供更为友好的体验。 2. 从服务器端⾓度⽽⾔，优化能够减少页⾯请求数、或者减⼩请求所占带宽，能够节省可观的资源。 总之，恰当的优化不仅能够改善站点的⽤户体验并且能够节省相当的资源利⽤。
前端优化的途径有很多，这⾥我整理成三个⼤点，第⼀个是HTTP请求层⾯，第⼆个是程序代码层⾯，第三个就是请求源就近响应源层⾯ 。⼀、HTTP请求层⾯
u型电动牙刷
这条策略基本上所有前端⼈都知道，⽽且也是最重要最有效的。都说要减少 HTTP请求，那请求多了到底会怎么样呢 ?⾸先，每个请求都是有成本的，既包含时间成本也包含资源成本。⼀个完整的请求都需要经过 DNS域名解析、与服务器建⽴连接（建⽴tcp通道，三次握⼿）、发送数据、等待服务器响应、 接收数据这样⼀个 “漫长” ⽽复杂的过程、最后浏览器还需要解析html,css⽣成对应Render DOM渲染树，经过⼀系列回流重绘以及js执⾏⽣成相应的页⾯给⽤户。
那么减少 HTTP请求数的主要途径包括：
1. 减少 HTTP请求数（量化）
(1) 优化图⽚请求数：说到请求数，那页⾯中图⽚的请求肯定脱不了⼲系的，⼀个图⽚就会发送⼀次请求，所以对于图⽚的请求量，我们可以使⽤CSS Sprites将图⽚整合到⼀张⼤图，然后通过background-position拿到对应的图⽚进⾏使⽤，对于请求数来说，这⽆疑将好⼏个图⽚请求，变成了⼀个请求，当然这也同样增加了请求所占带宽，所以也算是美中有⼀点点不⾜吧；其次也就是图⽚base64化，base64编码的图⽚是不需要消耗请求数的，但要注意使⽤base64的图⽚尽可能不要超过10k，因为图⽚的⼤⼩越⼤，转化成的base64码也就越多，⼤⼤影响代码质量；最后⼀个也就是的 字体图标，这种图标是⼀种字体格式的Iconfont，这种图标也是不消耗请求的，⽽且⼀般都可以满⾜我们现阶段项⽬中⼤多数⼩ICON →
(2) 资源合并与压缩：如果可以的话，尽可能的将外部的脚本、样式进⾏合并，多个合为⼀个。另外， CSS、 Javascript、Image 都可以⽤相应的⼯具进⾏压缩，压缩后往往能省下不少空间
(3) 图⽚懒加载（Lazy Load Images）：想必⼤家也知道，像淘宝，花瓣这种图⽚特别多的⽹站难道都是将当前页⾯的图⽚都给⽤户加载吗？显然不可能，对于这种图⽚多的页⾯都是进⾏懒加载处理来减少⾸屏中对图⽚的请求数，但是注意这⾥的减少 HTTP请求数，并不是说通过懒加载可以让加载的图⽚不需要发送请求，⽽是当你进⼊页⾯时，通过懒加载的机制会先给你加载部分图⽚，⽽并不是当前页⾯的图⽚都需要发送请求；只有当⽤户继续往后滚屏的时候才加载后续的图⽚。这样⼀来，假如⽤户只对第⼀屏的内容感兴趣时，那剩余的图⽚请求就都节省了。简单说⼀下实现原理，也就是前端拿到后端响应数据图⽚时，将图⽚的地址，先放在img便签上的 data-src 属性上，此时 src 这个属性为空，然后配合JS监听⽤户的页⾯滚动距离，只要当前图⽚进⼊这个窗⼝可视区域就将 data-src ⾥的图⽚地址放在 src上实现图⽚的显⽰
(4) 合理设置 HTTP缓存：缓存的⼒量是强⼤的，恰当的缓存设置可以⼤⼤的减少 HTTP请求。以⾸页为例，当浏览器没有缓存的时候假设访问⼀共会发出 50个请求，共 500多 K数据 ，⽽当第⼆次访问即浏览器已缓存之后访问则仅有 10个请求，共 20多 K数据。 (这⾥需要说明的是，如果直接 F5刷新页⾯的话效果是不⼀样的，这种情况下请求数还是⼀样，不过被缓存资源的请求服务器是 304响应，只是Header没有Body ，可以节省带宽 ) 怎样才算合理设置？例如很少变化的图⽚资源可以直接通过 HTTP Header中的Expires设置⼀个很长的过期头 ；变化不频繁⽽⼜可能会变的资源可以使⽤ Last-Modifed来做请求验证。尽可能的让资源能
够在缓存中待得更久。虽然这⼀点⼤部分是后端设置，这个就要涉及到后端对响应的标志，合理设置可以减少前后端过多的交互，加快页⾯加载速度
2. 减少 HTTP请求所占宽带（质化）
(1) 资源合并与压缩（这个前⾯量化已经提及过，这⾥还是再写⼀下吧，可以理解为合并减少了请求量，压缩就减少了请求所占宽带）：如果可以的话，尽可能的将外部的脚本、样式进⾏合并，多个合为⼀个。另外， CSS、 Javascript、Image 都可以⽤相应的⼯具进⾏压缩，压缩后往往能省下不少空间
(2) 避免⼤图⽚（体积⼤）请求：⼤图⽚的请求慢是必然的，也会影响⽤户的体验，但是项⽬中肯定避免不了有⼏个⼤图⽚的加载，那么我们就可以对图⽚体积进⾏适当的压缩，注意不能影响图⽚的质量⽐如失真模糊，这种⼀般UI设计师都会对这些图⽚进⾏处理的；当然如果公司没有分⼯那么明确的话，可能前端就要完成这份⼯作了（所以要会做，现在都是有软件可以完成的），但是如果你不知道怎么处理或者你压缩的时候还是出现了质量问题，建议使⽤SVG格式的图⽚，这种图⽚不但体积相对于其他格式的图⽚⼩，最重要的是放⼤不失真！
⼆、程序代码层⾯
代码层⾯的优化，是程序员的必备素质，代码的规范不仅仅是维护上的提升，也是性能的提升（⾼质量的代码影响性能你不能不信！），不多哔哔赖赖我们看看有哪些⽅法：
1. 样式及脚本代码位置
(1) 将 CSS放在 HEAD中⽽JS脚本置底：这个⼤家应该都是知道的，这⾥说⼀下原因 → ① 如果将 CSS放在其他地⽅⽐如 BODY中，则浏览器有可能还未下载和解析到 CSS就已经开始渲染页⾯了，这就导致页⾯由⽆ CSS状态跳转到 CSS状态，⽤户体验⽐较糟糕。除此之外，有些浏览器会在 CSS下载完成后才开始渲染页⾯，如果 CSS放在靠下的位置则会导致浏览器将渲染时间推迟；② 在HTTP1.1后浏览器对HTTP请求是可以并发进⾏的，这⼀特点使得其能够更快的加载资源，然⽽JS脚本在加载时却会阻塞其他资源，例如在脚本加载完成之前，它后⾯的图⽚、样式以及其他脚本都处于阻塞状态，直到脚本加载完成后才会开始加载。如果将脚本放在⽐较靠前的位置，则会影响整个页⾯的加载速度从⽽影响⽤户体验。解决这⼀问题的⽅法有很多，⽽最简单可依赖的⽅法就是将脚本尽可能的往后挪，减少对并发下载的影响。
2. HTML
(1) 合理利⽤HTML5语义化便签，并且标签不乱嵌套，减少⽆⽤便签；你们应该会问这跟前端性能优化有什么关系？ 注意了DOM结构的合理设计，会减少浏览器在解析HTML DOM树时的速度（DOM结
短信通道
构如果越复杂，遍历时就会损耗跟多更多性能），具体可以看这篇⽂章 →
(2) ⾃从HTML5新增的⼀个重要的⽹页存储的API特性Web Storage，⽅便Web应⽤的离线使⽤。除此之外，新的API相对于cookie也有着⾼安全性，⾼效率，更⼤空间等优点。正因为每次请求都会携带cookie所以当中还是会消耗对应的请求数，⽽session Storage和local Storage正好可以优化这⼀点；
3.CSS
(1) 在⼤多数⼈的观念中，都觉得浏览器对 CSS选择符的解析式从左往右进⾏的，例如 #pic A { color: #444; } 这样⼀个选择符，如果是从左往右解析则效率会很⾼，因为第⼀个 ID选择基本上就把查的范围限定了，但实际上浏览器对选择符的解析是从右往左进⾏的。如上⾯的选择符，浏览器必须遍历查每⼀个 A标签的祖先节点，效率并不像之前想象的那样⾼；所以既然浏览器是这样解析CSS的话，我们是不是应该在写CSS样式的时候不要有深层次的嵌套，这个性能优化，跟上⾯提到的HTML⼀样，也是在浏览器解析CSS DOM树的时候涉及的，只要写的嵌套太深⼊（⽆论是HTML还是CSS结构）都是会让浏览器解析速度变慢；
(2) 在动画⽅⾯，应该让动画本⾝脱离⽂档流，这样可以减少页⾯中不断的重绘回流，因为动画本⾝是运动的，如果存在⽂档流中，会影响旁边的布局，浏览器就会重新计算这部分涉及的元素⼤⼩及位置等 ；其次就是使⽤css3硬件加速，可以让transform、opacity、filters这些动画不会引起回流重绘 →
关于这些都可以看这篇⽂章 ⾥⾯说的很清楚
4.Javascript
(1) 减少DOM节点的操作：
DOM操作应该是脚本中最耗性能的⼀类操作，例如增加、修改、删除 DOM元素或者对 DOM集合进⾏操作。如果脚本中包含了⼤量的DOM操作则需要注意以下⼏点：
a. HTML Collection（HTML收集器，返回的是⼀个数组内容信息）
在脚本中 document.images、document.forms 、getElementsByTagName()返回的都是 HTMLCollection类型的集合，在平时使⽤的时候⼤多将它作为数组来使⽤，因为它有 length属性，也可以使⽤索引访问每⼀个元素。不过在访问性能上则⽐数组要差很多，原因是这个集合并不是⼀个静态的结果，它表⽰的仅仅是⼀个特定的查询，每次访问该集合时都会重新执⾏这个查询从⽽更新查询结果。所谓的 “访问集合” 包括读取集合的 length属性、访问集合中的元素。
因此，当你需要遍历 HTML Collection的时候，尽量将它转为数组后再访问，以提⾼性能。即使不转换为数组，也请尽可能少的访问它，例如在遍历的时候可以将 length属性、成员保存到局部变量后再使⽤局部变量。
b. Reflow & Repaint
除了上⾯⼀点之外， DOM操作还需要考虑浏览器的 Reflow和Repaint ，因为这些都是需要消耗资源的
c. 现阶段的框架如Vue/React操作的都是虚拟DOM，框架底层通过DIff算法对⽐前后DOM的不同进⾏操作，具体不在这细讲了
ecall测试
(2) 变量数据访问：
Javascript中的数据访问包括直接量 (字符串、正则表达式 )、变量、对象属性以及数组，其中对直接量和局部变量的访问是最快的，对对象属性以及数组的访问需要更⼤的开销。当出现以下情况时，建议将数据放⼊局部变量：
a. 对任何对象属性的访问超过 1次
b. 对任何数组成员的访问次数超过 1次
另外，还应当尽可能的减少对对象以及数组深度查。
(3) 减少作⽤域链查（这⽅⾯设计到⼀些内容的相关问题）：
前⽂谈到了作⽤域链查问题，这⼀点在循环中是尤其需要注意的问题。如果在循环中需要访问⾮本作⽤域下的变量时请在遍历之前⽤局部变量缓存该变量，并在遍历结束后再重写那个变量，这⼀点对全局变量尤其重要，因为全局变量处于作⽤域链的最顶端，访问时的查次数是最多的；我们来对⽐⼀下两种写法 ↓
① 低效率的写法：
// 全局变量
var globalVar =1;
function myCallback(info){钢管扩口机
for(var i =100000; i--;){
//每次访问 globalVar 都需要查到作⽤域链最顶端，本例中需要访问 100000 次
globalVar += i;
}
}
② 更⾼效的写法：
// 全局变量
var globalVar =1;
function myCallback(info){
// 局部变量缓存全局变量
var localVar = globalVar;
for(var i =100000; i--;){
// 访问局部变量是最快的
localVar += i;
}
/
/ 本例中只需要访问 2次全局变量
// 在函数中只需要将 globalVar中内容的值赋给localVar
globalVar = localVar;
}
此外，要减少作⽤域链查还应该减少闭包的使⽤。
(4) 字符串拼接
在 Javascript中使⽤"+" 号来拼接字符串效率是⽐较低的，因为每次运⾏都会开辟新的内存并⽣成新的字符串变量，然后将拼接结果赋值给新变量。与之相⽐更为⾼效的做法是使⽤数组的 join⽅法，即将需要拼接的字符串放在数组中最后调⽤其 join⽅法得到结果。不过由于使⽤数组也有⼀定的开销，因此当需要拼接的字符串较多的时候可以考虑⽤此⽅法；其次就是ES6的模版语法完美KO了这种通过"+"进⾏拼接的做法，⽅便⾼效
(5) Lazy Load Javascript（这⾥可以理解为按需加载，如Vue中的异步加载语法，结合webpack进⾏代码分割）
随着 Javascript框架的流⾏，越来越多的站点也使⽤起了框架。不过，⼀个框架往往包括了很多的功能实现，这些功能并不是每⼀个页⾯都需要的，如果下载了不需要的脚本则算得上是⼀种资源浪费 -既浪费了带宽⼜浪费了执⾏花费的时间。⽬前的做法⼤概有两种，⼀种是为那些流量特别⼤的页⾯专门定制⼀个专⽤的 mini版框架，另⼀种则是 Lazy Load。YUI 则使⽤了第⼆种⽅式，在 YUI的实现中，最初只加载核⼼模块，其他模块可以等到需要使⽤的时候才加载。⽽Vue中就是在路由配置中进⾏异步加载的语法，在SPA单页⾯应⽤是很常见的
(6) 提⾼代码的利⽤率：
a. 何为代码利⽤率（代码覆盖率）？
我就通俗说⼀下，具体可以⾃⾏Goole。代码覆盖率就是指当前页⾯加载的⽂件有多少被真正的激活使⽤（图中绿⾊为激活的代码，红⾊就是待激活的代码）
b. 怎么看？
上图为爱奇艺⾸页加载时，通过使⽤ Show Coverage 测试出来的，通过红框中可以看出来，爱奇艺⾸屏加载完成后有70%的代码覆盖率，很nb了，有55以上都挺不错的了；
c. 怎么优化，怎么做？
其⼀ → 当前加载的页⾯不掺杂其他页⾯不相关的代码，并且避免因为疏忽或页⾯由多个模块拼接⽽成，然后每个模块中请求了同样的资源时，会导致资源的重复请求；
苯乙烯树脂其⼆ → 异步代码，关于与⽤户交互的逻辑，使⽤异步代码进⾏处理，可以增加代码利⽤率，通过coverage可以进⾏测试，当我们成功触发交互，对应的异步代码就会变绿，并且异步的代码是可以提升覆盖率的，最后说⼀句现在前端的优化不能在只单单考虑缓存这个层⾯，也要关注代码利⽤率层⾯；
其三 → 最近不是Vue3.0重磅出炉吗？有了解过的⼩伙伴应该知道Vue3.0优化了"摇树 Tree-shaking"的功能，这个功能可厉害了，他可以⾃动识别页⾯中并未使⽤的代码进⾏Shaking，当然不是说因为这个让⼤伙觉得是不是要升级Vue了不然跟不上潮流，毕竟刚出炉的⾹芋烫⼿的很，需要时间；这个如果不使⽤Vue3.0进⾏开发的话，还可以通过去配置Webpack来实现 Tree-shaking的功能 这个完全可以参考
→
三、请求源就近响应源层⾯
这个名字我是乱起的，所以不⽤在意。只要知道接下来指的是什么就⾏；
(1) CDN加速：这种服务⼀般都是有专门的供应商提供，只需要钱到位就⾏；主要就是实现，请求源（就⽐如⽤户在⼴州请求了项⽬数
据，CDN就会解析这个ip拿到请求的地址）发送请求后，响应源（根据购买的CDN部署地进⾏快速分配距离这个ip地址最近的服务器进⾏请求的接收，最后返回对应的相应数据给客户端）返回响应数据；
结语
本⽂从三个⽅⾯阐述了前端优化的各种⽅式做了⼀个总结，这些⽅法基本上都是前端开发⼈员在开发的过程中可以借鉴和实践的，希望可以帮到你；当然优化的⽅法可能还有，只是我没有提及或者压根还不知道，所以承蒙各路⼤佬指点迷津，⼀起加油~
