关于前端:前端性能优化

性能优化是把双刃剑，有好的一面也有坏的一面。好的一面就是能晋升网站性能，坏的一面就是配置麻烦，或者要恪守的规定太多。并且某些性能优化规定并不实用所有场景，须要审慎应用，请读者带着批判性的眼光来浏览本文。

1. 缩小 HTTP 申请

一个残缺的 HTTP 申请须要经验 DNS 查找，TCP 握手，浏览器收回 HTTP 申请，服务器接管申请，服务器解决申请并发回响应，浏览器接管响应等过程。接下来看一个具体的例子帮忙了解 HTTP：

这是一个 HTTP 申请，申请的文件大小为 28.4KB。

名词解释：

• Queueing: 在申请队列中的工夫。
• Stalled: 从 TCP 连贯建设实现，到真正能够传输数据之间的时间差，此工夫包含代理协商工夫。
• Proxy negotiation: 与代理服务器连贯进行协商所破费的工夫。
• DNS Lookup: 执行 DNS 查找所破费的工夫，页面上的每个不同的域都须要进行 DNS 查找。
• Initial Connection / Connecting: 建设连贯所破费的工夫，包含 TCP 握手 / 重试和协商 SSL。
• SSL: 实现 SSL 握手所破费的工夫。
• Request sent: 收回网络申请所破费的工夫，通常为一毫秒的工夫。
• Waiting(TFFB): TFFB 是收回页面申请到接管到应答数据第一个字节的工夫。
• Content Download: 接管响应数据所破费的工夫。

从这个例子能够看出，真正下载数据的工夫占比为 13.05 / 204.16 = 6.39%，文件越小，这个比例越小，文件越大，比例就越高。这就是为什么要倡议将多个小文件合并为一个大文件，从而缩小 HTTP 申请次数的起因。

2. 应用 HTTP2

HTTP2 相比 HTTP1.1 有如下几个长处：

解析速度快

服务器解析 HTTP1.1 的申请时，必须一直地读入字节，直到遇到分隔符 CRLF 为止。而解析 HTTP2 的申请就不必这么麻烦，因为 HTTP2 是基于帧的协定，每个帧都有示意帧长度的字段。

多路复用

HTTP1.1 如果要同时发动多个申请，就得建设多个 TCP 连贯，因为一个 TCP 连贯同时只能解决一个 HTTP1.1 的申请。

在 HTTP2 上，多个申请能够共用一个 TCP 连贯，这称为多路复用。同一个申请和响应用一个流来示意，并有惟一的流 ID 来标识。多个申请和响应在 TCP 连贯中能够乱序发送，达到目的地后再通过流 ID 重新组建。

首部压缩

HTTP2 提供了首部压缩性能。

例如有如下两个申请：

:authority: unpkg.zhimg.com
:method: GET
:path: /za-js-sdk@2.16.0/dist/zap.js
:scheme: https
accept: */*
accept-encoding: gzip, deflate, br
accept-language: zh-CN,zh;q=0.9
cache-control: no-cache
pragma: no-cache
referer: https://www.zhihu.com/
sec-fetch-dest: script
sec-fetch-mode: no-cors
sec-fetch-site: cross-site
user-agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/80.0.3987.122 Safari/537.36
:authority: zz.bdstatic.com
:method: GET
:path: /linksubmit/push.js
:scheme: https
accept: */*
accept-encoding: gzip, deflate, br
accept-language: zh-CN,zh;q=0.9
cache-control: no-cache
pragma: no-cache
referer: https://www.zhihu.com/
sec-fetch-dest: script
sec-fetch-mode: no-cors
sec-fetch-site: cross-site
user-agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/80.0.3987.122 Safari/537.36

从下面两个申请能够看进去，有很多数据都是反复的。如果能够把雷同的首部存储起来，仅发送它们之间不同的局部，就能够节俭不少的流量，放慢申请的工夫。

HTTP/2 在客户端和服务器端应用“首部表”来跟踪和存储之前发送的键-值对，对于雷同的数据，不再通过每次申请和响应发送。

上面再来看一个简化的例子，假如客户端按程序发送如下申请首部：

Header1:foo
Header2:bar
Header3:bat

当客户端发送申请时，它会依据首部值创立一张表：

如果服务器收到了申请，它会照样创立一张表。当客户端发送下一个申请的时候，如果首部雷同，它能够间接发送这样的首部块：

62 63 64

服务器会查找先前建设的表格，并把这些数字还原成索引对应的残缺首部。

