您的位置:首页 > Web前端

161026、更快速将你的页面展示给用户[前端优化篇]

2016-11-01 16:53 260 查看
现在许多公司往往注重后端优化,而忽略了前端优化

想想如果辛苦优化了服务器,后台,排查了sql,却在最后页面加载展示的时候很慢,也得不偿失

其实,前后台优化都是相辅相成的,后台优化好了,响应请求速度快,前台展示的更迅速

前台优化了不必要的请求,后台压力也会更小

一直想静下心来写一篇博文,无奈心浮气躁,不得安定,断断续续一直写到今天….那么现在就来和大家分享一下我的前端优化经验吧

大纲:

请求优化

图片延迟加载

ajax局部加载数据

预加载

资源优化

资源压缩(uglify-js,clean-css)

资源合并

图片合并csssprite

iconfont

引用优化

单独域名存放资源

缓存

Cache-Control缓存策略

离线存储

本地存储localStorage

其它的

css3替换js动画

替换flash

结语

请求优化

首先我们来优化HTTP请求数

由于用户浏览的,往往只是局部网页,
所以只加载用户可视范围内的资源,就会减少一些不必要的请求,也会减少浏览器加载资源的消耗
考虑到移动端可视范围,网络流量,性能,延迟加载作用尤为明显

图片延迟加载

适合延迟加载的东西很多,最需要的当然是图片,这里推荐lazyload

https://github.com/tuupola/jquery_lazyload


图片延迟加载的原理就首先将要延迟加载的图片src替换为空白图片或者参数指定的loading图
然后根据当前元素的位置(offset)来判断是否在页面可视范围(页面宽/高度+滚动宽/高度)

如果在,就将真实图片资源路径替换回src让浏览器加载

防止浏览器解析到HTML中标签的src属性就开始下载资源,最好将原的src属性去掉
统一配置lazyload的参数去加载loading图吧,如我们项目中这样:

$(".main_contentimg").lazyload({


placeholder:"/images/loading.gif",


threshold:200


});


再来看到lazyload的源代码,可视范围判断上下左右,写的十分完善

$.belowthefold=function(element,settings){


varfold;




if(settings.container===undefined||settings.container===window){


fold=(window.innerHeight?window.innerHeight:$window.height())+$window.scrollTop();


}else{


fold=$(settings.container).offset().top+$(settings.container).height();


}




returnfold<=$(element).offset().top-settings.threshold;


};




$.rightoffold=function(element,settings){


varfold;




if(settings.container===undefined||settings.container===window){


fold=$window.width()+$window.scrollLeft();


}else{


fold=$(settings.container).offset().left+$(settings.container).width();


}




returnfold<=$(element).offset().left-settings.threshold;


};




$.abovethetop=function(element,settings){


varfold;




if(settings.container===undefined||settings.container===window){


fold=$window.scrollTop();


}else{


fold=$(settings.container).offset().top;


}




returnfold>=$(element).offset().top+settings.threshold+$(element).height();


};




$.leftofbegin=function(element,settings){


varfold;




if(settings.container===undefined||settings.container===window){


fold=$window.scrollLeft();


}else{


fold=$(settings.container).offset().left;


}




returnfold>=$(element).offset().left+settings.threshold+$(element).width();


};




$.inviewport=function(element,settings){


return!$.rightoffold(element,settings)&&!$.leftofbegin(element,settings)&&


!$.belowthefold(element,settings)&&!$.abovethetop(element,settings);


};


关于图片这里,除了延迟加载外,用户上传的图片以及我们所用的资源图片都应该进行压缩处理
如需要进一步提高压缩率,可以使用例如:google开发的webp图片格式等..
不过不是所有浏览器都支持webp格式,需要针对浏览器响应

ajax局部加载数据

根据上面这段代码,其实我们就可以延迟加载其他内容了,
总之呢,这里我们的目的就是尽量减少不必要的请求

比如现在用的很多的下拉式翻页,就是判断到页面底部之后再ajax获取下页内容

如果考虑到网页只是局部更新的话,那使用ajax是很合适的
好处显而易见,无需重新请求整页,小巧快速,网页展示也友好一些

善用ajax对前端性能,体验都是有改善的

但是也要考虑到对搜索引擎的友好,
如果页面整体功能改变了,或者页面改动量大就要进行取舍了。

预加载

延迟加载的目的就是减少不必要的请求,在用户有需求时才请求资源
所以对于用户来说,其实是有一点点“等待”的过程的

一般会用loading图,等待文字来改善这里的用户体验

但是有一些需求是希望尽量少出现这种“等待”过程的

这里我们就可以预加载资源,如下,我们先在js中加载图片

varimg=newImage();


img.src="test.png";


提前加载好了图片,用户进行下一步时,图片则是从浏览器缓存中获取

多页数据也可以类似处理,页面初始可以默认加载两页数据
翻到第二页时,就ajax去获取第三页内容
翻到第三页时,就去获取第四页内容……
总是提前预加载一页数据

如此可一定程度上减少一些等待的过程

总的来说延迟加载是尽量少加载资源,预加载则是判断可能要的资源,尽量去提前多加载,
都是为了优化用户的体验,适用于不同场景

