太长，读不下去了Cloudinary致力于开放和透明现在可以通过请求头Pragma:Server Timing按需提供服务器计时我们计划在不久的将来让这个"永远开启"我们想听听你的反馈概述本周在PerfMatters会议上，我们了解到了性能度量的重要性，以及chrome65、Opera和Firefox中提供的新标准，比如服务器定时。在Cloudinary，我们致力于透明度和问责制。这就是为什么我非常兴奋地宣布，我们现在支持所有客户的服务器计时！现在，服务器计时是按需提供的，但在不久的将来，我们将广泛地启用这一功能，从而使您的RUM能够更深入地了解情况解决方案。如何解决我看到了吗？现在，所有客户都可以按需进行服务器计时。它可以在客户端通过添加头Pragma:server timinging在curl中启用，您可以使用-H"Pragma:server timing"：Copy to clipboardcurl添加它"Pragma:server timing"-D--INote（-D-将头发送到控制台，-I表示head请求，因此您看不到字节）作为回报，你会的请参见：复制到剪贴簿日期：2018年3月28日星期三15:22:05 GMT内容类型：image/jpg服务器计时：cloudinary；dur=105；start=152225055.545；total=105服务器计时：akam；dur=18；start=1522250525.454；total=233；desc="~（cache~'miss~rtt~6~id~'42c1b76~pconn~1~f_pconn~1）"或在浏览器中，您可以添加Chrome分机：现在你可以看到你的devtools:你呢可以通过j查询avascript:复制到剪贴板window.performance.getEntries()你在分享什么细节？在我们的第一个迭代中，我们共享了许多操作细节。在desc字段中，您将注意到jsurl编码的有效负载。此迭代揭示了一些有趣的细节：开始(历元.ms)-开始时间-从服务器的角度来看总计（毫秒）-使响应恢复的总"时钟时间"。如果存在依赖关系，这一点很重要。dur（ms）-满足请求的持续时间或"工作时间"。这将是cpu、io等，从请求开始到字节作为响应刷新到网络。rtt（ms）-从服务器的角度来看，从最后一个数据包开始的TCP往返时间。缓存-命中或未命中pconn-TCP套接字上的请求计数fpconn-传出TCP套接字上的请求计数注意是的，它不是人类可读的，但这是唯一允许Javascript以编程方式访问这些额外字段的机制。一些重要注意事项：公开了三个不同的名称：cloudinary、akamai和fastly。这与不同的服务提供商有关。第一个是来自服务器的条目，后两个条目来自我们使用的cdn多个服务器计时条目-在旅程中每个"跳跃"一个检查开始时间！历史服务器计时条目也会被保留。它可能是CDN上的缓存命中，但您仍然可以看到此项来自何处，何时添加到缓存中，等等。今天我能学到什么？以下是我们已经发现的一些有趣的观察结果洞察：成本TCP overheadConsider以下内容响应：复制到剪贴板服务器计时：cloudinary；dur=94；start=1516653847.986；total=94服务器计时：akam；dur=16；start=1516653847.922；total=207；desc="~（cache~'miss~rtt~57~id~'1ca34068~pconn~7~f_pconn~1）"服务器计时：akam；dur=16；start=1516653847.879；total=278；desc="~（cache~'miss~rtt~26~id~'9ca8e39~pconn~1~f_pconn~1）"下面是上述内容的分解（从下往上读取，因为头是累积添加的）：从浏览器的角度来看，此资源花费了~400毫秒：复制到剪贴板重新计时=window.performance.getEntries（）[4]；重新计时响应开始- 重新计时.requestEnd;398CDN边缘节点用了278毫秒完成此请求（总计=278）是一个缓存失误反过来，CDN使用了一个父节点，从它的角度来看，这个节点花费了207毫秒（total=207）这也是一个缓存未命中，需要转到原点最后，这又反过来向我们的服务器发出了一个请求，耗时94毫秒。时间到哪里去了？首先，到CDN的浏览器需要一个TCP连接。RTT为26ms，因此使用~100ms连接TCP。CDN的各个层需要连接到源站等等实际的思考时间是94毫秒额外的时间在TCP开销中，而不是在服务器上的思考时间。如果我们有一个缓存命中，这些额外的税收都不会被应用我们的经验教训是：缓存再次是重要的-请参阅苏德的web性能规则中的#2。缓存未命中可能会导致用户等待，因为TCP通过网络进行握手。我们更需要最大限度地利用cdn。个性化和缓存效率有许多有趣的实验，我们希望这些数据可以帮助阐明。例如，您的个性化英雄图像加载速度慢是因为它没有被缓存并且是按需生成的吗？缓存命中的转换率是多少？这些都是现在很容易观察到的有趣的假设。使用Lux等RUM工具，您可以添加一点Javascript来提高性能仪表板：复制到剪贴板勒克斯=窗口.LUX;//在浏览器的服务器计时中查找英雄图像让英雄主义=window.performance.getEntriesByName（'personalized-hero'）。服务器定时；//测试缓存命中让cacheHit=/cache~'hit/.test（英雄）[英雄主义长度-1.说明）；//将该值添加到lux数据中LUX.addData（"个性化英雄"，cacheHit？1:0）；从这里，您可以轻松地为您的用户绘制真实世界影响的结果。令人兴奋！反对？！？！与任何"新"事物一样，有许多理由不采纳或支持它。以下是我们根据当前观点快速考虑的反对意见：我们的开发团队-我们将暴露我们的技术债务，我们不知道什么骨架可能在衣柜！是的。我们预计会有一些尴尬。没有一家公司是完美的，任何技术都没有技术债务。然而，这将有助于我们专注于什么对我们的客户是重要的，并有助于提高我们提供的服务质量的标准。我们的产品团队-这不会让我们破产吗？我们不会透露太多信息，客户会自己动手做吗？也许 吧。但不太可能。思想自由而丰富。如果我们提供的服务可以通过对我们的表现进行透明化而被淘汰，那么我们就没有为我们的客户提供足够的价值。作为一个客户，这不会减慢我的用户的下载速度吗？这是我们共同关心的问题，也是我们为什么要谨慎行事的原因。实际上，额外的服务器计时头将达到大约100字节。在24KiB的典型图像上，这个值增加了0.4%。这不会增加发送给用户的数据包的数量，因为许多数据包都是"半空"的。这是我们将观察到的情况，并将在不久的将来报告，然后我们将默认打开此功能。下一步是什么？我们有很多计划。我们希望公开更多细节，使之与您更加相关，并帮助您深入了解生意。第一我们需要在密切相关和可操作之间找到平衡，而不是简单的"有趣"。在不久的将来，我们将公布更多我们正在分享的细节。如果你有意见和想法，我们很乐意听听更多重要的是，我们有一些关于如何使用服务器定时来改善您的业务的好主意。事实上，真的很令人兴奋。敬请期待！该规范仍在发展中。您会注意到我们使用了一些非标准字段，如total和start。同时，我们正在"使用"desc字段来提供自定义详细信息。随着规范的发展，我们将进行更改。如前所述，我们需要你的帮助，这只是开始。我们致力于为您提供更加透明和深入的服务。如果您有意见、想法或顾虑，我们很乐意倾听。我们如何向您提供更多细节以帮助您的业务？帮助你的运营团队？帮助你的营销团队？我们想听你的消息！请在评论栏留下你的想法下面。上面下一篇：深入研究服务器计时在下一期中，我们将更详细地探讨服务器计时以及我们正在追求的一些令人兴奋的用例。