Smashing Podcast 第 34 集与 Harry Roberts：Web 性能状况如何？

在本集中，我们将讨论 Web 性能。 2021 年的业绩前景如何？ 我与专家哈里·罗伯茨（Harry Roberts）进行了交谈以找出答案。

显示注释

Harry 将于 2021 年 5 月与 Smashing 一起举办一个 Web 性能大师班研讨会。在发布时，仍然可以享受大早鸟折扣。

• 哈利在推特上
• Harry 的咨询网站 CSS Wizardry
• 视频课程我为快速制作 CSS 魔法所做的一切，包括15% 的折扣
• 顾问电子书的问题，包括15% 的折扣
• Web Vitals 的 Web.dev 指南
• 德鲁最喜欢的 OXO GoodGrips 打蛋器

每周更新

• 2021 年网页设计趋势：Suzanne Scacca 撰写的报告
• 在由 Fortune Ikechi 编写的 React 应用程序中使用 Grommet
• 如何为以太坊区块链构建 Node.js API 由 John Agbanusi 编写
• 我们如何改进 SmashingMag 性能 作者 Vitaly Friedman
• 何时对 Becca Kennedy 撰写的自由职业者项目说不

成绩单

Drew McLellan：他是来自英国利兹的独立顾问 Web 性能工程师。 在他的职责中，他帮助一些世界上最大和最受尊敬的组织为他们的客户提供更快、更可靠的体验。 他是受邀的 Google 开发专家、Cloudinary 媒体开发专家、屡获殊荣的开发人员和国际演讲者。 所以我们知道他对网络性能了如指掌，但你知道他有 14 条胳膊和 7 条腿吗？ 我的 Smashing 朋友们，请欢迎 Harry Roberts。 嗨，哈利，你好吗？

哈里·罗伯茨：嘿，非常感谢你。 显然，14 条手臂，7 条腿……仍然是它常见的问题。 不可能买裤子。

德鲁：还有自行车。

哈利：是的。 好吧，我有三辆半自行车。

德鲁：所以我今天想和你谈谈，不幸的是，不是关于自行车，尽管这本身很有趣。 我想和你谈谈网络性能。 这是一个我个人非常热衷的主题，但这是我担心的领域之一，当我把注意力从球上移开并参与其他一些工作，然后再回来做一些表演工作时，我担心我正在使用的知识很快就会过时......这些天网络性能是否像我认为的那样快速发展？

哈利：这是……我什至不是为了对你好，这是一个很好的问题，因为我最近一直在思考这个问题，我想说有两半。 我会尝试告诉客户的一件事是，实际上它并没有那么快。 主要是因为，这是我一直使用的声音片段，你可以在浏览器上打赌。 不允许浏览器从根本上改变它们的工作方式，因为当然，它们必须维护二十年的传统。 所以，一般来说，如果你押注浏览器并且你知道这些内部结构是如何工作的，并且 TCP/IP 永远不会改变......所以某些事情是相当固定的，这意味着最佳实践总体上将始终是涉及基本面的最佳实践。

Harry：它变得更有趣的地方是……我越来越多地看到，当涉及到站点速度问题时，我们正在把自己画到角落里。 所以我们实际上给自己制造了很多问题。 所以这实际上意味着性能……我想这是移动的球门柱。 网络的景观或地形变化越多，它的构建方式和我们的工作方式越多，我们就会给自己带来新的挑战。 因此，在客户端上做更多工作的出现带来了与五年前我们解决的不同的性能问题，但这些性能问题仍然与浏览器内部有关，总的来说，五年来没有改变。 所以很大程度上取决于...而且我想说它肯定有两个明确的方面...我鼓励我的客户依靠浏览器，依靠标准，因为它们不能只是改变，球门柱并没有真正移动. 但是，当然，这需要与更现代、或许更有趣的开发实践相结合。 所以你保持你的……好吧，我想说“在两个阵营都有一只脚”，但我的七英尺，我必须……四和三。

Drew：您提到基本原理不会改变，TCP/IP 之类的东西也不会改变。 确实发生了变化的一件事……我说的是“最近几年”，这实际上可能要追溯到现在，但是 HTTP 是因为我们已经建立了用于在客户端和服务器之间进行通信的 HTTP 协议，然后它发生了变化我们得到了 H2，它是二进制的并且是不同的。 这改变了很多......这是出于性能原因，它是为了消除一些现有的限制，但这是一个变化，我们必须针对该协议进行优化的方式发生了变化。 现在稳定了吗？ 或者它会再次改变，或者......

哈里：所以我想进一步了解的一件事是问题的后半部分，即再次变化。 我需要更多地研究 QUIC 和 H3，但它对我的客户有用。 当谈到 H2 时，情况发生了很大变化，但我真的认为 H2 是很多虚假的承诺，我相信它是匆匆忙忙的，考虑到 H1 的推出，这很了不起……我的意思是 1.1，是 1997 年，所以我们有很多时间来研究 H2。

Harry：我想主要的好处是 Web 开发人员理解它或认为它现在在飞行请求中是无限的。 因此，而不是一次六个已调度和/或六个飞行中的请求，可能是无限的，无限的。 虽然带来了非常有趣的问题，因为......如果没有视觉辅助很难描述，但您仍然可以获得相同数量的可用带宽，无论您运行的是 H1 还是 H2，该协议都不会使您的连接更快。 因此，您很可能会通过一次请求 24 个文件来淹没网络，但您没有足够的带宽。 因此，您实际上并没有变得更快，因为您一次只能管理其中的一小部分。

哈里：还有你必须考虑的是文件如何响应。 这是我在客户研讨会等方面经历的另一个专业提示。 人们会看到一个 H2 瀑布，他们会看到传统的 6 个调度请求，他们可能会看到 24 个。调度 24 个请求实际上并没有那么有用。 有用的是这些响应何时返回。 您会注意到您可能会发送 24 个请求，因此您的瀑布左侧看起来非常漂亮且陡峭，但它们都以相当交错的顺序返回，因为您需要限制带宽量，所以您无法同时完成所有响应。

哈利：嗯，另一件事是，如果你要同时完成所有响应，你就会交错响应。 所以你晚上得到了每个文件的前 10%，接下来的 20%……JavaScript 文件的 20% 是无用的。 JavaScript 在 100% 到达之前是不可用的。 所以你会看到，事实上，当你查看响应时，H2 瀑布的表现方式......无论如何，它看起来更像 H1，它更加交错。 所以，H2，我认为它被超卖了，或者工程师没有被引导相信它的有效性有上限。 因为你会看到人们过度分片他们的资产，他们可能有 20 个……让我们保持数字 24。你可能有 24 个小包，而不是两个大的 JS 文件。 他们仍然会按顺序返回。 它们不会同时到达，因为您没有为自己增加带宽。

Harry：另一个问题是每个请求都有固定的延迟。 因此，假设您请求两个大文件，往返时间为 100 毫秒，下载时间为 250 毫秒，即 250 毫秒的两倍。 如果您将最多 24 个请求相乘，您仍然有恒定的延迟，我们已经确定为 100 毫秒，所以现在您有 2400 毫秒的延迟和 24 倍……而不是 250 毫秒的下载，假设它是 25 毫秒的下载，它实际上需要更长的时间，因为延迟保持不变，您只需将该延迟乘以更多请求。 所以我会看到客户会读到 H2 是这个神奇的子弹。 他们会分片……哦！ 他们不能简化开发过程，我们不需要做捆绑或连接等等等等。 最终它会变得更慢，因为您已经设法将您的请求传播出去，这是承诺，但您的延迟保持不变，因此您实际上在浏览器中获得了 n 倍的延迟。 就像我说的，真的很难，如果没有视觉效果，试图解释这一点可能毫无意义，但与人们希望它可能做的相比，H2 的表现方式非常了不起。

德鲁：那个分片过程还有好处吗，好吧，得到全部仍然需要相同的时间，但是当你得到第一个 100% 的第 24 回时，你可以开始处理它，你可以在 24 日结束之前开始执行它。