资源优化

网页中有些资源可以通过延迟加载等方式减少不必要的请求
而许多的javascript脚本,css样式等资源却是网页中必须要加载的

既然不可避免需要加载,那接着,我们就可以去优化这些资源

资源压缩(uglify-js,clean-css)

首先我们可以优化资源文件的大小,资源文件变小了,传输速度当然也快了
这里我们压缩分为如下两种:

HTTP压缩,我们可以在web服务器内设置压缩输出的内容

如下,在IIS7内启用Gzip压缩


可以看到,设置了之后资源的HTTP响应多了Content-Encoding:gzip


对javascript代码,css样式代码进行语法压缩,减少文件大小
我们写js代码,css,都命名尽量取得有意义,多换行,tab把格式弄的优美
都是为了方便维护,再阅读,而机器解析我们的代码的时候可不管这些。

这里压缩我推荐uglify-js和clean-css,都在nodejs环境下


这里可见压缩效果还是很显著的,按我目前代码习惯,平均可以压缩一半左右

但是,不可避免,我们在日常开发,发布的时候,会增加额外的工作量

这里我分享一下我的用法:

为了方便开发,我在项目中还是引用的原文件
只是在生成发布文件后,执行下面bat批处理脚本

把发布文件夹内的js代码进行压缩,同名覆盖原文件,这样就不用修改项目内js引用地址

@echooff


::设置压缩JS文件的根目录,脚本会自动按树层次查找和压缩所有的JS


SETJSFOLDER=D:\project\scripts


echo正在查找JS文件


chdir/d%JSFOLDER%


for/r.%%ain(*.js)do(


@echo正在压缩%%~a...


uglifyjs%%~fa-mangle-o%%~fa


)


echo完成!


pause&exit


(*这个bat批处理脚本不是我写的,是以前在网上搜来的)

资源合并

我们项目内往往会引用多个javascript脚本,和多个css样式文件
所以可以把多个脚本合并到一个js文件内,然后统一引用它就能减少http请求

这里uglify-js和clean-css都支持多个文件合并压缩输出

>uglifyjsjs1.jsjs2.js-m-omerge.js


>cleancss-omegar.cssstyle1.cssstyle2.css


也可以在服务器内合并输出,比如我们看淘宝的合并:

<scriptsrc="//g.alicdn.com/kissy/k/6.2.4/??node-min.js,node-base-min.js,dom-base-min.js,query-selector-base-min.js,dom-extra-min.js,node-event-min.js,event-dom-base-min.js,event-base-min.js,event-dom-extra-min.js,event-gesture-min.js,event-touch-min.js,node-anim-min.js,anim-transition-min.js,anim-base-min.js,promise-min.js,base-min.js,attribute-min.js,event-custom-min.js,json-base-min.js,event-min.js,io-min.js,io-extra-min.js,io-base-min.js,io-form-min.js,cookie-min.js"></script>


他们则是在web服务器内做了处理,请求多个文件,会自动合并
有条件的同学也可以这样进行合并

图片合并csssprite

图片合并目的也是减少http请求,将页面中需要的相关图片合并到一张大图片里
然后用css的background-position定位到大图的具体局部位置

比如这样:


但是近年来好像用的越来越少了
想想原因,应该是。。。。维护起来[太麻烦]了
只要稍微改动一张图片,尤其是改变了大小的话,整个大图片都要改
并且还要把css样式也改个遍
否则就是继续往大图片里拼,无效的老图保留,导致图片越来越臃肿

再有,如果只是一些这样的小图标的话,用fonticon要方便得多

iconfont

iconfont就是图标字体,将图标输出为矢量的字体

使用起来非常方便,对应字体的编码,就和网页中的普通文字一样

<iclass="iconiconfont">U</i>


它对比合并的图片来说
体积会更小,并且能用css控制大小,颜色
然后它还是矢量的,放大也不失真

虽然iconfont制作,维护成本也不低,引用起来为兼容浏览器得引用多种格式
但好在现在用的人多,网上也有许多免费图标库供使用

比如这里阿里巴巴图标库

http://iconfont.cn/


引用优化

引用css放在内,引用js放在结束标签前,现在很多朋友都会这么做了

css加载是异步的,更早的加载出样式就能更早呈现出页面
js放在尾部,防止浏览器加载js而阻塞页面,造成页面“白屏”现象

单独域名存放资源

如果有条件的话,我们还可以启用额外的服务器,域名来存放资源

这样能减少主域名的HTTP请求数,让主服务器更快响应请求
还能减少主域名的cookie请求

缓存

说到缓存,首先想到的肯定是服务器后台的缓存
其实,打开我们的浏览器工具看一下,就会发现,网页前台也存在着许多缓存
它无声无息,悄悄优化着每一次访问

Cache-Control缓存策略

直接看响应头,我们会发现这些字段:


Expires:Thu,20Oct201606:43:43GMT//告诉浏览器此日期以前可以使用缓存文件


Cache-Control:public,max-age=3600//表示资源在3600毫秒之内可以使用缓存文件,如果和Expires同时存在则覆盖Expires


