【大型网站性能优化实战】学习笔记（一）
【大型网站性能优化实战】学习笔记（一）
基于用户体验的性能优化要素
1.页面用户体验的要素介绍
用户体验:
抽象,带有强烈的主观意识
难以量化
我觉得这样会更好
我认为用户喜欢这样或者那样
......
从用户打开浏览器,浏览网页的感知过程,我们分解出了几个要素来衡量网站性能方面的用户体验,并尝试通过不同监控系统进行系统监控和指标量化
- 白屏。
- 首屏。
- 页面整体加载。
- 页面可交互。
- 功能交互响应
1.白屏
- 白屏时间的重要性
白屏时间:用户打开浏览器输入网站的URL后,从屏幕空白到第一个画面出来的时间,这个时间的长短将直接决定网站页面给用户的第一印象.
重要性:页面渲染的时间越短,用户等待的时间就越短,用户感知页面的速度就越快,这样可以大大提高用户体验,减少新用户的跳出,提高留存率.反之,过长的等待时间,会让用户变得烦躁,更轻易跳出或关闭这个网站
- 白屏过程详解
依次说明每个步骤.从中可以看到浏览器与服务器做了哪些交互,又在客户端经历了那些过程
1.DNS Lookup
DNS Lookup即浏览器从DNS服务器中进行域名查询,浏览器解析域名拿到对应的IP地址后,才能和服务器进行通信.通常浏览器在加载页面的过程中,会进行很多次DNS Lookup操作,其中包括页面本身的域名查询,以及浏览器在解析页面HTML代码过程中,需要加载JS,CSS,Image等资源产生的解析.
对大中型网站来说,通常在页面加载过程中会产生下列域名解析:
www.example.com,页面URL本身
style.example.com,JS\css等静态资源请求
img.example.com,静态图片请求
ajax.example.com,各种站内的Ajax请求
*.google.com其他不Google的站外请求
域名解析的过程,可短至几毫秒,也可能消耗几秒,所以解析过程的快慢直接影响页面整体加载的渲染速度,特别是对于每天访问量达千万级别的页面
DNS解析速度的优化策略有很多,通常我们会从以下几个方面思考细节的优化
- DNS缓存优化
- DNS预加载策略
- 页面中资源的域名的合理分配
- 稳定可靠的DNS服务器等
2.建立TCP/IP请求连接
基于不同的网络环境,优化数据包的大小,以减少数据因传输丢失或者被破坏产生的重传,从而提高传输效率
网络传输链路的优化,对于大部分企业来说,是需要很大投入的.
3.服务器端处理响应
4.客户端下载,解析,渲染显示页面
服务器返回HTTP Response后,浏览器陆续开始接受数据,进行HTML下载,解析,渲染显示等过程
具体步骤如下
- 如果是Gzip包,则先解压为HTML.
- 解析HTML的头部代码,下载头部样式代码中引用的资源样式或者脚本资源文件.
- 解析HTML代码和样式文件代码,这个过程会构造出两个树结构,即与HTML相关的DOM树,以及与CSS相关的CSSOM树.
- 通过遍历DOM树和CSSOM树,浏览器依次计算每个节点的大小,坐标,颜色等样式,构造出渲染树.
- 根据渲染过程完成绘制的过程.
关于浏览器下载,解析,渲染页面的优化策略,根据渲染步骤,大概可以从以下几个方面入手
- 优化HTML的代码和结构,缩短HTML下载时间,加快HTML解析速度.
- 优化CSS文件和结构,缩短CSS文件下载和解析时间
- 合理放置JS代码,避免前面第三种情况的出现
2.首屏
- 首屏的定义
从字面上理解,为”第一个屏幕”,而首屏时间即代码页面在”第一个屏幕”中的内容完全展示出来的时间.
与白屏不同的是,我们并不能从浏览器的系统API中获取首屏时间.在真实网络环境中,我们通过模拟的方法来获取首屏指标
- 首屏时间的重要性
- 完善指标量化系统
- 更加真实的反馈用户体验
首屏的优化:不合理的HTML代码结构,页面资源下载序列等.最关键的是,要能够找到衡量各自页面首屏内容展示速度的方法,通过监控发现潜在的问题,然后做出调整.
3.页面整体加载
页面加载完成又称Pageload,顾名思义,即页面相关资源(CSS样式文件,JS脚本文件,图片等)全部加载完成的时间.当这个时间点被触发时,意味着当前页面对于用户来说是可以进行安全交互的.
8s规则
4s规则
4.页面可交互
5.功能交互响应
6.数据采集可行性分析
- 终端环境数据采集分析
- 页面性能数据采集分析
使用很多新版浏览器中已经被支持实现的HTML5 Perfomance API
- 基于H5 Performance Timing API,收集页面的基础性能信息
Performance Timing API主要包括一下3部分
- Navigation Timing :主要提供页面加载过程中的性能数据
- Resource Timing:主要提供页面所包含的脚本,样式表,图片等资源加载的性能数据
- User Timing:方便为在复杂脚本内部记录不同代码片段的执行时间提供API实现
通过Navigation Timing和Resource Timing两个部分的API，通过他们提供的属性数据，基本上可以获取从页面加载开始到结束涉及的网络加载及浏览器端渲染等待时间的消耗
- Navigation API
通过访问window.performance.timing对象中的属性，可以得到当前页面的相关性能信息。如下图在W3C规范定义的图可以看到Timing提供了那些属性
通过对照页面的加载顺序，可以清晰的了解页面的不同加载阶段。比如计算域名解析，TCP请求等处理过程中所需要的属性区间
Timimg 口中提供的属性，都是UTC时间，即指定的时间距 GMT 时间 1970-0 1-01 午夜的毫秒数（在下面的介绍中，如果没有特殊说明 默认都是 UTC 时间）。一般我们都以NavigationStart或者 Fetch Start 的值作为页面加载的开始时间，以ResponseEnd作为分隔点，在它之前的时间一般归属到网络相关的消耗，而在它之后的时间一般归属到终端渲染的消耗，最后以 LoadEventEnd作为结束时间
- Resource API
通过访问 window.performance.getEntriesByTpe reso urce”）返回的数组对象 可以遍历当前页面所包含 资源加载相关的性能信息，通过官方的例子发现，笔者获取某种特定资源的加载相关性能信息也非常方便，如图
- 页面白屏时间的监控
目前在 IE9＋、 Chrome 浏览器中分别提供各自版本的 FirstPaint(即 StartRender)时间，可通过 JavaScript访问来获取
( I ) IE9＋。
IE9＋中，页面开始渲染的时间由 window.performance.timings. msFirstPaint来提供，即以毫秒为单位的 UTC 时间
( 2 ) Chrome
Chrome 中， 页面开始渲染的时间由 window .chrome. loadTimes().firstPaintTime 提供，但Chrome 中返回的 FirstPaintTime 以特殊的秒、 毫秒（ seconds millseconds 单位的 UTC时间。所以在使用他之前需要做简单的处理
- 页面性能数据加工计算
从浏览器获取原始的性能数据后，开始对数据进行加工计算，来映射前面定义的和用户体验相关的各种体验指标
- StartTime基准计算
StarTime的定义非常重要，因为后面所有的指标都需要以此时间为基准进行计算。基于我们的经验，如果NavigationStart不为0,则使用NavigationStart作为页面Start基数。
7.计算实例-demo
1.前端优化-如何计算白屏和首屏时间
https://www.cnblogs.com/longm/p/7382163.html
2.前端速度性能统计
https://segmentfault.com/a/1190000005869953
通常一个网站，如果首屏时间在2秒以内是比较优秀的，5秒以内是可以接受的，5秒以上就不可容忍了。用户会选择刷新页面或立刻离开。
8.附录
<高性能网站建设指南>
- 尽量减少HTTP请求
- 使用CDN
- 静态资源使用cache
- 启用Gzip压缩
- js脚本尽量放在页面底部
- CSS样式表放在顶部
- 减少内联js和css的使用,尽可能使用外部的CSS文件
- 减少DNS查询
- 精简js
- 避免重定向
- 删除重复的脚本
这些规则能够帮助开发者快速的发现页面性能问题,一个页面如果遵守了以上规则进行前端开发,那么抛开网络因素,至少可以保证它在页面加载阶段的性能不会出现问题
性能指标
1.并发数
并发数是指系统同时能处理的请求数量，这个也是反应了系统的负载能力。
2.响应时间(RT)
响应时间是一个系统最重要的指标之一，它的数值大小直接反应了系统的快慢。响应时间是指执行一个请求从开始到最后收到响应数据所花费的总体时间。
RT ( Response Time）表示响应时间，它是从接收请求开始到服务器处理完成的时间差值。RT的长短取决于应用的特点，对于大型网站而言，所有应用都通过RPC（远程接口调用）服务化的接口得到需要的数据，大部分时间消耗都在网络和远程接口的处理上。减少 RT 的方较简单，要么合并请求，将多次调用合并成一次调用，要么减少调用，减少远程接口调用，可以通过缓存架构升级或者去除多余调用来实现。应用本身的时间大部分部依赖于CPU的处理时间，CPU的处理时间一般较短，当然应用本身仍然有很多瓶颈，例如锁等待和线程池连接等待。
对于大型网站而言,由于需要大量的服务器资源,其性能优化的目标通常是针对QPS来进行的,大型网站通常跨地区,跨国家,甚至跨洲,网络时间消耗占据90%的时间总消耗,所以优化服务器QPS目的是提升处理能力.优化PT通常不会在服务器上下功夫.通常以浏览器端(减少HTTP请求\预加载\延迟加载\异步化)和网络处理架构(如DNS\TCP\CDN)的优化作为主要方案
3.吞吐量(Throughput)
吞吐量是指单位时间内系统能处理的请求数量，体现系统处理请求的能力，这是目前最常用的性能测试指标。
QPS（每秒查询数）、TPS（每秒事务数）是吞吐量的常用量化指标，另外还有HPS（每秒HTTP请求数）。
跟吞吐量有关的几个重要是：并发数、响应时间。
QPS（TPS），并发数、响应时间它们三者之间的关系是：
QPS（TPS）= 并发数 / 平均响应时间
4.页面浏览量(PV)
PV即Page View的简写, 即页面浏览量或点击量，用户每次刷新即被计算一次。
单台服务器每天PV计算：
公式1：每天总PV = QPS * 3600 * 6
公式2：每天总PV = QPS * 3600 * 8
5.网站独立访客(UV)
UV即Unique Visitor的简写，访问您网站的一台电脑客户端为一个访客。00:00-24:00内相同的客户端只被计算一次
服务器数量。
机器：峰值时间每秒QPS / 单台机器的QPS = 需要的机器
机器：ceil( 每天总PV / 单台服务器每天总PV )
- 峰值QPS和机器计算公式
QPS ( Query per Second ）表示每秒处理完成的请求数，是衡量系统吞吐量大小或者系统处理能力的指标，服务器的 QPS 越高，提供服务需要的机器就越少。每个系统都有自己的峰值QPS 表示系统最大的吞吐量。在做容量规划时，峰值 QPS 作为容量规划的主要因子，来计算需要多少台机器。可以根据一定的数学计算得出业务访问需要多少QPS 再除以 Peak QPS, 就可以得出需要机器的数量。
原理：每天80%的访问集中在20%的时间里，这20%时间叫做峰值时间
公式：( 总PV数 * 80% ) / ( 每天秒数 * 20% ) = 峰值时间每秒请求数(QPS)
机器：峰值时间每秒QPS / 单台机器的QPS = 需要的机器
例子：
每天300万PV的在单台机器上，这台机器需要多少QPS？
答：( 3000000 * 0.8 ) / (86400 * 0.2 ) = 139 (QPS)
如果一台机器的QPS是58，需要几台机器来支持？
答：139 / 58 = 3
7.关键帧时间
关键帧时间是一个时间指标——关键帧技术测算而来，关键帧技术结合图像分析、人脑视觉感知、统计学，把页面加载过程中最符合用户视觉意识中“该网站加载完成了”的时间点定义出来，该时间点就是关键帧时间。
8.页面首字节时间
TTFB (Time To First Byte)-首字节时间，是指网络请求从被发起到从服务器接收到第一个字节这段时间，它包含了 TCP连接时间，发送HTTP请求时间和获得响应消息第一个字节的时间，是能够反映服务端响应速度的重要指标。
First Byte表示首字节响应时间,该时间可以综合反映出当前连接的网络状况和服务器的响应处理速度
9.资源请求数
资源请求数（Total number of Requests）是指：一个页面加载完成时，向服务器端发起的请求的总数。
80%的响应时间花在下载网页内容(images,stylesheets, javas, s, flash等)。合并文件以减少请求次数可以减少网络建立连接的耗时，提高传输效率，从而加快页面渲染进度。