Devtool的正确食用姿势

1 前言

作为一名合格的前端，我们不可避免的需要接触到浏览器的开发者工具，也必须掌握这个工具。介于我自身的掌握水平，我将在本文对chrome devtool的选项卡Lighthouse、Sources与Elements进行讲解，同时也对比不同浏览器之间的devtool的功能差异。

2 Lighthouse

如果你对于Performance标签并不太熟悉又想优化一些网站的性能，那么我非常建议你使用Lighthouse。运行Lighthouse你可以获得页面的一些审核指标（自由选择）、得到页面加载时各个时刻的截图，同时Lighthouse还会提供如何提高特定页面加载性能的提示。

2.1 Lighthouse的使用

下图是Lighthouse的启动界面，目前在启动Lighthouse时，需要选择四个选项。分别是模式、网站会在哪个设备运行、需要测试的类别、是否包含广告插件。

Lighthouse的不同模式略有差异。我们需要了解一下一些使用场景、使用方式的差异。

Navigation 导航模式

导航模式作为默认模式，其使用场景是首次进入页面的分析 ，即其指标与评分是在测试首屏渲染，无法分析页面加载后需要手动触发使用的内容。同时根据官方文档，其对于表单提交或者SPA页面转换也没有分析的能力。受益于Navigation，我们可以得到页面加载各个时刻的页面加载截图。

注意，仅该模式可以分析所有的类别和插件。点击"分析网页加载情况"，此时页面会重载，无需手动操作，等待片刻Lighthouse即会输出一份报告。

Timespan 时间跨度模式

时间跨度模式是我最喜欢的模式，其可以测量布局变化和交互，它允许我们在一个时间范围内自由操作页面，Lighthouse会在我们结束后分析整个过程的各个指标。对于网页性能优化来讲，Timespan绝对是最佳选择（实际上，Timespan目前也确实只支持性能分析）。

使用时间跨度模式，需要在Lighthouse准备就绪后操作页面，在所有操作完毕后，点击结束时间跨度模式Lighthouse将开始审查整个操作过程，输出一份性能报告。

Snapshot 快照

快照模式，顾名思义，快照模式下Lighthouse不会重新加载页面，它会直接分析当前页面当前状态得出各项指标。注意，快照模式下，不能分析广告和PWA。

使用快照模式的方式和导航模式类似，点击后Lighthouse会自动审查分析，不需要额外操作。

一个有趣的事情是，lighthouse可以通过nodejs的方式启动。此时虽然仍有Navigation等模式的区分，但是我们可以在启动后做一些点击、表单一系列操作。

2.2 Lighthouse的指标

我们将以Navigation模式中生成的指标作为基础讲解各个指标，其他两个模式的指标与Navigation模式中生成的指标并无太大区别，其基本逻辑都是：lighthouse提供诊断分数------提供优化建议------提供诊断结果。

2.2.1 性能Performance

在Performance报告中，其由性能分数、性能指标、优化建议、诊断结果组成。

关于性能分数的计算，也就是下图这一部分，Lighthouse官方给了一份完整的计算方式讲解，同时包含了一个在线计算器。

根据这份计算方式讲解，我们可以了解到，Lighthouse 10对下边的五个指标进行加权计算得到性能分数。这五个指标，即目前主流性能检测中常见的First Contentful Paint、Speed Index、Largest Contentful Paint、Total Blocking Time、Cumulative Layout Shift。

我想大部分前端同学或多或少都听过这些指标的大名，但是或许大部分人并不了解其中的含义，所以我们有必要进行更详细的讲解。报告中的指标部分就是具体展示了这些指标，并同时提供了原始追踪记录和资源加载树状图。其中的原始追踪记录，会导向Performance标签，我们暂不做演示。我们首先讲解五个指标的意义，再看一下树状图。

First Contentful Paint

