网站的第一字节时间（TTFB）是从用户开始导航到他请求的页面的第一个HTML代码到达的时间。自从十多年前我开始网页测试以来，慢的ttfb是我生活中的诅咒。TTFB是webgetest用来评估网站的少数几个"注释"之一，这是有原因的，尤其是为什么它是列表中的第一个注释是。如果第一个字节是慢的，也是其他度量慢的。TTFB的改进是为数不多的能够预测它将如何影响所有其他测量结果的情况之一。TTFB的每一毫秒改进意味着每隔一次测量节省毫秒（即，如果TTFB提高500 ms，则第一内容的显示速度将加快500 ms）。请注意，快速的TTFB不一定保证快速的体验，但是慢的TTFB肯定会提供缓慢的体验。我想大约50%的帮助问题都来自于webgetest的结果，他们可以使用一个慢的TTFB很多疫苗。事情可以流入TTFB，包括转发、DNS、连接构建、SSL协商和实际的服务器响应时间。其中大部分可以通过Cloudflare这样的服务相对容易地修复，但是HTML的服务器响应时间通常是最大的，也是最难解决的问题。下面的瀑布图以浅蓝色条显示第一次请求时的服务器响应时间；如果服务器响应时间很长，可能会非常明显。在最佳条件下，服务器响应时间不会超过直接进行套接字连接的橙色条以前。更多离服务器还有三秒钟回答。慢点源代码的响应时间可能由各种问题引起；这些范围从服务器配置到系统加载，以及与应用程序代码本身通信的后端数据库和系统。为了从根本上解决性能问题，DevOps工程师团队通常使用应用程序性能管理工具来跟踪应用程序最慢的部分，并提高。A与我共事过的大部分网站所有者没有资源或专业知识，进行这类调查。大多数时候，他们向某人支付一次性开发费来创建他们的网站，或者他们自己在WordPress上创建，并以最低的成本在提供商处托管。托管通常设计为承载尽可能多的页面，而不一定要达到最高性能边缘。边缘-从HTMLDie缓存的事情是，大多数HTML代码并不是真正的动态的。当网站更新时，它必须能够相对快速地改变，但是对于网站的大部分内容来说，它已经消失了几个月或几年了静电。它有一些特殊情况，例如当用户以管理员或其他身份登录时，内容必须不同，但绝大多数的访问都是匿名用户。如果HTML代码可以保存在中间，并直接从边缘提供，那么性能的提高将是显著的（在这种情况下，所有指标都要快3秒钟以上）。响应时间。为WordPress提供了几十个插件，用于在源代码处缓存内容，但它们必须进行配置（页面将存储在中间），并且性能仍然很大程度上取决于主机本身的性能。如果将内容缓存移到边缘，则复杂性降低，返回原点的额外时间消失，而且托管性能完全从等式中消失了。此外，通过免除托管系统的所有匿名访问，可以大大减轻托管系统的负担云闪。云闪支持缓存静态HTML代码，企业和企业客户可以允许注册用户跳过缓存，通过激活"跳过缓存到Cookie"。这与WordPress的Cloudflare插件一起工作，以便在更新内容时清空缓存。还有几个其他缓存插件可以集成到不同的CDN中，但在所有情况下，它们都必须配置CDN的API密钥，并且每个实现都是特定的CDN。免费配置来自htmlf的边缘缓存对于广泛的应用程序，我们必须自动（或尽可能自动地）缓存HTML。为此，我们需要一种在源（如WordPress网站）和边缘缓存（如Cloudflare的边缘节点）之间进行通信的方法，以管理显式删除的远程缓存可以。那个来源必须是：认识到：是 啊。如果前面有受支持的边缘缓存位置。请指定要为哪些访问者存储哪些内容（即，没有登录cookie的访问）。当存储的内容发生更改时（在所有边缘全局删除）。源代码包含一个API，以便在发生更改时删除，并且必须手动配置应保存的内容，因此我们可以使用HTTP头来处理边缘和源代码之间的查询以及h徒步旅行：1。提供了一个支持边缘缓存的源函数和一个支持边缘缓存的函数标记：x-HTML-Edge-Cache支持=缓存当源代码用一个可缓存的页面进行应答时，它将用一个HTTP头提供一个应答，并指示在这两个标头之间保存它。头还包含不使用缓存版本的规则（以便注册用户可以绕过缓存）：x-HTML Edge cache:cache，bypass cookies=wp-/124s；wordpress启动cookie名称，绕过缓存并转到origin。当请求更改网站内容（更新帖子、更改布局、添加注释）时，源服务器会添加一个HTTP响应头，指示缓存将被删除必须：x-HTML-Edge-Cache唯一棘手的是，删除必须清除所有边缘的缓存，而不仅仅是通过请求的一个边缘。当接收到新的HTML代码请求（位于边缘缓存中）时，将根据保存响应的规则检查请求cookie。如果cookie不存在，则提供保存的版本；否则将向始发地提出请求和这个简单的、基于头的命令和控制接口不再需要源代码来与API和显式配置通信。这使得在源代码处实现逻辑更加容易，因为没有配置（或用户界面），也不需要向特定于提供者的API发出传出请求。WordPress插件示例只有不到50行代码，其中绝大多数代码用于所有事件的调用函数其他。还没有关于工人，我最喜欢的一个方面是，它有一个完全可编程的优势你可以尝试想法，实现你自己的逻辑。我已经创建了一个worker脚本，它在Cloudflare边缘上实现了基于头的协议和边缘缓存，以及一个实现WordPress源逻辑的WordPress插件实现了关于worker的唯一棘手的部分是找到一种从缓存全局删除元素的方法。辅助缓存是边缘的本地缓存，不为全局操作提供接口。一种方法是使用Cloudflare API来清理全局缓存，但这是一个相当沉重的任务（从缓存中删除所有内容，包括脚本和图像），并且需要一些配置。如果您知道通过内容更改修改的特定url，通过API对这些url进行定向删除可能是最佳解决方案唱。用新的Workers键值数据库（Workers KV）我们可以用另一种方式清理缓存。Worker脚本对缓存使用一个版本方案，其中每个URL都会添加一个版本号（即。….tin round+rock+texascf边缘缓存ver=32）。修改后的URL总是由worker本地使用，作为保存答案的密钥，当前版本号存储在键值数据库（一个全局内存）中。删除缓存后，版本号将增加，从而更改所有资源的URL。旧条目在其使用寿命到期后自动从缓存中移出，因为它们不再被访问。为worker设置键值数据库需要一些配置，但希望在将来的auc中可以这样做