神话般的“快速”网页

Web性能对许多不同的人可能意味着很多不同的事情。从根本上讲，这是一个网页的速度问题。但是对谁快速？

不久前加载此页面时，速度很快吗？如果是这样，那么祝贺您，您的体验很快。因此，问问自己，这是否会使您快速浏览页面？没那么快！仅仅因为您拥有快速的体验，并不意味着其他所有人也都会。您甚至可能会重新访问此页面，并会感到很慢。

假设您和加载此页面的其他所有人都有快速的体验。当然可以使它成为快速的页面，对吗？大多数人都会同意。假设，如果所有人的互联网速度在一夜之间降低100倍，该怎么办？现在，此页面上的所有体验突然变慢。这个页面与昨天的字节相同，还是很快吗？

快速是用户浏览网络时会想到的一个概念。这并不是说页面很快-体验很快。

好的，这已经足够了。为什么这有关系？因为专为提高速度而打造的页面与感觉快速的页面有所不同。如果页面出现问题，可能会使人感觉较慢。如果页面未经过优化，则高端硬件上的用户可能会感觉很快。这些类型的用户所占的比例可以决定页面的总体浏览速度，甚至比实际优化程度还高。

衡量网页性能的方法可以告诉您该网页是为提高速度而构建的还是感觉很快。我们称它们为实验室和现场工具。实验室工具是显微镜，用于检查页面上所有可能的摩擦点。现场工具是双筒望远镜，可让您大致了解用户如何浏览页面。

诸如WebPageTest或Lighthouse之类的实验室工具可以告诉您成千上万个有关页面的构建方式以及从页面角度看页面加载速度的事实。这使得实验室工具不可替代地用于检查和诊断性能问题。您可以可视化页面加载的每一步，并深入了解阻止页面加载的原因。实验室工具甚至可以针对他们认为应该修复的问题提出明智的建议，从而节省了调查时间和精力。但是，尽管具有优势，但实验室工具仍可以使您误入歧途。

与您的快速体验问题（不一定反映其他所有人的问题）类似，您的实验室测试可能不会像大多数用户那样通过两种重要方式进行配置：访问权限和行为。实验室工具通过特定的硬件和网络配置访问网页，这可能会严重影响网页的加载性能。实验室工具的行为可能无法模仿真实用户，例如，测试可能未登录，加载后滚动页面或单击按钮。

随着开发人员正确地关注以用户为中心的指标，这个问题变得越来越明显。核心网络生命周期代表了良好用户体验的几个不同方面：加载性能，输入响应能力和布局稳定性。这些分别通过最大内容绘画（LCP），第一输入延迟（FID）和累积布局偏移（CLS）进行测量。那么在实验室中测量这些指标可能会出什么问题？

LCP是在屏幕上加载最大内容的时间。负载的时间高度依赖于网络的速度，因此实验室配置可以根据其带宽和延迟设置产生完全不同的LCP值。诸如图像之类的大内容也可能会被缓存并立即可供某些用户使用，但是实验室测试往往会在缓存为空的情况下运行，从而需要通过网络进行另一次访问。

FID是从首次与页面进行交互（例如单击）到浏览器准备对其进行响应之间的延迟。主线程可能非常忙于脚本执行或DOM构建，以致事件处理程序不得不等待其轮到它。在实验室中测试页面的明显限制是没有任何用户可以与之交互！实验室中有一些针对交互性的诊断指标，例如总阻止时间（TBT），但这些指标实际上并不能衡量用户体验。我们可以伪造FID并模拟用户的点击，但是有关单击什么以及何时单击的问题可能非常主观。

CLS大致是由于布局不稳定而移动的视口比例。当突然添加或删除元素并且相邻内容的位置移动时，布局可能会出现不稳定的时刻。由于布局平移分数是视口的一部分，因此手机和台式机之间的CLS可能会非常不同。在实验室中使用或仿真的设备类型直接影响CLS的计算方式。还有一个与用户行为有关的问题：何时停止衡量。加载页面后，实验室工具往往会停止运行，但是实际用户才刚刚开始与页面进行交互，并可能引起更多的版式移位。实际用户会滚动并单击并触发新的条件，这些条件会导致布局不稳定。在实验室中模拟这些行为将更接近于现实，但它与FID有着相似的挑战。

这就是为什么字段数据是页面体验的根本事实。充其量，我们只能在实验室中模拟用户体验，并且我们仍在假设用户访问页面的方式以及访问页面后的行为。

可是等等！如果我们根据现场的实际用户数据校准实验室配置该怎么办？这不是一个新主意；多年来，开发人员一直在根据现场数据校准访问因素，例如地理位置，浏览器和网络速度。但是现在，校准行为也比以往任何时候都更加重要。例如，我们可以使用分析来查看用户倾向于首先单击的内容以及何时单击。

一些实验室工具（例如WebPageTest）已经足够先进，能够将这种行为编写脚本到测试中。但是，诸如PageSpeed Insights（PSI）之类的流行工具没有可配置性，只能插入您要测试的URL，因此您需要花些时间来获取其实验室结果。请记住，性能是一种分布，而一个实验室测试只是一个人为设计的数据点。

不用担心，即使不切实际的实验室测试仍然有用。一种实际的应用是测试最坏的情况。您可能无法肯定地说访问页面的任何人都将获得快速的体验，但是如果您可以使它在最慢的条件下看起来也很快，那将有很长的路要走。通过在紧张的网络速度下使用（或仿真）低端硬件对页面的性能进行压力测试，是放大显微镜功能以解决更多性能问题的好方法。这是在用户甚至遇到问题之前解决问题的机会。

如果用户因不适应而没有得到如此缓慢的性能怎么办？体验可能很差，以至于用户在体验变得更糟之前就放弃了。他们可能根本不会回到现场，在这种情况下，您的现场数据存在生存偏差，在这种情况下，只能测量出可忍受的缓慢经历。您没有测量多少次难以忍受的缓慢经历？您以为我们已经解决了哲学问题！

个人经验只是分布中的数据点。快感取决于体验的条件。每个人的条件都不一样。

实验室测试可能无法配置为代表曲线上最常见的经验，或者代表该问题的曲线上的任何经验。

以用户为中心的指标需要格外小心，以确保在实验室中忠实地模拟行为。

作为一个Web开发社区，我们需要改变的不仅仅是“快速”网页的思维方式。仅了解可能导致我们误入歧途的陷阱是不够的：要避免这些陷阱，需要性能测试工具的制造商和用户之间共同努力。

实验室工具必须可配置才能访问并像真实用户一样工作。没有一种千篇一律的实验室配置可以代表用户如何体验所有页面。开发人员需要积极参与配置过程-不一定要达到Mbps的带宽，但开发人员应就他们在实验室中模拟的用户类型做出高层决策。这可能是一个手动猜测游戏，但至少使开发人员更加意识到结果的相关性。

更好的解决方案是在现场工具和实验室工具之间建立更强大的数据桥梁，以便实验室工具本身可以针对要模拟的最现实的用户配置文件提供明智的建议。

开发人员工具的功能正处于令人兴奋的转折点。随着更新的指标侧重于从用户角度来看页面的体验，我们有机会重新思考和重塑我们的工具帮助我们评估和优化页面的方式。通过为实验工具配备真实用户的行为特征，我们可以释放新的机会来改善页面加载以外的体验。

Rick Viscomi（@rick_viscomi）是Google的高级开发人员计划工程师，致力于网络透明性计划，例如Chrome UX报告和HTTP存档。 Rick还是视频系列《网络状态》的主持人和《使用WebPageTest》的合著者。