FCP测量的是，用户进入到页面后浏览器呈现第一段DOM内容所需的时间，这个时间一般是秒。页面上的图像、非白色 <canvas> 元素和SVG都被认为是DOM内容，而iframe里面的任何东西都不包括在内。

在上边的图中，我们会发现对我这份报告来说，FCP为1s，颜色显示为黄色，这是因为Lighthouse的评分标准中，对于0-49呈现红色，50-89呈现黄色，90-100呈现绿色。而对于FCP来说，根据官方文档（2021-06-04更新），这一块的分数以1.8和3分为界限。1.8s以下为绿色，3s以上为红色。但是实测下来，1s的表现仍是黄色，对于这里存在的差异，官方文档中有提到FCP的得分计算方式是与真实网站做比较，基于HTTP Archive的数据。例如，99%中执行的站点在大约0.5秒内呈现FCP。如果我们的网站的FCP是0.5秒，则FCP得分99。

那么我们可以根据截至2023年6月1日的数据，计算得出目前的评分表（对于PC网页）：

FCP time(in seconds) Color-coding

0--1.1 Green (fast)

1.1--2.1 Orange (moderate)

Over 2.1 Red (slow)
Largest Contentful Paint

LCP测量视口中最大的内容元素何时呈现到屏幕上。这个指标的意义是，最大内容元素的呈现近似于用户看到页面主要内容的时间。LCP的测量方式相比FCP更复杂，根据W3C对于LCP的测量范围定义，最大内容绘制考量的元素类型为：
- img元素。
- image内的元素svg。
- 元素的海报图像video。
- 具有背景图像的元素。
- 文本节点组，按照§ 3.2 CSS 规范的修改中的描述进行聚合。
W3C还提供了具体的API使用案例，Devtool中对于LCP的测量即依赖于PerformanceObserver。
html 复制代码
```
<img src="large_image.jpg">
<p id='large-paragraph'>This is large body of text.</p>
...
<script>
const observer = new PerformanceObserver((list) => {
  let perfEntries = list.getEntries();
  let lastEntry = perfEntries[perfEntries.length - 1];
  // Process the latest candidate for largest contentful paint
});
observer.observe({entryTypes: ['largest-contentful-paint']});
</script>
```
Total Blocking Time

TBT代表当任务用时超过 50 毫秒时计算首次内容绘制 (FCP) 和可交互时间之间的所有时间段的总和，以毫秒表示。通过将第一次内容绘制和交互时间之间的所有长任务的阻塞部分相加来计算总和。任何执行时间超过50毫秒的任务都是长任务。50ms之后的时间量是阻塞部分。例如，如果Lighthouse检测到70ms长的任务，则阻塞部分将是20ms。
Cumulative Layout Shift

CLS对布局进行审查，是测量视觉稳定性的一个以用户为中心重要指标，因为该项指标有助于量化用户经历意外布局偏移的频率。所谓布局偏移，就是在交互时，页面布局的跳动。导致页面布局跳动的因素一般是图像加载未定义宽高、滚动条显隐挤压内容变化，更多可能导致布局跳动的因素，可以参考下边这份文档layout-instability。
Speed Index

Speed Index 表明了网页内容的可见填充速度。该速度指数的分数计算方式和FCP类似，参考了HTTP Archive。其测量方式是在页面加载过程中内容以视觉方式显示的速度。Lighthouse首先捕获浏览器中页面加载的视频，并计算帧之间的视觉进展。然后Lighthouse使用Speedline Node.js模块生成速度指数得分。

FCP time(in seconds)	Color-coding
0--1.1	Green (fast)
1.1--2.1	Orange (moderate)
Over 2.1	Red (slow)

简述了这些指标，我们说说资源加载树状图。该树状图根据单个文件的大小排列与展示，方便看到是哪些资源拖累了页面加载。同时，其计算了哪些文件中的哪些部分是未使用的，帮助开发者寻找到需要精简的文件。

要注意的是，浏览器插件的代码也会影响评分。

剩下的部分中，lighthouse给出了优化建议和诊断结果，这一部分内容通过红橙绿三色表示严重程度，每一项都可以展开查看详细结果。这些优化建议根据上方的指标可以进行筛选，相当于手把手教导我们如何优化工程优化网页来提高相关指标的得分。

2.2.2 无障碍功能

对于中小型网站，可能对于无障碍功能考虑得会比较少。但是，随着互联网的发展，人们愈发考虑无障碍人群的体验了。浏览器作为一个非常核心的互联网窗口，自然不能停下脚步，lighthouse提供的无障碍功能检测一方面可以让我们具体感知到自己网页的无障碍程度，一方面也通过它提供的多条指标与指引了解浏览器的无障碍标准。

Devtool工具会检查网页的ARIA、对比度、名称和标签，帮助改善辅助技术用户的体验。从测试结果来看，lighthouse提供的检测报告总共包含44项自动检测，10项手动检查，所以我说lighthouse提供了一个很好的学习途径，54项检查我整理在下边的表格中，需要自取。

问题	说明
图片元素缺少 [alt] 属性	说明性元素应力求使用简短的描述性替代文字。未指定 alt 属性的装饰性元素可被忽略。
链接缺少可识别的名称	请确保链接文字（以及用作链接的图片替代文字）可识别、独一无二且可聚焦，这样做会提升屏幕阅读器用户的导航体验。
元素中使用了 [user-scalable="no"]，或者 [maximum-scale] 属性小于 5。	对于必须依靠放大屏幕才能清晰看到网页内容的弱视用户而言，停用缩放功能会给他们带来问题。
背景色和前景色没有足够高的对比度。	对于许多用户而言，对比度低的文字都是难以阅读或无法阅读的。
列表并非只包含 * 元素和脚本支持元素（	屏幕阅读器会采用特定的方法来读出列表内容。确保列表结构正确有助于屏幕阅读器顺利读出相应内容。
列表项 ( * ) 未包含在、或父元素中。	屏幕阅读器要求列表项 ( * ) 必须包含在父、或中，这样才能正确读出它们。
文档中没有 [aria-hidden="true"]	在文档上设置 aria-hidden="true" 后，辅助技术（如屏幕阅读器）的工作方式不一致。
[role] 具备所有必需的 [aria-*] 属性	一些 ARIA 角色有必需属性，这些属性向屏幕阅读器描述了相应元素的状态。
[role] 值有效	ARIA 角色必须具备有效值，才能执行它们的预期无障碍功能。
按钮有可供访问的名称	当某个按钮没有无障碍名称时，屏幕阅读器会将它读为"按钮"，这会导致依赖屏幕阅读器的用户无法使用它
表单元素具有关联的标签	标签可确保辅助技术（如屏幕阅读器）正确读出表单控件。
文档包含元素	屏幕阅读器用户可借助标题来大致了解某个页面的内容，搜索引擎用户则非常依赖标题来确定某个页面是否与其搜索相关。
元素包含 [lang] 属性	屏幕阅读器用户可借助标题来大致了解某个页面的内容，搜索引擎用户则非常依赖标题来确定某个页面是否与其搜索相关。
元素的 [lang] 属性具备有效值	指定有效的 www.w3.org/Internation...
"[accesskey]"值是独一无二的	快捷键可让用户快速转到页面的某个部分。为确保正确进行导航，每个快捷键都必须是独一无二的。
[aria-*] 属性与其角色匹配	每个 ARIA"role"都支持一部分特定的"aria-"属性。如果这些项不匹配，会导致"aria-"属性无效。
button、link 和 menuitem 元素都有可供访问的名称	如果某个元素没有无障碍名称，屏幕阅读器会将它读为通用名称，这会导致依赖屏幕阅读器的用户无法使用它。
[aria-hidden="true"] 元素都不含可聚焦的下级元素	有一个 [aria-hidden="true"] 元素包含可聚焦的下级元素，导致这些交互式元素都无法被辅助技术（如屏幕阅读器）用户使用。
ARIA 输入字段都有可供访问的名称	如果某个输入字段没有无障碍名称，屏幕阅读器会将它读为通用名称，这会导致依赖屏幕阅读器的用户无法使用它。
ARIA meter 元素都有可供访问的名称	如果某个输入字段没有无障碍名称，屏幕阅读器会将它读为通用名称，这会导致依赖屏幕阅读器的用户无法使用它。
ARIA progressbar 元素都有可供访问的名称	如果某个 progressbar 元素没有无障碍名称，屏幕阅读器会将它读为通用名称，这会导致依赖屏幕阅读器的用户无法使用它。
具有 ARIA [role]且要求子元素必须包含特定[role]的元素包含全部必需子元素。	一些 ARIA 父角色必须包含特定子角色，才能执行它们的预期无障碍功能。
[role] 包含在其必需的父元素中	一些 ARIA 子角色必须包含在特定的父角色中，才能正确执行它们的预期无障碍功能。
ARIA 切换字段都有可供访问的名称	如果某个切换字段没有无障碍名称，屏幕阅读器会将它读为通用名称，这会导致依赖屏幕阅读器的用户无法使用它。
ARIA tooltip 元素都有可供访问的名称	如果某个 tooltip 元素没有无障碍名称，屏幕阅读器会将它读为通用名称，这会导致依赖屏幕阅读器的用户无法使用它。
ARIA treeitem 元素都有可供访问的名称	如果某个 treeitem 元素没有无障碍名称，屏幕阅读器会将它读为通用名称，这会导致依赖屏幕阅读器的用户无法使用它。
[aria-*] 属性具备有效值	辅助技术（如屏幕阅读器）无法解读值无效的 ARIA 属性。
[aria-*] 属性有效且拼写正确	辅助技术（如屏幕阅读器）无法解读名称无效的 ARIA 属性。
该页面包含一个标题、跳过链接或地标区域	添加用于绕过重复内容的方式有助于键盘用户更高效地浏览页面。
和 : 组及	如果未正确标记定义列表，屏幕阅读器读出的内容可能会令人困惑或不准确。
定义列表项已封装在	定义列表项（和）必须封装在父
处于活动状态的可聚焦元素的 [id] 属性都是独一无二的	所有可聚焦的元素都必须具有独一无二的 id，以确保能被辅助技术识别。
ARIA ID 都是独一无二的	ARIA ID 的值必须独一无二，才能防止其他实例被辅助技术忽略。
表单字段都没有多个标签	有多个标签的表单字段可能会被辅助技术（如屏幕阅读器）以令人困惑的方式播报出来，因为这些辅助技术可能会使用第一个标签或最后一个标签，也可能会使用所有标签。
或元素有标题	屏幕阅读器用户依靠框架标题来描述框架的内容。
标题元素按降序显示	未跳过任何等级且排序正确的标题会准确传达页面的语义结构，从而使得相应页面在使用辅助技术时更易于浏览和理解。
元素有对应的 [alt] 文字	将图片用作按钮时，提供替代文字有助于屏幕阅读器用户了解该按钮的用途。
文档未使用	用户并不希望网页自动刷新，因为自动刷新会不断地将焦点移回到页面顶部。这可能会让用户感到沮丧或困惑。
元素有对应的替代文字	屏幕阅读器无法转换非文字内容。通过向元素添加替代文字，可帮助屏幕阅读器将含义传达给用户。
所有元素的 [tabindex] 值都不大于 0	值大于 0 意味着明确的导航顺序。尽管这在技术上可行，但往往会让依赖辅助技术的用户感到沮丧。
元素中使用 [headers] 属性的单元格引用的是同一表格中的单元格。	------------------------------------------------