优先级

HTTP2 能够对比拟紧急的申请设置一个较高的优先级，服务器在收到这样的申请后，能够优先解决。

流量管制

因为一个 TCP 连贯流量带宽（依据客户端到服务器的网络带宽而定）是固定的，当有多个申请并发时，一个申请占的流量多，另一个申请占的流量就会少。流量管制能够对不同的流的流量进行准确管制。

服务器推送

HTTP2 新增的一个弱小的新性能，就是服务器能够对一个客户端申请发送多个响应。换句话说，除了对最后申请的响应外，服务器还能够额定向客户端推送资源，而无需客户端明确地申请。

例如当浏览器申请一个网站时，除了返回 HTML 页面外，服务器还能够依据 HTML 页面中的资源的 URL，来提前推送资源。

当初有很多网站曾经开始应用 HTTP2 了，例如知乎：

其中 h2 是指 HTTP2 协定，http/1.1 则是指 HTTP1.1 协定。

3. 应用服务端渲染

客户端渲染: 获取 HTML 文件，依据须要下载 JavaScript 文件，运行文件，生成 DOM，再渲染。

服务端渲染：服务端返回 HTML 文件，客户端只需解析 HTML。

• 长处：首屏渲染快，SEO 好。
• 毛病：配置麻烦，减少了服务器的计算压力。

上面我用 Vue SSR 做示例，简略的形容一下 SSR 过程。

客户端渲染过程

1. 拜访客户端渲染的网站。
2. 服务器返回一个蕴含了引入资源语句和 <div id="app"></div> 的 HTML 文件。
3. 客户端通过 HTTP 向服务器申请资源，当必要的资源都加载结束后，执行 new Vue() 开始实例化并渲染页面。

服务端渲染过程

1. 拜访服务端渲染的网站。
2. 服务器会查看以后路由组件须要哪些资源文件，而后将这些文件的内容填充到 HTML 文件。如果有 ajax 申请，就会执行它进行数据预取并填充到 HTML 文件里，最初返回这个 HTML 页面。
3. 当客户端接管到这个 HTML 页面时，能够马上就开始渲染页面。与此同时，页面也会加载资源，当必要的资源都加载结束后，开始执行 new Vue() 开始实例化并接管页面。

从上述两个过程中能够看出，区别就在于第二步。客户端渲染的网站会间接返回 HTML 文件，而服务端渲染的网站则会渲染完页面再返回这个 HTML 文件。

这样做的益处是什么？是更快的内容达到工夫 (time-to-content)。

假如你的网站须要加载完 abcd 四个文件能力渲染结束。并且每个文件大小为 1 M。

这样一算：客户端渲染的网站须要加载 4 个文件和 HTML 文件能力实现首页渲染，总计大小为 4M（疏忽 HTML 文件大小）。而服务端渲染的网站只须要加载一个渲染结束的 HTML 文件就能实现首页渲染，总计大小为曾经渲染结束的 HTML 文件（这种文件不会太大，个别为几百 K，我的集体博客网站（SSR）加载的 HTML 文件为 400K）。 这就是服务端渲染更快的起因 。

4. 动态资源应用 CDN

内容散发网络（CDN）是一组散布在多个不同地理位置的 Web 服务器。咱们都晓得，当服务器离用户越远时，提早越高。CDN 就是为了解决这一问题，在多个地位部署服务器，让用户离服务器更近，从而缩短申请工夫。

CDN 原理

当用户拜访一个网站时，如果没有 CDN，过程是这样的：

1. 浏览器要将域名解析为 IP 地址，所以须要向本地 DNS 发出请求。
2. 本地 DNS 顺次向根服务器、顶级域名服务器、权限服务器发出请求，失去网站服务器的 IP 地址。
3. 本地 DNS 将 IP 地址发回给浏览器，浏览器向网站服务器 IP 地址发出请求并失去资源。

如果用户拜访的网站部署了 CDN，过程是这样的：