哈利：哦，伙计，另一个很好的问题。 所以，绝对地，如果事情进展顺利并且它确实体现在一个更像 H1 的响应中，这个想法将是文件一首先返回，二、三、四，然后它们可以按照到达的顺序执行。 因此，您实际上可以通过确保事物同时到达来缩短总时间。 如果我们查看网页而不是瀑布流，并且您注意到请求是交错的，那是个坏消息。 因为就像我说的，10% 的 JavaScript 文件是无用的。

哈里：如果服务器正常工作并且发送、发送、发送、发送、发送，那么它会变得更快。 然后，您的缓存策略可以更精细地获得连锁反应。 所以真的很烦人，你会更新日期选择器小部件上的字体大小。 在 H1 世界中，您必须缓存站点中大约 200 千瓦的 CSS。 而现在，您只需缓存 bust datepicker.css。 所以我们有这样的分支好处，这绝对是非常有价值的。

德鲁：我想，在你神奇地一次获得所有请求的情况下，这显然会潜在地让客户端陷入困境，不是吗？

哈利：是的，有可能。 然后实际发生的是客户端必须进行大量资源调度，所以你最终会得到一个瀑布，你的所有响应都会同时返回，那么你之间就会有相当大的差距最后一个响应到达及其执行能力。 所以理想情况下，当我们谈论 JavaScript 时，您希望浏览器按请求顺序请求它们，基本上是您定义它们的顺序，服务器以正确的顺序返回它们，这样浏览器就可以执行它们以正确的顺序排列。 因为，正如您所说，如果它们都同时返回，那么您就可以同时运行大量的 JavaScript，但仍需要对其进行调度。 因此，在文件到达和它变得有用之间，您最多可能会有第二个怀疑。 所以，实际上，H1 ......我想，理想情况下，你所追求的是 H2 请求调度，H1 样式响应，所以当它们到达时，事情就会变得有用。

德鲁：所以你基本上是在寻找一个看起来可以滑下来的响应瀑布。

哈利：是的，没错。

德鲁：但你不需要降落伞。

哈利：是的。 这真的很难……我认为大声说出来听起来真的很微不足道，但考虑到 H2 的销售方式，我觉得这很……没有挑战性，因为这让我的客户听起来……愚蠢……但这是一件需要解释的事情对他们来说……如果你想想 H1 是如何工作的，那还不错。 如果我们得到这样的回复，“哦，是的，我现在可以看到”。 我以前必须教过性能工程师这个。 做我做的事的人。 我不得不告诉性能工程师，当我们提出请求时，我们不会太介意，我们真的很关心响应何时变得有用。

德鲁：事情似乎进展得很快，尤其是在过去五年中，其中一个原因是性能是谷歌的一个大话题。 当谷歌将重量放在这样的事情上时，它就会获得牵引力。 但本质上，性能是用户体验的一个方面，不是吗？

哈利：哦，我的意思是……这是一个非常好的播客，我半小时前就在想这个，我向你保证我半小时前就在想这个。 性能是应用的可访问性。 您正在保证或增加某人可以访问您的内容的机会，我认为可访问性始终只是……哦，它是屏幕阅读器，对吗？ 是看不见的人。 建立网站而不是应用程序的决定......这些决定是访问更多的受众。 所以，是的，性能是应用的可访问性，因此是用户体验。 这种用户体验可以归结为“有人能体验你的网站吗”句号。 或者它可能是“那种体验令人愉快吗？ 当我点击一个按钮时，它是否及时响应？”。 所以我 100% 同意，我认为这就是谷歌重视它的很多原因，因为它会影响用户体验，如果有人要信任搜索结果，我们想尝试给那个人一个网站他们不会讨厌的。

Drew：这是……你所想的一切，你所想的所有好处，用户体验，诸如增加参与度之类的东西，这绝对是真的，不是吗？ 没有什么比缓慢的体验更能让用户离开网站的了。 这太令人沮丧了，不是吗？ 使用您知道导航可能不是那么清晰的网站，并且如果您单击链接并认为“这就是我想要的吗？ 不是吗？” 只是点击的成本，只是等待，然后你必须点击返回按钮，然后等待，这只是......你放弃了。

哈利：是的，这很有意义。 如果你去超市，你看到它绝对挤满了人，你会做的最低限度。 你不会在那里花很多钱，就像“哦，我只需要牛奶”，进进出出。 而如果这是一次不错的体验，你会得到“哦，好吧，我在这里的时候，我会看看……哦，是的，他们有这个……哦，我明天晚上做这个”或其他什么。 我仍然认为，网络进入了三个十年，即使是为网络构建的人也在挣扎，因为它是无形的。 他们很难真正认为在真实商店中会惹恼您的东西会在网上惹恼您，并且确实如此，并且统计数据表明确实如此。

德鲁：我认为在早期，我在想 90 年代后期，在这里显示我的年龄，当我们建立网站时，我们非常考虑性能，但我们从人们之间的联系的角度考虑性能使用太慢了。 我们谈论的是拨号、调制解调器、通过电话线、28K、56K 调制解调器，并且在某一时刻，有一种趋势是使用样式图像，图像的每一行都会用纯色空白来给出这个……如果你可以想象它就像透过百叶窗看图像。 我们这样做是因为它有助于压缩。 因为每隔一行，压缩算法都可以——

哈利：折叠成一个指针。

德鲁：是的。 因此，您已经显着减小了图像尺寸，同时仍然能够获得……它成为了一个设计元素。 每个人都在做。 我想也许 Jeffrey Zeldman 是最早开创这种方法的人之一。 但我们当时考虑的主要是我们能以多快的速度把事情搞定。 不是为了用户体验，因为我们没有考虑……我的意思是我猜这是用户体验，因为我们不希望人们离开我们的网站，本质上。 但是我们正在考虑不要将事物优化为非常快，而是尽量避免它们非常慢，如果这有意义的话。

哈利：是的，是的。

Drew：然后，我认为随着像 ADSL 线路这样的速度变得越来越普遍，我们不再考虑这些术语，而是开始根本不考虑它。 现在我们处于使用移动设备的情况，它们的连接受限，可能 CPU 速度较慢，我们不得不重新考虑它，但这次是为了获得优势。 除了用户体验方面，它还可以在成本和盈​​利能力方面获得真正的商业利益。 不是吗？

哈利：是的，非常好。 我的意思是，不知道如何措辞。 不是在这里开枪打死自己，而是我尝试向客户强调的一件事是，网站速度会给你带来竞争优势，但只有一件事能给你带来竞争优势。 如果您有没有人愿意购买的产品，那么您的网站速度有多快都没有关系。 同样，如果有人真的想要世界上最快的网站，你必须删除你的图片，删除你的 CSS，删除你的 JavaScript，然后看看你告诉了多少产品，因为我保证网站速度不是因素。 但研究表明，速度快有巨大的好处，数以百万计。 在我们说话的时候，我正在和一位客户一起工作。 我们为他们计算出，如果他们可以将给定的页面渲染速度快一秒，或者更确切地说，他们最大的绘制内容快一秒，那么每年价值 180 万，这是一个很大的数字。

德鲁：那几乎可以支付你的费用。

哈利：嘿！ 是的，差不多。 我确实对他们说：“看，两年后这一切都会得到回报。 你会收支平衡”。 我希望。 但是，是的，面向客户的方面......对不起，如果您有一个电子商务网站，他们将花费更多的钱。 如果您是出版商，他们会阅读更多文章，或者他们会查看更多分钟的内容，或者您​​所做的任何事情都是您衡量的 KPI。 可能是在 Smashing 网站上，也可能是他们没有反弹，他们实际上点击了更多文章，因为我们让它变得非常简单和快速。 然后更快的网站运行成本更低。 如果您已对缓存策略进行了排序，那么您将使人们远离您的服务器。 如果您优化您的资产，那么必须来自您的服务器的任何东西的重量都会减少很多。 运行起来便宜很多。

哈利：问题是，到达那里是有代价的。 我认为 Scott Jehl 可能说得最多……我首先是从他那里听到的，所以我假设他想出了这个词，但俗话说“做一个快速的网站很容易，但做一个网站很难快速地”。 这就是如此简洁。 因为网络性能可能会被推到要做的事情列表中的原因是因为您可能可以对客户说“如果我让您的网站快一秒，您将每年多赚 180 万”或者它可以是“如果你刚刚在结账时添加了 Apple Pay，你将多赚 500 万。” 因此，这不仅仅与网络性能有关，也不是决定因素，它是更大战略的一部分，尤其是对于在线电子商务而言。 但有证据表明，我已经与我的零售客户、我的电子商务客户进行了第一手测量。 它的情况就在那里，你是绝对正确的。 这是竞争优势，它会让你赚更多的钱。

