站点的第一字节时间（TTFB）是从用户开始导航到他们请求的页面的HTML开始到达的时间。在我运行webgetest的十多年里，一个慢的TTFB一直是我存在的祸根。查看最近的测试数据集（约10万页）：20%TTFB>3s80%start render>5s（10%>10s）500页>15MBSo-more slow to fix-Patrick Meenan（@patmeenan）2016年8月10日TTFB之所以会成为WebPageTest网站上为数不多的"分数"之一，这是有原因的，特别是，为什么它是排行榜上的第一名。如果第一个字节很慢，那么其他度量也会很慢。改进它是为数不多的几个例子之一，在这种情况下，你可以预测每一次测量的影响。TTFB的每一毫秒改进直接转化为每隔一次测量节省的毫秒数（即，如果TTFB提高500毫秒，第一次喷漆的速度将加快500毫秒）。也就是说，一个快速的ttfb不能保证一个快速的体验，但是一个慢的ttfb保证一个慢的体验。据我估计，大约50%的请求帮助网页测试结果来自网站所有者与缓慢的TTFB斗争。TTFB中包含了许多内容，包括重定向、DNS、连接设置、SSL协商和实际的服务器响应时间。通过使用Cloudflare这样的服务可以相对容易地修复大多数问题，但是HTML本身的服务器响应时间通常是最大的问题，也是最难解决的问题。下面的瀑布图将服务器响应时间显示为第一个请求时的浅蓝色条形图，当响应速度较慢时，它会非常明显。在最佳条件下，服务器响应时间不会比它前面的橙色套接字连接条长。超过三秒钟，服务器才会响应。从服务器配置、系统负载、后端数据库和它所对话的系统，到应用程序代码本身，各种各样的问题都可能导致源代码响应速度慢。要找到性能问题的根源，通常需要开发操作工程师团队使用应用程序性能管理工具来跟踪应用程序最慢的部分并加以改进。与我共事过的网站所有者中有很大一部分没有资源或专业知识来处理此类调查。更多的时候，他们向某人支付一次性开发费来建立他们的网站，或者自己在WordPress上建立自己的网站，并以最低的成本托管。主机通常设计为运行尽可能多的站点，而不一定是为了达到最高性能。HTML的边缘缓存问题是，大多数HTML并不是真正的动态的。它需要能够在站点更新时相对快速地改变，但是对于web的很大一部分来说，内容一次在几个月或几年内是静态的。有一些特殊情况，比如用户登录时（作为管理员或其他人），内容需要有所不同，但绝大多数访问都是匿名用户。如果HTML可以被缓存并直接从边缘提供服务，那么性能提升将是可观的（在本例中，所有指标都要快3秒以上）。更快的服务器响应时间。WordPress有几十个插件用于在源代码处缓存内容，但它们需要配置（缓存页面的位置），性能仍然很大程度上取决于主机本身的性能。将内容缓存进一步推到边缘可以降低复杂性，消除返回源位置的额外时间，并完全消除托管性能。它还可以通过卸载所有匿名流量来显著降低托管系统的负载。Cloudflare支持缓存静态HTML，企业和企业客户可以通过启用"绕过cookies上的缓存"来让登录用户跳过缓存。它与用于WordPress的Cloudflare插件协同工作，因此每当内容更新时都可以清除缓存。还有几个其他缓存插件与各种CDN集成，但在所有情况下，它们都需要为CDN配置API密钥，并且每个CDN的实现都是特定的。HTML的零配置边缘缓存为了广泛采用，我们需要使HTML的缓存自动发生（或尽可能接近自动）。为此，我们需要一种在源服务器（如WordPress站点）和边缘缓存（如Cloudflare的边缘节点）之间进行通信的方法，以管理可以显式清除的远程缓存。原点需要能够：识别其前面何时有受支持的边缘缓存。指定应缓存的内容以及访问者（即没有登录cookie的访问）。当缓存内容发生更改时清除它（在所有边缘全局清除）。我们不需要要求源代码与API集成以清除更改，也不需要手动配置缓存什么，我们可以使用HTTP头在边缘和源服务器之间来回传输的请求上完成所有任务：1-向从边缘到源站的请求添加HTTP标头，以通告存在边缘缓存及其支持的功能：x-HTML-Edge-Cache:supports=Cache |清除所有|绕过cookies2-当源站使用可缓存页面响应时，它会在响应上添加一个HTTP标头，以指示应该缓存它，以及何时不应使用缓存版本的任何规则（允许登录用户绕过缓存）：x-HTML-Edge-Cache:Cache，绕过cookies=wp-| wordpress在这种情况下，HTML将被缓存，但是任何cookie名称以"wordpress"或"wp-"开头的请求都将绕过缓存并转到源代码。3-当请求修改站点内容（更新帖子、更改主题、添加注释）时，源服务器会添加一个HTTP响应头，指示需要清除缓存：x-HTML-Edge-Cache:清除唯一需要处理的问题是清除需要清除所有边缘的缓存，而不仅仅是请求通过的一个边缘。4-当边缘缓存中的HTML出现新请求时，将根据缓存响应的规则检查请求cookie。如果cookies不存在，则提供缓存版本；否则，请求将传递到源站。有了这个简单的基于头的命令和控制接口，我们就不需要源站与API通信，也不需要任何显式配置。它还使得源代码上的逻辑更容易实现，因为它不需要配置（或UI），也不需要向特定于供应商的API发出任何出站请求。示例WordPress插件不到50行代码，其中绝大多数代码都是连接所有更改内容的事件的回调。现在就开始用WordPress和Workers进行缓存关于工人，我最喜欢的一点是，它给了你一个完全可编程的优势，可以试验想法和实现你自己的逻辑。我创建了一个Worker脚本，在Cloudflare边缘上实现基于头的协议和边缘缓存，以及一个实现WordPress源逻辑的WordPress插件。工作线程唯一棘手的部分是找到一种全局清除缓存项的方法。辅助缓存是每个边缘的本地缓存，不提供用于执行任何全局操作的接口。一种方法是使用Cloudflare API清除全局缓存，但这有点麻烦（清除缓存中的所有内容，包括脚本和图像），而且需要一些配置。如果您知道内容更改将更改的特定url，那么通过API对这些url进行有针对性的清除可能是最好的解决方案。使用新的Workers KV存储，我们可以用不同的方式清除缓存。Worker脚本对缓存使用一个版本控制方案，其中每个URL都会附加一个版本号（即。？cf_edge_cache_ver=32）。修改后的URL只在本地被worker用作缓存响应的键，当前版本号存储在KV中，这是一个全局存储。清除缓存时，版本号将递增，从而更改所有资源的URL。旧条目将正常从缓存中过时，因为它们将不再被访问。它需要一些配置来为工人设置KV，但希望在将来的某个时候也能实现自动化。下一步呢？我认为对于web来说，标准化边缘缓存和源代码的通信方式对于动态内容的缓存有着巨大的价值。这将激励内容管理系统直接在平台中构建支持，并提供可跨不同提供商使用的标准接口（甚至用于负载平衡器或其他反向代理中的本地边缘缓存）。在对不同类型的站点做了更多的测试之后，我打算把这个概念带到IETF HTTP工作组，看看我们能否为控制头（使用不同的名称）制定一个官方标准。如果您对它应该如何工作或者您需要公开哪些功能有什么看法，我很乐意听到（比如清除特定的url，为移动/桌面或区域更改内容，将其扩展到涵盖所有内容类型，等等）。