add: 优化指标和工具
This commit is contained in:
qianguyihao
parent
70fe324a5b
commit
ba5f4b4b7a
@ -19,20 +19,24 @@
|
||||
我们可以看到淘宝网站的一些指标：
|
||||
|
||||
- 资源量是 1.3M。
|
||||
|
||||
- DOM加载完成时间（DOMContentLoaded）：511ms。这是一个很关键的指标。
|
||||
|
||||
- 其他资源的总加载时间是 1.05秒。
|
||||
|
||||
我们再来对比一下京东的：
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
### 保存快照
|
||||
|
||||
network里的信息挺多，我们可以将其保存下来，留着以后做分析、做对照。
|
||||
|
||||
|
||||
|
||||
如上图所示，我们可以在 network 的空白处右键，选择“Save all as HAR with content”，讲 network 信息保存为 HAR文件格式。
|
||||
如上图所示，我们可以在 network 的空白处右键，选择“Save all as HAR with content”，将 network 信息保存为 **HAR**文件格式。
|
||||
|
||||
HAR是一种标准的Web格式，用户保存性能测试的结果。里面的数据是json格式。
|
||||
**HAR是一种标准的Web格式，用户保存性能测试的结果。里面的数据是json格式。**
|
||||
|
||||
我们可以使用第三方的 HAR 分析软件来打开 HAR 文件，比如：
|
||||
|
||||
@ -44,7 +48,6 @@ HAR是一种标准的Web格式，用户保存性能测试的结果。里面的
|
||||
|
||||
|
||||
|
||||
|
||||
### 瀑布图 Waterfall
|
||||
|
||||
|
||||
@ -75,11 +78,11 @@ HAR是一种标准的Web格式，用户保存性能测试的结果。里面的
|
||||
|
||||
（3）请求和响应：
|
||||
|
||||
- Request sent：到这一步，开始真正地请求资源。
|
||||
- Request sent：到这一步，真正开始请求资源。
|
||||
|
||||
- Waiting（**TTFB**）：资源从请求到响应，有一个等待的时间。
|
||||
|
||||
- Content Download：资源的下载时间。如果值月太大，表明下载时间太长。有些资源会造成阻塞，导致网页的整体加载时间过长，让用户等待太久。
|
||||
- Content Download：收到响应后，资源的下载时间。如果值越大，表明下载时间越长。有些同步加载的资源会造成阻塞，导致网页的整体加载时间过长，让用户等待太久。
|
||||
|
||||
|
||||
**TTFB** 是一个很重要的指标，它表示的是：请求发出到响应，到底要经历多久。TTFB 可以给我们一个很直观的感受，我们网站的请求和响应到底是快还是慢，很大程度上是由 TTFB 决定。
|
||||
@ -92,7 +95,7 @@ HAR是一种标准的Web格式，用户保存性能测试的结果。里面的
|
||||
|
||||
**2、纵向看**：（主要看两点）
|
||||
|
||||
（1）看资源与资源之间的联系：如果发生阻塞，说明资源可能是串行地按顺序加载。可以按需要适当调整为并行。
|
||||
（1）看资源与资源之间的联系：如果发生阻塞，说明资源可能是串行地按顺序加载。可以**按需要适当调整为并行**。
|
||||
|
||||
（2）看关键的时间节点。Waterfall 中有**两根时间线**：蓝色的线是 DOM 加载完成的时间，红色的线是所有资源加载完成的时间。
|
||||
|
||||
@ -104,7 +107,7 @@ HAR是一种标准的Web格式，用户保存性能测试的结果。里面的
|
||||
|
||||
关于交互体验的性能，我们需要关注的是：
|
||||
|
||||
- 交互动作的响应时间要短：比如点击按钮后的弹窗、在搜索框里输入关键字后的搜索结果。
|
||||
- 交互动作的**响应时间**要短：比如点击按钮后的弹窗、在搜索框里输入关键字后的搜索结果。
|
||||
|
||||
- 页面滚动要流畅：可以查看 FPS 帧率。
|
||||
|
||||
@ -114,11 +117,14 @@ HAR是一种标准的Web格式，用户保存性能测试的结果。里面的
|
||||
|
||||
这里首先科普两个概念：
|
||||
|
||||
- 刷新率：显示器每秒有多少帧画面。大多数显示器的刷新率是60帧/秒。
|
||||
- 刷新率：显示器每秒有多少帧画面。大多数显示器的刷新率是60帧/秒（即60hz）。
|
||||
- 帧率（FPS：frames per second）：视频或者动画的内容本身，每秒有多少帧。由显卡输出帧率。
|
||||
|
||||
- 帧率（FPS：frames per second）：视频或者动画的内容本身，每秒有多少帧。
|
||||
上面的两个参数中，不要把「刷新率」和「帧率」弄混了。「刷新率」是屏幕的参数，「帧率」是图像、视频等内容的参数。人眼最终看到的效果，是以最低的参数为准的。
|
||||
|
||||
上面的两个参数中，人眼最终看到的效果，是以最低的参数为准的。
|
||||
目前，市场主流手机和电脑屏幕的刷新率基本都是60Hz，即每秒显示60帧画面。也就是说，当我们在使用手机的时候，本质上是手机在连续播放一张张静态图片，每秒播放60张，让肉眼误认为眼前的画面在动。
|
||||
|
||||
|
||||
|
||||
持续滑动的过程中，如果页面输出到显示器的帧率低于60帧/秒，则人眼会感觉卡顿。
|
||||
|
||||
@ -143,7 +149,7 @@ Chrome官方给我们提供了下面这个网站，用于观察 FPS 效果：
|
||||
|
||||
- <http://googlesamples.github.io/web-fundamentals/tools/chrome-devtools/rendering-tools/forcedsync.html>
|
||||
|
||||
我们可以借助第三方的 [chrome 插件]()来查看 fps参数。
|
||||
如果实在想要看fps，我们可以借助第三方的 [chrome 插件]()来查看 fps参数。
|
||||
|
||||
## 用 RAIL 模型测量性能
|
||||
|
||||
@ -239,6 +245,16 @@ RAIL 模型是Google提出的可以量化性能的测量**标准**。我们做
|
||||
|
||||
## 使用Chrome DevTools 分析性能
|
||||
|
||||
现在主流的性能测量工具：
|
||||
|
||||
- Chrome DevTools：开发调试、分析性能。
|
||||
|
||||
- Lighthouse 网站整体质量评估。
|
||||
|
||||
- WebPageTest：给网站提供多个地点的测试，以及全面的性能报告。
|
||||
|
||||
这一段，我们先来讲一讲 Chrome DevTools 。
|
||||
|
||||
大家平时在用 Chrome DevTools 的时候，一般使用来开发调试、查看 DOM、css、接口请求等，但其实，这个工具非常强大。
|
||||
|
||||
### size：文件大小分析
|
||||
@ -322,15 +338,7 @@ Timing参数中，尤其注意看`DCL`（DOMContentLoaded），即DOM加载完
|
||||
|
||||
## 使用 WebPageTest 评估网站性能
|
||||
|
||||
现在主流的性能测量工具：
|
||||
|
||||
- Chrome DevTools：开发调试、分析性能。
|
||||
|
||||
- Lighthouse 网站整体质量评估。
|
||||
|
||||
- WebPageTest：给网站提供多个地点的测试，以及全面的性能报告。
|
||||
|
||||
这一段，我们先来讲一讲 WebPageTest。
|
||||
|
||||
程序员经常说的有句话是：“我这儿能打开啊。我这儿不报错呀。”大家应该都懂这个梗，这就是为什么，我们要借助第三方的测试工具，而不仅仅只是自己电脑上访问正常就ok了。
|
||||
|
||||
@ -369,34 +377,38 @@ JD网站性能测试报告：
|
||||
|
||||
拿到 WebPageTest 报告之后，我们来看看报告里的几个重点指标。
|
||||
|
||||
|
||||
|
||||
1、摘要里的参数：
|
||||
|
||||
- First Byte：第一个请求的响应时间。可以反映后台的处理能力，以及网络回路的情况。
|
||||
|
||||
- Start Render：从白屏到首次渲染的时间。
|
||||
|
||||
- Speed Index：速度指数。
|
||||
|
||||
- **Total Blocking Time**：页面被阻塞，导致用户不能交互的累计时间。
|
||||
|
||||
|
||||
|
||||
2、详情里的参数：**First View**。
|
||||
|
||||
First View展示的是：首次访问时，总的加载时间。这里面提供的瀑布图，比 chrome DevTools里提供的更为详细。
|
||||
|
||||
点击进入 First View 的详情之后，可以看到：所有的资源请求，都会在这里列出来。
|
||||
点击进入 First View 的详情之后，可以看到：所有的资源请求，都会在这里列出来。如下：
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
- page is Interactive：页面在加载的过程中，大部分时间段，用户都是可以交互的。这是非常有用的一个指标。
|
||||
|
||||
- Brower Main thread：浏览器主线程的占用情况。可以看看空闲的时间多不多。
|
||||
|
||||
- CPU Utilization：CPU的使用情况。
|
||||
|
||||
- 多张图片的资源请求。
|
||||
|
||||
上图中，我们可以看到：多张图片的开始请求时间都是相同的。也就是说，如果让资源做**并行加载**，我们就可以加大地减少加载时间，最终所消耗的时间就由最大的图片来决定。这是一个很好的优化技巧，至于具体是怎么实现的，可以自行了解。
|
||||
|
||||
|
||||
上图中，我们可以看到：多张图片的开始请求时间都是相同的。也就是说，如果让资源做**并行加载**，我们就可以加大地减少加载时间，**最终所消耗的时间就由最大的图片来决定**。这是一个很好的优化技巧，至于具体是怎么实现的，可以自行了解。
|
||||
|
||||
|
||||
我们看到，有一部分的请求，被高亮出来了：
|
||||
另外，我们看到，有一部分的请求，被高亮出来了：
|
||||
|
||||
|
||||
|
||||
@ -406,8 +418,6 @@ First View展示的是：首次访问时，总的加载时间。这里面提供
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
### 局域网部署 WebPageTest 工具
|
||||
|
||||
如果我们开发的页面，还没有上线，公网则无法访问。这个时候我们也想通过WebPageTest看看网站的性能，那要怎么办呢？
|
||||
@ -439,9 +449,9 @@ lighthouse 是 chrome 浏览器的一个性能测量工具。我们先来看看
|
||||
|
||||
Lighthouse 跑分里，最重要的两个指标如下：
|
||||
|
||||
- First Contentful Paint：从白屏到第一次出现内容的时间。我们可以看到，上面提供了一些加载过程的截图，10屏里如果只有1到2屏是白屏，说明体验还是可以的。
|
||||
- **First Contentful Paint**：**从白屏到第一次出现内容的时间。**我们可以看到，上面提供了一些加载过程的截图，10屏里如果只有1到2屏是白屏，说明体验还是可以的。
|
||||
|
||||
- Speed Index：速度指数。
|
||||
- **Speed Index**：速度指数。
|
||||
|
||||
我们不需要关心这个指数是怎么来的，因为背后涉及一套很复杂的公式，我们暂时只需关注这个数值。
|
||||
|
||||
@ -657,6 +667,12 @@ Connection type changed from 4g to 3g
|
||||
|
||||
|
||||
|
||||
## 总结
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Loading…
Reference in New Issue
Block a user