聊聊关于性能优化（一）

隔了许久都没有更新博客，前一阵子是因为忙其他事去了，现在想写点什么，但是思前想后不知道该写些什么，这是这个系列的第一篇，这篇文章没有干货，只是聊聊关于前端优化，关于5G的到来，关于前端的未来。

关于为什么要优化

前端的大咖们在推动前端届蓬勃发展的同时，越来越多的人能抄起手上的工具（ React、Vue、Angular ）加上各种 CLI 一键生成，再加上天然的 UI 库（ Antd、Element-UI、iView、Bootstrap ）就能快速构建写出一个用户界面，加上在这个性能过剩的年代，非大厂能够投入人力优化前端性能，大部分网页能加载出来功能没问题就告之大吉，只要不是太 过分 的代码编写，一般来说，电脑端的网页加载也就差个 1~3 秒，更多的则是网络问题。

这么一看，性能优化仿佛不是那么重要，但是由于前端圈的蓬勃发展，越来越多的功能实现放置在前端页面上，现代的网站拥有比以往多很多的功能，页面数量都是几倍的增长，甚至该网站是这个企业的核心业务，尤其是这几年移动设备的爆发式发展，如果这么多的功能放置在移动端时，轻微的性能问题可能只会导致轻微的延迟、等待，仅仅会给用户带来短暂的不便，但是严重的性能问题就会导致用户无法访问或者无法响应用户的动作之类，很多人意识到这个问题，可惜的是，大部分网站都将这个原因归结于网络条件不好或者用户设备太差，从而忽略真正的前端性能的优化。

对于一般网站来说，用户进入浏览，关心的是自己的用户体验、网页浏览舒适度，他们很大一部分并不关心网络和设备问题，有很多数据表明，一个网站的舒适度决定了用户的去留。

对不起，我真的不想等（优化和用户去留的关系）

我们希望我们所构建的页面能和用户进行互动，而不是呆板的纯静态页面，一个可交互的页面可以留存很多的用户。

如果我们构建的是博客，我们希望用户能顺畅的读完博文，并给予点评。

如果我们构建的是商城系统，我们希望用户能快速精准的定位到需要购买的商品。

如果我们构建的是社交系统，我们希望用户能快速找到对应的人并进行彼此的互动。

而这一切，差异化是一条出路，但是差异化很容易就被抄袭、模仿，企业更多的这是面对同质化的红海竞争，与此同时，性能扮演着至关重要的角色。

有几组数据来表明性能优化与用户留存的关系：

根据 DoubleClick by Google 更多研究，如果一个网站加载时间越短，优势越大。

根据大量测试发现，同一个页面，加载时间 19 秒和加载时间 5 秒是两种截然不同的结果，加载在 5 秒之内的网站，用户浏览率增长 70%，流失率下降 35%，广告可见率提升 25%。

大家可以使用 Speed Scorecard 工具进行移动网站的加载速度测试，由于没有中国大陆节点，大家移步至香港节点进行测试。

以下是我对一些常用网站4G加载的测试：

高优化和收入的关系

从上一小节可以看出来，一个好的优化可以提升用户的转化率，反之流失率会大大增加。

下面一些小栗子显示了一些优化对收入的影响：

根据 Mobify 研究发现，首页加载时间每减少 100 毫秒，用户留存率就会增加 1.11% ，年收入增长近 380,000 美元。此外，结账页面加载时间每减少 100 毫秒，用户付款率增长 1.55%，从而，年均收入增长近 530,000 美元。
DoubleClick 发现网站加载时间在 5 秒内的服务商比网站加载时间在 19 秒内的服务商的广告收入增长一倍多。
AutoAnything 的页面加载时间减少一半，其销售额提升 12%-13%。
支付宝和微信开通离线支付，无网络也可以支付。

用户体验的哲学

关于加载速度

当用户在用移动设备访问某一个网站时，由于各种外在条件的因素（网速、设备硬件条件），打开同一网站的效果可能截然不同（某锤官网）：

在 Fast 3G 情况下大概使用了 34 秒全部加载完毕：
在 模拟 4G（5MB/s） 的速度下大概使用了 11 秒全部加载完毕：

然而，实际情况下，由于地理位置、人流量等环境因素，很少有移动设备能满速 5MB 的下载。而用户体验的基础是在于已经看到显示的内容，在此之前就谈不上用户体验，如果网络较快可能还好点，如果网速不好，用户就不得不等待，还可能会遇到各种各样的问题，例如，JS 加载不完整导致点击事件无效等。全部加载完毕之后的某锤网站使用感觉还可以，我们来看一下此次加载了多少 JS 资源：