Drew：再一次回到过去，但像 Steve Souders 这样的人是第一批真正开始撰写和谈论 Web 性能的人。 像史蒂夫这样的人基本上是在说“忘记后端基础设施，所有的收益都在浏览器中，在前端，一切都慢了。” 15年后还是这样吗？

哈利：是的，是的。 他在当时和现在之间重新进行了测试，差距实际上已经扩大了，所以实际上成本更高。 但是有一个反击，那就是如果你的后端性能真的很差，如果你慢慢地走出大门，那么你只能在前端抓回这么多。 我现在有一个客户，他们到第一个字节的时间是 1.5 秒。 因此，我们的渲染速度永远不会超过 1.5 秒，所以这将是一个上限。 我们仍然可以在前端抢回时间，但是如果您的第一个字节的时间非常非常糟糕，那么您的后端速度就会变慢，您的前端性能努力可以让您加快多少速度是有限度的。 但绝对。

哈利：然而，这正在改变，因为……嗯，不，我猜它没有改变，它变得更糟了。 我们正在将更多内容推给客户。 它曾经是“你的服务器和它一样快但之后我们得到一堆问号”的情况。 因为我经常听到这样的话“我们所有的用户都在 WiFi 上运行。 他们都有台式机，因为他们都在我们的办公室工作。” 嗯，不，现在他们都在家工作。 你没得选。 所以，这就是所有问号出现的地方，这是减速发生的地方，你无法真正控制它。 在那之后，事实上我们现在倾向于把更多的东西放在客户身上。 我的意思是，客户端上的整个运行时间。 无论如何，您已经将所有应用程序逻辑移出服务器，因此您的第一个字节时间应该非常非常少。 应该是从 CDM 发送一些捆绑包到我的……但是你已经从能够规范到你自己的服务器到希望有人没有让 Netflix 在他们试图查看你的网站的同一台机器上运行.

Drew：关于我们设计网站的方式，这是一个非常好的观点，我认为传统的最佳实践一直是你应该尝试迎合各种浏览器、各种连接速度、各种屏幕尺寸，因为你不不知道用户会期待什么。 而且，正如您所说，您会遇到这样的情况，人们会说“哦，不，我们知道我们所有的用户都在他们的工作发布的台式机上，他们正在运行这个浏览器，它是最新版本，他们已经硬连线到 LAN 中”但后来事情发生了。 拥有网络应用程序的一大好处是我们可以做一些事情，比如将我们的劳动力突然全部分配回他们的家中，他们可以继续工作，但这只有在工程质量达到这样的情况下才成立他们的家用机器上可能装有 IE11 或其他任何东西，无论工作质量是否存在，这实际上意味着 Web 发挥了其成为真正可访问媒体的潜力。

Drew：正如你所说，有一种趋势是将越来越多的东西转移到浏览器中，当然，如果浏览器速度很慢，那就是速度变慢的地方。 你不得不怀疑“这是一个好趋势吗？ 我们应该这样做吗？” 我有一个我特别想到的站点，注意到它几乎 100% 呈现服务器。 JavaScript 很少，而且速度极快。 每次我去看它时，我都会想“哦，这太快了，这是谁写的？” 然后我意识到“哦，是的，是我”。

哈利：那是因为你在本地主机上，难怪感觉很快。 这是您的开发网站。

Drew：然后，我的日常工作是构建单页应用程序并将内容从服务器转移，因为在这种情况下服务器是瓶颈。 你能说在浏览器中性能更高吗？ 或者在服务器上性能更高？ 这只是一个根据具体情况衡量和采取的情况吗？

哈里：我认为你需要非常、非常、非常了解你的背景，并且......真的，我认为一个错误是......自恋，人们认为“哦，我的博客应该在某人的浏览器中呈现。 我的博客跳出率为 89%，需要在浏览器中拥有自己的运行时间，因为我需要快速的后续导航，我只想获取一个……基本上是数据的差异。” 无论如何，没有人会点击您的下一篇文章，伙计，不要将运行时推送到管道中。 所以你需要非常了解你的上下文。

Harry：而且我知道……如果 Jeremy Keith 听到这个，他可能会对我大发雷霆，但我想说，网站和网络应用程序之间存在差异，它的定义非常，很模糊。 但是，如果您有一个读写量很大的应用程序，那么您在输入数据、操作数据等的地方。 基本上我的网站不是一个网络应用程序，它是一个网站，它是只读的，我会坚定地加入网站阵营。 像我的会计软件是一个网络应用程序，我会说是一个网络应用程序，我准备承受一点启动时间成本，因为我知道我会在那里呆 20 分钟，一个小时，不管怎样。 所以你需要一些背景知识，也许自恋有点苛刻，但你需要有一个真正的“我们需要让这份报纸成为客户端应用程序吗？” 不，你没有。 不，你没有。 人们已经启用了广告拦截器，无论如何人们都不喜欢通勤报纸网站。 他们可能甚至不会阅读这篇文章并在 Facebook 上大肆宣扬。 只是不要将类似的东西构建为客户端呈现的应用程序，它是不合适的。

哈里：所以我确实认为，在某一点上，更多地关注客户肯定会有所帮助，那就是你对客户流失的敏感性降低的时候。 因此，任何com 类型，例如，我正在为一个站点进行片刻审核……我认为它是一个E-Com 站点，但它是100% 的客户端。 你禁用了 JavaScript，你什么也看不到，只是一个空的 div id="app"。 E-Com 是……你对任何问题都非常敏感。 您的结帐流程甚至有点错误，我在其他地方。 太慢了，我去别的地方了。 您没有人愿意在一段时间内使用该应用程序的上下文。

哈里： Photoshop。 我打开 Photoshop，我很高兴知道这将需要 45 秒的启动画面，因为我将在那里待……基本上 45 秒值得 45 分钟。 这很难定义，这就是为什么我真的很难说服客户“请不要这样做”，因为我不能只说“你认为你的用户会在那里呆多久”。 如果您 89% 的跳出率没有针对第二次页面浏览进行优化，您可以从以下方面进行代理。 首先降低跳出率。 我确实认为肯定存在分歧，但我想说的是，大多数人都站在这条线的错误一边。 大多数人将不应该存在的东西放在客户端中。 例如 CNN，在完全启动 JavaScript 应用程序之前，您无法阅读 CNN 网站上的单个标题。 服务器唯一呈现的是页眉和页脚，这是人们唯一不关心的。

哈利：我觉得那只是……我不知道我们是怎么走到那一步的。 它永远不会是更好的选择。 你提供了一个实际上毫无用处的页面，然后不得不说“酷，我会去获取本来应该是一个网络应用程序的东西，但我们要在浏览器中运行它，然后我会去问一个标题，然后你就可以开始……哦，你走了。” 这真的，真的让我很恼火。

Harry：这不是任何人的错，我认为这是这种 JavaScript 生态系统的起步阶段，围绕它的炒作，而且，这听起来真的很刺耳，但是……这基本上是很多天真的实现。 当然，Facebook 已经发明了 React，不管怎样，它对他们有用。 10 人中有 9 人不是在 Facebook 规模工作，100 人中有 95 人可能不是最聪明的 Facebook 工程师，这真的很残酷，说起来听起来很可怕，但你只能……没有默认情况下，这些东西很快。 你需要一个非常非常优雅的实现这些东西来使它们正确。

Harry：我正在和我的老……讨论这个问题……他是我 10 年前在 Sky 所在球队的首席工程师。 前几天我和他谈过这个问题，他必须非常努力地让客户端渲染的应用程序快速，而让服务器渲染的应用程序快速，你不需要做任何事情。 你只需要不再让它变慢。 而且我觉得有很多玫瑰色眼镜，天真，营销......我听起来很凄凉，我们需要继续前进，然后我才开始真正失去这里的人。

Drew：您认为作为一个行业，我们有时是否倾向于更多地关注开发者体验而不是用户体验？

哈利：不是作为一个整体，但我认为这个问题会出现在你所期望的地方。 如果你看一下这种差异……我不知道你是否看过这个，但我想你已经看到了，你似乎非常了解脉搏，HTTP 存档关于哪些框架和哪些数据之间的差异JavaScript 库与 JavaScript 状态调查相比，JavaScript 库被广泛使用，如果您遵循 JavaScript 调查状态，它会说“哦，是的，75% 的开发人员正在使用 React”，而只有不到 5% 的网站正在使用 React。 所以，我觉得，总的来说，我不认为这是一个问题，但我认为在你所期望的领域，例如对一个框架的高度忠诚度，开发人员的体验是……可能在用户之前得到传播。 我认为不应忽视开发人员的经验，我的意思是，一切都有维护成本。 你的车。 设计时有一个决定，“好吧，如果我们对机制隐藏这个键，那个功能，那么这个机制会花费更长的时间来修复它，因此我们不会做那样的事情”。 所以确实需要在人体工程学和可用性之间取得平衡，我认为这很重要。 我认为主要关注开发人员体验对我来说只是莫名其妙。 不要为你优化，为你的客户优化，你的客户付钱给你，不是相反。

德鲁：所以当你看到每个人都说“哦，你应该使用这个，你应该这样做”时，在线回声室并不能完全代表现实，那么这实际上只是一小部分人。

哈利：是的，这是一件好事，让人放心。 回音室……如果你想这样称呼它，那么拥有那种单一文化也许是不健康的。 而且，我觉得……而且我在我自己的很多工作、很多开发人员中都看到了这一点……作为一名顾问，我与很多不同的公司合作。 很多人都在 WordPress 中做着惊人的工作。 WordPress 为 24% 的网络提供支持。 而且我觉得对于像这样的开发人员来说，在后端使用 WordPress 或 PHP 之类的东西，自定义代码，不管它是什么，感觉有点像“哦，我猜每个人都在使用 React 而我们不是” 但实际上，没有。 每个人都在谈论 React，但你仍然随波逐流，你仍然是大多数人。 找到沉默的大多数是相当令人欣慰的。

Drew：静态网站生成器的趋势，然后将网站完全托管在 CDN 上，有点像 JAMstack 方法，我想当我们谈论那些发布类型的网站，而不是软件类型的网站时，我想这是一个非常健康的趋势，你觉得呢？

哈利：我非常喜欢，绝对。 你还记得我们以前把 SSG 称为“flap 文件”的时候吧？

德鲁：是的。

Harry：所以，当 Jekyll 被称为翻页文件网站时，我在 Jekyll 上构建了 CSS Wizardry。 但现在我们为我们的发电机提供服务，这是它的超级超级粉丝。 There's no disadvantage to it really, you pay maybe a slightly larger up front compute cost of pre-compiling the site but then your compute cost is… well, Cloudflare fronts it, right? It's on a CDN so your application servers are largely shielded from that.

Harry: Anything interactive that does need doing can be done on the client or, if you want to get fancy, what one really nice approach, if you are feeling ambitious, is use Edge Side Includes so you can keep your shopping cart server rendered, but at the edge. You can do stuff like that. Tremendous performance benefits there. Not appropriate for a huge swathe of sites, but, like you say, if we're thinking publishing… an E-Com site it wouldn't work, you need realtime stock levels, you need… search that doesn't just… I don't know you just need far more functionality. But yeah, I think the Smashing site, great example, my site is an example, much smaller than Smashing but yeah, SSG, flap filers, I'm really fond of it.

Drew: Could it work going deeper into the JAMstack approach of shifting everything into the client and building an E-Commerce site? I think the Smashing E-Commerce site is essentially using JavaScript in the client and server APIs to do the actual functionality as service functions or what have you.

Harry: Yeah. I've got to admit, I haven't done any stuff with serverless. But yeah, that hybrid approach works. Perhaps my E-Commerce example was a bit clunky because you could get a hybrid between statically rendering a lot of the stuff, because most things on an E-Com site don't really change. You filter what you can do on the client. Search, a little more difficult, stock levels does need to go back to an API somewhere, but yeah you could do a hybrid for a definite, for an E-Com site.

Drew: Okay, so then it's just down to monitoring all those performance metrics again, really caring about the network, about latency, about all these sorts of things, because you're then leaning on the network a lot more to fetch all those individual bits of data. It hosts a new set of problems.

Harry: Yeah, I mean you kind of… I wouldn't say “Robbing Peter to pay Paul” but you are going to have to keep an eye on other things elsewhere. I've not got fully to the bottom of it, before anyone tweets it at us, but a client recently moved to an E-Commerce client. I worked with them two years ago and that site was already pretty fast. It was built on… I can't remember which E-Com platform, it was .net, hosted on IIS, server rendered, obviously, and it was really fast because of that. It was great and we just wanted to maintain, maybe find a couple of hundred milliseconds here and there, but really good. Half way through last year, they moved to client side React for key pages. PP… product details page, product listing page, and stuff just got marketable slower lower, much slower. To the point they got back in touch needing help again.

Harry: And one of the interesting things I spotted when they were putting a case for “We need to actually revert this”. I was thinking about all the…what's slower, obviously it's slower, how could doing more work ever be faster, blah blah blah. One of their own bullet points in the audit was: based on projections, their yearly hosting costs have gone up by a factor of 10 times. Because all of a sudden they've gone from having one application server and a database to having loads of different gateways, loads of different APIs, loads of different microservers they're calling on. It increased the surface area of their application massively. And the basic reason for this, I'll tell you exactly why this happened. The developer, it was a very small team, the developer who decided “I'm going to use React because it seems like fun” didn't do any business analysis. It was never expected of them to actually put forward a case of how much is it going to cost the dude, how much is it going to return, what's the maintenance cost of this?

Harry: And that's a thing I come up against really frequently in my work and it's never the developer's fault. It's usually because the business keeps financials away from the engineering team. If your engineers don't know the cost or value of their work then they're not informed to make those decisions so this guy was never to know that that was going to be the outcome. But yeah, interestingly, moving to a more microservice-y approach… And this is an outlier, and I'm not going to say that that 10 times figure is typical, it definitely seems atypical, but it's true that there is at least one incident I'm aware of when moving to this approach, because they just had to use more providers. It 10x'ed their… there's your 10 times engineer, increased hosting by 10 times.

Drew: I mean, it's an important point, isn't it? Before starting out down any particular road with architectural changes and things about doing your research and asking the right questions. If you were going to embark on some big changes, say you've got a really old website and you're going to structure it and you want it to be really fast and you're making all your technology choices, I mean it pays, doesn't it, to talk to different people in the business to find out what they want to be doing. What sort of questions should you be asking other people in the business as a web developer or as a performance engineer? Who should you be talking to you and what should you be asking them?

Harry: I've got a really annoying answer to the “Who should you be talking to?” And the answer is everyone should be available to you. And it will depend on the kind of business, but you should be able to speak to marketing “Hey, look, we're using this AB testing tool. How much does that cost as a year and how much do you think it nets as a year?” And that developer should feel comfortable. I'm not saying developers need to change their attitude, what I mean is the company should make the developers able to ask those kind of questions. How much does Optimizely cost as a year? Right, well that seems like a lot, does it make that much in return? Okay, whatever we can make a decision based on that. That's who you should be talking to and then questions you should ask, it should be things like…

Harry: The amount of companies I work will, they won't give their own developers to Google Analytics. How are you meant to build a website if you don't know who you're building it for? So the question should be… I work a lot with E-Com clients so every developer should things like “What is our average order value? What is our conversion rate? What is our revenue, how much do we make?” These things mean that you can at least understand that “Oh, people spend a lot of money on this website and I'm responsible for a big chunk of that and I need to take that responsibility.”

Harry: Beyond that, other things are hard to put into context, so for me, one of things that I, as a consultant, so this is very different to an engineer in the business, I need to know how sensitive you are to performance. So if a client gives me the average order value, monthly traffic, and their conversion rate, I can work out how much 100 milliseconds, 500 a second will save them a year, or return them, just based on those three numbers I can work out roughly “Well a second's worth 1.8 mil”. It's a lot harder for someone in the business to get all the back information because as a performance engineer it's second nature to me. But if you can work that kind of stuff out, it unlocks a load of doors. Okay, well if a second's work this much to us, I need to make sure that I never lose a second and if I can, gain a second back. And that will inform a lot of things going forward. A lot of these developers are kept quite siloed. “Oh well, you don't need to know about business stuff, just shut up and type”.

Drew: I've heard you say, it is quite a nice soundbite, that nobody wants a faster website.

Harry: Yeah.

Drew: What do you mean by that?

Harry: Well it kind of comes back to, I think I've mentioned it already in the podcast, that if my clients truly wanted the world's fastest website, they would allow me to go in and delete all their JavaScript, all their CSS, all their images. Give that customer a Times New Roman stack.

Harry: But fast for fast sake is… not chasing the wrong thing but you need to know what fast means to you, because, I see it all the time with clients. There's a point at which you can stop. You might find that your customer's only so sensitive to web perf that it might mean that getting a First Contentful Paint from four seconds to two seconds might give you a 10% increase in revenue, but getting from that two to a one, might only give you a 1% increase. It's still twice as fast, but you get minimal gains. So what I need to do with my clients is work out “How sensitive are you? When can we take our foot off the gas?” And also, like I said, towards the top of the show… You need to have a product that people want to buy.

Harry: If people don't want to buy your product, it doesn't matter how quickly you show them it, it'll just disgust them faster, I guess. Is your checkout flow really, really, really seamless on mobile, for example. So there's a number of factors. For me, and my clients, it'll be working out a sweet spot, to also working out “If getting from here to here is going to make you 1.8 mil a year, I can find you that second for a fraction of that cost.” If you want me to get you an additional second on top of that, it's going to get a lot harder. So my cost to you will probably go up, and that won't be an extra 1.8, because it's not lineal, you don't get 1.8 mil for every one second.

Harry: It will tail off at some point. And clients will get to a point where… they'll still be making gains but it might be a case of your engineering effort doubles, meaning your returns halve, you can still be in the green, hopefully it doesn't get more expensive and you're losing money on performance, but there's a point where you need to slow down. And that's usually things that I help clients find out because otherwise they will just keep chasing speed, speed, speed and get a bit blinkered.

Drew: Yeah, it is sort of diminishing returns, isn't it?

Harry: That's what I was look for-

德鲁：是的。

Harry: … diminishing returns, that's exactly it. 是的，正是。

Drew: And in terms of knowing where to focus your effort… Say you've got the bulk of your users, 80% of your users are getting a response within two, three seconds, and then you've got 20% who may be in the long-tail that might end up with responses five, ten seconds. Is it better to focus on that 80% where the work's really hard, or is it better to focus on the 20% that's super slow, where the work might be easier, but it's only 20%. How do you balance those sorts of things?

Harry: Drew, can you write all podcast questions for everyone else? 这太好了。 Well, a bit of a shout out to Tim Kadlec, he's done great talks on this very topic and he calls it “The Long-Tail of Web Performance” so anyone listening who wants to look at that, Tim's done a lot of good firsthand work there. The 80, 20, let's just take those as good example figures, by the time you're dealing with the 80th percentile, you're definitely in the edge cases. All your crooks and web file data is based around 75th percentile. I think there's a lot of value investing in that top 20th percentile, the worst 20%. Several reasons for this.

Harry: First thing I'm going to start with is one of the most beautiful, succinct soundbites I've ever heard. And the guy who told me it, I can guarantee, did not mean it to be this impactful. I was 15 years old and I was studying product design, GCSE. Finally, a project, it was a bar stool so it was a good sign of things to come. And we were talking about how you design furniture. And my teacher basically said… I don't know if I should… I'm going to say his name, Mr. Brocklesby.

哈里：他赢得了尊重，但他是小伙子中的一员，我们都非常喜欢他。 但他在各个方面都是巨大的。 身高超过六英尺，但只是个大男孩。 大，大，大，大人。 他对我们说：“如果你要设计一个门口，你会为普通人设计吗？” 15 岁的大脑会说“嗯，是的，如果每个人的身高都大约是 5 英尺 9 英寸，那么是的”他就像“嗯，马上，哈利不能使用那扇门。” 您不是为普通人设计，而是为四肢设计，因为您希望它对大多数人有用。 如果你为普通人设计一把椅子，Brocklesby 先生不会适合它。 所以他从一个非常非常大的年龄教我设计到你的四肢。

Harry：在网络性能中真正有趣的地方是......如果你想象一个梯子，然后你用机器人拿起梯子......好吧，我刚刚意识到我的比喻可能......我会坚持下去，你可以笑之后我。 想象一个梯子，你通过底部的梯级将梯子抬起。 那是你最糟糕的经历。 您选择梯子的底部梯级将其抬起。 整梯随其而来，如涨潮浮舟。 比喻不起作用的原因是，如果你从最上面的梯级拿起梯子，它也会升起来，它就是梯子。 如果我把它变成一个绳梯，这个比喻甚至都行不通，因为一个绳梯，你抬起底部梯级，什么都没有发生，但是……我的意思是，如果你能提高 90% 的体验，它必须把它提高到你的第 10 个百分位，对吧？

哈里：这就是为什么我告诉客户，他们会对我说“哦，我们的大多数用户都在 iPhone 上使用 4G”之类的话，好吧，我们开始在 Android 上测试 3G，比如“不，不，我们的大多数用户都是 iPhone”好吧……这意味着您的普通用户将获得更好的体验，但任何尚未处于第 50 个百分位的人都会被远远甩在后面。 因此，通过将期望设置得相当低，为自己设置相当高的标准。

哈利：对不起，我有一个很坏的习惯，就是对简短的问题给出很长的答案。 但这是一个绝妙的问题，而且，尝试总结一下，我 100% 肯定同意你的观点，你想看看那个长尾，你想看看那个……你的第 80 个百分位，因为如果你把所有的经验都放在该网站并查看中位数，并且您提高了中位数，这意味着您已经让那些已经非常满意的人变得更好。 50% 的人被有效地忽视不是正确的方法。 是的，它总是回到布洛克斯比先生告诉我“不要为普通人设计，因为那样哈利就不能使用门”。 哦，对于任何人来说，我是 193 厘米，所以我很瘦，就是这样。

德鲁：还有那些胳膊和腿。

哈利：是的。 这也是另一个很好的。 我的女朋友最近发现了 iOS 中的辅助功能设置……所以每个人的手机都处于静音状态，对吧？ 没有人真正拥有真正响起的电话，每个人都将其设为静音。 她发现“哦，你知道，你可以设置它，这样当你收到一条消息时，闪光灯就会闪烁。 如果你点击手机背面两次，它就会截屏。” 这些是可访问性设置，它们是为第 95 个百分位设计的。 然而她就像“哦，这真的很有用”。

Harry： OXO Good Grips 也是如此。 OXO Good Grips，厨房用具。 我在厨房里有很多。 它们的设计是因为创始人的妻子患有关节炎，他想制作更舒适的器皿。 他为 99% 的人设计的，大多数人没有关节炎。 但是通过为 99% 进行设计，不经意间，其他所有人都会说“天哪，为什么所有的土豆削皮器都不能这么舒服？” 而且我觉得它真的，真的……我喜欢在这些场景中推出的感觉良好或轶事。 但是，是的，如果您针对他们进行优化……嗯，涨潮会使所有船只飘浮，因此优化了人们的尾端，您将在此之上吸引更多更快乐的客户。

德鲁：你有 OXO Good Grips 手动手动打蛋器吗？

哈利：我没有。 没有，好用吗？

德鲁：调查一下。 它是那么好。

哈利：我确实有 OXO Good Grips 曼陀林切片机，它上周把我的手指末端弄断了。

德鲁：是的，我不会靠近其中一个。

哈利：是的，这是我自己愚蠢的错。

德鲁：从我自己的经验中获得长尾服务的另一个例子是，在我目前正在进行的项目中，长尾就在最后，你有表现最慢的人，但如果你看看这些客户是谁，他们是企业最有价值的客户——

哈利：好的。

德鲁： ……因为他们是拥有最多数据的最大组织。

哈利：对。

Drew：所以他们遇到了瓶颈，因为他们有太多的数据要显示在页面上，而这些页面需要稍微重构以帮助该用例。 因此，他们的体验最慢，归根结底，他们支付的钱最多，并且比所有拥有真正快速体验的人产生的影响要大得多，因为他们是免费用户，拥有少量的数据，一切都很好，而且速度很快。

哈利：那是一个迷人的维度，不是吗？ 事实上，我也有类似的情况……我对业务的影响远没有你刚才描述的那样，但几年前我和一个客户合作过，他们的 CEO 联系了他们，因为他们的网站速度很慢。 比如，慢，慢，慢。 也是非常好的人，他只是一个非常接地气的人，但他受到指导，就像真正的有钱人一样。 他有最新的 iPhone，他买得起。 他是一位千万富翁，他花费大量时间往返于他来自的澳大利亚和他现在居住的爱沙尼亚之间。

哈利：而且他坐的是头等舱，他当然是。 但这意味着他大部分时间都在他漂亮、闪亮的 iPhone 12 Pro Max 上，不管怎样，都是通过飞机 WiFi 进行的，这太糟糕了。 正是这种惊人的并列，他拥有该网站并且他经常使用它，这是他使用的网站。 他正在推动它……我的意思是，他们最富有的客户很容易就是他们的首席执行官。 而且他处于这个奇怪的特权位置，他的联系比 Joe Public 更糟糕，因为他在新加坡上空的某个地方乘坐 Quantas 的航班，香槟倒在他的脖子上，他正在挣扎。 这是一个非常令人着迷的见解……哦，是的，因为你有 95% 的百分位基本上可以朝任何一个方向发展。

德鲁：是的，当你开始优化使用一个手里拿着一杯香槟的网站时，你会想“也许我们开始有点迷路了”。

哈利：是的，没错。

德鲁：我们谈了一点关于绩效衡量的问题，根据我自己在绩效工作中的经验，衡量每一个问题非常重要你正在做出不同，你正在做出多大的改变。 我们应该如何衡量我们网站的性能？ 我们可以使用哪些工具，我们应该从哪里开始？

哈利：哦，伙计，另一个好问题。 因此，根据修复站点速度的时间、资源和倾向，有一系列答案。 所以我将尝试对客户做的是……某些现成的指标非常好。 加载时间，不再关心这个了。 它非常、非常、非常……我的意思是，如果您的加载时间为 120 秒，它是一个很好的代理。我猜您的网站速度不是很快，但它太晦涩难懂而且不是真正面向客户的。 实际上，我认为 Vitals 是朝着正确方向迈出的非常好的一步，因为它们确实衡量了用户体验，但它们基于技术输入。 Largest Contentful Paint 对视觉来说是一件非常好的事情，但其中的技术内容可以畅通您的关键路径，确保英雄图像快速到达并确保您的网络字体策略是体面的。 这些指标存在技术暗流。 那些现成的真的很好。

Harry：但是，如果客户有时间，通常是时间，因为您想要捕获数据但您需要时间来实际捕获数据。 所以我尝试与客户一起做的是让我们去“看，我们不能在接下来的三个月里一起工作，因为我已经订满了。 所以，我们能做的就是快速让您免费试用 Speedcurve，设置一些自定义指标”，这意味着对于出版商客户、报纸，我将衡量“文章呈现？ 文章的主要图片渲染速度有多快？” 对于我想要衡量的电子商务客户，因为显然您正在衡量诸如开始被动渲染之类的东西。 一旦您开始使用任何性能监控软件，您就可以免费获取实际的性能指标。 因此，您的第一个内容丰富的绘画、最大的内容内容等。我真正想要捕捉的是对他们作为企业而言重要的事情。

Harry：所以，在我们能够关联的那一刻与 E-Com 客户合作……您的开始渲染速度越快，添加到购物车的概率是多少。 如果您能尽快向他们展示产品，他们就更有可能购买。 这需要付出很多努力，对于真正有抱负的客户来说，这是一种延伸目标，但任何你真正想要衡量的东西，因为就像我说的，你真的不想衡量你最大的目标Contentful Paint 是，您想衡量您的收入，这是否受到大型 Contentful Paint 的影响？ 因此，延伸目标，即最终目标，将是您认为该业务的 KPI 的任何内容。 可能是，在报纸上，有人将文章向下滚动了多远？ 这是否与第一次输入延迟有任何关系？ 如果 CLS 较低，人们是否阅读了更多文章？ 但在我们开始进行自定义、自定义指标之前，老实说，我认为 Web Vitals 是一个非常好的起点，而且它也已经很好地标准化了。 它变成了一个……我不知道这个词是什么。 我猜是最低公分母，现在行业中的每个人都可以在这个公平的竞争环境中讨论表现。

Harry：我遇到的一个问题是，我实际上需要与 Vitals 团队开会，我也真的认为 Lighthouse 很棒，但 CLS 占 web Vitals 的 33%。 你有 LCP、FID、CLS。 CLS 占您生命体征的 33%。 Vitals 是通常出现在您的营销团队、分析部门面前的内容，因为它会在搜索控制台中弹出，在搜索结果页面的上下文中被提及，而 Vitals 则具有很高的权重，33%，三分之一Vitals 是 CLS，它只占我们 Lighthouse 分数的 5%。 所以你会得到的是围绕 Lighthouse 构建的开发人员，因为它可以集成到工具中，这是一个实验室指标。 Vitals 是现场数据，是朗姆酒。

Harry：所以你有一个巨大的脱节，你的营销团队说“CLS 真的很糟糕”，而开发人员认为“嗯，这是 DevTools 给我的 Lighthouse 分数的 5%，这是分数的 5% Lighthouse CLI 在 CircleCI 中为我们提供了“或任何您正在使用的东西，但对于营销团队来说，他们关心的是 33% 的内容。 所以问题有点脱节，因为我确实认为 Lighthouse 非常有价值，但我不知道他们如何调和在生命体征中的相当大的差异，CLS 是你得分的 33%……嗯，不是因为你得分真的没有，Lighthouse 只有 5%，在我们可以无缝讨论之前，仍然需要解决这些问题。

哈利：但是，再一次，对一个简短问题的长回答。 生命体征真的很好。 LCP 是一个很好的用户体验指标，可以归结为技术解决方案，与 CLS 相同。 所以我认为这是一个非常好的起点。 除此之外，它是自定义指标。 我试图让我的客户达到一个点，他们并不真正关心他们的网站有多快，他们只关心他们从昨天赚更多的钱，如果这样做是因为它运行得很快？ 如果它减少了，是因为它运行得更慢了吗？ 我不希望他们追逐神秘的两秒 LCP，我希望他们追逐最优的 LCP。 如果这实际上比你想象的要慢，那么无论如何，没关系。

Drew：所以，对于只对……感兴趣的 Web 开发人员来说……他们没有预算花在 Speedcurve 之类的工具上，他们显然可以在浏览器中运行 Lighthouse 之类的工具，以获得一些好的测量结果……像 Google 这样的东西吗？分析对那个级别有用吗？

哈利：它们是，而且它们可以变得更有用。 多年来，分析已经捕获了基本的性能信息。 这将是 DNS 时间、TCP 和 TLS、第一个字节的时间、页面下载时间，这是一个代理......好吧，无论如何，只是页面下载时间和加载时间。 所以相当笨重的指标。 但这是一个很好的起点，通常我从客户开始的每个项目，如果他们没有 New Relic 或 Speedcurve 或其他什么，我只会说“好吧，让我看看你的分析”，因为我可以至少从那里代理情况。 它永远不会像 Speedcurve 或 New Relic 或 Dynatrace 之类的那样好。 您可以非常、非常、非常轻松地将自定义指标发送到分析。 如果有人收听希望能够发送……例如我的网站。 我有一些指标，比如“你能多快阅读我的一篇文章的标题？ 关于页面图像是在什么时候呈现的？ 在什么时候呼吁采取行动，恳求你雇用我？ 多久会渲染到屏幕上？” 捕获这些数据真的很简单，将其发送到分析几乎同样简单。 因此，如果有人想在我的网站上查看源代码，向下滚动到结束正文标签并找到分析片段，您将看到我捕获自定义数据并将其发送到分析是多么容易。 而且，在分析 UI 中，您无需执行任何操作。 通常，您必须设置自定义报告并挖掘数据并使其易于呈现。 这些是谷歌分析中的一等公民。 因此，当您开始捕获自定义分析时，仪表板的整个部分都专门用于它。 GA 本身没有设置，也没有繁重的工作，所以这真的很简单，如果客户有真正的预算，或者我想向他们展示自定义监控的力量，我不想说“哦，是的，我保证真的很好，我可以为 Speedcurve 准备 24 个 Grand 吗？” 我可以先说“看，这是初级的。 让我们看看这里的可能性，现在我们也许可以说服你升级到像 Speedcurve 这样的东西。”

