上一篇讲了PC端的部分:前端性能优化(PC端),此次继续说移动端的。相对于PC端的,移动web浏览器上有一些明显的特色:设备的屏幕小、新特性兼容性较好、支持一些比较新的HTML5和CSS三、须要与Native应用交互等。但移动端可用的CPU资源和网络资源极为有限,所以要作好移动端web上的优化每每须要考虑作更多的事情。首先在移动web的前端页面渲染中,PC的优化规则一样适用,此外针对浏览器也要作一些更细节的优化达到更好的效果。须要注意的是,并非移动端的优化在PC端不适用,而是因为兼容性的缘由,一些优化规则在移动端更具备表明性,因此也是为何我把DNS预解析,离线缓存,HTTP2协议,GPU加速等东西放到这部分来说...javascript
为了进一步提示页面加载速度,能够考虑将页面的数据请求尽量提早,避免在JavaScript文件加载完成后才去请求数据。一般数据请求是页面内容渲染中关键路径最长的部分,并且不能并行,因此若是数据请求能提早的话,能够极大程度上缩短页面内容的渲染完成时间。css
因为移动端网络相对较慢,网络资源有限,所以为了保证尽快完成页面内容的加载,须要保证首屏加载资源的最小化,非首屏的内容使用滚动的方式异步加载。通常推荐移动端页面首屏数据展现延迟不超过3秒。html
主要指模块化JavaScript资源的异步加载,例如AMD的异步模块,使用并行的加载方式可以缩短多个文件资源的加载时间。前端
一般为了在HTML加载完成时能使浏览器中有基本的样式,须要将页面渲染时必备的CSS和JS经过script或style的方式内联到页面中,避免页面HTML载入完成到页面内容展现这段过程当中页面出现空白java
设置文件资源的DNS预解析,能让浏览器提早解析获取静态资源的主机IP,避免等到请求的时候才发起DNS解析。web
<!-- cdn域名预解析 --> <meta http-equiv='x-dns-prefetch-control' content='on'> <link rel="dns-prefetch" href="//x.autoimg.cn">
首屏加载完成后可能会使用的资源,咱们能够用 link标签声明特定文件的预加载ajax
<link rel='subresource' href='main.css'> <link rel='prefetch' href='secondary.js'>
注意:只有可缓存的资源才进行预加载,不然浪费资源!chrome
预渲染意味着咱们提早加载好用户即将访问的下一个页面,不然进行预渲染这个页面将浪费资源,慎用!编程
<link rel='prerender' href='//j.autohome.com.cn'>
一般状况下,TCP网络传输的最大传输单元(MTU)为1500B,即一个RTT(Round-Trip Time,网络请求返回时间)内能够传输的数据量最大为1500字节(为何以太网mtu值被设定为1500 - 知乎)。所以在先后端分离的开发模式中,尽可能保证页面的HTML内容在1KB之内,这样整个HTML内容的请求就能够在一个RTT内完成,最大限度的提升了HTML载入速度canvas
除了上一节说到的Cache-Control、Expires、Etag和Last-Modified来设置HTTP缓存外,在移动端还可使用localstorage等来保存ajax返回的数据,或者使用localstorage保存CSS或JS等静态资源,实现移动端的离线应用,尽量的减小网络请求,保证静态资源内容的快速加载。
对于移动端或者混合应用,能够设置离线文件或离线包机制让静态资源请求从本地读取,加快资源载入速度,并实现离线更新。这块推荐叶小钗大神的前端优化带来的思考,浅谈前端工程化 能够挑着看。离线资源这块东西太多了,之后有时间单独拿出来写
AMP HTML 能够做为优化前端页面性能的一个解决方案,使用AMP Component中的元素来代替原始页面元素进行直接渲染 [译]关于谷歌的AMP,你须要知道这些。
移动端一般要保证页面中一切用到的图片都是通过压缩优化处理,而不是以原图的形式直接使用的,由于那样很消耗流量,而且加载时间更长。
在页面使用的背景图片很少且比较小的状况下,能够把图片转成base64编码嵌入到html页面或者CSS文件中,这样能够减小页面的HTTP请求数。须要注意的是,要保证图片较小,通常超过5kb的就不推荐base64嵌入显示了(前端开发中,使用base64图片的弊端是什么? - 知乎)
使用具备较高压缩比格式的图片,如webp等。在同等图片画质的状况下,高压缩比格式的图片体积更小,可以更快的完成文件传输,节省网站流量。