居然有一个 JS 文件达到了 2.3MB，这显然是不合理的，纵使网站优化再好，加载很慢就会导致用户的不耐烦。

关于代码优化

得益于现在移动端 CPU 的高速发展，甚至有些媲美桌面端处理器，但是用户不可能一直手持最新设备，所有现在不要高估了移动端的处理器，其计算能力和内存大小依旧有限。

一些未经优化的代码，我们在 Chrome 下调试可能没觉得有差，但是到移动设备上时，就会出现各种各样的问题，当问题多到一定程度时，用户必然忍受不了，将其抛弃。

利用 Google 提供的 Lighthouse 插件，我们可以直观的分析一个网站的优劣，以及优化点，让我们有方向的去改进：

嗯，再看看我们的掘金（还是挺不错滴）：

优化关乎用户成本

这是一个最好的时代，所有的一切都在迅速发展；这是一个最坏的时代，渐渐地越来越多的人们跟不上时代的步伐（比如我们的父母，哎）。

未来一定是移动的世界。

根据 statcounter 统计，全球范围内，移动端设备占据了较大比例，这一比例在中国更大，甚至占到了 70%-80%，我们要记住，绝大多数用户都是通过 LTE、4G、3G 访问网络，在 2017 年，Ben Schwarz做出真实网络与优化的调查：Beyond the Bubble: Real world performance 显示，愈加成熟的网络建设背后，用户数据流量的成本正在逐渐下滑，到了 5G 时代又是另一番景象，这个我们下面再讨论。

这一现象表明，几乎任何用户都可以廉价的访问网络，在这个互通互联的时代，网络几乎成为我们生活的必需品。

另一研究表明，从 2011 年起，网站页面数量就开始稳步增长，其中移动端的 URL 总数甚至超过了桌面端，更多统计数据点击这里查看：

上图统计发现，2011 年起，网站页面数量就开始稳步增长，尤其是近几年，得益于移动端的爆发式增长，桌面端也配套了对应的页面，但是增速仍然低于移动端。

这一趋势发展下去，意味着我们需要花费更多的流量（貌似现在已经是这样了）。

关于如何优化

性能优化并不是一件很难得事，但也绝对不轻松，做到以下几点便提升性能，这次没有具体的实施细节，只有一些建议。

关于资源的加载

构建一个高性能高效的 WEBAPP 最为有效的一个注意点就是，检查用户在进入页面时，到底加载了多少有效的资源，又加载了多少无效的资源。尽管我们可以从 Chrome DevTools 的 Network 面板查看所有已加载的资源，但是如果开发者从未关注过，不知该如何下手，可以看看以下几个意见：

如果使用网上开源的 UI 库，例如：Bootstrap、Antd 来构建自己的界面，在做之前询问自己是不是一定要用，结合自身的项目需求，但至少应做到按需引入而不是在 app.js 里全部引入这些样式和组件。另外，若使用 link 标签来引入资源，这些资源在网站资源加载之前加载，可能会有些阻碍。
多使用 Flex 和 Grid 来进行布局，这两种布局方式可以使用较少的代码来实现简单或复杂的布局。
CSS 加载是一种阻塞浏览器渲染的资源（以后会聊到），使用 CSS 框架的消耗某些情况下会导致渲染延迟严重，最好视情况引用资源，加速渲染。
JavaScript 库十分方便，但是不一定是必须的。例如 JQuery，现代浏览器都支持了 querySelector 和 querySelectorAll 等，能够快捷的选择元素。addEventListener 可以轻松的绑定事件。classList、setAttribute 和 getAttribute 提供了类和元素属性的简便方法。如果不得已一定要使用库，请选择合适并且占用空间较小的替代产品，例如使用 dayjs 来代替 moment.js、Zepto 代替 JQuery 、 Preact 代替 React 等。
得益于网络条件日益变好和 WEBAPP 的迅猛发展，现在很多一部分企业选择 SPA 作为首选，此类应用通常需要加载大量的JavaScript，例如上面的某锤科技。根据 Addy Osmani 发布的文章 The Cost Of JavaScript 分析发现，此类资源必须经过下载、解析、编译和执行这一过程，浏览器会花费很长时间解析/编译代码，严重时会严重延迟用户与网站交互的时间。因此网站发送的 JavaScript 越多，网站进行交互之前解析和编译它所需的时间就越长。但是这并不是说 SPA 不可取，合理使用 HTTP 缓存或者 Service Worker，相比传统的多页面网站，经过优化的 SPA 网站往往能提供更好的用户体验。

