使用 WebPageTest 识别和修复布局不稳定问题的分步演示。
在之前的一篇文章中,我介绍了如何在 WebPageTest 中衡量累积布局偏移 (CLS)。CLS 是所有布局偏移的汇总,因此在本文中,我想深入探究并检查网页上的每个单独的布局偏移,以便了解可能导致不稳定性的原因,并实际尝试解决问题。
衡量布局偏移
使用 Layout Instability API,我们可以获取网页上所有布局偏移事件的列表:
new Promise(resolve => {
new PerformanceObserver(list => {
resolve(list.getEntries().filter(entry => !entry.hadRecentInput));
}).observe({type: "layout-shift", buffered: true});
}).then(console.log);
这将生成一个不在输入事件前面的布局偏移数组:
[
{
"name": "",
"entryType": "layout-shift",
"startTime": 210.78500000294298,
"duration": 0,
"value": 0.0001045969445437389,
"hadRecentInput": false,
"lastInputTime": 0
}
]
在此示例中,在 210 毫秒时出现一次非常小的变动 (0.01%)。
了解偏移的时间和严重程度有助于缩小可能导致偏移的原因范围。我们返回 WebPageTest 实验室环境,进行更多测试。
在 WebPageTest 中测量布局偏移
与在 WebPageTest 中衡量 CLS 类似,衡量各个布局偏移需要使用自定义指标。幸运的是,现在 Chrome 77 已是稳定版本,因此这一过程变得更轻松了。布局不稳定性 API 默认处于启用状态,因此您应该能够在 Chrome 77 中的任何网站上执行该 JS 代码段,并立即获得结果。在 WebPageTest 中,您可以使用默认的 Chrome 浏览器,而无需担心命令行标志或使用 Canary 版。
因此,我们来修改该脚本,为 WebPageTest 生成自定义指标:
[LayoutShifts]
return new Promise(resolve => {
new PerformanceObserver(list => {
resolve(JSON.stringify(list.getEntries().filter(entry => !entry.hadRecentInput)));
}).observe({type: "layout-shift", buffered: true});
});
此脚本中的 promise 解析为数组的 JSON 表示形式,而不是数组本身。这是因为自定义指标只能生成字符串或数字等原始数据类型。
我将使用 ismyhostfastyet.com 进行测试,该网站是我构建的,用于比较网站托管服务的实际加载性能。
确定布局不稳定的原因
在结果中,我们可以看到 LayoutShifts 自定义指标的值为:
[
{
"name": "",
"entryType": "layout-shift",
"startTime": 3087.2349999990547,
"duration": 0,
"value": 0.3422101449275362,
"hadRecentInput": false,
"lastInputTime": 0
}
]
总而言之,在 3087 毫秒时发生了一次 34.2% 的布局偏移。为了帮助找出罪魁祸首,我们来使用 WebPageTest 的影片片段视图。
滚动到影片片段中大约 3 秒处,我们可以清楚地看到导致布局偏移 34% 的原因:彩色表格。该网站会异步提取 JSON 文件,然后将其渲染到表格中。该表最初是空的,因此在结果加载时等待填充该表会导致偏移。
但这还不是全部。当页面在约 4.3 秒内视觉上完整显示时,我们可以看到“我的主机现在快了吗?”页面的 <h1>
突然出现。这是因为该网站使用了网页字体,且未采取任何措施优化呈现效果。发生这种情况时,布局实际上似乎不会发生变化,但用户仍然需要等待很长时间才能阅读标题,这会给用户带来糟糕的体验。
解决布局不稳定问题
现在,我们已经知道异步生成的表格导致了视口的三分之一发生了偏移,接下来就该解决这个问题了。在 JSON 结果实际加载之前,我们不知道表格的内容,但我们仍然可以使用某种占位符数据填充表格,以便在渲染 DOM 时布局本身相对稳定。
以下是用于生成占位符数据的代码:
function getRandomFiller(maxLength) {
var filler = '█';
var len = Math.ceil(Math.random() * maxLength);
return new Array(len).fill(filler).join('');
}
function getRandomDistribution() {
var fast = Math.random();
var avg = (1 - fast) * Math.random();
var slow = 1 - (fast + avg);
return [fast, avg, slow];
}
// Temporary placeholder data.
window.data = [];
for (var i = 0; i < 36; i++) {
var [fast, avg, slow] = getRandomDistribution();
window.data.push({
platform: getRandomFiller(10),
client: getRandomFiller(5),
n: getRandomFiller(1),
fast,
avg,
slow
});
}
updateResultsTable(sortResults(window.data, 'fast'));
占位符数据会先随机生成,然后再进行排序。它包含随机重复多次的“█”字符,用于为文本创建视觉占位符,以及三个主要值的随机生成分布。我还添加了一些样式,以降低表格中所有颜色的饱和度,以表明数据尚未完全加载。
您使用的占位符的外观对布局稳定性没有影响。创建占位符的目的在于向用户保证,有内容可供访问,网页没有损坏。
在 JSON 数据加载期间,占位符如下所示:
解决 Web 字体问题要简单得多。由于网站使用的是 Google Fonts,因此我们只需在 CSS 请求中传入 display=swap
属性即可。就这些了。Fonts API 会在字体声明中添加 font-display: swap
样式,以便浏览器立即以回退字体渲染文本。下面是包含修复程序的相应标记:
<link href="https://fonts.googleapis.com/css?family=Chivo:900&display=swap" rel="stylesheet">
验证优化
通过 WebPageTest 重新运行页面后,我们可以生成“之前和之后”比较,以直观地显示差异并衡量新的布局不稳定程度:
[
{
"name": "",
"entryType": "layout-shift",
"startTime": 3070.9349999997357,
"duration": 0,
"value": 0.000050272187989256116,
"hadRecentInput": false,
"lastInputTime": 0
}
]
根据自定义指标,布局仍然会在 3071 毫秒(与之前大致相同的时间)发生偏移,但偏移的严重程度大大降低,为 0.005%。我可以接受。
此外,从幻灯影片中可以看出,<h1>
字体会立即回退到系统字体,让用户能够更快地阅读它。
总结
复杂的网站可能会经历比本例更多的布局偏移,但修复过程仍然相同:向 WebPageTest 添加布局不稳定性指标,将结果与视觉加载幻灯影片进行交叉引用以找出问题所在,并使用占位符实施修复,以预留屏幕空间。
(还有一点)衡量真实用户遇到的布局不稳定性
在优化前后对网页运行 WebPageTest 并看到某个指标有所提升,这固然令人欣喜,但真正重要的是,用户体验确实有所提升。这不正是我们一开始就努力改进网站的原因吗?
因此,如果我们能将传统的 Web 性能指标与真实用户的布局不稳定体验一起衡量,那就太棒了。这是优化反馈环的重要环节,因为从现场获取的数据可以告诉我们问题所在,以及我们的修复措施是否有积极作用。
除了收集您自己的布局不稳定数据外,您还可以查看 Chrome 用户体验报告,其中包含来自数百万个网站上的真实用户体验的 Cumulative Layout Shift 数据。借助该工具,您可以了解自己(或竞争对手)的表现,也可以探索网络上布局不稳定的状态。