1. 浏览器要将域名解析为 IP 地址，所以须要向本地 DNS 发出请求。
2. 本地 DNS 顺次向根服务器、顶级域名服务器、权限服务器发出请求，失去全局负载平衡零碎（GSLB）的 IP 地址。
3. 本地 DNS 再向 GSLB 发出请求，GSLB 的次要性能是依据本地 DNS 的 IP 地址判断用户的地位，筛选出间隔用户较近的本地负载平衡零碎（SLB），并将该 SLB 的 IP 地址作为后果返回给本地 DNS。
4. 本地 DNS 将 SLB 的 IP 地址发回给浏览器，浏览器向 SLB 发出请求。
5. SLB 依据浏览器申请的资源和地址，选出最优的缓存服务器发回给浏览器。
6. 浏览器再依据 SLB 发回的地址重定向到缓存服务器。
7. 如果缓存服务器有浏览器须要的资源，就将资源发回给浏览器。如果没有，就向源服务器申请资源，再发给浏览器并缓存在本地。

5. 将 CSS 放在文件头部，JavaScript 文件放在底部

所有放在 head 标签里的 CSS 和 JS 文件都会梗塞渲染（CSS 不会阻塞 DOM 解析）。如果这些 CSS 和 JS 须要加载和解析很久的话，那么页面就空白了。所以 JS 文件要放在底部，等 HTML 解析完了再加载 JS 文件。

那为什么 CSS 文件还要放在头部呢？

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

另外，JS 文件也不是不能够放在头部，只有给 script 标签加上 defer 属性就能够了，异步下载，提早执行。

6. 应用字体图标 iconfont 代替图片图标

字体图标就是将图标制作成一个字体，应用时就跟字体一样，能够设置属性，例如 font-size、color 等等，十分不便。并且字体图标是矢量图，不会失真。还有一个长处是生成的文件特地小。

压缩字体文件

应用 fontmin-webpack 插件对字体文件进行压缩。

7. 善用缓存，不反复加载雷同的资源

为了防止用户每次拜访网站都得申请文件，咱们能够通过增加 Expires 或 max-age 来管制这一行为。Expires 设置了一个工夫，只有在这个工夫之前，浏览器都不会申请文件，而是间接应用缓存。而 max-age 是一个绝对工夫，倡议应用 max-age 代替 Expires。

不过这样会产生一个问题，当文件更新了怎么办？怎么告诉浏览器从新申请文件？

能够通过更新页面中援用的资源链接地址，让浏览器被动放弃缓存，加载新资源。

具体做法是把资源地址 URL 的批改与文件内容关联起来，也就是说，只有文件内容变动，才会导致相应 URL 的变更，从而实现文件级别的准确缓存管制。什么货色与文件内容相干呢？咱们会很天然的联想到利用数据摘要要算法对文件求摘要信息，摘要信息与文件内容一一对应，就有了一种能够准确到单个文件粒度的缓存管制根据了。

8. 压缩文件

压缩文件能够缩小文件下载工夫，让用户体验性更好。

得益于 webpack 和 node 的倒退，当初压缩文件曾经十分不便了。

在 webpack 能够应用如下插件进行压缩：

• JavaScript：UglifyPlugin
• CSS：MiniCssExtractPlugin
• HTML：HtmlWebpackPlugin

其实，咱们还能够做得更好。那就是应用 gzip 压缩。能够通过向 HTTP 申请头中的 Accept-Encoding 头增加 gzip 标识来开启这一性能。当然，服务器也得反对这一性能。

gzip 是目前最风行和最无效的压缩办法。举个例子，我用 Vue 开发的我的项目构建后生成的 app.js 文件大小为 1.4MB，应用 gzip 压缩后只有 573KB，体积缩小了将近 60%。

附上 webpack 和 node 配置 gzip 的应用办法。

下载插件

npm install compression-webpack-plugin --save-dev
npm install compression

webpack 配置

const CompressionPlugin = require('compression-webpack-plugin');

module.exports = {plugins: [new CompressionPlugin()],
}

node 配置

const compression = require('compression')
// 在其余中间件前应用
app.use(compression())

9. 图片优化

(1). 图片提早加载

在页面中，先不给图片设置门路，只有当图片呈现在浏览器的可视区域时，才去加载真正的图片，这就是提早加载。对于图片很多的网站来说，一次性加载全副图片，会对用户体验造成很大的影响，所以须要应用图片提早加载。

首先能够将图片这样设置，在页面不可见时图片不会加载：

<img data-src="https://avatars0.githubusercontent.com/u/22117876?s=460&u=7bd8f32788df6988833da6bd155c3cfbebc68006&v=4">

等页面可见时，应用 JS 加载图片：

const img = document.querySelector('img')
img.src = img.dataset.src

这样图片就加载进去了。

(2). 响应式图片

响应式图片的长处是浏览器可能依据屏幕大小主动加载适合的图片。

通过 picture 实现

