【性能监测】前端性能监测方法总结（非监测平台）

前言

前端性能是考验一个前端攻城狮技术至关重要的一个点。也许很多新生代农民工掌握或了解了一些前端优化的方法，但是在实际的项目工作中却难以一展拳脚。至此，了解优化方法重要，了解性能监测同样重要，正所谓，有病乱投医，你都不知道哪里有性能问题，怎么去进行针对性的优化呢？下面阿彬就为大家总结一下前端性能监测的一些实用方法。

一、谷歌控制台

1. network瀑布路waterfall

地球人都知道，network是查看网页加载资源，以及请求信息的地方。细心的观众就会发现，这里有个叫waterfall的地方，顾名思义，它叫瀑布流，首先我们可以很直观的看到每个请求的时长，点击每个色块之后，又可以请求时间具体花在了哪部分。当你了解了每个颜色以及各项指标的含义，你就可以分析出你网页中的一些网络请求问题。

颜色
瀑中有好几种颜色：浅灰，深灰，橙色，绿色，蓝色
浅灰：查询中
深灰：停滞，代理转发，请求发送
橙色：初始连接
绿色：等待中
蓝色：内容下载

各项指标

Queueing（浅灰）
浏览器将资源放入队列时间，比如：遇到更高优先级的请求或请求并发超过 6 了。
Stalled（深灰）
因放入队列时间而发生的停滞时间。
Proxy negotiation
与代理服务器协商时间。
DNS Lookup（深绿）
DNS 解析时间，浏览器需要将域名转换成 IP。
Initial Connection（橙色）
在浏览器发送请求前，需要建立 HTTP 连接的时间。
SSL（紫色）
如果网站使用了 HTTPS，这个就是浏览器与服务器建立安全性连接的时间。
Request sent
请求发送的时间。
Waiting (TTFB)（绿色）
等待服务端返回数据的时间，这个时间受制于服务端处理性能。
Content Download（蓝色）
浏览器下载资源的时间，这个时间受制于文件大小和带宽。

分析

chrome中的瀑布流可以看到两条线：蓝红两条，蓝线表示DOM加载完成，红线表示页面上所有声明的资源加载完成的时间。
通过瀑布流对资源加载时间的拆分，我们就能观察哪些资源加载耗时较长或造成了堵塞，从而进行优化等。我们可以从以下几个方面考虑优化：

减少所有资源的加载时间。亦即减小瀑布图产品的宽度。瀑布图越窄，网站的访问速度越快
减少请求数量也就是降低瀑布图的高度。瀑布图越矮越好
优化资源顺序，减少首屏打开时间。将绿色的“开始渲染”线向左移。这条线向左移动的越远越好。
合理收敛和发散网站的域名，域名太多导致更多的 HTTP 连接无法复用，域名太少导致超过浏览器限制并等待。
减少 HTTP 请求数，如合理利用客户端缓存，现在前端也有些工具可以合并 JS/CSS 资源等。

2. performance

在谷歌浏览器调式模式下，切换到 performance 选项卡。点击刷新图标（或者Ctrl+Shift+E快捷键）开始分析。

停止后，出现性能分析图。
注意点：
1.需要勾选屏幕快照选项，才会出现如下屏幕快照截图（一般是默认勾选）。
2.整个分析图出现的时间轴就是前面步骤中分析进度条的时间，而默认出现的区域时间轴是首屏加载时间。

如图所示：
（1）以上红色框出的部分（也是整个时间轴）就是前面分析进度条的分析时间。
（2）以上绿色框出的部分是首屏加载时间。
（3）首屏加载时间刻度与选项卡 Summary 的 Total 总时间一致。
（4）如下图可通过左右边界来调整时间轴区域。时间轴区域 2 是时间轴区域 1 的放大版，便于查看时间轴区间的各项指标性能情况。

更多使用详解，可以看看这篇文章详解谷歌浏览器 performance 选项卡

3. Lighthouse （好用推荐！！！）

Lighthouse 是一个开源的自动化工具，用于改进网络应用的质量。
它分别针对网页的Performance、Accessibility、Best Practices、SEO进行检测评分，并给出相应的优化建议，方便站长优化网页的加载速度、搜索引擎排名等。

