WordPress 托管与插件
让 WordPress 更快更安全：性能与插件核对清单
WordPress 的运行速度和安全程度完全取决于承载它的底层系统。以下是我们应用于所托管的每一个 WordPress 站点的实用核对清单 — 哪些需要缓存、哪些需要加固安全，以及哪些插件值得保留、哪些已被平台本身的功能取代。
WordPress 的性能取决于运行它的环境
WordPress 为网络的大部分内容提供支持，因为它极具灵活性，但这种灵活性也是它变慢和变得不安全的原因：默认安装下每个页面都会查询数据库数十次，向所有查看者公开其版本和技术栈，并诱导您不断堆叠插件，直到性能下降且攻击面悄然激增。这些与其说是 WordPress 本身的缺陷，不如说是在没有提供任何帮助的基础设施上运行它所导致的结果。
好消息是，只需做出少数几项相同的决策便能解决大部分问题，而且这些决策关乎技术栈而非内容本身。在适当的层级积极进行缓存，让数据库远离热点路径，仅运行极少数确实物有所值的插件，保持所有组件及时修补，并隔离网站以确保问题得到控制。本文正是这份清单，已按照我们应用于平台上每个 WordPress 网站的顺序进行排列。
在服务器端进行缓存，而不仅仅是在插件中
提升 WordPress 速度的最重要单一杠杆是在大多数访问中完全不运行 WordPress。标准请求在发送任何字节之前，都会启动 WordPress、运行您的插件并查询数据库；而全页缓存会在下一次访问时直接从网络服务器提供已完成的页面，从而跳过整个启动过程。该缓存所在的位置至关重要：缓存插件位于 PHP 内部，因此在缓存能够响应之前 PHP 仍会启动，而服务器级缓存则会在请求的更早阶段作出响应，并以服务器可以即时清空的形式保存页面。
我们托管的每个 WordPress 站点均在配备服务器级 LSCache 的 LiteSpeed Enterprise 上运行，并且我们自有的缓存插件开箱即可将 WordPress 正确连接至该系统——已预先安装并自动更新，因此您无需额外配置或维护。在非 LiteSpeed 源站上，同一插件只需不发出整页标头即可保持避让，同时对象缓存继续工作，从而确保迁移后的站点绝不会处于半配置状态。供您自查清单参考的实用规则：服务器端保留一个整页缓存，切勿在其之上堆叠第二个缓存插件——它们会相互冲突。
对象缓存和数据库
并非每个请求都可以是静态页面。已登录会话、管理后台、搜索、购物车和任何个性化片段都必须运行 PHP，对于这些情况，目标从跳过应用程序转变为跳过数据库。单站点对象缓存（在我们的方案中为 Redis）将重复的数据库读取结果保留在内存中，因此无需在每次访问时都针对数据库查询相同的选项、临时数据和查找项。其效果恰恰体现在整页缓存无法提供帮助的地方：更快的管理后台、更流畅的购物车，以及流量高峰期显著降低的数据库负载。
至关重要的词是“按站点”（per-site）。共享对象缓存意味着一个繁忙或编写糟糕的站点可能会清除其他所有人的缓存数据，并让邻近站点缺乏数据库资源；而专用的按站点缓存与按站点数据库限制相结合，可以将这种影响范围控制在一定范围内。在您的清单上，对于任何包含登录用户或商城的站点，都应将持久对象缓存视为不可或缺的项，并对租户之间共享该缓存的托管服务保持警惕。
值得运行的插件——以及平台所替代的插件
您添加的每个插件都是在请求时运行的代码，也是有朝一日可能被人利用的门户，因此切合实际的目标是用尽可能少的插件做尽可能多的事。一个优秀的托管主机可以让整整一类的插件不再有存在的必要：有了服务器级缓存、托管对象缓存和平台级备份，您就不需要缓存插件、单独的对象缓存插件或备份插件——这些工作在 WordPress 底层能处理得更好，而在上层运行它们只会增加冲突和系统开销。
剩下值得运行的，只有那一小部分能带来实际功能的插件：您的网站运行真正需要的插件，以及——在我们的平台上——我们构建并为每个网站预装的两个官方代码库级别的插件。我们的缓存插件将 WordPress 与服务器缓存相连接，并处理智能清理，从而确保每次编辑仅清除确实需要清除的页面。我们的足迹消除插件会在每次部署时，剥离默认 WordPress 安装向外广播的痕迹——版本号和生成器标签、发现端点、XML-RPC、pingback 以及 powered-by 请求头——因此插件或主题更新不会悄然恢复它们。两者均按照 WordPress.org 插件目录标准构建，完全免费，且支持自动更新。
保持 WordPress 安全并处于最新状态
大多数 WordPress 入侵并不高明，它们都很老套。带有已知公开漏洞且过时的核心、主题或插件是网站遭受攻击的绝大多数常见途径，这使得保持更新成为最有价值的安全工作——也是最繁琐的工作，正因如此它常常被忽略。托管型主机服务应当为您分担此项负担：修补 WordPress 底层的技术栈，并通过提供用于测试的分阶段环境副本以及用于回滚的备份，确保核心和插件更新能够安全地应用。
除了时效性之外，您还可以期待平台为您筑牢安全边界：默认开启恶意软件扫描，从而在访客察觉之前就捕获感染；严格隔离，确保单个受损站点无法波及其他站点；在边缘提供 DDoS 防护；并在所有环节应用 TLS，证书自动续期。这些都无法取代基本的安全习惯——强凭证、最小权限访问、移除不再使用的插件——但这意味着基础设施不会成为薄弱环节。在您的核对清单上，针对任何主机商的问题都很简单：安全是默认配备，还是需要额外购买的捆绑包？
WooCommerce 以及切勿缓存的页面
对于商店而言，如果激进缓存处理不当，其带来的损害与带来的最大收益一样显著。目录、产品和分类页面是您流量最高、最适合缓存的页面，通过整页缓存提供这些页面是您提升商店速度的最佳途径。但是购物车、结账和账户页面属于个人页面，绝不能通过共享缓存提供——如果这样做，顾客就会看到他人的购物车，这不仅会导致商店功能异常，还会造成隐私泄露。
兼顾两者的途径是对页面进行缓存，并为实时动态部分“挖孔”。当页面的其余部分从缓存中提供时，Edge Side Includes 会根据每个请求渲染购物车片段、迷你购物车总额以及账户状态，而 cart、checkout、my-account 以及任何包含 nonce 或会话的页面在默认情况下均会被排除。数据的新鲜度由智能自动清除机制处理，该机制会在产品、价格或订单发生变化时触发，从而确保陈旧价格绝不停留。如果您运营 WooCommerce，这是核对清单中必须确保完全准确的部分：从缓存中快速加载店面、针对每位用户的实时购物车，以及绝不缓存任何个人信息。
常见问题
我还需要像 WP Rocket 这样的缓存插件吗？
不需要。整页缓存由 LiteSpeed 的 LSCache 在 Web 服务器端处理，我们自有的缓存插件负责将 WordPress 与其连接并执行智能清理，底层还有为每个网站单独配置的 Redis 对象缓存提供支持。在此基础上再添加第二个整页缓存插件通常会与服务器级缓存发生冲突，而不是起到辅助作用，因此既无必要也不推荐。
该平台使哪些插件变得不再必要？
缓存插件、独立的对象缓存插件和备份插件在这里都是多余的，因为这些工作都在 WordPress 底层完成——服务器级缓存、按站点托管的对象缓存以及平台备份。移除它们可以减少冲突和受攻击面。真正值得保留运行的，是您的网站正常运作切实需要的插件，再加上我们预装的两个免费缓存与 footprint 插件。
缓存会破坏我的 WooCommerce 购物车或已登录页面吗？
不。购物车、结账、my-account 以及任何 nonce 或会话页面默认均从缓存中排除，Edge Side Includes 则确保在其他已缓存的页面上购物车片段和总计金额保持实时更新。买家始终能看到自己的购物篮和可正常使用的结账流程，同时店面仍然从缓存中加载；当商品、价格或订单发生变化时，智能自动清除功能会清理受影响的页面。
在不需要我进行管理的情况下，您是如何确保WordPress安全的？
我们修复 WordPress 底层的软件栈，通过暂存环境和一键恢复确保核心与插件更新的安全应用，默认开启恶意软件扫描与 DDoS 防护，隔离每个站点以防单一安全事件扩散，并自动签发和续期 TLS 证书。这消除了作为薄弱环节的基础设施隐患；而采用强凭据和清理无用插件等基本安全规范仍由您负责。