30 工具：最容易被忽视的工具和定位问题路径
你好，我是三桥。
之前的课程我们一直在分析前端页面的问题，每一次分析，都会有工具的出现。今天我们就来说说这些前端辅助工具，看看在使用这些工具的时候，有哪些被我们忽视但又能事半功倍的小细节。
我们将以谷歌浏览器的开发者工具为例进行讲解。检查性能和用户体验问题的模块包括网络、Lighthouse、性能。
网络模块
开发者工具有很多模块，但前端同学最常用的是“元素”和“网络”模块，也就是下图中红框一的部分。
图中红框2部分是统计当前页面加载资源的情况，包含六种统计信息。
第一个是 当前请求总数的统计。
请求总数可以帮助我们分析用户访问资源的数量情况。例子中通过移动设备访问时，初始化页面请求了300多个资源。以我的判断，这里的请求数量有些过多。我们在之前的课程中提到过，资源加载过多会影响网页打开速度，尤其是FCP和LCP等指标都会受影响，所以这里是存在优化空间的。
第二是 已传输和已加载资源的总大小。
图中显示已传输2.8MB，已加载资源5.5MB。这两个数据可以帮助我们判断前端页面是否存在大的资源，因为这可能会影响页面加载速度。
第三是 完成时间。
完成时间是指最后一次发生请求的时间。这里注意，如果当前页面持续进行请求动作，即使页面打开后没有用户互动，程序定时发起的埋点统计请求也会使完成时间持续累积。
最后，显示了 DOMContentLoaded 和加载时间。 DOMContentLoaded 是所有DOM元素加载完毕的时间，加载时间是 Load 事件的时间。这两个时间只作为参考，我们主要参考WebVitals指标。
总的来说，这六种统计可以帮助我们初步判断前端页面的请求数量、文件大小、加载时间等问题。这些统计信息在开发过程中很重要，但也容易被忽视。
接下来，让我们看看其中一个资源的具体时间情况。
通过步骤1和2，我们可以看到请求时间的详细信息。
每个请求都有三种类型的时间，分别是资源调度、开始连接、请求和响应。
资源调度的时间只有“正在排队”，这表示需要等待多久才发起请求。如果有优先级更高的请求，那么资源可能需要排队。
如果当前请求的协议是HTTP 1.x，TCP连接数可能达到上限，需要等待。
如果视口中资源的排队时间较长，说明资源的优先级较低，无法达到FCP指标的要求。这就需要考虑优化，具体的优化方法在之前的课程中已经学过，你可以参考第26节课。
第二是开始连接，包含三个阶段：已停止、初始连接和SSL。
这些阶段涵盖了从浏览器发起请求到建立连接所需要的时间，包括TCP握手、重试和协商SSL。这意味着在浏览器向第三方服务请求资源前，必须先将域名解析为IP地址。
预解析可以减少开始连接的时间。当同一时刻下，相同域名的前端资源发起请求时都需要建立链接，那么就可以考虑使用预解析DNS。但是，如果增加后效果不佳，那就得不偿失，这时就需要更换其它方案。
所以，开始连接类型时间的优化需要考虑全局资源，包括加载顺序和数量，以判断是否需要增加预解析和预连接。
然后是请求和响应。“正在等待服务器响应”这个时间，实际上就是TTFB时间，是浏览器等待响应的第一个字节的时间，包括一次往返延迟时间和服务器准备响应所用的时间。
如果等待时间过长，就需要排查TTFB的主因。特别是图片资源，如果TTFB时间过长，就要判断是否没有启用CDN。具体的优化方法在之前的课程中已经详细讲解了，在这里就不再详述。
“下载内容”指的是读取文件响应所用的总时长。这个值可以反映用户的网络速度情况，或者是浏览器忙于执行其它任务，导致响应延迟。例如，上图中的3.18秒，正是由于模拟4G网络用户访问导致的下载时长过长。
因此，我们不仅要关注主文档TTFB指标，还要重点关注图片资源TTFB指标和大小。在开发者工具中查看资源的“正在等待服务器响应”和“下载内容”两个时间，对于前端同学排查TTFB和FCP具有重要的参考价值。
灯塔（Lighthouse）
灯塔是谷歌浏览器的一个开发者工具，用于评估网页的性能和质量。它可以帮助前端同学检查网页的性能、可访问性、最佳实践和SEO等，我们之前已经多次讨论如何用它来分析、优化WebVitals指标。
什么页面适合灯塔
灯塔入口是一个选择生成报告类型的选项，有三种类型可供选择。其中，“设备”和“类别”比较容易理解，而“类别”则是选择需要生成哪些报告信息。如下图所示。
我们重点谈谈“模式”。灯塔提供了三种生成报告的模式，每种模式都有其特定的应用场景。
首先，“导航”模式是默认并且最常用的模式。它分析并报告了单个页面从请求开始到加载完成的全过程。
虽然导航模式能够为单个页面提供完整的分析报告，但通常一个前端应用程序包含多个页面。在这种情况下，我们可能需要从多个页面的角度来分析前端的性能。
这时，我们可以使用第二种模式，即“时间跨度”模式。
顾名思义，"时间跨度"模式记录并报告了在特定时间范围内页面的加载、跳转和交互的全过程。下面的视频将直观地展示时间跨度分析的效果。
在这个例子中，我在不缓存资源和使用5G网络的条件下，测量了TapTap移动站的页面性能。生成的报告如下图所示。
从这个模式的报告中，我们可以看到FCP和LCP指标已经不在报告中了，只剩下了TBT、CLS和INP。因此，我们无法通过这个模式来衡量FCP和LCP。
TapTap移动站使用Nuxt.js技术栈来构建Web App应用，并且提供四个Tab功能模块供用户交互，整个交互过程没有任何刷新或白屏的感觉。因此，CLS和INP是衡量这类网站的主要指标。
此外，报告中的所有诊断结果和“导航”模式基本一致。从“时间跨度”我们可以看到，它分析了页面路由的交互效果，包括路由跳转、表单交互、动画交互等。通过这些交互，我们可以发现影响用户体验的布局偏移和交互延迟等问题。
总的来说，交互和布局偏移是影响SPA单页面用户体验的核心指标。通过“时间跨度”模式，我们可以有效地找出页面性能和用户体验问题。具体交互和布局偏移的优化方法，我们在之前的课程中已经详细学习过了，你可以参考第28节课。
至于第三种模式是“快照”模式，它也可以提供诊断报告。
最后我们总结一下几个衡量前端页面的建议。
- 衡量页面从发起请求到可交互的时间，建议使用“导航”模式。
- 衡量SPA单页面的交互性能，尤其是路由切换和表单交互，建议使用“时间跨度”模式。
- 衡量页面的变化过程，例如活动H5、动画等，可以考虑使用“快照”模式。
- 如果是多页面前端项目，应结合“导航”和“时间跨度”两种模式，来分析前端应用的性能问题。
诊断结果
Lighthouse的“导航”模式提供四种分析报告：性能、无障碍、最佳做法和SEO。
这四种类型的报告对应不同领域的分析场景，前端应用所关注的报告也因此而各不相同。
- 后台类型的前端应用不需关注无障碍和SEO。
- 移动优先的H5页面重点关注性能和最佳做法。
- 需要搜索引擎收录的前端页面，性能、最佳做法和SEO都是关键。
- 支持视觉障碍用户的前端应用，应根据无障碍报告做优化。
以下是访问TapTap移动站的性能和最佳实践报告分析结果。
在诊断结果中，所有的优化建议都是基于Web Vitals指标的诊断结果。在进行前端优化之前，我们首先分析报告中标红的建议，然后根据这些建议找出解决方案。
我们重点讲讲“性能”报告分数。
灯塔提供了“性能”报告的总分数，其中FCP、LCP和CLS这三个核心指标占了总分数的一半以上，而且大部分前端性能问题都会影响到这三个指标。所以，你也可以认为这个分数反映的就是前端页面的性能状态。
如果“性能”分数大于80分，说明性能或用户体验问题较少，如果诊断报告中没有严重问题，我们可以判断前端页面无需优化。如果分数在60分和80分之间，我们需要重点分析问题原因。尤其是三个核心指标问题，优化顺序最好是FCP，然后是LCP，最后是CLS。
当然，“性能”分数会根据不同的条件而变化。比如，在WIFI或4G网络下，分数差异会非常大。
因此分数需要根据条件和用户群体进行区分，不同群体的优化重点会不同，主要有两点。
- 如果前端应用是面向移动设备的，那么这个分数就应该以4G网络作为参考价值，因为低速网络是测试前端页面性能问题的最佳条件。在这种情况下，应将FCP和CLS作为核心优化问题。
- 如果前端应用是桌面应用，通常使用桌面应用的设备都通过WIFI连接，属于高速网络。因此，这种前端应用的性能考虑因素应以LCP和CLS为主。
通过灯塔提供的分数，我们可以初步判断前端是存在性能或用户体验问题，诊断报告可以给出解决问题的建议，关于问题建议和优化，大部分都在之前的课程中详细学习了，在这里就不详细说。
性能模块
第三个模块是性能模块，这是解决前端和全链路问题的关键模块。性能模块通常需要和灯塔的“导航”模式一起使用，以分析前端问题。
“导航”模式提供了诊断报告的分数和建议，而性能模块提供了页面加载的时序图，可以真实反映前端页面的全过程。
性能模块包括五个部分：红框2的火焰图、红框3的资源加载时序图、红框4的功能和指标分析图、红框5的文档和脚本运行统计图、红框6的详细信息，如图下所示。
我们重点讨论红框3和红框4部分。
红框3的资源加载时序图能让我们看到前端资源加载的顺序，这对优化FCP和LCP很有帮助。我们可以用这个图来判断是否需要预加载资源以提高FCP指标。
时序图也可以帮助我们发现资源加载时间过长的问题，特别是图片和JavaScript文件。如果加载时间过长，白屏时间就会增加。关于如何优化，我们在第23节课已经详细讲过，你可以去参考一下。
红框4的分析图可以让我们清楚地看到每一帧的变化，还能知道每个指标在哪一帧出现。
分析图可以帮助我们直观地发现每个指标的问题。这里给你提供四种观察图表后的分析方向，一定能帮你初步判断前端问题。
第一，如果FCP出现的时间很较晚，我们就需要排查JavaScript和CSS文件的加载时间是否过长。如果是服务器端渲染的页面，还需要检查是否因为服务器端请求的接口耗时过长等问题。
第二，FP和FCP时间之间较长，我们就需要检查是否因为执行了较长的任务导致渲染延迟。
第三，FCP和LCP之间的间隔较大，那说明视口中需要加载的资源过多，或者正在处理一个大文件。假如使用了SSR模式，两个指标的间隔也很大，说明前端页面没有充分利用SSR模式的优势，需要找出问题的根源。
第四，如果分析图中出现很多CLS值，说明页面存在布局偏移问题，尤其是指标总值超过0.25，我们需要重点优化。
前端全链路是以用户为中心，衡量的是用户体验。性能模块的记录分析可以完整地展示浏览器处理前端全链路过程。
我们的目标是加快前端页面展示，减少白屏时间，减少图片加载时长，优化视口内容，增强视觉稳定性。这是前端性能优化，也是前端全链路优化的核心思路。
我们在前面的课程中已经详细讲解了这些方法，只要我们善用工具分析问题，任何性能问题都可以找到优化方案。
总结
总结一下，在这节课主要学习了前端优化中使用的分析工具。灯塔（Lighthouse）的诊断报告是前端优化的重要参考文档，通过性能模块还原全链路的路径，我们可以清楚地找出前端性能的问题。
前端链路优化不同于后端，它不仅包含性能优化，还包含用户体验的优化。如果说，前端全链路的监控是快速发现问题，那么工具就是帮助我们找出并分析问题。
为了快速找到真正的前端问题，我最喜欢的一个技巧是在工具中更改网络和屏幕尺寸。尤其是网络，模拟4G网络的上行和下行速率能反映出用户的真实使用体验。考虑到低速网络用户的体验，我们就能提高前端应用的转化率，这才就是前端团队的真正价值。
思考题
专栏结尾，我为你准备了两道有趣的作业，它们可以帮助你更深入了解前端页面的细节。
第一题，通过编程方式收集开发者工具网络模块中每个资源的时间数据。我们主要使用 Server Timing API 这套API。
我建议你选择一个项目，尝试通过编程的方式采集每个资源的时间日志，并分析前端应用加载资源的实际情况，看是否存在影响TTFB、FCP、LCP指标的问题。
第二题，灯塔（Lighthouse）不只是本地分析工具，也提供了基于Node环境的API。而每当前端项目发布新版本时，都应该具有自动化分析前端性能的任务，这是自动化测试的一部分。
你可以试试使用Lighthouse API接入你负责的前端项目，每次发布版本后，实时分析前端性能，并将报告发送到公司的内部聊天工具，例如钉钉的聊天群。
欢迎你在留言区和我交流。如果觉得有所收获，也可以把课程分享给更多的朋友一起学习。我们下节课见！