托管与性能
我们如何让 WordPress 更加快捷：LiteSpeed Enterprise、LSCache 以及每个站点独立的 Redis
最快的 WordPress 请求是无需执行的请求——了解我们的技术栈如何在调用 PHP 或 MySQL 之前通过缓存响应大多数访问，以及这对 Core Web Vitals 意味着什么。
最快的请求是永远无需运行的请求
一个标准的 WordPress 请求开销很大。Web 服务器移交给 PHP，PHP 启动 WordPress、运行插件、对 MySQL 进行数十次查询、组装 HTML，只有在这之后才返回字节。在访问繁忙的网站上，每个访客都会触发这整套流程，而这几乎消耗了您所有的首字节时间。
我们的应对方案是确保对于绝大多数访问，这些情况完全不会发生。在我们托管的网站中——包括超过 100,000 个 PBN 网站以及主流托管型 WordPress——绝大多数前端页面浏览都是直接从缓存中以预渲染的完整页面形式提供服务，无需调用 PHP，亦无需访问数据库。本文的其余部分将探讨实现这一目标的各个层级是如何协同工作的，以及它们各自发挥作用之处。
核心的思维框架在于，这些并不是非此即彼、相互竞争的缓存。全页缓存、对象缓存和 CDN 边缘各自负责截获不同类型的请求，而它们的价值正在于彼此之间如何顺畅交接。
LiteSpeed Enterprise + LSCache：整页缓存层
每个站点都运行在具有服务器级 LSCache 的 LiteSpeed Enterprise 上。当前端响应可被缓存时，Web 服务器会为其添加 LiteSpeed 缓存控制和标签标头，LiteSpeed 会在下一次请求时直接提供完整页面——不产生任何 PHP 进程，也不执行任何 MySQL 查询。这是优化 WordPress TTFB 的最重要单一手段，因为它将整个应用程序的启动过程从关键路径中完全移除。
由于 LSCache 驻留在 Web 服务器内部而非 PHP 插件中，它在请求生命周期中更早开始工作，并以服务器可以立即刷新的形式保留页面。缓存抓取工具可保持热门页面的预热状态，因此清除缓存后的第一位访问者无需承担重新生成页面的耗时代价。其结果是，相比于附加在通用技术栈上且缓存仍位于 PHP 之后的纯插件缓存，TTFB 明显更低且更稳定。
我们仓库级别的专有缓存插件已预装在每个站点上并支持自动更新，开箱即可将 WordPress 正确连接至 LSCache。在非 LiteSpeed 源站上，它不会发送整页标头并自动规避干扰，而对象缓存和排除规则仍会继续发挥作用——因此迁移后的站点绝不会处于损坏或仅配置了一半的状态。
保持快速且不提供过时内容：ESI 与智能自动清除
激进的全页缓存存在两种典型的故障模式：向已登录用户提供其他人的页面，以及向任何人提供本应发生更改的页面。这两者都是在缓存层解决，而不是通过减少缓存来解决。
ESI（Edge Side Includes）使我们能够在为必须保持实时的部分预留接口的同时缓存页面。在 WooCommerce 商店中，目录、产品和分类页面均作为全页缓存提供，以实现尽可能最快的 TTFB，而 ESI 则按需呈现购物车片段、迷你购物车总计和账户状态。购物车、结账、我的账户以及任何 nonce 或会话页面默认均被排除在外。购物者始终能看到自己的购物篮和可正常运作的结账页面；每个人也依然能从缓存中获取店面内容。
内容的新鲜度由智能自动清除功能提供保障。当内容、产品、价格或订单发生变化时，清除钩子会自动触发，因此相关的缓存页面会立即刷新，而非等待定时器，您还可以从仪表盘或在 WordPress 内部按需执行清除。基于标签的清除机制意味着编辑单篇帖子只会清除该帖子及其存档——而不是整个缓存——因此单次编辑不会导致整个网站重新冷启动。
单站点 Redis 对象缓存：用于无法生成完整页面的内容
并非每个请求都可以是静态完整页面。已登录会话、WordPress 管理后台、WooCommerce 购物车、搜索以及 ESI 保留的动态片段都必须运行 PHP。对于这些内容，目标已从“跳过应用程序”转变为“跳过数据库”。
每个站点都拥有专属的 Redis 对象缓存。WordPress 会将重复的数据库读取结果（选项、transients、文章与分类项查询、WooCommerce 产品及会话数据）缓存到内存中，从而避免每次访问都针对 MySQL 运行相同的查询。在整页缓存无法起效的地方，这一优势体现得最为明显：更快的控制面板、更流畅的购物车，以及在高流量下显著降低的数据库负载。
对象缓存是按站点独立的，并非共享，这对于性能和隔离性都至关重要。结合按站点的数据库限流措施，单个站点繁重或编写不佳的查询不会耗尽其相邻站点的数据库资源。您可以在我们的缓存功能页面上详细了解整个多层架构是如何协同运作的，以及隔离状态下租户之间的边界。
边缘以及底层的传输
位于源服务器上的缓存仍需穿过网络。CDN 边缘位于服务器前方，因此静态资源和可缓存页面均由靠近访客的网络接入点提供，即使在负载下源服务器也能保持低负荷运行。对于我们的无足迹（footprint-free）主机系列，该边缘是由分布在多个供应商中的 multi-CDN 池组成，既能达成 SEO 足迹目标，也能实现性能目标；在主流 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 这样的缓存插件吗？
不需要。整页缓存由 Web 服务器上的 LiteSpeed LSCache 处理，我们自带的缓存插件（预装并自动更新）可将 WordPress 正确连接到该缓存，后台还配备了针对每个站点的 Redis 对象缓存。在此之上叠加第二个整页缓存插件通常会与服务器级缓存发生冲突而不是提供帮助，因此既不需要也不建议这样做。
缓存会破坏我的 WooCommerce 购物车或已登录页面吗？
不会。Cart、checkout、my-account 以及任何 nonce 或 session 页面在默认情况下都会从缓存中排除，并且 ESI 会在其他已缓存的页面上保持购物车片段和总计金额的实时更新。即使店面仍然从缓存中加载，购物者也始终能看到自己的购物篮和正常工作的结账流程。
当我发布或编辑时，缓存如何保持最新？
智能自动清除功能会在相关的 WordPress 钩子上触发，因此在发布、编辑内容，或更改产品、价格或订单时，仅会清除受影响的页面及其归档——而非整个缓存——随后抓取工具会重新预热它们。您还可以随时从仪表盘或在 WordPress 内部手动清除。
仅凭主机托管服务就能让我获得完美的 Core Web Vitals 吗？
它能为您提供尽可能最佳的 TTFB，这是服务器端的贡献，并为 Largest Contentful Paint 赢得先机。但是，LCP、CLS 和 INP 很大程度上取决于页面本身——图片大小、阻止渲染的资源、布局稳定性以及主线程 JavaScript。我们的技术栈使服务器端响应快速且稳定；而保持精炼的前端载荷则是弥合其余差距的关键。