Last-Modified:Wed,13Jul201508:52:12GMT//配合Cache-Controls使用,标示资源的最后修改日期


ETag:5384183131862232576//配合Cache-Controls使用,标示资源由服务器生成的唯一标识(某些资源最后修改日期不可靠,或者不希望展示最后修改日期,就可以使用ETag)


上面这些都是控制前端缓存的字段,然后再来看看下面的HTTP状态码

//200OK请求已成功,请求所希望的响应头或数据体将随此响应返回。


//304NotModified请求资源没有改变,可以使用缓存资源


所以这里当我们第一次访问的时候,得到响应资源及缓存策略,

之后如果缓存有效,资源就会来自缓存
如果缓存无效了,就会判断是否有Last-Modified或者ETag,有则发送If-Modified-Since或If-None-Match请求头
服务器如果判断资源无修改,就会返回304,有修改就会返回200以及新的缓存策略

当然,这里只是指用户的普通操作,如:地址栏回车,页面链接跳转,新窗口,前进后退
如果用户是进行刷新操作,则不会读取缓存资源了,但是如果有Last-Modified或者ETag,依然会发送If-Modified-Since或If-None-Match请求头
如果用户是进行强制刷新(ctrl+f5)操作,那所有缓存策略都失效,会重新请求

可见,我们往往只有第一次请求的时候,才会有较多的资源加载
所以我们上面做了这么多优化,延迟加载,资源压缩,合并等等,
都是为了用户第一次访问的时候尽量友好。

那么Cache-Control要如何在服务器设置呢,其实针对静态资源来说
大部分服务器都会默认就将Cache-Control设置好了的,我们可以视情况修改一些时效参数等等

我们这里要注意的是用url去控制缓存的有效性

如下:


虽然它们请求的都是服务器上的同一个js文件,但是浏览器不会把它们当作同一个资源

可以看到v=1.01.js的请求是来源于cache
其他几个请求都是新请求

所以,我们每次发布都可以修改资源url强制让用户页面上的缓存失效
这样用户不需要刷新也能得到最新的资源

离线存储

离线存储在我之前一篇文章里也提到过,在移动端应用的比较多
它和缓存不同,它设置好了之后,连离线也能访问,无论用户刷新或者新窗口,链接等等

使用manifest

<htmlmanifest="/mobile.manifest">


在html上添加manifest,其中文件格式内容如:

CACHEMANIFEST


##需要离线的内容


CACHE:




Script/jquery.js


Script/gameconfig.js






Image/home.png


Image/logo.png




##总是访问网络的内容


NETWORK:


*


##访问A失败时访问B


FALLBACK


浏览器将缓存chache内所有的内容,并且可以离线访问,只要文件发生任何改变都将会重新读取并刷新全部缓存,所以更改注释是个更新缓存的好方法

这里要注意的是

添加了manifest的当前网页也会被缓存所以推荐的方式是页面缓存,页面动态内容全部用ajax获取,所以在移动网站项目设计开始就要注意这个问题

页面中添加iframe然后子页面引用manifest想达到缓存资源而不缓存当前页面内容,是无效的。

本地存储localStorage

本地存储数据一直是网页端的弱项,在没有HTML5的localStorage前,用cookie可以保存一点数据
但付出的代价很大,cookie能保存的数据很少,并且它会伴随着每一次请求一起发送

localStorage就好多了,默认5MB的大小,除非用户手动清除,否则一直不过期,就连IE8浏览器都支持

这里要注意,localStorage和cookie一样受到跨域的限制
可以使用domain控制

document.domain="";


其它的

css3替换js动画

在js中,我们实现动画,就是利用定时器循环改变dom元素的属性来达到动画效果,但是许多属性更改之后会造成浏览器重绘,增加性能消耗

当然浏览器更新换代也做了许多优化,我们优化js,css减少重绘,也能改进动画性能,但是想一想,究竟应不应该让js去实现页面动画呢?

css3就是往这方面发展,让js更纯粹的去实现业务逻辑,页面效果之类的事情就让css去做吧

并且css3在动画效率上面也有增强,浏览器会单独处理css3动画,不占用js主线程,还可以硬件加速,将来还有提升的可能,所以快把我们的js动画替换为css3吧!

替换flash

同样更迭的还有flash,当初flash是为了弥补网页展现的不足而出现的“插件”,而现在网页标准一次次升级,html5的出现,再加上flash自身也有各种漏洞,性能问题,尤其是现在flash在移动端的支持很少,都加快了我们替换flash的步伐

结语

写到这里快写完了,突然发现好像自己在啰啰嗦嗦了一整页。。
却又感觉哪里漏都了一些,好吧,希望大家不要嫌烦,如果都了解了,就当温习吧
如有纰漏,欢迎提醒

哦,还有些想说的

优化一定要选择适合自己项目,硬件条件的优化方式,千万不要盲目硬搬
还有要持续不断的关注新标准,方法,一直保持活力!
内容来自用户分享和网络整理,不保证内容的准确性,如有侵权内容,可联系管理员处理 点击这里给我发消息
标签: