diff --git a/13-前端面试/02-前端性能优化/01-性能优化的指标和工具.md b/13-前端面试/02-前端性能优化/01-性能优化的指标和工具.md index 5e46906..b6334f3 100644 --- a/13-前端面试/02-前端性能优化/01-性能优化的指标和工具.md +++ b/13-前端面试/02-前端性能优化/01-性能优化的指标和工具.md @@ -19,20 +19,24 @@ 我们可以看到淘宝网站的一些指标： - 资源量是 1.3M。 - - DOM加载完成时间（DOMContentLoaded）：511ms。这是一个很关键的指标。 - - 其他资源的总加载时间是 1.05秒。 +我们再来对比一下京东的： + +![](http://img.smyhvae.com/20210116-1357.png) + + + ### 保存快照 network里的信息挺多，我们可以将其保存下来，留着以后做分析、做对照。 ![](http://img.smyhvae.com/20210115-1723.png) -如上图所示，我们可以在 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格式，用户保存性能测试的结果。里面的 ![](http://img.smyhvae.com/20210115-1733.png) - ### 瀑布图 Waterfall ![](http://img.smyhvae.com/20210115_1618.png) @@ -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张，让肉眼误认为眼前的画面在动。 + +![](http://img.smyhvae.com/20210107_2115.gif) 持续滑动的过程中，如果页面输出到显示器的帧率低于60帧/秒，则人眼会感觉卡顿。 @@ -143,7 +149,7 @@ Chrome官方给我们提供了下面这个网站，用于观察 FPS 效果： - -我们可以借助第三方的 [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 报告之后，我们来看看报告里的几个重点指标。 +![Xnip2021-01-16_13-14-24](/Users/meiyamin/Downloads/前端性能优化/image/Xnip2021-01-16_13-14-24.png) + 1、摘要里的参数： - First Byte：第一个请求的响应时间。可以反映后台的处理能力，以及网络回路的情况。 - - Start Render：从白屏到首次渲染的时间。 - - Speed Index：速度指数。 - - **Total Blocking Time**：页面被阻塞，导致用户不能交互的累计时间。 +![Xnip2021-01-16_13-15-04](/Users/meiyamin/Downloads/前端性能优化/image/Xnip2021-01-16_13-15-04.png) + 2、详情里的参数：**First View**。 First View展示的是：首次访问时，总的加载时间。这里面提供的瀑布图，比 chrome DevTools里提供的更为详细。 -点击进入 First View 的详情之后，可以看到：所有的资源请求，都会在这里列出来。 +点击进入 First View 的详情之后，可以看到：所有的资源请求，都会在这里列出来。如下： + +![Xnip2021-01-16_13-16-11](/Users/meiyamin/Downloads/前端性能优化/image/Xnip2021-01-16_13-16-11.png) + + - page is Interactive：页面在加载的过程中，大部分时间段，用户都是可以交互的。这是非常有用的一个指标。 - - Brower Main thread：浏览器主线程的占用情况。可以看看空闲的时间多不多。 - - CPU Utilization：CPU的使用情况。 - - 多张图片的资源请求。 -上图中，我们可以看到：多张图片的开始请求时间都是相同的。也就是说，如果让资源做**并行加载**，我们就可以加大地减少加载时间，最终所消耗的时间就由最大的图片来决定。这是一个很好的优化技巧，至于具体是怎么实现的，可以自行了解。 +![Xnip2021-01-16_13-16-50](/Users/meiyamin/Downloads/前端性能优化/image/Xnip2021-01-16_13-16-50.png) + +上图中，我们可以看到：多张图片的开始请求时间都是相同的。也就是说，如果让资源做**并行加载**，我们就可以加大地减少加载时间，**最终所消耗的时间就由最大的图片来决定**。这是一个很好的优化技巧，至于具体是怎么实现的，可以自行了解。 -我们看到，有一部分的请求，被高亮出来了： +另外，我们看到，有一部分的请求，被高亮出来了： ![](http://img.smyhvae.com/20210115-2250.png) @@ -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 +## 总结 + + + + +