(O)WEB:前端网站性能优化(原创)

*从理论、实战编码、实战调试3个方面学习前端性能优化(包括页面加载时间和页面流畅度):

-------------------------------理论-------------------------------
*浏览器的完整渲染过程
①输入url,发送请求
②加载(即下载)整个.html文件
③加载完后解析(即运行)html,并在解析的过程中构建DOM树
·JavaScript是单线程的。浏览器是多线程的:有的线程负责加载资源,有的线程负责执行脚本,有的线程负责渲染界面。
·浏览器按从上之下(深度遍历)的原则解析各个html标签
·解析标签的过程就是构建DOM树的过程
·解析遇到link、script、img标签时,浏览器会向服务器发送请求资源。
    script加载时不影响其他资源加载,但由于不知道js中的执行内容,所以需要等JS加载并执行完后才会继续解析和渲染。
    script的执行会阻塞html解析、其他下载线程以及渲染线程。
    link加载完css后会解析为CSSOM(层叠样式表对象模型,一棵仅含有样式信息的树)。css的加载和解析不会阻塞html的解析,但会阻塞渲染。
    img的加载不会阻塞html的解析,但img加载后并不渲染,它需要等待Render Tree生成完后才和Render Tree一起渲染出来。未下载完的图片需等下载完后才渲染。
④当css解析为CSSOM后,html解析为DOM后,两者将会结合在一起生成Render Tree(渲染树)。
⑤Layout(reflow): 计算出Render Tree每个节点的形状和位置。(很耗性能)
⑥Painting(repaint):浏览器绘制这些元素的样式,颜色,背景,大小及边框等。(很耗性能)
⑦Composite(层叠时):浏览器会将各渲染层的信息发送给GPU,GPU会按照合理的顺序合并图层然后显示到屏幕上。(GPU合成图像,单独线程,更流畅,但耗内存)

*渲染时长
大多数电脑显示器的刷新频率是60Hz,大概相当于每秒钟重绘60次,因为小于这个频率,页面的渲染就会出现卡顿现象,影响用户体验。大多数浏览器都会对重绘操作加以限制,不超过显示器的重绘频率,因为即使超过那个频率用户体验也不会有提升。因此,最平滑动画的最佳循环间隔是1000ms/60,约等于16.6ms。


