为什么使用骨架屏？包含反面教材及如何权衡使用骨架屏

如果设计和构建得当，骨架屏幕可以向用户发出信号，表明网站正在运行，内容正在制作中。不过，它们确实需要深思熟虑地使用。

Tim Kadlec 在《有效的骨架屏幕》中分享了设计骨架屏幕时需要牢记的一些重要事项：

当我第一次偶然想到骨架屏幕时，多亏了Luke Wroblewski 在 2013 年谈论过它，我很快就迷上了它。我从来都不喜欢进度条和旋转器，而骨架屏幕似乎是朝着正确方向迈出的明智一步。

对于那些不熟悉的人来说，骨架屏幕是一种显示即将显示的内容轮廓（骨架）的方法，通常在内容加载时使用灰色框和线条代替进度条。这是一种非常有创意的处理等待的方法——毫无疑问，它比永久旋转的圆圈更有创意，也更有帮助。

但如果我们偏离初衷太多，即使是好的想法也会变成坏的想法。

前几天，卢克在社交媒体上对骨架屏幕的使用表示遗憾：

我是唯一一个认为骨架 UI 用户体验非常糟糕的人吗？“这是一些客户端渲染的内容——哎呀，等等，现在你得到的是矩形！”

这让我开始思考我们如何谨慎地应用优化并开始随意地应用它，而没有过多考虑为什么以及如何有效地使用它。

重新审视卢克对该方法的应用是有帮助的。

为什么使用骨架屏

当时，卢克正在创办一家名为 Polar 的创业公司。Polar 是一款基于微交互理念构建的移动应用程序。用户会看到一个简单的“非此即彼”调查。他们点击一个答案，然后转到下一个调查。

在应用程序中的几个位置，例如加载调查问卷时，这些元素需要一些时间才能下载并显示出来。Polar 最初使用的东西与许多应用程序相同：通用加载器。

当他们查看用户反馈时，他们发现人们经常抱怨等待内容刷新的时间太长。考虑到应用程序当时面临的网络和网页视图性能限制，他们在技术方面能做的事情有点有限。相反，他们调整了设计，从通用加载器切换到骨架屏幕，随着内容从服务器返回而逐步填充。人们不再抱怨等待时间，一种新的感知性能“最佳实践”诞生了。

但最佳实践只有在正确的环境中使用时才是最佳实践。如果使用不当，即使是最佳实践也可能有害。这就是为什么当我进行性能培训时，我总是从浏览器和网络的工作方式开始。你需要知道某些东西为什么有效，才能知道什么时候有意义，什么时候没有意义。

那么回到骨架屏幕，为什么它们（至少在理论上）有效？

这与主动等待和被动等待有关。在主动等待中，我们在等待时感觉自己在做一些事情。在被动等待中，我们只是被动地坐在那里，无事可做，等待着我们想要发生的事情。根据对时间感知的研究，主动等待阶段被认为比被动等待阶段更快。

有了进度条或旋转器，我们的整个等待时间都是被动的：我们除了观看这个与我们将要看到的内容完全无关的旋转器之外什么也做不了。

借助 Polar 的骨架屏幕，部分等待时间可以转换为活动状态。如果我们查看页面进展的屏幕截图，我们会看到我们从几个灰色框和主要文本标题变成了一些填充的文本内容，最后变成了显示的图像和图标。

每当状态发生变化时，我们都会进行短暂的主动等待，开始处理呈现给我们的信息，从而了解最终将会发生什么。

这就是为什么从理论上来说，骨架屏幕很有用。它们可以即时反馈接下来的内容，并且随着内容的出现和填充，它们会不断将我们拉回到短暂的积极等待阶段，帮助时间过得更快一些。

对我来说，这似乎是合理的，但在我们的界面中实现骨架屏时，我们必须记住一些事情。

首先，这是一种解决方法。如果您可以立即显示内容，请务必这样做。

骨架屏的反面例子

如果您注意到，Jeremy 举的具体例子是客户端应用程序加载时间过长。不幸的是，这种情况非常常见。根据我对依赖大量客户端 JavaScript 来显示内容的网站和应用程序的分析经验，这些延迟通常以秒为单位，而不是毫秒。

