关于前端性能优化相关的技术知识,网上随便搜一些就有很多,本文将系统性的从初级到高级的思路,总结移动前端性能优化各个方面的相关技术点,内容来自笔者以往经验的总结,希望读者可以花些时间看看。
在目前大多数刚从事前端开发,或者是正在学习前端开发的同学来说,性能优化对于他们可能还比较远,但是脱颖而出,拉开差距的点,往往就在与性能优化,和理论知识不同,性能优化往往来自日常的工作经验中总结而来,也是目前大厂面试前端必问的知识点,所以重要性就不言而喻了。
一,入门篇
1.资源合并与压缩
为什么要压缩?
不同于大部分放在服务端的后台代码,前端所有的文件程序代码都是要通过浏览器下载下来运行使用,这就牵扯到网络和请求延时,所以前端文件的精简和压缩决定了前端性能的第一步。
介于目前的前端框架类库,webpack,vue-cli等等,已经可以直接将这一步操作集成到我们的系统项目中了,可以直接查看各个框架的文档来进行配置,单纯的使用原生技术,可以参考下面:
html的压缩
HTML代码压缩就是压缩这些在文本文件中有意义,但是在HTML中不显示的字符,包括空格,制表符,换行符等,还有一些其他意义的字符,如HTML注释也可以被压缩。
- Nodejs的html-minifier。
- 在线压缩工具,站长工具等等。
CSS和JavaScript文件的压缩
JavaScript压缩,主要是去除多余的换行和空格等等,对于语法来说,JavaScript可以选择混淆压缩和非混淆压缩,无论哪种压缩都是为了减少JavaScript的文件大小,当然出于前端代码保护来看,混淆压缩会大大破坏原有的阅读逻辑,增加压缩比,从而给代码添加一层保护。 CSS压缩,同理是去除多余的换行和空格等等,由于CSS文件的特殊性暂时无法实现混淆压缩,压缩主要是将大量的换行去除,可以减少不少的文件大小。
图片的压缩
对于常见的前端项目,关于图片的使用,主要有以下两种:
- 固定图标,背景,按钮icon等等,这些图片有一个特点就是固定和用户无关,一般是放在源码包里面,由前端代码直接引入。
- 人物头像,文章配图,内容图片等等,这些非固定图片一般由用户上传,有很强的用户性,这些图片一般放在
CDN
上,前端通过链接请求。
- 对于固定图片,推荐tinypng.com/在线压缩之后再进行引入,支持png,jpeg类型的图片,属于有损压缩,去除图片一些不必要的元数据,把相似像素的24bit位用8bit位来表示,肉眼很难区分,压缩率70%。
- 采用CSS雪碧图:把你的网站用到的一些图片整合到一张单独的图片中:
优点:减少HTTP请求的数量(通过
backgroundPosition
定位所需图片)。 缺点:整合图片比较大时,加载比较慢(如果这张图片没有加载成功,整个页面会失去图片信息)。 - 对于非固定图片,常见的优化压缩主要有以下几种原则:
优先使用压缩率高的
jpeg
类型图片,缺点是不支持透明。 有条件的话使用webP(一种Google开发的新类型)类型图片是最佳选择,相比于jpeg,有更小的文件尺寸和更高的图像质量。
资源合并
在前端编码的时候将css、js等静态资源文件合并压缩之外,我们还可以在页面中将多个css、js的请求合并为一个请求。文件的合并带来的是http请求数的减少,尤其是在移动端,每一个http请求带来的是慢启动
,三次握手
,连接建立
,所以资源的合并是由为重要的,合并和不合并对比:
2.浏览器加载原理优化
HTML页面加载渲染的过程:
根据上图我们来屡一下整个流程:
- 当浏览器从服务器接收到了HTML文档,并把HTML在内存中转换成DOM树,在转换的过程中如果发现某个节点(node)上引用了CSS或者 IMAGE,就会再发1个request去请求CSS或image,然后继续执行下面的转换,而不需要等待request的返回,当request返回 后,只需要把返回的内容放入到DOM树中对应的位置就OK。
- 但当引用了JS的时候,浏览器发送1个js request就会一直等待该request的返回。
- 因为浏览器需要1个稳定的DOM树结构,而JS中很有可能有代码直接改变了DOM树结构,浏览器为了防止出现JS修改DOM树,需要重新构建DOM树的情况,所以 就会
阻塞
其他的下载和呈现。 那么如何解决和避免阻塞的问题呢,我们通过测试代码分别测试不同情况下引入js和css的问题如下:
<!DOCTYPE html>
<html>
<head>
<title>test</title>
<link rel=”stylesheet” type=”text/css” href=”stylesheet.css” media=”screen”>
<link rel=”stylesheet” type=”text/css” href=”page-animation.css” media=”screen”>
<script type =”text/javascript” >
测试过程省略,可以参考这里,我们可以得到如下的结论:
- 浏览器存在并发加载:资源请求是并发请求的。
- 浏览器中可以支持并发请求,不同浏览器所支持的并发数量不同(以域名划分),以Chrome为例,并发上限为6优化点: 把CDN资源分布在多个域名下。
- css 在head中通过link引入会阻塞页面的渲染,处于页面样式,我们必须这样放置。
- 直接通过
<script src>
引入的外部js会阻塞后面节点的渲染,所以外部js尽量放在body底部。 - 在head里面尽量不要引入js。
- 如果要引入js 尽量将js内嵌。
- 把内嵌js放在所有link引入css的前面。
- 对于要阻塞后续内容的的外部js
<script src>
,需要增加defer
来解决。
3.缓存优化
如果一个H5页面没有利用任何缓存,那么这个页面将没有任何存在的意义。
从从HTTP协议缓存,到浏览器缓存,再到APP Cache,一直在最近比较火的Service worker,我们可以选择多种的缓存方式,入门基本来说说HTTP协议缓存:
强缓存:Expires&Cache-Control
当浏览器对某个资源的请求命中了强缓存时,返回的HTTP状态为200,在chrome的开发者工具的network里面 size会显示为from disk cache,这种情况下是不用发送任何请求,如下图
- Expires:指定了在浏览器上缓冲存储的页距过期还有多少时间,等同Cache-control中的max-age的效果,如果同时存在,则被Cache-Control的max-age覆盖。
- Cache-Control:
- public:响应被缓存,并且在多用户间共享。
- private:默认值,响应只能够作为私有的缓存(e.g., 在一个浏览器中),不能再用户间共享;
- no-cache:响应不会被缓存,而是实时向服务器端请求资源。
- max-age:数值,单位是秒,从请求时间开始到过期时间之间的秒数。基于请求时间(Date字段)的相对时间间隔,而不是绝对过期时间;
协商缓存:Last-Modified&Etag
当浏览器对某个资源的请求没有命中强缓存,就会发一个请求到服务器,验证协商缓存是否命中,如果协商缓存命中,请求响应返回的http状态为304并且会显示一个Not Modified的字符串,比如你打开京东的首页,按f12打开开发者工具,再按f5刷新页面,查看network,可以看到有不少请求就是命中了协商缓存的:
- Last-Modified/If-Modified-Since:本地文件在服务器上的最后一次修改时间。缓存过期时把浏览器端缓存页面的最后修改时间发送到服务器去,服务器会把这个时间与服务器上实际文件的最后修改时间进行对比,如果时间一致,那么返回304,客户端就直接使用本地缓存文件。
- Etag/If-None-Match:(EntityTags)是URL的tag,用来标示URL对象是否改变,一般为资源实体的哈希值。和Last-Modified类似,如果服务器验证资源的ETag没有改变(该资源没有更新),将返回一个304状态告诉客户端使用本地缓存文件。Etag的优先级高于Last-Modified,Etag主要为了解决
- Last-Modified 无法解决的一些问题。
- 文件也许会周期性的更改,但是他的内容并不改变,不希望客户端重新get;
- If-Modified-Since能检查到的粒度是s级;
- 某些服务器不能精确的得到文件的最后修改时间。
4.懒加载与预加载
懒加载对于移动web端,尤其是最常见的滚动加载场景是一项非常重要的优化措施。而预加载则常常应用于多tab场景的页面,让用户更快的看到打开的下一个页面。
懒加载
- 图片进入可视区域之后请求图片资源。
- 对于电商等图片很多,页面很长的业务场景适用。
- 减少无效资源的加载。
- 并发加载的资源过多会会阻塞js的加载,影响网站的正常使用。
img src被设置之后,webkit解析到之后才去请求这个资源。所以我们希望图片到达可视区域之后,
img src
才会被设置进来,没有到达可视区域前并不现实真正的src,而是类似一个1px的占位符。
预加载
- 图片等静态资源在使用之前的提前请求。
- 资源使用到时能从缓存中加载,提升用户体验。
- 点击操作前预先加载下一屏数据。
对于一些刚入门的前端玩家,或者是还在学习前端的同学,掌握了上面的入门级性能优化基础知识,才能算是基本的合格,真正更进一步的优化,更适合移动端web的性能点,可以参考进阶版。