Performance - 性能检测，如网页的加载速度、响应时间等
Accessibility - 铺助检测，如网页的可访问性问题，HTML代码标签之类的优化等
Best Practices - 实践性检测，如网页安全性，如是否开启HTTPS、网页存在的漏洞等
SEO - 搜索引擎优化检测，如网页title是否符合搜索引擎的优化标准等

操作方法
打开要检测的网页地址
右键检查打开Lighthouse选项卡，在打开的窗口中点击“Generate report”按钮生成检测报告

稍等片刻之后，会给出网页的检测结果以及优化建议

上面的结果显示，该页面性能Performance （如加载速度）打分偏低，并给出了相关的优化提示。

4. 谷歌插件PageSpeed Insights

下载地址：传送门
安装方法：打开谷歌浏览器的扩展程序，将下载的crx文件拖进去即可。
使用方法：
直接在页面上点击右键，然后选择审查元素，找到PageSpeed选项卡。

点击开始分析，稍等片刻就可以看到分析结果啦~

分析
PageSpeed的分析基于一个分为五类的最佳实践列表：

优化缓存——让你应用的数据和逻辑完全避免使用网络
减少回应时间——减少一连串请求-响应周期的数量
减小请求大小——减少上传大小
减小有效负荷大小——减小响应、下载和缓存页面的大小
优化浏览器渲染——改善浏览器的页面布局

二、使用console进行性能测试和计算代码运行时间

1.console.time()配合console.timeEnd()

console.time()配合console.timeEnd()，可以将之间代码的运行时间输出到控制台上。
注意传入相同的参数，相当于计时器的唯一名称。

console.time('计时器');
for (var i = 0; i < 1000; i++) {for (var j = 0; j < 1000; j++) {}
}
console.timeEnd('计时器');

以上代码计算console.time(‘计时器’);和console.timeEnd(‘计时器’);之间的代码块所需要的时间。

2. console.trace()

console.trace()用来追踪函数的调用过程。
在大型项目尤其是框架开发中，函数的调用轨迹可以十分复杂，console.trace()方法可以将函数的被调用过程清楚地输出到控制台上。

3. console.profile();

开发中，我们常常要评估段代码或是某个函数的性能。在函数中手动打印时间固然可以，但显得不够灵活而且有误差。借助控制台以及console.profile()方法我们可以很方便地监控运行性能。
console.time()虽然可以计算代码的运行时间，但是在分析逻辑较为复杂的JavaScript程序，试图从中找出性能瓶颈的时候，console.time()就不适用了 — 深入分析逻辑较为复杂的JavaScript程序的运行就意味着插入大量的console.time()语句，而这无疑是不可接受的。对于复杂逻辑的JavaScript程序调优，正确的方法是使用console.profile()。
使用：在需要开始profile的地方插入console.profile()，在结束profile的地方插入console.profileEnd()即可。以下面的代码为例：
不过console.profile()有兼容性问题，具体可以查看兼容性检查

function doTask(){doSubTaskA(1000);doSubTaskA(100000);doSubTaskB(10000);doSubTaskC(1000,10000);
}function doSubTaskA(count){for(var i=0;i<count;i++){}
}function doSubTaskB(count){for(var i=0;i<count;i++){}
}function doSubTaskC(countX,countY){for(var i=0;i<countX;i++){for(var j=0;j<countY;j++){} }
}
console.profile();
doTask();
console.profileEnd();

4. new date() 或 Perfomance.now

这个办法就比较笨了，但是也能用。
new date() ：

let t1 = new Date()
for (let i = 0; i <= 1000000; i++) {//测试计算机跑完100W次所需要时间
}
console.log('耗时',new Date() - t1);
//输出：耗时 2

Perfomance.now：

let array = [0,1,2,3]
const t0 = performance.now();
for (let i = 0; i < array.length; i++)
{// some code
}
const t1 = performance.now();
console.log(t1 - t0, 'milliseconds');

