名词解释

APM:Application Performance Management，应用性能管理
blank:白屏时间，指浏览器从响应用户输入网址地址，到浏览器开始显示内容的时间，blankTime = responseEnd - navigationStart
fp:First Paint Time, 首次渲染时间,getPaintTime('first-paint')
fcp:First Contentful Paint Time, 首次内容渲染时间,getPaintTime('first-contentful-paint')
fmp:First Meaning Pain，Google 定义它为「是否有用？」的时间点，社区中常有这么几种方式进行「相对准确」的计算 FMP，所谓相对准确，是相对于实际项目而言。

主动上报：开发者在相应页面的「Meaning」位置上报时间

权重计算：根据页面元素，计算权重最高的元素渲染时间

趋势计算：在 render 期间，根据 dom 的变化趋势推算 FMP 值

domready:首次可交互时间,浏览器完成所有 HTML 解析并且完成 DOM 构建，此时浏览器开始加载资源,domreadyTime = domInteractive - navigationStart
firstscreen:首屏时间，如果页面首屏有图片，首屏时间 = 首屏图片全部加载完毕的时刻 - window.performance.timing.navigationStart
；如果页面首屏没有图片，首屏时间 = 页面处于稳定状态前最后一次 dom 变化的时刻 - window.performance.timing.navigationStart
load:页面完全加载时间，loadTime = 首次渲染时间 + DOM 解析耗时 + 同步 JS 执行 + 资源加载耗时

function getPaintTime(type) {
    if (utils.isFunction(performance.getEntriesByType)) {
      const paint = performance.getEntriesByType('paint');
      if (utils.isArray(paint)) {
        const filter = paint.filter(p => {
          return p.name === type;
        });
        if (filter.length === 0) {
          return 0;
        } else {
          return filter[0].startTime;
        }
      }
    }
    return 0;
  }

需要解决的问题

如何获取及展示性能数据，即需要有现状性能大盘，优化后数据提升等数据
如何制定性能标准，即性能优化的目标是什么，达到多少可以满足用户的需求
众多不达标页面中，如何给出最需要优化的页面，即给出优化完后，见效快的页面

获取性能数据及展示

浏览器获取

以chrome为例，打开开发者模式，可以看到每个请求的网络耗时以及相应的页面耗时

queue：表示在队列中等待的时间，包括以下时间

请求已被渲染引擎推迟，因为该请求的优先级被视为低于关键资源（例如脚本/样式）的优先级。图像经常发生这种情况。

请求已被暂停，以等待将要释放的不可用 TCP 套接字。

请求已被暂停，因为在 HTTP 1 上，浏览器仅允许每个源拥有六个 TCP 连接。

生成磁盘缓存条目所用的时间（通常非常迅速）
如下图中各个间隙的时间

stall:请求等待发送所用的时间。可以是等待 Queueing 中介绍的任何一个原因。此外，此时间包含代理协商所用的任何时间

DNS Lookup: 执行 DNS 查询所用的时间。页面上的每一个新域都需要完整的往返才能执行 DNS 查询。

Initial Connection:建立连接所用的时间，包括 TCP 握手/重试和协商 SSL 的时间。

SSL:完成 SSL 握手所用的时间。

Request Sent:发出网络请求所用的时间。通常不到一毫秒。

Waiting (TTFB):等待初始响应所用的时间，也称为至第一字节的时间。此时间将捕捉到服务器往返的延迟时间，以及等待服务器传送响应所用的时间。

Content Download: 接收响应数据所用的时间

命令行获取耗时时间

curl获取请求的各个阶段耗时

time_namelookup: DNS解析时间

time_connect：tcp建联时间

time_appconnect：SSL/SSH 等上层协议建立连接的时间，比如 connect/handshake 的时间。

time_redirect：从开始到最后一个请求事务的时间

time_pretransfer：从请求开始到开始传输的时间

time_total：这次请求花费的全部时间

curl -o /dev/null -w 'time_namelookup:  %{time_namelookup}\ntime_connect:  %{time_connect}\ntime_appconnect:  %{time_appconnect}\ntime_redirect:  %{time_redirect}\ntime_pretransfer:  %{time_pretransfer}\ntime_starttransfer:  %{time_starttransfer}\n----------\ntime_total:  %{time_total}\n' -s 'http://www.baidu.com'
输出为：
time_namelookup:  0.004559
time_connect:  0.009082
time_appconnect:  0.044093
time_redirect:  0.000000
time_pretransfer:  0.044128
time_starttransfer:  0.050661
----------
time_total:  0.050772

一个美化版本的curl--->httpstat,pip install httpstat

httpstat https://www.baidu.com
Connected to 61.135.169.125:443 from 192.168.1.5:51436

HTTP/1.1 200 OK
Accept-Ranges: bytes
Cache-Control: private, no-cache, no-store, proxy-revalidate, no-transform
Connection: keep-alive
Content-Length: 2443
Content-Type: text/html
Date: Sat, 18 Jan 2020 06:20:28 GMT
Etag: "588603e6-98b"
Last-Modified: Mon, 23 Jan 2017 13:23:50 GMT
Pragma: no-cache
Server: bfe/1.0.8.18
Set-Cookie: BDORZ=27315; max-age=86400; domain=.baidu.com; path=/

Body stored in: /var/folders/2f/dsc9h45518z77hmfvw2djg2h0000gn/T/tmp8wLyay

  DNS Lookup   TCP Connection   TLS Handshake   Server Processing   Content Transfer
[     4ms    |       9ms      |     27ms      |        6ms        |        0ms       ]
             |                |               |                   |                  |
    namelookup:4ms            |               |                   |                  |
                        connect:13ms          |                   |                  |
                                    pretransfer:40ms              |                  |
                                                      starttransfer:46ms             |
                                                                                 total:46ms

埋点上报

web端或者客户端埋点上报到APM服务，常用的APM工具有:

Pinpoint

zipkin

skywalking

cat

elasticserch APM

如何制定性能标准(仅供参考)

从「用户感知时间长度」可以为用户感知交互做以下分级：

立马返回，无任何延时 < 0.2s

流畅 0.2s ~ 1.0s

可用 1.0s ~ 2.0s

丢帧 2.0s ~ 3.0s

卡顿 3.0s ~ 5.0s

阻塞 > 5.0s，用户可能无法忍受网站，需要给用户一些提示，如正在处理，请稍后。。。；这种场景最好同步转异步，完成后给用户发送消息提示，让用户直接查看结果
因此可以根据自己网站情况制定相应的目标性能，如平均值、50分位值、90分位值等

最需要优化的页面

从用户角度看，影响每个用户体验的是页面耗时，如果以N秒为目标值，那么用户在此页面上是U秒，那么用户浪费(N-S)秒的时间，时间越长约需要优化

对于整个网站来说，访问量越大（时间Ts内访问量为A次），越需要优化

另外每个页面也有重要程度，比如KeyPerson关注度等，因此给定一个系数α;
因此可以粗略给出一个impact值（单位为s），即 impact = $(\sum_{k=1}^T(0\ if\ U<=S\ else\ (U-S)))*α$