网页性能 CaseStudy：以 PressOne 首页为例

一般来讲，工程师熟悉某个系统会只要搞清楚其数据结构和数据流转过程基本足够了，但从商业的角度来看，先后端工程师都应该关注的另外一个重要维度是系统性能，纯技术角度来看性能能够认为是系统的响应速度（实际上还能够认为是执行效率等），而从用户角度来看性能就是使用体验。

网页性能为何重要？

页面性能差的直接后果是用户须要等待，而等待，尤为是不肯定要多长时间的等待会给用户带来焦虑，为了尽早的结束这种焦虑，除非访问网页是刚需，用户一般会选择直接关闭页面。从实际数据来看，性能差是页面高跳出率的重要缘由之一。

为了搞清楚页面性能对业务目标的影响，诸如 Yahoo、Google、Amazon 等科技公司都投入了很多资源去研究和优化，好比下面是 ThinkWithGoogle 运用神经网络分析 2017 年 1100 万广告落地页加载速度和页面跳出率关系所获得的结论：

结论显而易见：越快越好，少便是多。

实际上，最近几年来大型互联网公司在页面性能优化研发中产出了很多工具和文档，方便工程师给网站作性能分析和优化。

其中文档方面比较经典的当属三本书：

• High Performance Websites，早期在 Yahoo 性能团队工做的 Steve Souders 所著；
• Even Faster Websites，同上，在上册的基础上，列出了不少行之有效的细节优化手段；
• High Performance Browser Networks，Google 性能工程师 Ilya Grigorik 所著，能够免费在线阅读，固然若是想支持读者，能够选择购买；

而工具则很是多，尤为是 2015 年开始爆发的各类应用性能管理（APM，如 New Relic）工具，对工程师来讲，比较经典易用的有：

• WebPageTest，能够认为是网页性能分析工具中的 Vim 了，纯开源项目，在全球都有节点，分析思路基本与 Yahoo 性能黄金法则相贴合；
• LightHouse，已经集成在 Chrome 开发者工具中，可以从现代 WEB 应用比较重要的几个维度给出分析结果，好比加载速度、PWA、可用性、SEO 等，工具易用性、可得性都高于 WebPageTest，我的强烈建议；

网页性能该怎么衡量？

要清晰、准确的衡量网页性能，咱们先要定义页面性能，如何定义页面性能？

1. 从后端角度看，能够是首字节时间，即页面发起请求到浏览器收到第一个响应字节的时间，英文 Time to First Byte；
2. 从浏览器角度看，能够是页面所依赖的所有静态资源加载完成所须要的时间，即常说的彻底加载时间；
3. 从用户角度看，能够是敲回车键开始到看到页面开始渲染的过程所需的时间，即常说的首次渲染时间，此概念还能够细分，好比 WebPageTest 和 LightHouse 都有的 FirstMeaningfulPaint；

性能优化工做处在不一样阶段，或者业务场景不一样，上面不一样定义视角的适用性是不一样的，也有把上面 3 种衡量方法加权求和获得综合的性能指数。

要想真正开始作优化，须要搞清楚从发起请求到浏览器渲染页面并呈现给用户的过程当中有哪些关键环节，好在现代浏览器提供的 Navigation Timing API 已经把这个过程标准化，方便咱们作性能指标的计算，以下图：

举例来讲上面提到的首字节时间和彻底加载时间能够用以下公式计算：

首字节时间 = responseStart - navigationStart

彻底加载时间 = loadEventEnd - navigationStart

至于首次渲染时间，准确的计算方式须要结合录屏，篇幅缘由，这里不作展开。

PressOne 首页性能 CaseStudy

PressOne 是基于区块链的内容分发公链，而 https://press.one 则是项目入口，目前功能还比较简单，主要包括帐户建立、用户登陆、三方帐号绑定、用户主页、内容签名等功能。首页是任何网站的门户，确保其访问速度和体验的重要性不言而喻，而 press.one 给笔者的初体验除了新奇还包括慢，新用户加载页面平均须要 6s 以上，即便内容渲染以前有加载中提示，仍是有明显的等待感。

虽然 press.one 是基于 angular 开发的单页应用，适用于传统页面的大部分性能优化方法一样适用，下面结合 LightHouse 对 press.one 首页作简单的性能分析，并列出行之有效的优化行动清单。

LightHouse 能够独立安装使用，也能够在 Google Chrome 中使用，由于集成到了开发者工具的 Audits 面板中，使用方法比较简单，建议直接阅读文档。

下面是使用 Google Chrome 作性能诊断的结果：

百分制的性能指数结果是 18 分，3G 网络下的彻底可交互时间长达 20S，一般到 10S 用户基本都觉得网站坏掉了，可见优化的空间是巨大的。

LightHouse 列出的优化手段（Opportunities）和可能的缘由诊断（Diagnostics）都比较直观：

• Enable text compression，启用文本压缩，针对 JS、CSS 等静态资源是很是有效的优化手段，一般可节省 60% 以上，实施成本低，收益巨大，若是加上适当的缓存，能够对重复访问用户更加友好；
• Reduce render-blocking stylesheets，减小阻塞渲染的样式，须要把首屏渲染的样式从总体样式中剥离出来优先加载，实施成本偏高，收益中等；
• Unused CSS rules 是针对 CSS 文件的优化，减小传输实际上不须要的代码，我仔细拔了下代码，项目引入的 fontawesome 貌似确实没用到，实际上这个库却不小，实施成本小，收益中等；
• Serve images in next-gen formats，使用更好的压缩算法压缩图片，实施成本低，收益大；
• Proper size images，请求的图片和使用尺寸对应，避免缩放，形成浪费，实施成本低，收益看状况；

若是上面的优化手段都落地实施，从新评估性能指数大几率能够达到及格线。

结合瀑布流分析，咱们也不难发现更进一步的优化点，关键资源加载链条（Critical Request Chain）太长了，以下图：

要开始首次渲染（对应以下瀑布流图右侧蓝色的竖线）除主文档外，咱们还须要额外下载 5 个 JS 文件，1 个 CSS 文件：

关键资源加载链条太长的问题怎么优化呢？

• 合并资源请求，好比 elliptic 和 keythereum 的三方依赖能够直接合并，更激进的能够和 polyfill 也合并；
• 合理使用懒加载，首次渲染不须要的资源作适当的拆分，SPA 和传统页面均可以实现，不让非关键资源阻塞页面首次渲染；
• 合理使用 CDN，由于一般 CDN 是地理位置离用户更近的节点，能够大大节省网络传输的 RTT；

关键资源加载链条的问题解决以后，从新评估的性能指数大几率能达到 80 分。

那么接下来呢？理论上看起来性能优化是无止境的，实际上任何一个领域花 20% 的时间能达到 80% 的目的（好比把页面首次渲染时间降到 3s 之内），而后能够收手去解决更重要的问题，固然时间容许的话，有追求的工程师会不断的问本身，这是我能作到的极致么？

继续往下优化则要从页面渲染的角度去考虑，毕竟咱们已经尽量快的把渲染页面所需的各类资源交给了浏览器，怎么让它更快、更流畅的渲染出可交互的页面是接下来须要重点考虑的。而渲染速度跟 DOM 节点的组织、JS 的组织、JS 和 DOM 交互的优化都有关系，篇幅缘由，能够单独写文章介绍。

以上，但愿对你有用。