Drew：我经常发现，我对某件事应该有多快或改变应该产生什么影响的直觉可能是错误的。 我会做出改变，并认为我让事情变得更快，然后我测量它，实际上我让事情变得更慢。 这只是我在网络性能上的垃圾吗？

哈利：一点也不。 我有一个非常相关的例子。 预加载……对于没有听说过预加载的人来说，这是一个真正的快速介绍，在网络上加载某些资产本质上非常慢，这里的两个主要候选者是 CSS 和网络字体的背景图像，因为在你可以下载背景图像之前，你有下载 HTML，然后下载 CSS，然后 CSS 显示“哦，主页上的这个 div 需要这个背景图片。” 所以它本质上是非常慢的，因为你有整个 CSS 时间介于两者之间。 使用预加载，您可以在 HTML 中的 head 标签中添加一行内容：“嘿，您还不知道，但是，相信我，您很快就会需要这张图片。” 因此，您可以在 HTML 中放置一个预加载，该预加载会抢先启动此下载。 当 CSS 需要背景图像时，就像“哦，太棒了，我们已经得到它了，真快。” 这被吹捧为这个网络表演弥赛亚......事情就是这样，我向你保证，我上周发了这个推文，从那以后我两次被证明是对的。 人们听说了预加载，以及它给出的承诺，而且它也受到 Lighthouse 的大力推动，理论上，它可以让您的网站更快。 人们对预加载的想法如此执着，以至于即使我可以证明它不起作用，他们也不会再次删除它。 因为“不，但灯塔说。” 现在这是理论合理的事情之一。 如果您必须等待您的网络字体，而不是早点下载它，您会更快地看到内容。 问题是，当您考虑 Web 的实际工作方式、您第一次访问的任何页面、您访问的任何全新域时，您的带宽是有限的，而浏览器非常聪明地正确地使用了该带宽。 它会非常快速地浏览您的 HTML 并制作购物清单。 最重要的是 CSS，然后是这个 jQuery，然后是这个……然后接下来的几件事是这些，这些，以及这些优先级较低的。 一旦您开始使用预加载加载 HTML，您就是在告诉浏览器“不，不，不，这不再是您的购物清单了，伙计，这是我的。 你得去拿这些。” 有限的带宽仍然是有限的，但它并没有花在更多的资产上，所以一切都会稍微变慢。 在过去的一周里，我不得不发出两次嘘声，但仍然有人说“是的，但不是，因为它下载得更快了。” 不，它被请求得更快，但它正在从你的 CSS 中窃取带宽。 您可以从字面上看到您的网络字体正在从您的 CSS 中窃取带宽。 所以这是你必须、必须、必须遵循数字的事情之一。 我以前在大型客户上做过。 如果你在听这个，你听说过这个客户，我非常坚持“不，不，你的头部标签顺序错误，因为它应该是这样的，你需要把它们放在这个订购，因为从理论上讲，它暗示了……”即使在我对客户的印象中，我也知道我是在为自己设置一个傻瓜。 由于浏览器的工作方式，它必须更快。 因此，我正在对数以百万计的人进行这种策略，这种改变，而且速度变慢了。 它变慢了。 而我坐在那里，愤愤不平地坚持“不，但是，浏览器是这样工作的”是没有用的，因为它不工作。 我们恢复了它，我就像“对不起！ 仍然要为此开具发票！” 所以根本不是你。

德鲁：按照这些数字。

哈利：是的，没错。 “我实际上要向你收取更多费用，因为我花了时间恢复它，花了我更长的时间。” 但是，是的，你是绝对正确的，不是你，这是其中之一……我已经做了很多次，规模要小得多，我会说“嗯，这理论上必须有效”，但它没有不。 你只需要跟随现实世界中发生的事情。 这就是为什么监控非常重要。

Drew：随着环境的变化和技术的发展，谷歌推出了新技术来帮助我们加快速度，有没有什么好方法可以让我们跟上变化？ 在网络性能方面，我们是否应该寻找任何资源来使我们的技能保持最新？

Harry：为了快速解决整个“谷歌制作”……我知道这有点开玩笑，但我会专注于这个。 我想一开始就押注在浏览器上。 例如，像 AMP 之类的东西，它们充其量只是一个经过深思熟虑的解决方案。 建立一个快速的网站是无可替代的，当你开始使用 AMP 之类的东西时，你必须坚持那些非标准的标准，AMP 团队会改变主意。 我有一个客户花了一大笔钱从 AMP 允许列出的字体提供商那里获得字体许可，然后在某个时候，AMP 决定“哦，实际上不，提供的字体，我们现在要阻止它们”所以我有一个客户谁在 AMP 和这个字体提供商上投入巨资，不得不选择“好吧，我们是撤消所有 AMP 工作，还是我们只是在网络字体上浪费了这个非常大的数字”等等。 所以我对任何人都非常警惕……我是一名 Google 开发人员专家，但我不知道任何令人作呕的命令……我可能很挑剔，我会说……避免被称为单一尺寸的东西- 万能的解决方案，例如 AMP。

Harry：为了让别人暂时倾倒，Cloudflare 有一个叫做 Rocket Loader 的东西，它是 AMP 式的。 它的设计就像“哦，只要在你的 CDN 上打开这个东西，它会让你的网站更快。” 实际上，它只是一开始就正确构建站点的替代品。 所以……为了解决这方面的问题，尽量保持独立，了解浏览器的工作原理，这立即意味着 Chrome 的单一文化，你又回到了谷歌的圈子里，但知道浏览器是如何工作的，坚持一些基本的意识形态。 在构建站点时，请查看页面。 无论是在 Figma、Sketch 还是其他任何地方，看看设计并说“嗯，这是用户首先想要看到的，所以我不会做任何事情。 我不会懒惰地加载这个主图像，因为那很愚蠢，我为什么要这样做？” 所以只要想一想“你希望用户首先是什么？” 在 E-Com 网站上，它将是那个产品图像，可能同时是导航，但是产品的评论、产品的 Q 和 A 会延迟加载。 把它藏在 JavaScript 后面。

Harry：无论您正在阅读什么技术，某些基本的工作方式都会为您服务，即“优先考虑客户的优先事项”。 做更多的工作会更快，所以不要把事情放在一边，而是让人们意识到更多的战术性事情，跟上……再次，直接回到谷歌，但是 web.dev被证明是框架不可知论、堆栈不可知论见解的非凡资源……所以如果你想了解生命体征，你想了解 PWA，所以 web.dev 真的很棒。

Harry：实际上很少有以性能为中心的出版物。 Calibre 的电子邮件是，我认为它每两周一次的电子邮件非常出色，它是一个非常好的摘要。 密切关注 Web 平台，所以有性能工作组，他们在 GitHub 提案上有很多东西。 再次回到谷歌，但没有人知道这个网站及其惊人的：chromestatus.com。 它准确地告诉你 Chrome 正在做什么，来自其他浏览器的信号是什么，所以如果你想看看优先提示的工作是什么，你可以去获取所有相关错误跟踪器的链接。 Chrome 状态会向您显示每个里程碑……“这是在 MAT8 中发布的，这是在 67 年发布的”或其他任何东西，这对于相当技术性的见解来说是一件非常好的事情。

