前端性能优化的经常使用手段

时间 2019-11-09

原文原文链接

反正，前端性能优化就是很重要，很差好学习怎么进阶到20K+的薪水啊？！javascript

性能优化方面一直有所关注，但若是不去对本身所负责的项目进行一下回锅，实践实践，优化优化，总会有点“书上得来终觉浅”的感受吧！css

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

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

从如下几个方面来讲一说本身实践过的优化方法：node

浏览器渲染页面的过程

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

理解了浏览器渲染页面的过程，也就明白了：CSS为何要放到<head>里面、js放到</body>前面，以及js的异步加载（async、defer）等优化。web

减小HTTP请求

CSS/JS 合并打包
小图标等用iconfont代替：做为单个DOM节点使用，能够设置大小、颜色等，很是便利。我的建议前端来维护这个字体包，每次有新增的图标，让设计师给咱们对应的svg文件便可，前端本身去 icomoon.io/ 这个网站，导入原来的selection.json文件，增量生成新的css，无比方便。以前，我一直觉得iconfont只能是单色的呢，其实也能够是多色的，svg里面多一些path而已，设计师会搞定的。生成字体后，前端正常引用便可（引用的时候，多色字体会多一些标签）
使用base64格式的图片：有些小图片，可能色彩比较复杂，这个时候再用iconfont就有点不合适了，此时能够将其转化为base64格式（不能缓存），直接嵌在src中，好比webpack的url-loader设置limit参数便可
~~使用雪碧图：设置背景图尺寸大小，感受很麻烦，并且雪碧图的维护也不怎么便利，好像使用率愈来愈低了，都被iconfont取代了~~

减小静态资源的体积

压缩静态资源：合并打包的js、css文件体积通常会比较大，一些图片也会比较大，这个时候必需要压缩处理。先后端分离项目，不管是gulp仍是webpack，都有相应的工具包。针对个别图片，有时候也能够单独拿出来处理，我我的常用这个网站 tinypng.com/ 在线压缩
编写高效率的CSS：涉及到代码层面的优化比较多也比较细，不一样水平的技术人员写出来的确定不同，这里不作进一步的分析。可是为何要把CSS拿出来讲一说呢？由于如今项目里面基本上都在使用CSS预处理器，Less、SaaS、Stylus等等，这致使了某些初级前端的滥用：嵌套五、6层，甚者能达到七、8层，吓死我的！嵌套这么深，影响浏览器查找选择器的速度不说，这也必定程度上产出了不少冗余的字节，这个要改、要提醒，通常建议嵌套3层便可。关于编写高效率的CSS，推荐一篇文章，《Writing efficient CSS selectors》
服务端开启gzip压缩：大招，最近刚知晓，真是太牛逼了，通常的css、js文件能压缩60、70%，固然，这个比率能够设定的。先后端分离，若是前端部署用node、express做服务器的话，使用中间件compression便可开启gzip压缩：express
```
// server.js
var express = require('express');
var compress = require('compression');
var app = express();
app.use(compress());复制代码
```
对于通常的SPA项目，若是node服务器的做用比较简单，好比只是作个接口转发之类的，不少人更倾向用Nginx做服务器，Nginx在转发接口、压缩、缓存等功能上更胜一筹。不过，大部分前端对Nginx应该陌生一些，为了实践技术，用熟悉的node便可，真正的项目部署，有专业的实施人员来搞。json

使用缓存

设置Http Header里面缓存相关的字段，作进一步的优化。gulp

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

能够设置etag、maxAge等，进一步会有200缓存和304缓存的区别：

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

内存溢出

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

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

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

性能优化这块，都是一点一点接触的，项目中碰到了问题，而后去分析、优化，解决问题的同时，本身也收获了不少知识。以上是我作前端使用过的优化方法，可能对于大牛来讲，或许不值得的一提，可是对于新手来讲应该仍是有些许参考意义。

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

PS： [译]无尽滚动的复杂度--来自Google大神的拆解，这个无线滚动的优化我看了很久了，尚未理出个因此然来 😓