让我们选取Scott Jehl 提供的一个例子：桌面浏览器中的 油管。我们选取它并不是因为它是一个特别恶劣的例子，而是因为它是当今骨架屏幕实现中许多常见问题的一个极好例子。

在该示例中，通过有线连接进行测试，我们盯着灰色框看了 6.9 秒才看到内容。

这么长的延迟实在是太难了，我们不可能指望几个灰色的盒子就能拖住我们……我们只是处于这种主动等待状态片刻，然后我们就会消化提供给我们的背景信息，准备继续前进。所有关于在主动等待状态下时间感知如何加快的研究？还有研究表明，随着总等待时间的增加，处于主动等待状态的好处会逐渐减弱。

这给我们带来了下一个考虑——活跃状态不会永远持续下去，所以我们需要快速取得进展。如果我们因为某种原因无法做到，那么我们需要逐步取得进展。

记住，在 Polar 示例中，我们看到了三个基本阶段：

1. 灰色框、边框和标题

2. 文本内容

3. 影像

如果加载时间非常快，也许这足以让我们一直处于活跃状态。如果加载时间稍慢，我们将在主动和被动等待状态之间切换，这就是增量方法的用武之地。在每个阶段，我们都会获得额外的背景信息，让我们花点时间思考。

回顾 油管 示例，我们有两个基本阶段（对于我们今天看到的许多骨架 UI 来说非常典型）：

4. 灰色框和边框

5. 所有的事情！

没有初始标题来提供任何附加背景信息，也没有增量阶段来处理更多信息。

在处理最初显示的灰色方框所需的最初一两分钟之后，我们将在剩余的时间内立即切换回被动等待状态。如果没有这种渐进式的进展（并且没有早期标题提供的额外背景信息），我们将大部分时间处于被动等待状态，并且可以理解的是，我们会对延迟感到恼火——即使延迟时间没有那么长。

另一件需要考虑的事情是：期望应该与现实相符。

在 Polar 应用中，原始框不会移动。相反，它们会准确描绘即将出现的内容以及显示的位置。

再次，油管 页面是相反效果的一个很好的例子。

下面的第一张截图显示了页面的初始状态。我们有一个方框网格，用于显示视频，还有一些圆圈用于显示缩略图。但第二张截图显示，随着广告的显示，整个骨架屏幕发生了显著变化。

在这种情况下，我们预期会显示哪些内容以及在哪里显示，而这些预期最终产生了误导。现在我们必须重新调整自己，确定内容最终会显示在哪里。

当骨架屏幕与结果不匹配时，我们就会感到困惑和沮丧，而这会抵消您尝试以更好的方式处理延迟所获得的任何好处。

总的来说，我认为这里也需要注意一些条件。随着骨架屏幕的模式变得越来越熟悉，它让我们进入主动等待状态的能力将会下降。如果我们试图将这种方法用作用户每次使用我们的网站时都必须遇到的长时间加载的补救措施，那么它很快就会失败。

权衡使用骨架屏

那么，骨架屏幕是否会带来糟糕的用户体验，还是改善感知性能的好方法？

就像任何事情一样，它们可能兼而有之。如果您正在权衡是否要在您的网站或应用程序中添加一个，请记住：

1. 这些措施有必要吗？你能用不同的方法完全避免延误吗？
2. 骨架屏幕只能分散注意力一段时间，然后就会变得令人沮丧。如果您的网站或应用程序在关键阶段出现长时间延迟，缩短该延迟仍应是主要关注点。
3. 当您使用骨架屏幕时，请确保人们看到渐进的进展，并确保在进展的每个阶段为他们提供尽可能多的背景信息。
4. 让期望与现实相符。虚假展示未来发展或定位的框架屏幕会让人迷失方向并造成混乱。

最后，测试。

骨架屏幕对 Polar 来说很有效。他们知道它有效，因为他们做了必要的研究，以了解它如何影响人们对整个应用程序的看法。这并不意味着它会以同样的方式对你的受众或你的所有受众起作用。

我们能做的最健康、最重要的事情之一就是不断挑战自己，质疑为什么“最佳实践”被贴上这样的标签。当我们理解它为什么以及如何起作用时，我们就能更好地知道如何在自己的环境中正确应用它，以及什么时候这样做是有意义的。