哈利：但我一直在谈论这件事，我知道我可能听起来像“老人对克劳德大喊大叫”，但坚持基本原则，我所赚取的几乎每一英镑或美元、欧元，都在教客户“你知道浏览器已经这样做了，对吧”或“你知道这不可能更快”，这听起来对我很有道理……我从来没有从销售额外技术中赚到一分钱。 我赚的每一点钱都是关于去除，减去。 如果您发现自己添加了一些东西以使您的网站更快，那么您就走错了方向。

哈里：举个例子，我不打算点名……大型广告/搜索引擎/浏览器公司，不打算点名，也不打算点名 JavaScript 框架，但我目前在与一个非常、非常大、非常流行的 JavaScript 框架讨论删除正在积极损害的东西，或者有选择地删除会损害大量网站性能的东西。 他们就像“哦，我们要循环进来……”来自这家大公司的某个人，因为他们做了一些研究……就像“我们需要一个选项来删除这个东西，因为你可以在这里和这里看到，并且这让这个网站变慢了。” 他们的解决方案是添加更多，比如“哦，但如果你也这样做，那么你可以回避那个”，就像“不，不，添加更多以使网站更快一定是错误的解决方案。 如果需要更多代码才能最终获得更快的网站，那么您肯定会发现您正朝着错误的方向前进。”

哈里：因为它一开始很快，而你添加的所有东西都会让它变慢。 以及添加更多以使其更快的想法，尽管……它可能会在更快的网站中表现出来，但这是错误的方式。 这是一场逐底竞赛。 对不起，我真的很生气，你可以看出我有一段时间没有咆哮了。 所以这是另一回事，如果您发现自己添加功能以使网站更快，那么您可能正朝着错误的方向前进，通过删除东西来加快速度要比添加它们更有效。

Drew：您制作了一个视频课程，名为“我为快速制作 CSS 魔法所做的一切”。

哈利：是的！

Drew：这和传统的在线视频课程有点不同，不是吗？

哈利：是的。 老实说，部分原因是……我不想说我的懒惰，但我不想设计一个必须非常严格的课程，让你从零到英雄，因为这样做需要时间是巨大的，我不知道我是否会有时间。 所以我想要的是有现成的材料，只是屏幕投射我自己通过它说话，所以它不会以“这是一个浏览器，这是它的工作原理”开始，所以你至少需要知道网络性能基础知识，但它是黑客和专业技巧以及现实生活中的例子。

哈里：而且因为我不需要完成完整的课程，我能够将价格大幅降低。 所以这不是一个 10 小时的大型课程，可以让你从零到英雄，它是你认为合适的进进出出。 它基本上只是在查看我的网站，这是一个非常适合不稳定事物的游乐场，或者……我在那里进行实验的风险非常低。 所以我刚刚完成了视频系列。 录制非常有趣。 只是拆除我自己的网站并谈论“这就是它的工作原理，这就是你如何使用它”。

Drew：我认为将其拆分为解决不同的问题真的很棒。 如果我想了解更多关于优化图像或其他内容的信息，我可以想“好吧，我的伙伴 Harry 对此有什么看法？”，然后观看有关图像的视频，然后我就走了。 以这种方式真的很容易获得，你不必坐几个小时的东西，你可以去你想要的地方，学习你需要学习的东西，然后出去。

哈里：我想我试着保持更多……不做死板课程的好处是你不需要先看某个视频，没有介绍，只是“去看看周围，看看你觉得有趣的东西”这意味着遇到 LTP 问题的人会说“哦，我必须在这里深入研究这个文件夹”，或者如果他们遇到 CSS 问题，他们可以深入研究那个文件夹。 显然我没有统计数据，但我想课程的放弃率很高，纯粹是因为你必须跋涉三个小时的介绍，以防你错过了什么，就像“哦，你知道吗，我不能每天都这样做”，人们可能会放弃很多课程。 所以我的想法只是潜入，你不需要看到前三个小时，你可以去寻找你想要的任何东西。 并且反馈真的，真的......事实上，我要做的是，它还不存在，但我会在通话后立即做，任何使用折扣代码 SMASHING15 的人，他们将获得 15% 的折扣其中。

德鲁：所以这几乎就像你已经优化了课程本身的性能，因为你可以直接进入你想要的部分，而不必进行所有谈判并且-

哈利：是的，是无意的，但我会为此负责。

Drew：所以，我一直在学习有关 Web 性能的所有知识，Harry，你最近在学习什么？

哈利：技术的东西……不是真的。 我的“要学习”清单上有很多东西，所以 QUIC、H3 之类的东西我想获得更多关于这方面的工作知识，但我在英国第一次封锁期间写了一本电子书，所以我学会了如何制作非常有趣的电子书，因为它们只是 HTML 和 CSS，而且我知道我的方法，所以这非常有趣。 我为这门课学习了非常基本的视频编辑，我喜欢这些都不是概念性的工作。 显然，学习一门编程语言，你必须与概念搏斗，而学习电子书只是工作流程和……我以前从未修改过的东西，所以学习很有趣，但不需要改变职业，所以这很好。

哈利：然后，非技术性的东西……我骑了很多自行车，我从自行车上摔下来了很多……而且因为自去年三月以来我几乎没有旅行过，现在已经快一年了，我已经做了很多骑自行车并更多地关注……改善这一点。 因此，我一直在围绕功率输出和功能性阈值功率进行大量研究，目前我正在做一个训练计划，因此经常，不断地疲惫的腿，但我正在学习很多关于骑自行车的生理学。 我不知道为什么，因为除了继续骑行之外，我没有任何计划对它做任何事情。 这真的很迷人。 我觉得在封锁期间我很幸运，复数，但我设法保持活跃。 很多人会错过一些简单的事情，比如每天上班通勤、伸展双腿的好机会。 如您所知，在英国，骑自行车非常受欢迎，因此我一直在努力从更生理的角度学习更多有关骑自行车的知识，这意味着……不知道，只是一个书呆子换个东西。

Drew：网络上的性能优化和自行车上的性能优化之间可能没有太大区别，都是边际收益，对吧？

哈利：是的，没错。 还有我在自行车上查看的图表数量……我已经从自行车上获得了功率数据，我会出去骑车然后回来，就像“哦，如果我在这里还有 5 瓦，然后节省了 10瓦在那里，我可以做到这一点，这个，这是有史以来最快的”，并且……对此非常着迷。 但是，是的，你是对的。 你知道吗，我想你在那里发现了一些真正感兴趣的东西。 我认为这种事情对于有点痴迷，喜欢追逐数字的人来说是一项很好的运动/消遣。 有些事情，我的意思是你会知道这一点，但是，Strava，你有你的 KOM。 去年我买了 19 个，对我来说，这是一个惊人的数字。 这几乎全来自对可用数据的痴迷，并看着“我试图击败的这个人，他现在的功率是 700 瓦，如果我能达到 1000 瓦然后停止”，等等，等等，等等......这是强迫症。 书呆子。 但你是对的，我想这是类似的事情，不是吗？ 如果你能知道你在哪里可以调整或挤出最后一点点……

Drew: And you've still got limited bandwidth in both cases. You've got limited energy and you've got limited network connection.

Harry: Exactly, you can't just magic some more bandwidth there.

Drew: If you, the listener, would like to hear more from Harry, you can find him on Twitter, where he's @csswizardty, or go to his website at csswizardry.com where you'll find some fascinating case studies of his work and find out how to hire him to help solve your performance problems. Harry's E-Book, that he mentioned, and video course we'll link up from the show notes. Thanks for joining us today, Harry, do you have any parting words?

Harry: I'm not one for soundbites and motivation quotes but I heard something really, really, really insightful recently. Everyone keeps saying “Oh well we're all in the same boat” and we're not. We're all in the same storm and some people have got better boats than others. Some people are in little dinghies, some people have got mega yachts. Oh, is that a bit dreary to end on… don't worry about Corona, you'll be dead soon anyway!

Drew: Keep hold of your oars and you'll be all right.

哈利：是的。 I was on a call last night with some web colleagues and we were talking about this and missing each other a lot. The web is, by default, remote, that's the whole point of the web. But… missing a lot of human connection so, chatting to you for this hour and a bit now has been wonderful, it's been really nice. I don't know what my parting words really are meant to be, I should have prepared something, but I just hope everyone's well, hope everyone's making what they can out of lockdown and people are keeping busy.