这两种方法都是用函数执行后的时间戳减去开始时的时间戳，使用起来很相似。但是是有区别的。

高性能API通过其函数 performance.now() 提供对DOMHighResTimeStamp 的访问，该函数返回自页面加载时间（以毫秒为单位），精度最高为 5µs（以分数为单位）。
performance API 提供的功能比仅返回时间戳要多得多。它可以测量导航时间、用户时间或资源时间更多功能。

但是如果我们只是想测试单个函数的性能，因此时间戳就足够了。

三、计算白屏时间(FP)

首屏时间(First Contentful Paint)：是指浏览器从响应用户输入网络地址，到首屏内容渲染完成的时间。

首屏时间 = 首屏内容渲染结束时间点 - 开始请求的时间点

白屏时间是从用户开始请求页面时开始计算到开始显示内容结束，中间过程包括DNS查询、建立TCP链接、发送首个HTTP请求、返回HTML文档、HTML文档head解析完毕。

因此影响白屏时间的因素：网络、服务端性能、前端页面结构设计。

通常认为浏览器开始渲染或者解析完的时间是白屏结束的时间点。所以我们可以在html文档的head中所有的静态资源以及内嵌脚本/样式之前记录一个时间点，在head最底部记录另一个时间点，两者的差值作为白屏时间。

<!DOCTYPE html>
<html lang="en">
<head><meta charset="UTF-8"><meta name="viewport" content="width=device-width, initial-scale=1.0"><title>白屏时间计算-常规方法</title><script>window.pageStartTime = Date.now()</script><link rel="stylesheet" href="https://b-gold-cdn.xitu.io/ionicons/2.0.1/css/ionicons.min.css"><link rel="stylesheet" href="https://b-gold-cdn.xitu.io/asset/fw-icon/1.0.9/iconfont.css"><script>window.firstPaint = Date.now()console.log(`白屏时间：${window.firstPaint - window.pageStartTime}`)</script>
</head>
<body><div>这是常规计算白屏时间的示例页面</div>
</body>
</html>

白屏时间 = window.firstPaint - window.pageStartTime
这个方法有个缺点：无法获取解析HTML文档之前的时间信息。

四、计算首屏时间(FCP)

首屏时间要知道两个时间点：开始请求时间点和首屏内容渲染结束时间点。开始请求时间点和白屏时间一样，下面就是如何拿到首屏内容渲染结束时间点。
首屏结束时间应该是页面的第一屏绘制完，但是目前没有一个明确的API可以来直接得到这个时间点，所以我们只能智取，比如我们要知道第一屏内容底部在HTML文档的什么位置，那么这个第一屏内容底部，也称之为首屏线。
计算首屏时间常用方法：

1. 首屏模块标签标记法

在HTML文档中对标记首屏内容的结束位置。只适用于不需要通过拉取数据以及不考虑图片等资源加载的情况。

<!DOCTYPE html>
<html lang="en">
<head><meta charset="UTF-8"><title>首屏</title><script type="text/javascript">window.pageStartTime = Date.now();</script><link rel="stylesheet" href="common.css"><link rel="stylesheet" href="page.css">
</head>
<body><!-- 首屏可见模块1 --><div class="module-1"></div><!-- 首屏可见模块2 --><div class="module-2"></div><script type="text/javascript">window.firstScreen = Date.now();</script><!-- 首屏不可见模块3 --><div class="module-3"></div><!-- 首屏不可见模块4 --><div class="module-4"></div>
</body>
</html>

首屏时间 = firstScreen- performance.timing.navigationStart

2、统计首屏内加载最慢的图片完成加载的时间

通常首屏内容加载最慢的就是图片资源，因此我们会把首屏内加载最慢的图片的时间当做首屏的时间。

首屏时间 = 加载最慢的图片的时间点 - performance.timing.navigationStart

3、自定义模块内容计算法

由于统计首屏图片完成加载的时间比较复杂。因此我们在业务中通常会通过自定义模块内容，来简化首屏时间。如下面的做法：

忽略图片等资源加载情况，只考虑页面主要DOM
只考虑首屏的主要模块，而不是严格意义首屏以上的所有内容。