Web性能分析工具WebpageTest详解
Posted 前端之巅
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了Web性能分析工具WebpageTest详解相关的知识，希望对你有一定的参考价值。
Web 性能与用户体验很像，我们很难通过在用户体验中随便加点东西就能让网站变得“漂亮”起来。用户体验并不是某种附加组件，而是由一系列基本决策组成的。用户体验意味着你需要花时间了解用户需求，并设计出适合他们的应用程序。这也不是能够一蹴而就的，而是一个持续的过程，Web 性能也是一样。
通过在性能方面添加一点东西让原本很慢的网站快起来是很困难的。的确，我们可以做一些事情，比如压缩图像、缩小文件、使用 font-display:swap，但创建一个专注于性能的网站需要从一开始就打好基础。三天打鱼两天晒网是不行的，这是一个持续的过程，需要进行持续的监控。
WebpageTest 可以让你在真实的设备上测试网站的性能，比如在 iPad、iPhone、Galaxy S7 甚至是 Moto G4 等低配置设备上进行测试，还可以设置各种网络连接速度，从光纤到蜂窝网络。
你可能会对 WebpageTest 提供的众多选项感到困惑，所以我们尽量保持简单。在测试时请按照最低标准来测，因为一个网站如果在网速慢的情况下具有足够快的速度，那么在网络快的时候依然是快的。Web 最大的资产是可达性，因为它们没有应用程序商店，只有链接，而高性能的网站可以更好地到达全球各地。
为了简单起见，我们只看简易模式：https://webpagetest.org/easy。
这个模式表示在“慢速 3G”网络上使用 Moto G4。是什么让这个设置变得这么慢？
这是一个低配置的设备。与现代 iPhone 相比，Moto G4 解析 javascript 的速度要慢得多。
带宽速度只有 400kbps。相比之下，4G 的速度为 9mbps。
延迟是 400 毫秒。一个往返时间为 400 毫秒，相当残酷。
不过不要太关注带宽，虽然 400kbps 并不理想，但与延迟相比，带宽并不是主要的问题。
带宽是用来衡量网络往返一次可以发送多少数据的指标，延迟是指发送数据一个往返所需的时间。带宽相当于管道的宽度，而延迟是长度。
我们很容易在带宽问题上纠结。更大的带宽意味着更快的下载速度吗？只有当你的网站足够大或者提供像 Netflix 那样的内容服务时，带宽才是个问题。如果你的网站的关键路径中只包含 300kb 的资产，也就是 300kb 的 html、CSS 和 JavaScript，那么带宽就不成问题，延迟才是问题所在。
移动网络因高延迟而臭名昭著。“慢速 3G”一个往返的延迟为 400 毫秒，这意味着客户端从服务器接收数据需要 400 毫秒，不管流量有多大。更糟糕的是，初始 HTTP 连接需要四次往返！这意味着你的网站在这 1.6 秒的时间里无法加载任何东西。
延迟已成事实，但我们可以在 HTTP/2、CDN 和减少请求链方面进行优化。延迟是性能的杀手，移动网络满是高延迟，所以务必要进行相应的测试。
“简易模式”为你提供了测试结果概要和三次运行结果，看起来像这样：
这个表格提供了一系列重要的指标，我最喜欢的指标是：
First Byte 告诉你服务器在发送数据的第一个字节之前经历了多长时间。在存在高延迟、长服务器进程或缺乏 CDN 缓存的情况下，这个时间往往会很长。
Start Render 是指用户从空白页面到屏幕上开始显示内容的时间。这并不是指一定能看到内容，它也可能只是个标题，因为其他内容还在加载中。
First Interactive 就有点奇怪了。根据 Lighthouse 的说法，First Interactive 是指“一个页面可以提供最低限度的交互能力”。也就是说，此时浏览器的主线程处于空闲状态，但并不代表线程会一直保持空闲。我们稍后会讲解“Time to Interactive”。
我没有提到的一个经常出现的指标是“加载时间”。“加载时间”是 5.8 秒，但它并不能代表全部。WebpageTest 文档指出：“加载时间是从用户开始打开页面到文档完成（Document Complete）事件的时间（通常是指所有页面内容都已加载完毕）。”
“文档完成”事件指的是 window.onload 事件。根据 MDN 的描述：“加载事件会在文档加载过程结束时触发。此时，文档的所有对象都在 DOM 中，并且所有图像、脚本、链接和子帧都已完成加载”。
在触发这个事件之前，整个页面可能已经是可用的，但延迟的脚本和图像会让这个指标变大，即使页面似乎已经是可用的。
要了解其中发生了什么，我们需要用到“Flimstrip View”。
我很少会去关注概要，可能只会看一眼“First Byte”，确保没有发生什么奇怪的事情，然后就会进入 Filmstrip View。
右侧是跳转到“Filmstrip View”的链接，这可能是你最经常用到的页面。Filmstrip View 为你提供的不仅仅是数字，它还会告诉你在页面加载期间都发生了什么。
这个可滚动的缩略图集合显示了页面加载的过程，你可以修改缩略图显示的间隔。默认为 0.5 秒，但你可以将其设置为 0.1 秒，甚至是 60FPS。我通常选择 0.1 秒，因为这样可以更容易看到网络瀑布（请看下一节）。
下面是一个网络瀑布。请注意，当你滚动胶片时，垂直红条也会跟着移动。
这样你就可以将网络资源的加载过程与视觉上的变化关联起来。当你滚动已加载的资源时，就会看到相应的变化，所以可以使用这个方法来查找页面加载指标。
First Paint、First Contentful Paint、First Meaningful Paint 和 Time to Interactive
大量的页面加载指标有时候会让人摸不着头脑，我们应该关注页面加载的整体性能，而不用去操心每个具体的指标。有一些正式的指标可用于了解页面加载的进度：
First Paint 与 Start Render 非常相似，也就是指有东西出现在页面上，而不是指整个页面都加载好了。
First Contentful Paint 会告诉你浏览器何时渲染 DOM 的第一个元素。
First Meaningful Paint 会告诉你页面的主要内容何时加载完成。
Time to Interactive 是指页面何时变得可交互。可交互是指页面已经包含了有用的内容，可见的元素已经注册了事件处理器，并可以在 50 毫秒内对用户的操作做出响应。这个指标可以用来衡量网站的渲染是不是够快，执行大量 JavaScript 会阻塞主线程。
网络瀑布会告诉你这些指标是何时发生的。在网页上显示部分内容或主要内容是可以通过肉眼看出来的，但如何知道页面何时是可交互的？网络瀑布就提供了这方面的信息。
网络瀑布的底部提供了有关浏览器主线程活动的信息。主线程负责处理 UI 更新，如果线程被阻塞，就无法进行 UI 更新，页面就被冻住了。
上面这张图中的红块表示主线程被阻塞了。对于包含大量 JavaScript 的网站来说，这种情况是很常见的，但造成线程阻塞的不仅仅是 JavaScript。在上面的例子中，我们可以在一大块紫色下面看到一大块红色。这个紫色代表屏幕的布局。这是什么导致的？让我们来看看整个网络瀑布。
在 5.4 秒之前，完成了一个 Web 字体的加载，然后立即出现一堆紫色阻塞了线程。这是因为使用了 font-display:swap，浏览器必须使用自定义 Web 字体来布局页面，这是一个密集而短暂的过程。请记住，我们现在是在 Moto G4 上进行测试，但在现代设备上就不会有这个问题。
过了这个点，主线程图就很变得很清晰了。也就是说，我们可以认为网页在 5.5 秒的时候是可交互的。但这并不是一个完全有意义的指标。
Time to Interactive 其实是有点蹊跷的。乍一看，在出现这个指标之前，网站似乎是不可交互的，但情况并非总是如此。在上面的示例中，线程在前后几秒钟内是空闲的，被阻塞的部分就像是在打嗝。这在服务器端渲染的网站中是很常见的，如下所示：
这个使用服务器端渲染的 JavaScript 网站的 First Meaningful Paint 是 2.8 秒，但线程在两个不同的时间段被阻塞：在 5 秒和大约 6.7 秒的时候。这意味着用户开始使用页面，但在这些时间间隔内页面是被冻结的。
如果说这个指南教会了你什么，我希望是“单个指标无法代表页面加载性”。“加载时间”并不会告诉你用户何时可以看到内容，First Meaningful Paint 并不会告诉你用户是否可以使用网页，单独使用 Time to Interactive 指标也不是个明智的做法。哪些指标更为重要完全取决于对网站性能的具体要求。
https://frontendnews.io/editions/2018-08-22-a-brief-guide-to-webpagetest
以上是关于Web性能分析工具WebpageTest详解的主要内容，如果未能解决你的问题，请参考以下文章
Web性能优化工具WebPageTest——本地部署（Windows 7版本）