主机与性能
我们如何让 WordPress 运行提速：LiteSpeed Enterprise、LSCache 以及每个站点专属的 Redis
最快的 WordPress 请求是无需执行的请求——以下是我们的技术栈如何在调用 PHP 或 MySQL 之前从缓存响应绝大多数访问，以及这对 Core Web Vitals 意味着什么。
最快的请求是那个从未发出的请求
一个标准的 WordPress 请求成本高昂。Web 服务器将请求移交给 PHP，PHP 启动 WordPress，运行插件，对 MySQL 进行数十次查询，组装成 HTML，然后才将字节发送回去。在一个繁忙的网站上，每个访问者都要经历这一整套流程，几乎所有的首字节时间（time-to-first-byte）都耗费于此。
我们的解决方法是确保对于大多数访问，这些过程根本都不会发生。在我们托管的所有网站中——超过 10,000 个 PBN 网站以及主流托管 WordPress——绝大多数前端页面视图都是直接从缓存中提供预渲染的完整页面，而无需调用 PHP 或访问数据库。本文的其余部分将介绍实现这一目标的各个层级是如何协同工作的，以及每一层级是如何发挥其作用的。
核心框架在于，这些并不是让你二选一的竞争性缓存。全页缓存、对象缓存和 CDN 边缘节点各自捕获不同类别的请求，其价值在于它们之间如何进行交接。
LiteSpeed Enterprise + LSCache: 全页层
每个站点都运行在配有服务器级 LSCache 的 LiteSpeed Enterprise 上。当前端响应可缓存时，Web 服务器会为其打上 LiteSpeed cache-control 和 tag 标头，LiteSpeed 会在下一次访问时直接提供完整的页面——无需启动 PHP 进程，也无需发出 MySQL 查询。这是降低 WordPress TTFB 最有效的手段，因为它将整个应用程序的引导过程从关键路径中完全剔除了。
因为 LSCache 存在于网页服务器内部而不是 PHP 插件中，它在请求生命周期的更早阶段就开始工作，并以服务器能够立即刷新的形式保存页面。缓存爬虫使热门页面保持预热，因此清理缓存后的第一位访问者无需承担重新生成页面的时间成本。其结果是，与依赖位于 PHP 身后的通用技术栈的纯插件缓存相比，它的 TTFB 显著降低且更加稳定。
我们自研的仓库级缓存插件在每个网站上都是预装并自动更新的，开箱即可将 WordPress 正确连接到 LSCache。在非 LiteSpeed 源服务器上，它简便地不发出整页标头并自动退让，同时对象缓存和排除规则继续发挥作用——因此迁移后的网站绝不会处于损坏且半配置的状态。
保持速度且不提供陈旧内容：ESI 与智能自动清除
积极的全页缓存有两种典型故障模式：向已登录用户展示其他人的页面，以及向任何人展示本应更改的页面。这两者都是在缓存层解决，而不是通过减少缓存来解决。
ESI（Edge Side Includes）允许我们在缓存页面的同时，为必须保持动态的部分打孔。在 WooCommerce 商店中，目录、产品和分类页面采用全页缓存以实现最快的 TTFB，而 ESI 则按请求渲染购物车片段、迷你购物车总数和账户状态。购物车、结账、我的账户以及任何 nonce 或会话页面默认均被排除。购物者始终能看到自己的购物车和可用的结账页面，而所有人依然能从缓存中获取店面内容。
内容更新通过智能自动清理机制来处理。当内容、产品、价格或订单发生更改时，清理钩子会自动触发，从而使相关的缓存页面立即刷新，而无需等待定时器，您还可以从仪表盘或从 WordPress 内部按需进行清理。基于标签的清理意味着编辑单个文章会清除该文章及其归档——而不是整个缓存——因此单次编辑不会导致整个网站重新冷启动。
每个站点专属的 Redis 对象缓存：适用于无法完整缓存的页面内容
并非每个请求都可以是静态的完整页面。登录会话、WordPress 管理后台、WooCommerce 购物车、搜索以及 ESI 留下的动态片段都必须运行 PHP。对于这些请求，目标从“跳过应用程序”转变为“跳过数据库”。
每个站点都配有专属的 Redis 对象缓存。WordPress 会将重复数据库读取的结果（选项、瞬态数据、文章和词条查询，以及 WooCommerce 的产品和会话数据）缓存在内存中，从而避免每次访问时都对 MySQL 执行相同的查询。这种效果在全页缓存无法发挥作用的地方尤为明显：后台加载更快、购物车响应更敏捷，并在高流量下大幅降低数据库负载。
对象缓存是按站点划分的，而非共享的，这对于性能和隔离性都至关重要。结合按站点的数据库限流，某个站点繁重或编写糟糕的查询不会耗尽其相邻站点的数据库资源。您可以在我们的缓存功能页面上了解有关整个多层架构如何协同工作的更多信息，以及有关隔离下租户之间边界的更多信息。
边缘与底层传输
保存在源服务器上的缓存仍然需要跨越网络。服务器前方部署了 CDN 边缘节点，因此静态资源和可缓存页面可以从离访客最近的存在点提供服务，从而确保源服务器在负载下也能保持静默。对于我们的 footprint-free 主机系列而言，同一个边缘节点是由分布在多家服务商之间组成的多 CDN 池，它既能实现 footprint 目标，又能提升性能；在主流的 WordPress 上，它则是一个简单、运行良好且能让源服务器保持闲置的层。
在底层，基础性能绝不打折。网站运行在带有 HTTP/3 的 NVMe 存储之上，因此缓存命中的字节通过现代的多路复用传输协议送达，而在任何缓存未命中的情况下，都有高速存储作后盾。这些层级绝非附加组件：LiteSpeed、LSCache、独立于站点的 Redis、NVMe 和 HTTP/3 是每个套餐的标配，而不是需要额外加价升级的高级档次。
真正影响 Core Web Vitals 的因素
值得精益求精，因为主机服务在 Core Web Vitals 方面往往存在过度承诺。TTFB 是服务器负责的那部分，而上层的缓存架构则是将其缩短的关键——通过边缘节点经由 HTTP/3 提供服务的缓存完整页面，其 TTFB 几乎已达到最低水平。由于 TTFB 是 Largest Contentful Paint 的先头指标，一个快速的源站能为后续的每一个指标带来其他方式无法企及的领先优势。
但 LCP、CLS 和 INP 主要取决于浏览器端以及页面自身：未优化的首屏大图、阻塞渲染的 CSS 和 JavaScript、随着字体和广告加载而发生偏移的布局，以及插件导致的繁重主线程任务。无论多少服务器缓存，都无法修复 2 MB 的首屏大图或自带数兆 JavaScript 的主题。诚实的托管服务能让服务器的贡献变得切实免费且稳定，接下来就需要网站自身来保持前端的精简。
这种分工是一个实用的思维模型。我们保证请求能够快速到达浏览器，并在高流量下保持高速；您则负责保持有效负载精小稳定。这两者的交汇点——缓存预热、边缘分发以及保持数据库响应灵敏以防止动态页面停滞——正是我们技术栈经过调优的地方，这也是在此平台上托管的 WordPress 比在普通主机上运行同一网站更快的原因所在。
常见问题
我还需要像 WP Rocket 这样的缓存插件吗？
不需要。整页缓存由 LiteSpeed 的 LSCache 在 Web 服务器层面处理，而我们自己的缓存插件（预安装并自动更新）可将 WordPress 与其正确连接，并在其后运行每个站点专属的 Redis 对象缓存。在顶部叠加第二个整页缓存插件通常会与服务器级缓存冲突，而不是提供帮助，因此既不需要也不推荐。
缓存会损坏我的 WooCommerce 购物车或登录页面吗？
默认情况下，购物车、结账、我的账户以及任何 nonce 或会话页面均被排除在缓存之外，并且 ESI 可确保购物车片段和总计在其他已缓存的页面上保持实时更新。购物者在网店从缓存加载时，始终能看到自己的购物车和可正常使用的结账页面。
当我发布或编辑内容时，缓存是如何保持更新的？
智能自动清理功能会在相关的 WordPress 钩子上触发，因此发布、编辑内容或更改产品、价格或订单只会清除受影响的页面及其存档——而不是整个缓存——并且爬虫会再次预热它们。您还可以从仪表盘或 WordPress 内部按需进行清理。
仅凭托管能让我的 Core Web Vitals 达到完美吗？
它能为您提供最佳的 TTFB（首字节时间），这是服务器端能做到的极限，也为最大内容绘制（LCP）开了个好头。但 LCP、CLS 和 INP 很大程度上取决于页面本身——图片大小、渲染阻塞资源、布局稳定性和主线程 JavaScript。我们的技术栈让服务器的贡献变得快速且稳定；保持前端负载精简则是弥补其余差距的关键。