为了保证页面内容最小化,加速页面渲染,尽量节省首屏网络流量,页面中的图片资源推荐使用懒加载实现,在页面滚动时动态载入图片。
针对不一样屏幕尺寸和分辨率,输出不一样大小的图片或者背景图能保证用户体验不下降的前提下节省网络流量,加快部分机型图片载入速度,这在移动端很是值得推荐
iconfont体积较小并且是矢量图,所以缩放不会失真,还能够方便修改图片大小和呈现的颜色,可是须要注意iconfont引用不一样webfont格式会有兼容问题。
加载单张图片不建议超过30KB,避免大图片加载时间过长而阻塞页面其余资源的下载。若是用户上传的图片过大,建议设置限制。
选择页面DOM元素时尽可能使用id选择器,由于id选择器速度最快
对于须要重复使用的dom对象,要优先设置缓存变量,避免每次使用时都要从整个dom树从新查找。
// 不推荐 $("#mod .active").removeClass('active'); $("#mod .not-active").addClass("active"); // 推荐 const $mod = $("#mod"); $mod.find(".active").removeClass("active") $mod.find(".not-active").addClass("active")
jq 上有不少优化建议,详情搜索JQ 优化
使用事件代理能够避免对每一个元素都进行绑定。而且能够避免出现内存泄漏以及须要动态添加元素的事件绑定问题
// 不推荐 $(".btn").click( _ => console.log("hello") ) // 推荐 $(document).on("click", ".btn", _ => console.log("world"))
因为移动端屏幕的设计,touch事件和click事件触发之间存在300ms延迟,因此在页面没有touchmove实现滚动处理的状况,能够用touchstart代替元素的click事件,加快页面点击的响应速度,提升用户体验。但同时也须要注意页面重叠元素touch动做的点透问题。
// 不推荐 $("body").on("click",".btn",function(){ console.log(this) }); // 推荐 $("body").on("tap",".btn",function(){ console.log(this) }); // tap为zepto用touch事件封装的
须要对这类高频触发回调的事件设置函数节流(throttle | debounce),避免频繁的事件调用致使移动端页面卡顿
基本的安全脚本编写问题,尽量使用高效率的特性来完成这些操做,避免不规范或者不安全的写法。
ES6+在必定程度上更高效,在chrome59版本对ES6作了深度优化以后,不少特性速度提高了80%左右,这也是将来规范的须要。ES8前段时间也已经落地了,若是你尚未掌握ES6语法的话,抓紧时间学吧...
通常认为,在移动端设置viewport能够加速页面的渲染,同时能够避免缩放致使页面重排重绘。
// 利用meta标签对viewport进行控制
<meta name="viewport" content="width=device-width, initial-scale=1.0, maximum-scale=1.0, user-scalable=0">
页面的重排重绘很耗性能,因此必定要尽量减小页面的重排重绘,例如页面图片大小变化、元素位置变化这些状况都会致使重排与重绘
使用CSS3动画能够设置transform: translateZ(0)来开启移动设备浏览器的GPU图形处理加速。这里安利一波京东凹凸实验室,讲的挺好的,GPU加速是什么
选择canvas或者requestAnimationFrame等更高效的动画实现方式,避免使用settimeout、setInterval等方式直接处理连续动画
部分状况下能够考虑使用SVG代替图片实现动画,由于SVG格式内容更小,并且SVG的DOM结构方便调整
在DOM渲染树生成后的布局渲染阶段,使用float的元素布局计算比较耗性能,因此尽可能减小float的使用,推荐使用固定布局或者flex布局的方式来实现页面的元素布局
过多的font-size声明会增长字体的计算大小,并且也没啥必要
在条件容许的状况下能够考虑使用SPDY协议来进行文件资源传输,利用链接复用加快传输过程,缩短资源加载时间。HTTP2在将来也必定会成为主流的
SSR( Server Side Rendering,服务端渲染)的方式能够加速页面内容的渲染展现,避免空白页面的出现,同时能够解决页面SEO的问题。条件容许的话,SSR是一个很好的实践思路。百度SSP单页式应用性能优化实践,React 同构实践与思考
能够尝试使用Native View的MNV* 开发模式来避免HTML DOM性能慢的问题,目前使用MNV* 的开发模式已经能够将页面内容渲染体验作到接近客户端Native应用的体验了。
关于页面优化的经常使用技术手段和思路主要包括以上这些,有部分遗漏欢迎补充。你们能够根据须要将这些方法应用到本身的项目中去,想所有作到几乎是不可能的,但作到用户能够接受的程度仍是很容易的。
软件工程没有银弹,在咱们作到了极致优化的同时也须要付出很大的代价,这也是前端优化的一个问题。理论上这些优化均可以实现,可是咱们也要懂得权衡,优化提高了用户体验,使数据加载更快,可是项目代码却可能打乱,异步内容要拆分出来,首屏雪碧图可能要拆分2个或更多,项目代码维护成本成倍增长,项目结构也可能变得混乱。任何一部分优化均可以作得很深刻,但不必定都值得。在优化的同时考虑性价比,这才是咱们做为一名前端工程师处理前端优化时该具备的正确思惟。
PS:另外身位一个coder,虽然晚睡是常态了,但每次写东西都是熬到半夜二、3点身体也吃不消啊.... o(╥﹏╥)o !!