<picture>
 <source srcset="banner_w1000.jpg" media="(min-width: 801px)">
 <source srcset="banner_w800.jpg" media="(max-width: 800px)">
 <img src="banner_w800.jpg" alt="">
</picture>

通过 @media 实现

@media (min-width: 769px) {
 .bg {background-image: url(bg1080.jpg);
 }
}
@media (max-width: 768px) {
 .bg {background-image: url(bg768.jpg);
 }
}

(3). 调整图片大小

例如，你有一个 1920 * 1080 大小的图片，用缩略图的形式展现给用户，并且当用户鼠标悬停在下面时才展现全图。如果用户从未真正将鼠标悬停在缩略图上，则节约了下载图片的工夫。

所以，咱们能够用两张图片来履行优化。一开始，只加载缩略图，当用户悬停在图片上时，才加载大图。还有一种方法，即对大图进行提早加载，在所有元素都加载实现后手动更改大图的 src 进行下载。

(4). 升高图片品质

例如 JPG 格局的图片，100% 的品质和 90% 品质的通常看不出来区别，尤其是用来当背景图的时候。我常常用 PS 切背景图时，将图片切成 JPG 格局，并且将它压缩到 60% 的品质，基本上看不出来区别。

压缩办法有两种，一是通过 webpack 插件 image-webpack-loader，二是通过在线网站进行压缩。

以下附上 webpack 插件 image-webpack-loader 的用法。

npm i -D image-webpack-loader

webpack 配置

{test: /\.(png|jpe?g|gif|svg)(\?.*)?$/,
  use:[
    {
    loader: 'url-loader',
    options: {
      limit: 10000, /* 图片大小小于 1000 字节限度时会主动转成 base64 码援用 */
      name: utils.assetsPath('img/[name].[hash:7].[ext]')
      }
    },
    /* 对图片进行压缩 */
    {
      loader: 'image-webpack-loader',
      options: {bypassOnDebug: true,}
    }
  ]
}

(5). 尽可能利用 CSS3 成果代替图片

有很多图片应用 CSS 成果（突变、暗影等）就能画进去，这种状况抉择 CSS3 成果更好。因为代码大小通常是图片大小的几分之一甚至几十分之一。

(6). 应用 webp 格局的图片

WebP 的劣势体现在它具备更优的图像数据压缩算法，能带来更小的图片体积，而且领有肉眼辨认无差别的图像品质；同时具备了无损和有损的压缩模式、Alpha 通明以及动画的个性，在 JPEG 和 PNG 上的转化成果都相当优良、稳固和对立。

参考资料：

• WebP 绝对于 PNG、JPG 有什么劣势？

https://www.zhihu.com/questio…

10. 通过 webpack 按需加载代码，提取第三库代码，缩小 ES6 转为 ES5 的冗余代码

懒加载或者按需加载，是一种很好的优化网页或利用的形式。这种形式实际上是先把你的代码在一些逻辑断点处罚来到，而后在一些代码块中实现某些操作后，立刻援用或行将援用另外一些新的代码块。这样放慢了利用的初始加载速度，加重了它的总体体积，因为某些代码块可能永远不会被加载。

依据文件内容生成文件名，联合 import 动静引入组件实现按需加载

通过配置 output 的 filename 属性能够实现这个需要。filename 属性的值选项中有一个 [contenthash]，它将依据文件内容创立出惟一 hash。当文件内容发生变化时，[contenthash] 也会发生变化。

output: {filename: '[name].[contenthash].js',
    chunkFilename: '[name].[contenthash].js',
    path: path.resolve(__dirname, '../dist'),
},

提取第三方库

因为引入的第三方库个别都比较稳定，不会常常扭转。所以将它们独自提取进去，作为长期缓存是一个更好的抉择。这里须要应用 webpack4 的 splitChunk 插件 cacheGroups 选项。

