关于前端性能优化干系的技能知识，网上随便搜一些就有很多，本文将系统性的从低级到高等的思路，总结移动前端性能优化各个方面的干系技能点，内容来自笔者以往履历的总结，希望读者可以花些韶光看看。
在目前大多数刚从事前端开拓，或者是正在学习前端开拓的同学来说，性能优化对付他们可能还比较远，但是脱颖而出，拉开差距的点，每每就在与性能优化，和理论知识不同，性能优化每每来自日常的事情履历中总结而来，也是目前大厂口试前端必问的知识点，以是主要性就不言而喻了。
一，入门篇首先，主要的事情说三遍：
移动web性能优化事理知识同样适用于PCweb端！
移动web性能优化事理知识同样适用于PCweb端！
移动web性能优化事理知识同样适用于PCweb端！
1.资源合并与压缩
为什么要压缩？
不同于大部分放在做事真个后台代码，前端所有的文件程序代码都是要通过浏览器下载下来运行利用，这就牵扯到网络和要求延时，以是前端文件的精简和压缩决定了前端性能的第一步。
介于目前的前端框架类库，webpack，vue-cli等等，已经可以直接将这一步操作集成到我们的系统项目中了，可以直接查看各个框架的文档来进行配置，纯挚的利用原生技能，可以参考下面：
html的压缩
HTML代码压缩便是压缩这些在文本文件中故意义，但是在HTML中不显示的字符，包括空格,制表符,换行符等，还有一些其他意义的字符，如HTML注释也可以被压缩。
Nodejs的html-minifier。在线压缩工具，站长工具等等。CSS和JavaScript文件的压缩
JavaScript压缩，紧张是去除多余的换行和空格等等，对付语法来说，JavaScript可以选择稠浊压缩和非稠浊压缩，无论哪种压缩都是为了减少JavaScript的文件大小，当然出于前端代码保护来看，稠浊压缩会大大毁坏原有的阅读逻辑，增加压缩比，从而给代码添加一层保护。
CSS压缩，同理是去除多余的换行和空格等等，由于CSS文件的分外性暂时无法实现稠浊压缩，压缩紧张是将大量的换行去除，可以减少不少的文件大小。
Nodejs的uglifyjs2是一个强大的JavaScript压缩库。Nodejs的clean-css是一个强大的CSS压缩库。在线压缩工具，站长工具等等。图片的压缩
对付常见的前端项目，关于图片的利用，紧张有以下两种：
固定图标，背景，按钮icon等等，这些图片有一个特点便是固定和用户无关，一样平常是放在源码包里面，由前端代码直接引入。人物头像，文章配图，内容图片等等，这些非固定图片一样平常由用户上传，有很强的用户性，这些图片一样平常放在CDN上，前端通过链接要求。对付固定图片，推举https://tinypng.com/在线压缩之后再进行引入，支持png，jpeg类型的图片，属于有损压缩，去除图片一些不必要的元数据，把相似像素的24bit位用8bit位来表示，肉眼很难区分，压缩率70%。采取CSS雪碧图：把你的网站用到的一些图片整合到一张单独的图片中：优点：减少HTTP要求的数量(通过backgroundPosition定位所需图片)。
缺陷：整合图片比较大时，加载比较慢(如果这张图片没有加载成功，全体页面会失落去图片信息)。
3.对付非固定图片，常见的优化压缩紧张有以下几种原则：
优先利用压缩率高的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的问题如下：测试过程省略，可以参考这里，我们可以得到如下的结论：
浏览器存在并发加载：资源要求是并发要求的。浏览器中可以支持并发要求，不同浏览器所支持的并发数量不同（以域名划分），以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.
图片进入可视区域之后要求图片资源。对付电商等图片很多，页面很长的业务场景适用。减少无效资源的加载。并发加载的资源过多会会壅塞js的加载，影响网站的正常利用。img src被设置之后，webkit解析到之后才去要求这个资源。以是我们希望图片到达可视区域之后，img src才会被设置进来，没有到达可视区域前并不现实真正的src，而是类似一个1px的占位符。
预加载
图片等静态资源在利用之前的提前要求。资源利用到时能从缓存中加载，提升用户体验。点击操作前预先加载下一屏数据。ok，读到这里，对付一些刚入门的前端玩家，或者是还在学习前真个同学，节制了上面的入门级性能优化根本知识，才能算是基本的合格，真正更进一步的优化，更适宜移动端web的性能点，可以参考进阶版：
二，进阶篇1.资源合并与压缩启用GZIP
gzip是GNUzip的缩写，最早用于UNIX系统的文件压缩。HTTP协议上的gzip编码是一种用来改进web运用程序性能的技能，web做事器和客户端（浏览器）必须共同支持gzip。目前主流的浏览器，Chrome,firefox,IE等都支持该协议。常见的做事器如Apache，Nginx，IIS同样支持gzip。
gizp流程：
浏览器要求url，并在request header中设置属性accept-encoding:gzip。做事器支持gzip，response headers返回包含content-encoding:gzip。开启gzip可以达到80%的压缩率，即1MB的文件下载下来只须要200K，大大减少传输效率，是一项非常主要的资源压缩手段。Nginx中开启gzip：
升级HTTP/2.0
HTTP/2是HTTP协议自1999年HTTP 1.1发布后的首个更新，紧张基于SPDY协议（是Google开拓的基于TCP的运用层协议，用以最小化网络延迟，提升网络速率，优化用户的网络利用体验）。
优化事理：
根据上文中说的资源合并问题，浏览器可以同时建立有限个TCP连接，而每个连接都要经由慢启动，三次握手，连接建立，HTTP1.1为理解决这个问题推出了keep-alive，即保持连接不被开释，但是真正的这些连接下载资源是一个线性的流程：一个资源的要求相应返回后，下一个要求才能发送。这被称为线头壅塞，为了彻底办理此问题，HTTP2.0带来了多路复用：
HTTP2.0的其他新特性也有助于页面的打开速率：
二进制分帧做事器推送头部压缩合并资源 vs 并行加载资源？
现在回过分来磋商一下上文说的资源合并问题，有了HTTP2.0之后，我们是否还须要合并资源，目前看须要遵照下面的原则：
停滞合并文件在HTTP/1.1中，CSS，JavaScript被压缩到了一个文件，图片被合并到了一张雪碧图上。合并CSS、JavaScript和图片极大地减少了HTTP的要求数，在HTTP/1.1中能得到显著的性能提升。但是，在HTTP/2.0中合并文件不再是一个好的办法。虽然合并依然可以提高压缩率，但它带来了代价高昂的缓存失落效。纵然有一行代码改变了，全体文件就要重新打包压缩，浏览器也会逼迫重新加载新的文件。只管即便不要在HTML里内联资源非分外的代码（rem适配代码，上报代码等）之外，只管即便不要利用内联资源，在极度情形下，这确实能够减少给定网页的HTTP要求数。但是，和文件合并一样，HTTP/2优化时你不应该内联文件。内联意味着浏览器不能缓存单个的资源。如果你将所有页面利用的CSS声明嵌入了每一个HTML文件，这些文件每次都要从做事端获取。这导致用户在访问任何页面时都要传输额外的字节。合并域名拆分域名是让浏览器建立更多TCP连接的常日手段，浏览器限定了单个做事器的连接数量，但是通过将网站上的资源切分到几个域上，你可以得到额外的TCP连接，但是每个拆分的域名都会带来额外的DNS查询、握手，新连接的建立，根据HTTP2.0多路复用的原则：HTTP2采取多路复用是指，在同一个域名下，开启一个TCP的connection，每个要求以stream的办法传输，域名的合并可以带来更多的多路复用，如下图在chrome的Network面板中查看HTTP2.0，把稳protocol和ConnectID相同则表示启用复用:合理利用icon类图片base64化
在页面利用的背景类图片icon类图片，不多且比较小的情形下，可以把图片转成base64编码嵌入到html页面或者CSS文件中，这样可以减少页面的HTTP要求数。须要把稳的是，要担保图片较小，一样平常超过5kb的就不推举base64嵌入显示了。为什么是5kb？。
同时，采取Webpack的url-loader可以帮我们在不影响代码可读性的情形下，办理base64字符串问题。
Icon Font
IconFont技能起源于Web领域的Web Font技能，它是把一些大略的图标制作成字体，然后让图标变成和字体一样利用，Icon 的设计和利用在近几年的发展中，也经历了由当初的 img 方案 到现如今的 svg 方案，有以下优点：
字体是矢量的，以是可以随意改变大小。由于它是字体，以是所有字体的css都可以利用，比如font-size，color，background，opacity等。减少图片要求数。iconfont没有兼容性问题，IE6，Android2.3都能够兼容。2.浏览器加载事理优化首屏资源优化
剥离首屏资源首屏的快速显示，可以大大提升用户对页面速率的感知，因此应只管即便针对首屏的快速显示做优化，基于联通3G网络均匀338KB/s(2.71Mb/s)，以是首屏资源不应超过1014KB，剥离首屏须要的资源，非首屏的资源单独合并，采取CDN是将源站内容分发至最靠近用户的节点，利用户可就近取得所需内容，提高用户访问的相应速率和成功率。办理因分布、带宽、做事器性能带来的访问延迟问题，适用于站点加速、点播、直播等场景。
对付web页面来说，将项目的js，css等静态资源存放在CDN是一个主要的优化手段，加入所有资源统一打包放在同一个域名下，很难达到用户就近获取的上风（目前最佳实践是html页面采取一个域名，静态资源文件采取CDN域名），所谓静态资源即是可以被浏览器缓存的资源，而对付html页面，由于是js和css等链接的入口，常日不采取缓存。常用的阿里云CDN和腾讯云CDN都有开放接口，开拓者可以按需选择。
预加载
此预加载紧张分为两个部分，一种是采取原生浏览器支持的API来对页面的一些资源进行预先拉取或者加载，另一种是通过自己写逻辑来加载一些主要的资源，立即下面内容的条件是要立即目前移动web常见的hybrid架构，webview外壳+H5页面：
DNS预解析（dns-prefetch）DNS 作为互联网的根本协议，其解析的速率彷佛很随意马虎被网站优化职员忽略。现在大多数新浏览器已经针对DNS解析进行了优化，范例的一次DNS解析须要耗费 20-120 毫秒，减少DNS解析韶光和次数是个很好的优化办法。DNS Prefetching 是让具有此属性的域名不须要用户点击链接就在后台解析，而域名解析和内容载入是串行的网络操作，以是这个办法能 减少用户的等待韶光，提升用户体验 。
Preload 和 Prefetch两者都因此<link rel=\"大众preload\"大众> 和 <link rel=\公众prefetch\"大众>作为引入办法。Preload 一个基本的用法是提前加载资源,见告浏览器预先要求当前页须要的资源，从而提高这些资源的要求优先级，加载但是不运行，占用浏览器对同一个域名的并发数:Prefetch 一个一本用法是浏览器会在空闲的时候，下载资源, 并缓存起来。当有页面利用的时候，直接从缓存中读取。实在便是把决定是否和什么韶光加载这个资源的决定权交给浏览器。遗憾的是对付这两个接口，移动真个浏览器支持性很不好，这也是没有普遍推广开勇的缘故原由。什么时候利用Preload，什么时候利用Prefetch可以总结如下：
对付当前页面很有必要的资源利用 preload，对付可能在将来的页面中利用的资源利用 prefetch。
关于Preload 和 Prefetch可以参考这里,其余还有Prerender，subresource，Preconnect属性，由于目前能支持到这些属性的机型太少，这里就不在赘述了。
业务逻辑的预加载
关于业务逻辑的预加载，在这里我可以举一个微信小程序的例子。小程序紧张分为渲染层和逻辑层，逻辑层有iOS或者Android的JavaScript core来运行，渲染层由各自的webview组件卖力渲染。我们用户实际体验到的UI还是跑在我们的webview里面，这个和大多数H5页面的渲染用的是一个组件。但是为什么我们体验小程序会比H5页面要快很多？尤其是新开页面时？
小程序在启动时，会预先加载所有页面逻辑代码进内存，在 a页面跳转至 b页面 时，可以在内存中直接运行而无需在发送资源要求，a页面的逻辑代码 Javascript 数据也不会从内存中消逝。b页面乃至可以直接访问 a页面中的数据，全体坏境在一个大的高下文中。
当然这里你可能会有疑问？如果用户不会进入page2，那加载page2的逻辑代码岂不是摧残浪费蹂躏？这里就会牵扯到一个用户行为预测的问题，在小程序的架构中，全体逻辑代码是统一在一个包里，微信是统一将这些文件下载并加载到内存中，这可能会涉及到一些摧残浪费蹂躏，但是对付提速来讲收益大于弊端的。当然小程序页供应出分包策略来优化这些问题。
借助小程序的思路，我们的移动web同样适用这种预加载优化逻辑：
1. 预加载资源：在多tab的单页运用中，我们可以在用户打开头屏之后，预先加载其他tab的资源。例如用户进入时在推举tab，这时就可以预先加载订单，我的 这两个tab的资源了，当用户点击订单时，页面的展现就会快一些。
2. 预加载数据：预加载数据的机遇最好是在空闲时，什么是空闲时呢？我们剖析一下打开一个H5页面的流程：
从图上可以看到，利用闲时可以做的事情有很多，预加载数据是一个范例的优化手段，提前把新页面所须要的数据加载好，在新页面打开后，可以直接用数据来进行渲染，当然这里涉及到的跨页面数据通信，我们可以利用localStroage来实现。
3. 预加载webview
我利用闲时来做更多事情的条件是闲时够长，但这本书也不是一个很好的征象，只管即便的减少闲时，也是我们须要做的一项优化，例如我们来减少webview的加载韶光，这就须要提前加载webview，此项优化大多是由native端来完成：
在APP启动后，就提前在内存中将webview加载好，而不是等到点击进入web页面时才去加载。创建一个webview的复用池，例如最多只存在3个webview，每次从池子里获取webview，达到复用的目的。3.合理利用缓存上文说了浏览器缓存的根本知识，既然是根本，那就解释必须节制，下面来说一些进阶篇的利用缓存来优化页面：
妙用localStorage
HTML5 LocalStorage可以看做是加强版的cookie，数据存储大小提升，有更好的弹性以及架构，可以将数据写入到本机的ROM中，还可以在关闭浏览器后再次打开时规复数据，以减少网络流量，日常利用localStorage来优化我们的页面大概有以下几种场景：
缓存一些非实时更新的变量，例如某些闪屏的标志位信息，地理位置信息等等，取用方便，即存即用。利用localStorage缓存Js和css文的，为了提升页面的打开速率，或者是页面可以离线利用，有些页面会采取将静态资源文件直接缓存在localStorage中，当页面打开时将内容读取出并运行，利用此方法确实可以减少http要求，提速页面。在一些跨webview通信的场景中，localStorage是兼容性最好的数据通信方案，例如预加载的数据可以缓存在localStorage中，来实现各个页面的webview数据共享。须要把稳的是，localStorage并不是无限大的，针对每个域名，PC端浏览器给localStorage分配的容量大概4.5m-5m，移动审察似微信等等的浏览器大概容量是2.5m-3m参考这里。以是在利用时须要做好非常捕获，让localstorage超出容量时，是无法在进行插入并报错，如果对容量有更高的哀求，可以参考利用indexeddb。须要把稳的是indexeddb的兼容性却不是很好，android4.4之前以及iOS7以前都无法利用。旧调重弹离线包
离线包技能可以说是并不算很新的技能了，各个业务都有在利用，也都有自己的一套hybrid离线包系统，关键点在于离线包的打包，同时对文件加密/署名，更新离线包(增量)
，安全教研以及容错机制等等，在这里列举一些大厂的离线包方案来参考：
美团：LsLoader——通用移动端WebApp离线化方案。腾讯：手Q离线包Alloykit。阿里：极致的 Hybrid：航旅离线包再加速Service Worker探索
提到缓存，那就不得不提近几年比较火的Service Worker了：
作为一个比较新的技能，大家可以把 Service Worker 理解为一个介于客户端和做事器之间的一个代理做事器。在 Service Worker 中我们可以做很多事情，比如拦截客户真个要求、向客户端发送、向做事器发起要求等等，个中最主要的浸染之一便是离线资源缓存。
Service Worker的紧张繁芜点在于不断地对缓存策略的调度，笔者在这里就不过多展开，可以参考一下淘宝Service worker实战。
4.Nodejs做事端渲染（SSR）优化首屏韶光在前后端分离之后，后端措辞的模板功能被弱化，全体页面的渲染基本上都由前端 js 动态渲染，但这样对付一些运用来说是有缺陷的。比如须要 SEO 的，须要打开页面不用等待就能看到页面的，其余前端页面展示过度依赖js和css逻辑实行，在极度情形或者网络较差，手机性能低下(尤其在低端Android机型较为明显)时，白屏韶光较长，这时做事端渲染便运用而生，至于为什么是Nodejs，作为一个前端，难道还要用Java么。。？
为什么会有做事端渲染？
如果你说做事端渲染和早期web框架，例如SSH，JSP servlet，PHP等等一样的话，那我只能说呵呵，目前的做事端渲染和早期的框架是有实质差异的：
Web 2.0时期最大的思想革命实质不是前后端分离，而是把网页当作独立的运用程序（app）。建立在前后端分离的根本上，后端只卖力供应数据json格式，前端还是卖力页面交互逻辑，大多数的做事端渲染采取Nodejs层来进行数据组装，html拼接。重点在首屏！！
首屏韶光的优化，移动互联网时期的爆发，用户对网页性能的哀求越来越高，但毕竟基于3G，4G网络，让用户更快的看到页面就能挽留更多的潜在商机。做事端只卖力首屏的页面渲染，真正过了首屏，大多数的业务逻辑，页面交互，还是须要有单独的前端来实现的。
如何实现？
如果你的项目用的是React或者是vue，那么下面两个现场的开源框架是不错的选择。
next.js: 做事器端渲染 react 组件框架，参稽核看React做事端渲染指南。nuxt.js: 做事器端渲染 vue 组件框架，参稽核看 https://zh.nuxtjs.org/。gatsbyjs:做事端React渲染框架，目前看比较新，网上的资料还不是很多，参稽核看： https://www.gatsbyjs.org/当然，你也可以自己实现一套自己的做事端渲染框架，一样平常须要关注这些问题：
实现自定义的Node真个window高下文工具Cookie & Session等。远程数据的获取，一样平常采取Nodejs的http模块。React采取ReactDOMServer调用renderToString(),Vue采取vue-server-renderer调用renderToString()。Node端内存透露和掌握等问题代码同构(isomorphic)
利用Nodejs的做事端渲染的一大上风便是代码同构，这使得一个项目可以分别支配成走线上正常前端渲染版本，和走做事端渲染版本，这样可以更好的做到容灾机制，当任何一种分之挂掉之后，可以直接走另一个版本，提高稳定性。这也同构的魅力所在！
由于在同构直出宕掉的时候，还有前端渲染页面可以供应正常的做事。
取舍
虽然说做事端渲染这类优化确实可以提升一定的页面首屏韶光，但是也是须要本钱的，在前端开拓接管了Node作为中间层时，须要额外的机器资源支配，并且一旦打仗到后端，容灾机制，内存管理等性能指标都须要关注，这对付当前的业务系统架构可能须要有一定的调度，以是还是要推敲来利用。
5.渲染优化终于回到我们前真个老同族了，如果说前面的优化都是在框架，逻辑层面的优化，或者是参考后端，客户真个优化思路，那么真正涉及到UI渲染的优化才是我们作为前端工程师的立身之本了。
作甚渲染优化？
抛开头屏加速，真正让用户体验web页面的另一个很主要的部分便是用户行为交互了，这包括用户的点击相应，滚动流畅度，动画是否卡顿流畅度等等，这些关于用户交互性的优化在曩昔的PC端可能不是很被重视，由于PC浏览器的性能要远远大于手机端，但是到了移动web就不一样了，用户都希望移动web能有PC端一样的性能。为什么同样的页面在iPhone里总比Android流畅？
目前主流的Android硬件配置可以说是甩iPhone几条街了，那为什么高配置却得不到好的体验呢？关键两类机型的操作系统上的优化程度，个中一个缘故原由便是iOS操作系统采取实行率较高的Object-c措辞，大部分硬件接口可以直接调用和运行，而Android则采取Java措辞，由于虚拟机的存在，虽然跨平台性提升了，但是通过虚拟机在和系统硬件交互，实行效率就低了很多，当然这只是个中一个缘故原由。那么，我们移动web紧张优化的群体便是Android机型了。16ms优化
目前大多数设备的屏幕刷新频率为60次/秒，每一帧所花费的韶光约为16ms（1000 ms / 60 = 16.66ms），这16ms便是渲染帧的时长，所谓渲染帧是指浏览器一次完全绘制过程，帧之间的韶光间隔是DOM视图更新的最小间隔，但实际上，浏览器还有一些整理事情要做，因此开拓者所做的所有事情须要在10ms内完成。如果不能完成，帧率将会低落，网页会在屏幕上抖动，也便是常日所说的卡顿，这会对用户体验产生严重的负面影响。以是如果一个页面中有动画效果或者用户正在滚动页面，那么浏览器渲染动画或页面的速率也要尽可能地与设备屏幕的刷新频率保持同等，以担保良好的用户体验。在这一个间隔内，浏览器可能须要做以下事情：脚本实行（JavaScript）：脚本造成了须要重绘的改动，比如增删 DOM、要求动画等样式打算（CSS Object Model）：级联地天生每个节点的生效样式。布局（Layout）：打算布局，实行渲染算法重绘（Paint）：各层分别进行绘制（比如 3D 动画）合成（Composite）：合成各层的渲染结果重绘和重排
在上面浏览器须要做的这些事情中，会引发不同程度的重绘和重排，而重绘和重排正式影响流畅的主要成分：部分渲染树（或者全体渲染树）须要重新剖析并且节点尺寸须要重新打算，这被称为重排。由于节点的几何属性发生改变或者由于样式发生改变，例如改变元素背景色时，屏幕上的部分内容须要更新，这样的更新被称为重绘。重排和重绘代价是高昂的，它们会毁坏用户体验，并且让UI展示非常迟缓，但是每次重排，一定会导致重绘，而每次重绘并不一定会发生重排，我们须要在以下几种场景来减少重排的发生：当页面布局和几何属性改变时就须要回流。下述情形会发生浏览器回流：添加或者删除可见的DOM元素。元素位置改变。元素尺寸改变——边距、添补、边框、宽度和高度。内容改变——比如文本改变或者图片大小改变而引起的打算值宽度和高度改变。页面渲染初始化。浏览器窗口尺寸改变——resize事宜发生时。利用 requestAnimationFrame
提升动画流畅度的另一个主要成分是让浏览器变得智能起来，好在浏览器给我们供应了这个接口requestAnimationFrame，通过这个API,可以见告浏览器某个JavaScript代码要实行动画，浏览器收到关照后，则会运行这些代码的时候进行优化，它会确保JS尽早在每一帧的开始实行，实现流畅的效果，而不再须要开拓职员烦心刷新频率的问题了：试试requestIdleCallback
requestIdleCallback的涌现伴随着React 16 的Fiber特性，他的利用场景是当用户在做卖力交互时，不肯望由于一些不主要的任务（如统计上报）导致用户觉得到卡顿的话，就该当考虑利用了，由于requestIdleCallback回调的实行的条件条件是当前浏览器处于空闲状态，但是须要把稳的是不要在requestIdleCallback操作任何DOM，这违背了这个接口的设计原则。fragment元素的运用
在你利用dominnerHTML方法来插入大量dom节点时，不妨试试fragment，fragment文档片段是个轻量级的document工具，它的设计初衷便是为了完成这类任务——更新和移动节点。文档片段的一个便利的语法特性是当你附加一个片断到节点时，实际上被添加的是该片断的子节点，而不是片断本身。只触发了一次重排，而且只访问了一次实时的DOM。列表滚动优化
长列表滚动在移动端是一种非常常见的交互模式，例如feeds流，图片流等等，这些列表的滚动流畅度优化对用户体验的提升是非常主要的，基于目前的优化思路，借助dom复用的方案，类似iOS的UITableView或者Android的recyclerview事理，在列表滚动时，只担保视窗区域内的dom节点存在，在有限的dom节点内实现滚动，而不在创建新的节点，在用户不断下拉翻页的过程中，担保全体页面有限的dom元向来减少内存的花费，事理如下图：复用的dom：
采取这一个方案的前端是借助浏览器的onscroll事宜来做逻辑处理，但是问题在于有些机型例如iOS的UIWebview下，onscroll不能实时触发，这就给优化带来了难题，由此引发出了仿照滚动:
正常的滚动：我们平时利用的scroll，包括上面讲的滚动都属于正常滚动，利用浏览器自身供应的滚动条来实现滚动，底层是由浏览器内核掌握。仿照滚动：最范例的例子便是iscroll了，事理一样平常有两种：1).监听滚动元素的touchmove事宜，当事宜触发时修正元素的transform属性来实现元素的位移，让手指离开时触发touchend事宜，然后采取requestanimationframe来在一个线型函数下不断的修正元素的transform来实现手指离开时的一段惯性滚动间隔。2).监听滚动元素的touchmove事宜，当事宜触发时修正元素的transform属性来实现元素的位移，让手指离开时触发touchend事宜，然后给元素一个css的animation，并设置好duration和function来实现手指离开时的一段惯性间隔。结论是如果要采取仿照滚动，可以办理onscroll不实时触发的问题，从而实现长列表的复用的优化，但是带来新的问题便是仿照滚动本身也是dom的重绘，增加额外的性能花费，达到有优化效果并不理想，好在iOS的新版WKwebview办理了onscroll问题，让开发者有了更好的选择。
滚动函数防抖
当持续触发事宜时，一定韶光段内没有再触发事宜，事宜处理函数才会实行一次，如果设定的韶光到来之前，又一次触发了事宜，就重新开始延时。如下图，持续触发scroll事宜时，并不实行handle函数，当1000毫秒内没有触发scroll事宜时，才会延时触发scroll事宜。合理利用GPU
动画卡顿是在移动web开拓时常常碰着的问题，办理这个问题一样平常会用到CSS3硬件加速。硬件加速这个名字觉得上很高大上，实在它做的事情可以大略概括为：通过GPU进行渲染，解放CPU，我们可以利用GPU的图形层，将卖力的动画操作放在这个层，如何开启？逼迫把须要动画的dom的工具 ，放置在GPU的layout层来缓存从而达到任何移动，大小变革都在这个层。通过开启GPU硬件加速虽然可以提升动画渲染性能或办理一些棘手问题，但利用仍需谨慎，利用前一定要进行严谨的测试，否则它反而会大量占用浏览网页用户的系统资源，尤其是在移动端，肆无忌惮的开启GPU硬件加速会导致大量花费内存，千万不要 {webkit-transform: translateZ(0);}。写在末了本文在性能优化的根本上，将移动web的性能点逐步展开和深入，大部分属于结论性先容内容，真正实践还是须要开拓职员亲自考试测验来得到优化提升，总之，
技能便是在于不断折腾，愿各位在踩坑的道路上一帆风顺！
作者：吕小鸣
来源：慕课网