关于资源的传输

迁移至 HTTP2，相比HTTP1.1，HTTP2 能够提升至少 50% 资源的获取速度，并解决 HTTP1.1 固有的性能问题，例如并发请求数的限制、缺乏标头压缩。
在上面用户成本那里统计图可以看出来，现代网站的大小也在逐渐增加，在 HTTP1 中，由于并发请求数量的限制（浏览器通常是 6 个），常见的做法是将 CSS 和 JavaScript 捆绑打包成较大的 bundle，但是这么做及其影响资源的加载，对性能造成不利的影响。而在 HTTP2 之后不需要考虑此问题，因为 HTTP2 采用流传输，可以一次请求多个文件，极大的提升了性能，赶紧让后端小伙伴支持 HTTP2 吧！
采用 Webpack 代码拆分技术，仅下载目前需要用到的脚本，合理的拆分模块并且合理利用 HTTP1.1 协议传输，同样能够大幅提升加载速度。

关于资源的大小

压缩 HTML，CSS，JS，充分利用 Webpack 的能力，将各种资源打包压缩，这会大大减少资源的大小，而且不会影响功能。
利用 UglifyJS 将 JS 的内容丑化（变量名压缩），它会通过缩短变量名和函数名来节省空间。
利用 SVGO 优化 SVG 文件。
利用 GZIP 方式进行资源再次压缩。但是请记住，压缩能只能加快资源加载速度，并不是解决性能问题的万能方法。
如果有充足的时间，可以利用 WebP 格式代替 JPEG 或者 PNG，它能使用及其少量的数据保持和传统图片格式一样的高质量水平。
使用自适应图片。最简单的，使用 <img> 标签中的 srcset 属性，以指定浏览器可以选择的一组图像。
使用视频而不是 GIF。同等画质下，视频大小会比 GIF 小 80% 左右。

关于 5G 的到来

什么是 5G ？

写下这篇文章的时候，第一批支持 5G 的手机已经发布了。

在实验室测试结果上看，5G 的速度是 4G 的 65000 倍，能够直接实时传输 4K 流媒体，同时，5G 网络将具有接近零延迟。4G 的平均延迟 50 毫秒，当切割到 5G 后，只有 1 毫秒，这是 GSMA 设定的基准。

5G 的来临能改变很多行业，例如，视频直播互动，云，虚拟现实、增强现实，前端等行业，同时同等流量下的资费肯定愈发变低，带宽问题也可能不再是问题了。

随着技术的升级，HTTP2 也一定会越来越普遍，文件大小和数量可能不再是问题，以后优化的重点可能就是对应于浏览器（客户端）的优化，如何提升用户的使用体验可能是那个时候最重要的吧。

由于传输技术的巨大升级，一些很酷的客户端技术未来将可能在前端实现，随用随访问，比如 CAD 制图，power bi 等。

浏览器的地位将越来越重要。

目前来说，4G 的带宽已经足够，5G 的到来也只是加快了资源加载速度，最终阻碍 WebApp 的还是用户体验的问题，是有限的显示效果，不流畅的滑动，Native 硬件支持不完善，底下的性能等等，才是最重要的原因。

关于前端的未来

这几年前端层出不穷的框架技术让人有一种学不动的感觉，但是这大多是都是围绕着浏览器而进行的。

在我看来，其实就分两个端，客户端和服务端。一个和用户打交道，一个和服务器打交道而已。

真正让人兴奋不已的技术革新，Flutter、RN、WebAssembly、PWA 等技术让人眼前一亮； nodeJS 包揽后端一部分功能，让人心花怒放； 小程序 这种于 APP 之内的微小应用即用即开的能力。

未来

Rxjs 可以应对低延迟和万物互联的复杂异步
Web Worker 不阻塞主线程，高刷新率的渲染页面
5G 的低延迟意味着渲染交给服务器没有问题，打开网页玩大型主机游戏也不是梦想
随着浏览器的更新，WebGL/OpenGL/Canvas 的能力被完全挖掘出来，Web 3D、Web VR、可视化将变成主流，图像和动画交互将是个长期热点

总之，前端的路是光明的。

最后不好意思推广一下我基于 Taro 框架写的组件库：MP-ColorUI。

可以顺手 star 一下我就很开心啦，谢谢大家。

点这里是文档

点这里是 GitHUb 地址

聊聊关于性能优化和其他（一）