网站的功用优化关于用户的留存率、转化率有很大的影响，所以关于前端开发来说

  功用优化的点十分的多，有的小伙伴觉得记起来十分的费事，所以这儿首要梳理出一条线来协助回忆。

  望文生义加载时优化首要处理的便是让一个网站加载进程更快，比方紧缩文件巨细、运用CDN加速等办法能够优化加载功用。查看加载功用的目标一般看：白屏时刻和首屏时刻：

  运转时功用是指页面运转时的功用体现，而不是页面加载时的功用。能够经过chrome开发者东西中的 Performance 面板来剖析页面的运转时功用。

  咱们知道阅读器假如输入的是一个网址，首要要交给DNS域名解析 - 找到对应的IP地址 - 然后进行TCP衔接 - 阅读器发送HTTP恳求 - 服务器接纳恳求 - 服务器处理恳求并回来HTTP报文 - 以及阅读器接纳并解析烘托页面。从这一进程中，其实就能够挖出优化点，缩短恳求的时刻，然后去加速网站的拜访速度，提高功用。

  DNS 作为互联网的根底协议，其解析的速度好像简单被网站优化人员忽视。现在大多数新阅读器现已针对DNS解析进行了优化，典型的一次DNS解析耗费20-120毫秒，削减DNS解析时刻和次数是个很好的优化办法。

  DNS Prefetching是具有此特点的域名不需求用户点击链接就在后台解析，而域名解析和内容载入是串行的网络操作，所以这个办法能削减用户的等候时刻，提高用户体会。

  HTTP2带来了十分大的加载优化，所以在做优化上首要就想到了用HTTP2替代HTTP1。

  服务器解析 HTTP1.1 的恳求时，有必要不断地读入字节，直到遇到分隔符 CRLF 停止。而解析 HTTP2 的恳求就不必这么费事，因为 HTTP2 是依据帧的协议，每个帧都有表明帧长度的字段。

  在 HTTP2 上，多个恳求能够共用一个 TCP 衔接，这称为多路复用。

  当然HTTP1.1有一个可选的Pipelining技能，说的意思是当一个HTTP衔接在等候接纳呼应时能够经过这个衔接发送其他恳求。听起来很棒，其实这儿有一个坑，处理呼应是依照次序的，也便是后发的恳求有或许被先发的堵塞住，也正因而许多阅读器默许是不敞开Pipelining的。

  HTTP1 的Pipelining技能会有堵塞的问题，HTTP/2的多路复用能够大略的理解为非堵塞版的Pipelining。即能够一同经过一个HTTP衔接发送多个恳求，谁先呼应就先处理谁，这样就充沛的压榨了TCP这个全双工管道的功用。加载功用会是HTTP1的几倍，需求加载的资源越多越显着。当然多路复用是建立在加载的资源在同一域名下，不同域名神仙也复用不了。

  HTTP 1.1恳求的巨细变得越来越大，有时乃至会大于TCP窗口的初始巨细，因为它们需求等候带着ACK的呼应回来今后才干持续被发送。HTTP/2对音讯头选用HPACK（专为http/2头部规划的紧缩格局）进行紧缩传输，能够节约音讯头占用的网络的流量。而HTTP/1.x每次恳求，都会带着许多冗余头信息，糟蹋了许多带宽资源。

  服务端能够在发送页面HTML时自动推送其它资源，而不必比及阅读器解析到相应方位，建议恳求再呼应。

  这些进程都是需求花费时刻的，在网络状况差的状况下，花费的时刻更长。假如页面的资源十分碎片化，每个HTTP恳求只带回来几K乃至不到1K的数据（比方各种小图标）那功用是十分糟蹋的。

  咱们能够对html、css、js以及图片资源进行紧缩处理，现在能够很便利的运用 webpack 完结文件的紧缩：

  兼并文件尽管能削减HTTP恳求数量， 可是并不是文件兼并越多越好，还能够考虑按需加载办法（后边第6点有讲到）。什么样的文件能够兼并呢？能够提取项目中屡次运用到的公共代码进行提取，打包成公共模块。

  因为字体图标或许SVG是矢量图，代码编写出来的，扩大不会失真，并且烘托速度快。字体图标运用时就跟字体相同，能够设置特点，例如 font-size、color 等等，十分便利，还有一个长处是生成的文件特别小。

  在开发SPA项目时，项目中常常存在十几个乃至更多的路由页面， 假如将这些页面都打包进一个JS文件， 尽管削减了HTTP恳求数量， 可是会导致文件比较大，一同加载了许多主页不需求的代码，有些因小失大，这时分就能够运用按需加载， 将每个路由页面独自打包为一个文件，当然不仅仅是路由能够按需加载。

  经过装备 output 的 filename 属功用够完结这个需求。filename 特点的值选项中有一个[contenthash]，它将依据文件内容创建出仅有 hash。当文件内容发生改变时，[contenthash]也会发生改变。

  其次削减ES6 转为 ES5 的冗余代码：Babel 转化后的代码想要完结和本来代码相同的功用需求凭借一些协助函数，比方：

  这儿_classCallCheck便是一个helper函数，假如在许多文件里都声明晰类，那么就会发生许多个这样的helper函数。

  客户端烘托: 获取 HTML 文件，依据需求下载 JavaScript 文件，运转文件，生成 DOM，再烘托。

  一切放在 head 标签里的 CSS 和 JS 文件都会堵塞烘托。假如这些 CSS 和 JS 需求加载和解析好久的话，那么页面就空白了。所以 JS 文件要放在底部，等 HTML 解析完了再加载 JS 文件。

  因为先加载 HTML 再加载 CSS，会让用户第一时刻看到的页面是没有款式的、“丑恶”的，为了防止这种状况发生，就要将 CSS 文件放在头部了。

  别的，JS 文件也不是不能够放在头部，只需给 script 标签加上 defer 特点就能够了，异步下载，推迟履行。

  用户与服务器的物理距离对呼应时刻也有影响。把内容布置在多个地理方位涣散的服务器上能让用户更快地载入页面, CDN便是为了处理这一问题，在多个方位布置服务器，让用户离服务器更近，然后缩短恳求时刻。

  图片能够兼并么？当然。最为常用的图片兼并场景便是雪碧图（Sprite）。

  在网站上一般会有许多小的图标，不经优化的话，最直接的办法便是将这些小图标保存为一个个独立的图片文件，然后经过 CSS 将对应元素的背景图片设置为对应的图标图片。这么做的一个重要问题在于，页面加载时或许会一同恳求十分多的小图标图片，这就会遭到阅读器并发 HTTP 恳求数的约束。

  一般来说，咱们拜访网站页面时，其实许多图片并不在首屏中，假如咱们都加载的话，适当所以加载了用户纷歧定会看到图片， 这明显是一种糟蹋。处理的中心思路便是懒加载：完结办法便是先不给图片设置途径，当图片出现在阅读器可视区域时才设置实在的图片途径。

  完结上便是先将图片途径设置给original-src,当页面不行见时，图片不会加载：

  除了关于img元素的图片进行来加载，在 CSS 中运用的图片相同能够懒加载，最常见的场景便是background-url。

  关于上面这个款式规矩，假如不该用到详细的元素，阅读器不会去下载该图片。所以你能够经过切换className的办法，放心得进行 CSS 中图片的懒加载。

  有前端阅历的开发者对这个概念必定不会生疏，阅读器下载完页面需求的一切资源后， 就开端烘托页面，首要阅历这5个进程：

  当改动DOM元素方位或许巨细时， 会导致阅读器从头生成Render树， 这个进程叫重排

  当从头生成烘托树后， 将要将烘托树每个节点制作到屏幕， 这个进程叫重绘。

  重排发生后的底子原理便是元素的几许特点发生改动， 所以从能够改动几许特点的视点下手：

  了解了重排和重绘这两个概念，咱们还要知道重排和重绘的开支都是十分贵重的，假如不断的改动页面的布局，就会构成阅读器耗费许多的开支在进行页面的核算上，这样简单构成页面卡顿。那么回到咱们的问题怎样削减重绘与重排呢？

  DOM 的多个读操作（或多个写操作），应该放在一同。不要两个读操作之间，参加一个写操作。

  不要频发的操作款式，尽管现在大部分阅读器有烘托行列优化，可是在一些老版别的阅读器仍然存在功率低下的问题：

  运用肯定定位会使的该元素独自成为烘托树中 body 的一个子元素，重排开支比较小，不会对其它节点构成太多影响。当你在这些节点上放置这个元素时，一些其它在这个区域内的节点或许需求重绘，可是不需求重排。

  咱们现在大多数屏幕的刷新率-60次/s,阅读器烘托更新页面的规范帧率也为60次/s --60FPS(frames/pre second), 那么每一帧的预算时刻约为16.6ms ≈ 1s/60，阅读器在这个时刻内要完结一切的收拾作业，假如无法契合此预算， 帧率将下降，内容会在屏幕颤动， 此现象一般称为卡顿。

  首要你用js做了些逻辑，还触发了款式改变，style把运用的款式规矩核算好之后，把影响到的页面元素进行从头布局，叫做layout，再把它画到内存的一个画布里边，paint成了像素，最终把这个画布刷到屏幕上去，叫做composite，构成一帧。

  这几项的任何一项假如履行时刻太长了，就会导致烘托这一帧的时刻太长，均匀帧率就会掉。假定这一帧花了50ms，那么此刻的帧率就为1s / 50ms = 20fps.

  有时会有这样的需求， 需求在页面上展现包括上百个元素的列表（例如一个Feed流）。每个列表元素还有着杂乱的内部结构，这明显提高了页面烘托的本钱。当你运用了React时，长列表的问题就会被进一步的扩大。那么怎样来优化长列表呢？

  虚拟列表是一种用来优化长列表的技能。它能够确保在列表元素不断添加，或许列表元素许多的状况下，仍然具有很好的翻滚、阅读功用。它的中心思维在于：只烘托可见区域邻近的列表元素。下图左面便是虚拟列表的作用，能够看到只需视口内和临近视口的上下区域内的元素会被烘托。

  确认长列表每一个列表元素的宽和高，一同初始的条件下核算好长列表每一个元素相关于父元素的方位，并用一个数组来保存一切列表元素的方位信息

  初次烘托时，只展现相关于父元素可视区内的子列表元素，在翻滚时，依据父元素的翻滚的

  从头核算应该在可视区内的子列表元素。这样确保了无论怎样翻滚，实在烘托出的dom节点只需可视区内的列表元素。

  假定可视区内能展现5个子列表元素，及时长列表总共有1000个元素，可是每时每刻，实在烘托出来的dom节点只需5个。

  前端最简单碰到的功用问题的场景之一便是监听翻滚工作并进行相应的操作。因为翻滚工作发生十分频频，所以频频地履行监听回调就简单构成JavaScript履行与页面烘托之间相互堵塞的状况。

  当一个工作频频触发，而咱们期望距离必定的时刻再触发相应的函数时， 就能够运用节约（throttle）来处理。比方判别页面是否翻滚到底部，然后展现相应的内容；就能够运用节约，在翻滚时每300ms进行一次核算判别是否翻滚到底部的逻辑，而不必无时无刻地核算。

  当一个工作频频触发，而咱们期望在工作触发完毕一段时刻后（此段时刻内不再有触发）才实践触发呼应函数时会运用防抖（debounce）。例如用户一向点击按钮，但你不期望频频发送恳求，你就能够设置当点击后 200ms 内用户不再点击时才发送恳求。

  前面提到了许多数据的烘托环节咱们能够选用虚拟列表的办法完结,可是许多数据的核算环节仍然会发生阅读器假死或许卡顿的状况.

  一般状况下咱们CPU密集型的使命都是交给后端核算的,可是有些时分咱们需求处理一些离线场景或许解放后端压力,这个时分此办法就不见效了.

  还有一种办法是核算切片,运用 setTimeout 拆分密集型使命,可是有些核算无法运用此办法拆解,一同还或许发生副作用,这个办法需求视详细场景而动.

  最终一种办法也是现在比较见效的办法便是运用Web Worker 进行多线程编程.

  Web Worker 是一个独立的线程（独立的履行环境），这就意味着它能够彻底和 UI 线程（主线程）并行的履行 js 代码，然后不会堵塞 UI，它和主线程是经过 onmessage 和 postMessage 接口进行通讯的。

  Web Worker 使得网页中进行多线程编程成为或许。当主线程在处理界面工作时，worker 能够在后台运转，帮你处理许多的数据核算，当核算完结，将核算结果回来给主线程，由主线程更新 DOM 元素。

  绑定的工作越多， 阅读器内存占有就越多，然后影响功用，运用工作署理的办法就可节约一些内存。

  当断定条件越来越多时， 越倾向于运用switch,而不是if-else:

  向上面这种状况运用switch更好， 假定state为4，那么if-else句子就要进行4次断定，switch只需进行一次即可。

  可是有的状况下switch也做不到if-else的工作, 例如有多个判别条件的状况下，无法运用switch

  在前期的 CSS 布局办法中咱们能对元素实施肯定定位、相对定位或起浮定位。而现在，咱们有了新的布局办法 flexbox，它比起前期的布局办法来说有个优势，那便是功用比较好。