说到 WordPress 站点的整体速度，很多时候我们关注前端性能和优化，以提高页面加载速度。然而，有时候从服务器端(网站最初开始加载的地方)来看它是很好的方法。今天我们将深入探讨 TTFB (time to first byte)对您的影响，并讨论一些简单的方法来减少TTFB。TTFB 通常是一个被忽视的性能因素，但是在测试你的网站的速度时应该考虑到这一点。
什么是 TTFB？
TTFB 代表 time to first byte。简而言之，这是一个衡量浏览器在从服务器接收第一个字节数据之前需要等待多长时间的指标。获取数据所需的时间越长，显示页面所需的时间就越长。一个常见的误解是，这是在 DNS 查找时间之后计算的，然而，网络中 TTFB 的原始计算总是包含网络延迟。这包括了 3 个环节，延迟可能发生在其中任何一个环节，导致 FFTB 增加。这个问题的主要原因是在服务器端。
请求服务器
当有人访问你的网站时，首先发生的事情是 HTTP 请求从客户端(浏览器)发送到服务器。在这个步骤中，有许多因素可能会导致延迟。缓慢的 DNS 查找可能导致请求时间的增加。如果服务器位于很远的地理位置，这可能会导致数据传输距离的延迟。此外，如果您有复杂的防火墙规则，这可能会增加路由时间。当然还会收到客户的网速的影响。
服务器处理
发送请求后，服务器现在必须处理请求并生成响应。这可能会导致一些不同的延迟，比如缓慢的数据库调用、太多的第三方脚本、没有缓存第一个响应、优化得不好的代码或 WordPress 主题，以及低效的服务器硬件资源，比如磁盘 I/O 或内存。
服务器响应
在服务器处理请求之后，它必须将请求发送回客户机(或者更确切地说是发送回第一个字节)。这受到服务器和客户机的网络速度的严重影响。如果客户端网速较慢，TTFB 就会很长。
TTFB 时间多长算长？
因为每个服务器的硬件和网络环境都不尽相同，每个服务器的 TTFB 时间也不相同。大多数服务器的 TTFB 时间都在 50 ms 以下，这个时间就是我们优化时候可以追求的时间。一般来说，TTFB 时间如果超过了 500 ms，用户在打开网页的时候就会感觉到明显的等待。我么可以把 500 ms 以上认为是 TTFB 时间过长。
一般来说，低于100毫秒的都是非常好的 TTFB。建议服务器响应时间低于200ms。如果你是在300-500毫秒的范围内，这是相当标准的。如果你的速度超过了600毫秒，你的服务器可能配置错误，或者是时候升级到一个更好的网络栈了。请记住，SSL/TLS 协商也可能是一个重要因素。
如何测量 TTFB？
我们可以通过chrome开发者工具→网络中查看 TTFB。你可以通过启动 DevTools 在 Google Chrome 中测量 TTFB。但是如果你在电脑上测试 TTFB， 这将受到网络延迟和网络连接的影响。因此，使用来自数据中心的第三方工具可能更为有效。
减少 WordPress 站点上的 TTFB
现在让我们深入了解一些如何减少 WordPress 站点上的 TTFB 的方法。
- 使用更快的 WordPress 主机。
减少 TTFB 的第一个方法是确保你使用的是一个快速的 WordPress 主机。切换到一个更快的主机可以减少你网站的 TTFB 高达200% 。
- 使用 CDN：通过减少物理距离可以真正的改善TTFB。
注意如果你使用 Cloudflare，你可能会有稍高的 TTFB。这是由于运行完全代理服务的额外开销和复杂性造成的。记住，Cloudflare 有额外的防火墙和其他一些 CDN 提供商没有的特性。
- WordPress 缓存。
也许是最简单的减少 TTFB 的方法之一，就是在你的 WordPress 站点上使用缓存。许多人只认为缓存可以帮助减少加载时间，但实际上，它也有助于减少 TTFB，因为它有助于减少服务器处理时间。
- 使用升级的域名服务提供商。
DNS 在 TTFB 中也起到了一定的作用。
还有很多其他的方法你可以优化或者修复来减少 TTFB，比如数据库缓存，磁盘 IO，虚拟内存，RAM，PHP 设置，MySQL 设置，网络设置，TLS 开销等等。但是上面提到的这些方法很容易实现，并且能够给你带来最快的性能提升。
其他指标
Stalled（阻塞）
浏览器对同一个主机域名的并发连接数有限制，因此如果当前的连接数已经超过上限，那么其余请求就会被阻塞，等待新的可用连接；此外脚本也会阻塞其他组件的下载。
优化措施：
- 将资源合理分布到多台主机上，可以提高并发数，但是增加并行下载数量也会增大开销，这取决于带宽和CPU速度，过多的并行下载会降低性能。
- 脚本置于页面底部；
DNS Lookup（域名解析）
请求某域名下的资源，浏览器需要先通过DNS解析器得到该域名服务器的IP地址。在DNS查找完成之前，浏览器不能从主机名那里下载任何东西。
优化措施：
- 利用DNS缓存（设置TTL时间）；
- 利用 Connection:keep-alive 特性建立持久连接，可以在当前连接上进行多个请求，无需再进行域名解析；
Initial connection（初始化连接）
表示 TCP建立连接的三次握手时间，建立HTTPS连接的时间相当于三次握手的时间+SSL时间。
Request sent（发送请求）
发送HTTP请求的时间（从第一个bit到最后一个bit）。
优化措施：
- 减少HTTP请求，可以使用 CSS Sprites、内联图片、合并脚本和样式表等；
- 对不常变化的组件添加长久的Expires头，在后续的页面浏览中可以避免不必要的HTTP请求；
Waiting（等待响应）
通常是耗费时间最长的。从发送请求到收到响应之间的空隙，会受到线路、服务器距离等因素的影响。
优化措施：
- 使用CDN，将用户的访问指向距离最近的工作正常的缓存服务器上，由缓存服务器直接响应用户请求，提高响应速度；
Content Download（下载）
下载HTTP响应的时间（包含头部和响应体）。
优化措施：
- 通过条件Get请求，对比If-Modified-Since和Last-Modified时间，确定是否使用缓存中的组件，服务器会返回“304 Not Modified”状态码，减小响应的大小；
- 移除重复脚本，精简和压缩代码，如借助自动化构建工具grunt、gulp等；
- 压缩响应内容，服务器端启用gzip压缩，可以减少下载时间；
Jonsam
一个理科IT宅男，喜欢旅游、分享和美食，做点想做的事情，遇见想见的人。
🍒 美食 | 🌐 FE | 🕌 旅行 | 💻 加班 | ♍ 处女座
