APP开发平台 > Blog > 前端性能优化的常用手段

前端性能优化的常用手段

  前端性能优化就是很重要,不好好学习怎么进阶到20K+的薪水啊?!

  性能优化方面一直有所关注,但如果不去对自己所负责的项目进行一下回锅,实践实践,优化优化,总会有点“书上得来终觉浅”的感觉吧!

  从最开始的CSS放到里面、js放到前面、使用雪碧图等,到后面的静态资源压缩、合并以及使用iconfont代替小图标,再到最近实践的gzip压缩、设置HTTP Header缓存字段...

  gzip压缩、设置ETag等,早就在《高性能网站建设指南》那两本书中看过,但我一直认为这都是后端小伙伴干得事,就没有怎么留意过。直到最近,对前后端分离的理解越来越充分,对整个项目的部署越来越清晰,对项目里面的资源请求越来越明白,才恍然意识到:前后端分离了,这他妈就是前端自己干的事啊!!!

  从以下几个方面来说一说自己实践过的优化方法:

  ➤ 浏览器渲染页面的过程

  所谓优化,第一个要弄明白的就是:优化什么、从哪里优化。前端做出来的页面是在浏览器里面呈现的,那浏览器是怎么渲染这个页面的呢?遇到CSS、js静态资源,浏览器是怎么处理的?具体的过程这里不再赘述,网上资源一大堆,我自己之前也写过一篇,《网站性能优化—CRP》,算是谷歌文档的翻译版吧。

  理解了浏览器渲染页面的过程,也就明白了:CSS为什么要放到里面、js放到前面,以及js的异步加载(async、defer)等优化。

  ➤ 减少HTTP请求

  CSS/JS 合并打包

  小图标等用iconfont代替:作为单个DOM节点使用,可以设置大小、颜色等,非常便利。个人建议前端来维护这个字体包,每次有新增的图标,让设计师给我们对应的svg文件即可,前端自己去 https://icomoon.io/ 这个网站,导入原来的selection.json文件,增量生成新的css,无比方便。之前,我一直以为iconfont只能是单色的呢,其实也可以是多色的,svg里面多一些path而已,设计师会搞定的。生成字体后,前端正常引用即可(引用的时候,多色字体会多一些标签)

  使用base64格式的图片:有些小图片,可能色彩比较复杂,这个时候再用iconfont就有点不合适了,此时可以将其转化为base64格式(不能缓存),直接嵌在src中,比如webpack的url-loader设置limit参数即可

  使用雪碧图:设置背景图尺寸大小,感觉很麻烦,而且雪碧图的维护也不怎么便利,好像使用率越来越低了,都被iconfont取代了

  ➤ 减少静态资源的体积

  压缩静态资源:合并打包的js、css文件体积一般会比较大,一些图片也会比较大,这个时候必须要压缩处理。前后端分离项目,不论是gulp还是webpack,都有相应的工具包。针对个别图片,有时候也可以单独拿出来处理,我个人经常使用这个网站 https://tinypng.com/ 在线压缩

  编写高效率的CSS:涉及到代码层面的优化比较多也比较细,不同水平的技术人员写出来的肯定不一样,这里不做进一步的分析。但是为什么要把CSS拿出来说一说呢?因为现在项目里面基本上都在使用CSS预处理器,Less、SaaS、Stylus等等,这导致了某些初级前端的滥用:嵌套5、6层,甚者能达到7、8层,吓死个人!嵌套这么深,影响浏览器查找选择器的速度不说,这也一定程度上产出了很多冗余的字节,这个要改、要提醒,一般建议嵌套3层即可。关于编写高效率的CSS,推荐一篇文章,《Writing efficient CSS selectors》

  服务端开启gzip压缩:大招,最近刚知晓,真是太牛逼了,一般的css、js文件能压缩60、70%,当然,这个比率可以设定的。前后端分离,如果前端部署用node、express作服务器的话,使用中间件compression即可开启gzip压缩:

  // server.jsvar express = require('express');var compress = require('compression');var app = express();

  app.use(compress());

  对于一般的SPA项目,如果node服务器的作用比较简单,比如只是做个接口转发之类的,很多人更倾向用Nginx作服务器,Nginx在转发接口、压缩、缓存等功能上更胜一筹。不过,大部分前端对Nginx应该陌生一些,为了实践技术,用熟悉的node即可,真正的项目部署,有专业的实施人员来搞。

  ➤ 使用缓存

  设置Http Header里面缓存相关的字段,做进一步的优化。

  express里面也有对静态资源相关的设置,只不过平时没怎么注意:

  可以设置etag、maxAge等,进一步会有200缓存和304缓存的区别:

  200 OK (from cache) 是浏览器没有跟服务器确认,直接用了浏览器缓存;而 304 Not Modified 是浏览器和服务器多确认了一次缓存的有效性,然后再使用的缓存。

  相关的讨论可以参考 知乎:阿里云存储如何让浏览器始终以200 (from cache)缓存图片?

  ➤ 内存溢出

  这种优化因问题而异吧,最重要的是善于使用Google DevTools里面的Performance面板和Memory面板去分析、查找问题,进而找到优化的点。

  内存溢出目前我只碰到过一次,同事用echarts画K线图,同事的js逻辑写的有问题,点击事件发生时canvas反复渲染,导致内存逐渐升高,在APP内,直接导致了APP闪退。我重写了一下js逻辑,针对canvas做了一些优化,修复了这个bug。

  目前对这块分析经验还不是很多,后续碰到问题再实践。

  性能优化这块,都是一点一点接触的,项目中碰到了问题,然后去分析、优化,解决问题的同时,自己也收获了很多知识。以上是我做前端使用过的优化方法,可能对于大牛来说,或许不值得的一提,但是对于新手来说应该还是有些许参考意义。

  有些高级优化还没有实践到,比如划分主域,细节一点的无线滚动优化等,后期会继续学习。


        更多APP资讯,请关注www.apicloud.com

  原文作者:亚洲黑色卍,如有侵权,请联系删帖。


2017-12-26 来源:APICloud

An efficient app outsourcing platform that guarantees timely delivery!

Submit Requirements