-------------------------------编码实战-------------------------------
*前端加载优化:
·使用外联CSS和JS:让浏览器缓存,减少http请求。可利用webpack在引用的资源后面自动增加hash值,实现引用不变的基础上对浏览器缓存的资源进行更新。对于缓存容量小的问题,可以考虑缓存在localStorage。
·合并CSS、JS:减少http请求。
·按需加载:webpack的打包思路就是从程序逻辑入手:入口文件 => 分析代码 => 找出依赖 => 打包,这样代码里不引用的模块就不可能被打进包里,有效减少体积。
·按JS模块加载:例如echart中如果只用k线图就只加载k线模块。
·压缩HTML、CSS、JS:减少资源大小。
·图标采用base64:减少http请求。
·图标采用雪碧图(svg、font-icon):减少http请求,减少资源大小。
·图片压缩:picdiet(https://www.picdiet.com/zh-cn),是用JS编码,无大小、尺寸、数量限制,默认可平均减少50%体积,清晰度基本没损失,没有兼容性问题,也可以调节压缩比。
·避免图片和iFrame等的空src:减少http请求。
·图片:滚屏懒加载。
·CDN加速:常用资源使用CDN加速提高资源响应速度,如jquery、echarts。(http://www.bootcdn.cn/)
·BigRender首屏渲染优化:html, js, css和图片都放在textarea中懒加载(https://segmentfault.com/a/1190000006744741)。
·增加Loading进度条:将加载情况呈现给用户。

*服务端加载优化:
·缓存一切可缓存的资源:http缓存。
·使用长Cache,避免304重定向:在移动端网络不稳定的前提下,多一次请求,就多了一部分加载时间。
·使用DNS缓存:减少浏览器会在DNS解析中消耗的时间。
·启用GZip:GZip是http协议的一部分,用来压缩网页大小的。
·图片压缩:默认生成缩略图传前端。
·减少Cookie:Cookie会影响加载速度,所以静态资源域名不使用Cookie。
·域名解析:减少域名解析次数——减少跨站外部资源的引用。
·创建连接:减少连接创建次数——使用Keep-Alive避免重复连接。
·等待响应:提高服务器运行速度——提高数据运算及查询速度。

*HTML、CSS结构优化:
·页面的标签越少,页面的加载速度就越快,响应也更加迅速。
·css不能阻塞加载,所以将css放在头部,防止白屏和重排重绘造成的内容闪烁现象。
·尽量保持class的简短,如:.box:nth-last-child(-n+1) .title,改为:.final-box-title。
·用flex布局取代浮动布局。
·移除空的CSS规则:空的CSS规则增加了CSS文件的大小,且影响CSS树的执行。
·不声明过多的font-size:过多的font-size引发CSS树的效率。
·值为0时不需要任何单位:为了浏览器的兼容性和性能,值为0时不要带单位。
·display属性会影响页面的渲染,需合理使用:
①display:inline后不应该再使用width、height、margin、padding以及float
②display:inline-block后不应该再使用float
③display:block后不应该再使用vertical-align
④display:table-*后不应该再使用margin或者float

*DOM性能优化:主要是防止重排和重绘
·图片、音频和视频的宽高在加载完成之前为0,所以静态资源加载前需规定图片的大小。
·尽量避免重设图片大小:多次重设图片大小会引发图片的多次重绘
·多使用requestAnimationFrame(待学习)
·如果同时添加父元素和子元素,要在内存中先将所以子元素添加到父元素下,将父元素一次性加入DOM树。
·如果同时添加多个平级子元素,要先将平级子元素加入文档片段,再将文档片段整体加到页面。具体为:
①创建文档片段:var frag=document.createDocumentFragment();文档片段: 内存中临时存储多个平级子元素的虚拟父元素。
②将平级子元素,先追加到frag下: 用法同普通父元素
③将文档片段,整体添加到页面
·先把dom节点display:none;(会触发一次重排)。然后做大量的修改后,再把它显示出来。
·clone一个dom节点在内存里,修改之后;与在线的节点相替换。
·尽量使用ID选择器,ID选择器是最快的。
·每次Dom选择都要计算,缓存他,避免强制同步布局(force reflow)。
·对于修改元素多个样式,可以使用cssText属性,避免强制同步布局。例如如下,触发3次重排:
var el = document.getElementById('myDiv');
el.style.borderLeft = '1px';
el.style.borderRight = '2px';
el.style.padding = '5px';
改成这样,只需1次重排:
var el = document.getElementById('myDiv');
el.style.cssText = 'border-left: 1px; border-right: 2px; padding: 5px;';
将多个样式变化定义到一个class中,再通过className添加class也行。
·动画多使用transform和opacity,他们只会引起合成,不会引起布局和重绘。
·如果图层中某个元素需要重绘,那么整个图层都需要重绘。用translateZ(0)手动创建渲染层,减少需渲染的像素数,还可以用GPU加速。但是不要滥用这个属性,否则会大大增加内存消耗。(详情:https://developers.google.cn/web/fundamentals/performance/rendering/simplify-paint-complexity-and-reduce-paint-areas)
·不要使用table布局,一个小改动会造成整个table的重新布局。
·用css动画而不是js动画:css动画有一个重要的特性,它是完全工作在GPU上。因为你声明了一个动画如何开始和如何结束,浏览器会在动画开始前准备好所有需要的指令;并把它们发送给GPU。而如果使用js动画,浏览器必须计算每一帧的状态;为了保证平滑的动画,我们必须在浏览器主线程计算新状态;把它们发送给GPU至少60次每秒。除了计算和发送数据比css动画要慢,主线程的负载也会影响动画; 当主线程的计算任务过多时,会造成动画的延迟、卡顿。所以尽可能地使用基于css的动画,不仅仅更快;也不会被大量的js计算所阻塞。
·减小复合层的尺寸:可以将图片的尺寸减少5%——10%,然后使用scale将它们放大;用户不会看到什么区别,但是你可以减少大量的存储空间。
·采用虚拟DOM技术:例如Vue、React等框架就采用了虚拟DOM。

*script优化:
·我们知道脚本加载和运行会阻塞页面,所以应该把<script>标签放到最后。
·JS:throttle函数(节流):每XX秒内只执行一次;(https://github.com/jacksplwxy/gecko.js)
·JS:debounce函数(防抖):当连续触发函数调用时,在最后一次触发的XX秒以后才开始一次调用。(https://github.com/jacksplwxy/gecko.js)
·对于多条件判断,用钩子机制比if-else快。
·避免快速连续的布局:
改善前:function resizeWidth() {
// 会让浏览器陷入'读写读写'循环
for (var i = 0; i < paragraphs.length; i++) {
paragraphs[i].style.width = box.offsetWidth + 'px';
}
}
改善后:var width = box.offsetWidth;
function resizeWidth() {
for (var i = 0; i < paragraphs.length; i++) {
paragraphs[i].style.width = width + 'px';
}
}
·深入原形链越深,搜索的速度就会越慢。记住,搜索实例成员的过程比访问直接量或者局部变量负担更重,所以增加遍历原形链的开销正好放大了这种效果。
·函数作用域链的搜索也会消耗性能,全局变量总是在作用域链的最后,所以耗时最久。最好尽可能使用局部变量。一个好的经验法则是:用局部变量存储本地范围之外的变量值。
·成员嵌套越深,访问速度越慢。 location.href 总是快于window.location.href ,而后者也要比window.location.href.toString()更快。如果这些属性不是对象的实例属性,那么成员解析还要在每个点上搜索原形链,这将需要更长时间。
·计算简化,如:for(var i=2;i<=Math.sqrt(n);i++){if(n%i==0){return false}}
·前面提到每帧的渲染应该在16ms内完成,但在动画过程中,由于已经被占用了不少时间,所以JavaScript代码运行耗时应该控制在3-4毫秒。如果真的有特别耗时且不操作DOM元素的纯计算工作,可以考虑放到Web Workers中执行。


-------------------------------调试实战-------------------------------

①资源请求调试:chrome→F12→network→刷新→分析请求时间过长的资源
②渲染调试:chrome→F12→performance→录制→生成报告→对红色性能部分进行分析。中文资源:https://segmentfault.com/a/1190000011516068

 (对于不理解的地方可以百度关键词,基本都有资源可以参考学习。本人后续还会继续补充细节,觉得不错就请点个赞吧!)

转载于:https://www.cnblogs.com/jacksplwxy/p/7913051.html

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值
>