optimization: {
   runtimeChunk: {name: 'manifest' // 将 webpack 的 runtime 代码拆分为一个独自的 chunk。},
    splitChunks: {
        cacheGroups: {
            vendor: {
                name: 'chunk-vendors',
                test: /[\\/]node_modules[\\/]/,
                priority: -10,
                chunks: 'initial'
            },
            common: {
                name: 'chunk-common',
                minChunks: 2,
                priority: -20,
                chunks: 'initial',
                reuseExistingChunk: true
            }
        },
    }
},

• test: 用于管制哪些模块被这个缓存组匹配到。一成不变传递进来的话，它默认会抉择所有的模块。能够传递的值类型：RegExp、String 和 Function;
• priority：示意抽取权重，数字越大示意优先级越高。因为一个 module 可能会满足多个 cacheGroups 的条件，那么抽取到哪个就由权重最高的说了算；
• reuseExistingChunk：示意是否应用已有的 chunk，如果为 true 则示意如果以后的 chunk 蕴含的模块曾经被抽取进来了，那么将不会从新生成新的。
• minChunks（默认是 1）：在宰割之前，这个代码块最小应该被援用的次数（译注：保障代码块复用性，默认配置的策略是不须要屡次援用也能够被宰割）
• chunks (默认是 async)：initial、async 和 all
• name(打包的 chunks 的名字)：字符串或者函数 (函数能够依据条件自定义名字)

缩小 ES6 转为 ES5 的冗余代码

Babel 转化后的代码想要实现和原来代码一样的性能须要借助一些帮忙函数，比方：

class Person {}

会被转换为：

"use strict";

function _classCallCheck(instance, Constructor) {if (!(instance instanceof Constructor)) {throw new TypeError("Cannot call a class as a function");
  }
}

var Person = function Person() {_classCallCheck(this, Person);
};

这里 _classCallCheck 就是一个 helper 函数，如果在很多文件里都申明了类，那么就会产生很多个这样的 helper 函数。

这里的 @babel/runtime 包就申明了所有须要用到的帮忙函数，而 @babel/plugin-transform-runtime 的作用就是将所有须要 helper 函数的文件，从 @babel/runtime 包 引进来：

"use strict";

var _classCallCheck2 = require("@babel/runtime/helpers/classCallCheck");

var _classCallCheck3 = _interopRequireDefault(_classCallCheck2);

function _interopRequireDefault(obj) {return obj && obj.__esModule ? obj : { default: obj};
}

var Person = function Person() {(0, _classCallCheck3.default)(this, Person);
};

这里就没有再编译出 helper 函数 classCallCheck 了，而是间接援用了 @babel/runtime 中的 helpers/classCallCheck。

装置

npm i -D @babel/plugin-transform-runtime @babel/runtime

应用 在 .babelrc 文件中

"plugins": ["@babel/plugin-transform-runtime"]

**
**

11. 缩小重绘重排

浏览器渲染过程

1. 解析 HTML 生成 DOM 树。
2. 解析 CSS 生成 CSSOM 规定树。
3. 解析 JS，操作 DOM 树和 CSSOM 规定树。
4. 将 DOM 树与 CSSOM 规定树合并在一起生成渲染树。
5. 遍历渲染树开始布局，计算每个节点的地位大小信息。
6. 浏览器将所有图层的数据发送给 GPU，GPU 将图层合成并显示在屏幕上。

重排

当扭转 DOM 元素地位或大小时，会导致浏览器从新生成渲染树，这个过程叫重排。

重绘

当从新生成渲染树后，就要将渲染树每个节点绘制到屏幕，这个过程叫重绘。不是所有的动作都会导致重排，例如扭转字体色彩，只会导致重绘。记住，重排会导致重绘，重绘不会导致重排。

重排和重绘这两个操作都是十分低廉的，因为 JavaScript 引擎线程与 GUI 渲染线程是互斥，它们同时只能一个在工作。

什么操作会导致重排？

• 增加或删除可见的 DOM 元素
• 元素地位扭转
• 元素尺寸扭转
• 内容扭转
• 浏览器窗口尺寸扭转

如何缩小重排重绘？

• 用 JavaScript 批改款式时，最好不要间接写款式，而是替换 class 来扭转款式。
• 如果要对 DOM 元素执行一系列操作，能够将 DOM 元素脱离文档流，批改实现后，再将它带回文档。举荐应用暗藏元素（display:none）或文档碎片（DocumentFragement），都能很好的实现这个计划。

12. 应用事件委托

事件委托利用了事件冒泡，只指定一个事件处理程序，就能够治理某一类型的所有事件。所有用到按钮的事件（少数鼠标事件和键盘事件）都适宜采纳事件委托技术，应用事件委托能够节俭内存。

<ul>
  <li> 苹果 </li>
  <li> 香蕉 </li>
  <li> 凤梨 </li>
</ul>

// good
document.querySelector('ul').onclick = (event) => {
  const target = event.target
  if (target.nodeName === 'LI') {console.log(target.innerHTML)
  }
}

// bad
document.querySelectorAll('li').forEach((e) => {e.onclick = function() {console.log(this.innerHTML)
  }
}) 

13. 留神程序的局部性

一个编写良好的计算机程序经常具备良好的局部性，它们偏向于援用最近援用过的数据项左近的数据项，或者最近援用过的数据项自身，这种倾向性，被称为局部性原理。有良好局部性的程序比局部性差的程序运行得更快。

局部性通常有两种不同的模式：

• 工夫局部性：在一个具备良好工夫局部性的程序中，被援用过一次的内存地位很可能在不远的未来被屡次援用。
• 空间局部性：在一个具备良好空间局部性的程序中，如果一个内存地位被援用了一次，那么程序很可能在不远的未来援用左近的一个内存地位。

工夫局部性示例

function sum(arry) {
 let i, sum = 0
 let len = arry.length

 for (i = 0; i < len; i++) {sum += arry[i]
 }

 return sum
}

在这个例子中，变量 sum 在每次循环迭代中被援用一次，因而，对于 sum 来说，具备良好的工夫局部性

空间局部性示例

具备良好空间局部性的程序

// 二维数组 
function sum1(arry, rows, cols) {
 let i, j, sum = 0

 for (i = 0; i < rows; i++) {for (j = 0; j < cols; j++) {sum += arry[i][j]
  }
 }
 return sum
}

空间局部性差的程序

// 二维数组 
function sum2(arry, rows, cols) {
 let i, j, sum = 0

 for (j = 0; j < cols; j++) {for (i = 0; i < rows; i++) {sum += arry[i][j]
  }
 }
 return sum
}

看一下下面的两个空间局部性示例，像示例中从每行开始按程序拜访数组每个元素的形式，称为具备步长为 1 的援用模式。如果在数组中，每隔 k 个元素进行拜访，就称为步长为 k 的援用模式。一般而言，随着步长的减少，空间局部性降落。

这两个例子有什么区别？区别在于第一个示例是按行扫描数组，每扫描完一行再去扫下一行；第二个示例是按列来扫描数组，扫完一行中的一个元素，马上就去扫下一行中的同一列元素。

数组在内存中是依照行程序来寄存的，后果就是逐行扫描数组的示例失去了步长为 1 援用模式，具备良好的空间局部性；而另一个示例步长为 rows，空间局部性极差。

性能测试

运行环境：

• cpu: i5-7400
• 浏览器: chrome 70.0.3538.110

对一个长度为 9000 的二维数组（子数组长度也为 9000）进行 10 次空间局部性测试，工夫（毫秒）取平均值，后果如下：

所用示例为上述两个空间局部性示例

从以上测试后果来看，步长为 1 的数组执行工夫比步长为 9000 的数组快了一个数量级。

总结：

• 反复援用雷同变量的程序具备良好的工夫局部性
• 对于具备步长为 k 的援用模式的程序，步长越小，空间局部性越好；而在内存中以大步长跳来跳去的程序空间局部性会很差

14. if-else 比照 switch

当判断条件数量越来越多时，越偏向于应用 switch 而不是 if-else。

if (color == 'blue') {} else if (color == 'yellow') {} else if (color == 'white') {} else if (color == 'black') {} else if (color == 'green') {} else if (color == 'orange') {} else if (color == 'pink') {

}

switch (color) {
    case 'blue':

        break
    case 'yellow':

        break
    case 'white':

        break
    case 'black':

        break
    case 'green':

        break
    case 'orange':

        break
    case 'pink':

        break
}

像以上这种状况，应用 switch 是最好的。假如 color 的值为 pink，则 if-else 语句要进行 7 次判断，switch 只须要进行一次判断。从可读性来说，switch 语句也更好。

从应用机会来说，当条件值大于两个的时候，应用 switch 更好。不过 if-else 也有 switch 无奈做到的事件，例如有多个判断条件的状况下，无奈应用 switch。

15. 查找表

当条件语句特地多时，应用 switch 和 if-else 不是最佳的抉择，这时无妨试一下查找表。查找表能够应用数组和对象来构建。

switch (index) {
    case '0':
        return result0
    case '1':
        return result1
    case '2':
        return result2
    case '3':
        return result3
    case '4':
        return result4
    case '5':
        return result5
    case '6':
        return result6
    case '7':
        return result7
    case '8':
        return result8
    case '9':
        return result9
    case '10':
        return result10
    case '11':
        return result11
}

能够将这个 switch 语句转换为查找表

const results = [result0,result1,result2,result3,result4,result5,result6,result7,result8,result9,result10,result11]

return results[index]

如果条件语句不是数值而是字符串，能够用对象来建设查找表

const map = {
  red: result0,
  green: result1,
}

return map[color]

16. 防止页面卡顿

60fps 与设施刷新率

目前大多数设施的屏幕刷新率为 60 次 / 秒。因而，如果在页面中有一个动画或突变成果，或者用户正在滚动页面，那么浏览器渲染动画或页面的每一帧的速率也须要跟设施屏幕的刷新率保持一致。

其中每个帧的估算工夫仅比 16 毫秒多一点 (1 秒 / 60 = 16.66 毫秒)。但实际上，浏览器有整顿工作要做，因而您的所有工作须要在 10 毫秒内实现。如果无奈合乎此估算，帧率将降落，并且内容会在屏幕上抖动。此景象通常称为卡顿，会对用户体验产生负面影响。

如果你用 JavaScript 批改了 DOM，并触发款式批改，经验重排重绘最初画到屏幕上。如果这其中任意一项的执行工夫过长，都会导致渲染这一帧的工夫过长，均匀帧率就会降落。假如这一帧花了 50 ms，那么此时的帧率为 1s / 50ms = 20fps，页面看起来就像卡顿了一样。

对于一些长时间运行的 JavaScript，咱们能够应用定时器进行切分，提早执行。

for (let i = 0, len = arry.length; i < len; i++) {process(arry[i])
}

假如下面的循环构造因为 process() 简单度过高或数组元素太多，甚至两者都有，能够尝试一下切分。

const todo = arry.concat()
setTimeout(function() {process(todo.shift())
 if (todo.length) {setTimeout(arguments.callee, 25)
 } else {callback(arry)
 }
}, 25)

如果有趣味理解更多，能够查看一下高性能 JavaScript 第 6 章和高效前端：Web 高效编程与优化实际第 3 章。

17. 应用 requestAnimationFrame 来实现视觉变动

从第 16 点咱们能够晓得，大多数设施屏幕刷新率为 60 次 / 秒，也就是说每一帧的均匀工夫为 16.66 毫秒。在应用 JavaScript 实现动画成果的时候，最好的状况就是每次代码都是在帧的结尾开始执行。而保障 JavaScript 在帧开始时运行的惟一形式是应用 requestAnimationFrame。

/**
 * If run as a requestAnimationFrame callback, this
 * will be run at the start of the frame.
 */
function updateScreen(time) {// Make visual updates here.}

requestAnimationFrame(updateScreen);

如果采取 setTimeout 或 setInterval 来实现动画的话，回调函数将在帧中的某个时点运行，可能刚好在开端，而这可能常常会使咱们失落帧，导致卡顿。

18. 应用 Web Workers

Web Worker 应用其余工作线程从而独立于主线程之外，它能够执行工作而不烦扰用户界面。一个 worker 能够将音讯发送到创立它的 JavaScript 代码, 通过将音讯发送到该代码指定的事件处理程序（反之亦然）。

Web Worker 实用于那些解决纯数据，或者与浏览器 UI 无关的长时间运行脚本。

创立一个新的 worker 很简略，指定一个脚本的 URI 来执行 worker 线程（main.js）：

var myWorker = new Worker('worker.js');
// 你能够通过 postMessage() 办法和 onmessage 事件向 worker 发送音讯。first.onchange = function() {myWorker.postMessage([first.value,second.value]);
  console.log('Message posted to worker');
}

second.onchange = function() {myWorker.postMessage([first.value,second.value]);
  console.log('Message posted to worker');
}

在 worker 中接管到音讯后，咱们能够写一个事件处理函数代码作为响应（worker.js）：

onmessage = function(e) {console.log('Message received from main script');
  var workerResult = 'Result:' + (e.data[0] * e.data[1]);
  console.log('Posting message back to main script');
  postMessage(workerResult);
}

onmessage 处理函数在接管到音讯后马上执行，代码中音讯自身作为事件的 data 属性进行应用。这里咱们简略的对这 2 个数字作乘法解决并再次应用 postMessage() 办法，将后果回传给主线程。

回到主线程，咱们再次应用 onmessage 以响应 worker 回传的音讯：

myWorker.onmessage = function(e) {
  result.textContent = e.data;
  console.log('Message received from worker');
}

在这里咱们获取音讯事件的 data，并且将它设置为 result 的 textContent，所以用户能够间接看到运算的后果。

不过在 worker 内，不能间接操作 DOM 节点，也不能应用 window 对象的默认办法和属性。然而你能够应用大量 window 对象之下的货色，包含 WebSockets，IndexedDB 以及 FireFox OS 专用的 Data Store API 等数据存储机制。

19. 应用位操作

JavaScript 中的数字都应用 IEEE-754 规范以 64 位格局存储。然而在位操作中，数字被转换为有符号的 32 位格局。即便须要转换，位操作也比其余数学运算和布尔操作快得多。

取模

因为偶数的最低位为 0，奇数为 1，所以取模运算能够用位操作来代替。

if (value % 2) {// 奇数} else {// 偶数}
// 位操作
if (value & 1) {// 奇数} else {// 偶数}

取整

~~10.12 // 10
~~10 // 10
~~'1.5' // 1
~~undefined // 0
~~null // 0

位掩码

const a = 1
const b = 2
const c = 4
const options = a | b | c

通过定义这些选项，能够用按位与操作来判断 a/b/c 是否在 options 中。

// 选项 b 是否在选项中
if (b & options) {...}

20. 不要笼罩原生办法

无论你的 JavaScript 代码如何优化，都比不上原生办法。因为原生办法是用低级语言写的（C/C++），并且被编译成机器码，成为浏览器的一部分。当原生办法可用时，尽量应用它们，特地是数学运算和 DOM 操作。

21. 升高 CSS 选择器的复杂性

(1). 浏览器读取选择器，遵循的准则是从选择器的左边到右边读取。

看个示例

#block .text p {color: red;}

1. 查找所有 P 元素。
2. 查找后果 1 中的元素是否有类名为 text 的父元素
3. 查找后果 2 中的元素是否有 id 为 block 的父元素

(2). CSS 选择器优先级

 内联 > ID 选择器 > 类选择器 > 标签选择器 

依据以上两个信息能够得出结论。

1. 选择器越短越好。
2. 尽量应用高优先级的选择器，例如 ID 和类选择器。
3. 防止应用通配符 *。

最初要说一句，据我查找的材料所得，CSS 选择器没有优化的必要，因为最慢和慢快的选择器性能差异十分小。

22. 应用 flexbox 而不是较早的布局模型

在晚期的 CSS 布局形式中咱们能对元素履行相对定位、绝对定位或浮动定位。而当初，咱们有了新的布局形式 flexbox，它比起晚期的布局形式来说有个劣势，那就是性能比拟好。

上面的截图显示了在 1300 个框上应用浮动的布局开销：

而后咱们用 flexbox 来重现这个例子：

当初，对于雷同数量的元素和雷同的视觉外观，布局的工夫要少得多（本例中为别离 3.5 毫秒和 14 毫秒）。

不过 flexbox 兼容性还是有点问题，不是所有浏览器都反对它，所以要审慎应用。

各浏览器兼容性：

• Chrome 29+
• Firefox 28+
• Internet Explorer 11
• Opera 17+
• Safari 6.1+ (prefixed with -webkit-)
• Android 4.4+
• iOS 7.1+ (prefixed with -webkit-)

23. 应用 transform 和 opacity 属性更改来实现动画

在 CSS 中，transforms 和 opacity 这两个属性更改不会触发重排与重绘，它们是能够由合成器（composite）独自解决的属性。

参考资料：

• 应用 transform 和 opacity 属性更改来实现动画

24. 正当应用规定，防止适度优化

性能优化次要分为两类：

1. 加载时优化
2. 运行时优化

上述 23 条倡议中，属于加载时优化的是后面 10 条倡议，属于运行时优化的是前面 13 条倡议。通常来说，没有必要 23 条性能优化规定都用上，依据网站用户群体来做针对性的调整是最好的，节俭精力，节省时间。

在解决问题之前，得先找出问题，否则无从下手。所以在做性能优化之前，最好先考察一下网站的加载性能和运行性能。

查看加载性能

一个网站加载性能如何次要看白屏工夫和首屏工夫。

• 白屏工夫：指从输出网址，到页面开始显示内容的工夫。
• 首屏工夫：指从输出网址，到页面齐全渲染的工夫。

将以下脚本放在 </head> 后面就能获取白屏工夫。

<script>
 new Date() - performance.timing.navigationStart
</script>

在 window.onload 事件里执行 new Date() \- performance.timing.navigationStart 即可获取首屏工夫。

查看运行性能

配合 chrome 的开发者工具，咱们能够查看网站在运行时的性能。