WordPress 主机：你实际付费买到的是什么

WordPress 主机的售价从每月大约 3 英镑一直排到几百英镑，而价格带两端的方案，用来描述自己的措辞几乎一模一样。快。安全。有备份。有支持。真正能让买家分辨它们的规格，也就是网站跑在哪个 PHP 分支上、背后是哪种数据库引擎、一共有几层缓存、其中又有几层真的开着，通常并不出现在你被要求下单的那个页面上。

这种缺失本身就是产品的一部分。“托管”是一个营销分类而不是技术分类，没有任何标准组织为它下过定义。两家都用这个词的服务商，可能在是否运行持久化对象缓存、是否允许你保留自己的缓存插件、备份能否离开他们的基础设施、你究竟能不能打开一个 shell 这些问题上完全不同。

下面写的正是那些页面略去的规格：WordPress 到底要求什么，技术栈里哪些部分真的影响页面速度，托管型主机加了什么又悄悄拿走了什么，以及每个档位现实的月度价格。

买 WordPress 主机时你实际付费买到的是什么？ 四样东西。一个满足 WordPress 自己公布基线的 PHP 版本和数据库引擎。若干层缓存，否则你得自己安装和调优。运维工作，也就是更新、预发布环境、备份和防火墙。以及应付无法缓存请求的余量。展示型网站几乎不需要第四样。商店或会员站会把大部分预算花在那里。

WordPress 主机是一个类别名称，不是一份规格书

同一个类别内部的价格跨度就是证据。两个都标着托管型 WordPress 主机的方案，可以分别停在每月 20 英镑和 250 英镑，而营销文案不会解释这个差距，因为构成差距的东西文案根本没提。

在便宜的一端，你买到的是一台共享机器上的一块切片，上面有一个 PHP-FPM 进程池、一层页面缓存和一个控制面板。在昂贵的一端，你买到的是隔离的算力、持久化对象缓存、预发布环境、托管防火墙、一支会读你错误日志的支持团队，以及当一次核心更新弄坏模板时在合同上负责的人。

两者都是正当的产品。问题在于买家看不出摆在面前的是哪一种，于是决策就交给了价格，以及按联盟佣金排序的评测站。结果在两个方向上都可以预料。展示型网站落在它一辈子用不完的 150 英镑方案上，而 WooCommerce 商店落在 5 英镑方案上，然后在第一个繁忙的周六于结账环节倒下。

出路是按四个问题选购，而不是按档位名称：哪个 PHP 分支，有哪几层缓存，这个方案能吸收多少不可缓存的请求，以及你离开时你的数据会怎样。

WordPress 对服务器的真实要求

WordPress 公布了一个要求页面，它很短，而这正是它被跳过的原因。请把它当作采购规格来读，因为不满足它的方案，在讨论性能之前就已经出局。

PHP 版本

WordPress 要求页面把推荐基线写作“PHP 版本 8.3 或更高”。同一页还带着一条比推荐更重要的警告：WordPress“仍可在 PHP 7.4 以上和 MySQL 5.5.5 以上运行，但这些版本已到达官方生命周期终点，可能使你的网站暴露于安全漏洞之中”。

整个陷阱就在这一句里。WordPress 不会因为 PHP 分支老旧就拒绝启动。它照跑，看起来正常，然后安静地坐在一个多年没有收到安全修复的解释器上。

数据库

同一页要求“MariaDB 10.11 以上或 MySQL 8.0 以上”。更老的引擎仍能工作，这正是这么多网站还留在上面的原因。WordPress 自己的使用统计显示，大约每六个上报的安装里就有一个报告 MySQL 5.x 版本，远低于写明的下限，其中仅 MySQL 5.7 就占上报站点的约 12%。

后果不是网站会坏，而是你错过了引擎层面的改进，而那些改进恰恰作用于最难缓存的负载；同时你还背上了一次迟早都得做的迁移。

HTTPS 与扩展

HTTPS 被列为“每个安装都必需”，不是推荐。到了 2026 年还把证书当成付费加购项的主机商，已经顺便告诉了你这个方案的其余部分是什么水平。

除此之外，WordPress 主机手册把 json 和 mysqli 列为必需，把 curl、dom、exif、fileinfo、hash、igbinary、imagick、intl、mbstring、openssl、xml 和 zip 列为强烈推荐。有两个值得在销售面前点名。没有 zip，插件和核心的更新包无法解压。没有 imagick，媒体上传会退回到较弱的图像库，于是在任何人碰优化插件之前，你的图片质量就已经变差了。

PHP 版本是账单上杠杆最高的一行

在主机商掌控的一切当中，PHP 分支的效果与成本之比最好。在多数面板上它就是一个下拉框。什么都不用重建，什么都不用迁移，一个本来就兼容的网站就这样开始跑在更快也更受支持的解释器上。

它多年不变的原因是组织性的，不是技术性的。没有人拥有它。当初做这个网站的团队早已离开，主机商不会单方面改动，因为一个废弃插件抛出致命错误就成了他们的责任，而业务方也没有理由去想一个从来没人给他们看过的数字。

所以，问一家候选主机商的第一个问题不是速度，而是这个方案默认跑哪个 PHP 分支、提供哪些分支，以及你能否不开工单自己切换。一家只提供 WordPress 已不再推荐的分支的主机商，等于同时回答了其余所有问题。

在预发布环境测试，绝不要直接切生产。从 PHP 7.4 迁到 8.3 的网站，通常会从无人维护的插件里冒出两三条弃用提示，那才是真正的成本。请预留半天到一天的开发工时，我们在WordPress 开发者报价与该问的问题一文里讲得更细。

PHP 之争的安全那一半

人们给出的升级 PHP 的理由是性能。真正重要的理由是安全，而且它是可以度量的，不是可以争论的。

PHP 自己发布受支持版本时间表。每个分支获得两年的活跃支持，随后再有两年只提供安全修复。截至 2026 年 9 月，PHP 8.2 处于仅安全修复状态直到 2026 年 12 月 31 日；PHP 8.3 的活跃支持已于 2025 年 12 月 31 日结束，之后仅安全修复直到 2027 年 12 月 31 日。PHP 8.4 的活跃支持持续到 2026 年 12 月 31 日，安全修复到 2028 年 12 月 31 日；PHP 8.5 活跃支持到 2027 年 12 月 31 日，安全修复到 2029 年 12 月 31 日。比这更老的都已终结：PHP 8.1 于 2025 年 12 月 31 日结束，PHP 8.0 于 2023 年 11 月 26 日，PHP 7.4 于 2022 年 11 月 28 日。

把这些对照 WordPress 网站实际跑的东西。WordPress 统计页面报告，约 38.8% 的安装跑在一个完全生命周期终结的分支上，约 23.2% 仍停在 PHP 7.4 或更旧。只有约 36.4% 达到 WordPress 推荐的 PHP 8.3 基线，另有 24.8% 停在 PHP 8.2 上，而它将在今年年底失去安全支持。

也就是说，多数 WordPress 网站跑的解释器要么已经收不到安全修复，要么离那一天只剩几个月，而几乎每一例都只是一个没人看过的主机设置。纠正它的花费比一份插件授权还低，所以我们的WordPress 安全加固清单把它列为第一步。

缓存的层次，按一次请求遇到它们的顺序

主机商提出的性能主张几乎全是关于缓存的主张，而几乎每个买家都把它们听成一个笼统的承诺。缓存有四个不同的层，它们的次序固定，各自省下不同种类的工作。下面的顺序就是一次请求穿过它们的顺序，被前面某一层答复的请求永远不会到达后面的层。

边缘缓存，也就是 CDN

一次请求最先遇到的，是完全在你服务器之外、位于靠近访客的接入点网络上的缓存。如果响应已经存在那里，你的主机根本看不到这次请求。

这一层省下的不只是算力，还有网络距离。曼彻斯特的访客命中伦敦的边缘节点，就避开了一次跨大西洋往返。对静态资源来说它几乎是免费的，永远值得拥有。对 HTML 来说它很强大但有条件，因为你必须告诉边缘哪些响应是私人的、绝不可共享。

整页缓存

第二层保存一个页面渲染完成的 HTML，于是 PHP 和数据库不必再跑一遍。WordPress 主机手册推荐使用 NGINX 或 Varnish 这类反向代理，它“把输出直接存入服务器内存或硬盘”，并补上了决定这一层能否奏效的规则：“把所有已登录用户排除在缓存之外是个好主意，因为他们本应看到个性化内容。”

正是这一层让廉价主机显得体面。当它奏效时，访客拿到的是一个文件，而 PHP 版本、数据库引擎和插件数量对这次请求都不再重要，因为它们一个都没有执行。

对象缓存

第三层缓存的是单条数据库查询的结果和计算出来的值。WordPress 默认自带这一层，但它不是持久的。WP_Object_Cache 文档说得很直白：“默认情况下对象缓存是非持久的。这意味着存入缓存的数据只存在于内存中，且只在该次请求期间存在。”

让它持久化，意味着通过一个 drop-in 把 Redis 或 Memcached 放到它后面，从而把一个每次页面加载都要重建的缓存，变成一个跨请求、跨访客共享的缓存。当页面整体不再可缓存时，正是这一层开始起作用，而它也是廉价方案里最常缺席的一层。

操作码缓存

第四层是 OPcache，它把你的 PHP 文件编译后的字节码放进共享内存，让解释器不必在每次请求时重新解析和编译。主机手册写道：“对于生产环境的 WordPress，建议为网页请求启用 OPcache，并按站点或主机平台的规模进行配置。”

这带来一个部署上的后果。因为 OPcache 持有的是编译后的代码，一次部署必须重置它或让改动过的文件失效，否则服务器会继续跑上一个版本。一家说不清 OPcache 如何失效的主机商，就是那种插件更新后几分钟内看起来什么都没发生的主机商。

为什么展示型网站在几乎任何主机上都很快

顺着这四层推下去，会得到一个让主机行业不太舒服的结论。如果每位访客都是匿名的、每个页面都可缓存，那么整页缓存会答复几乎全部流量，而它背后那台机器的规格几乎不起作用。

所以，一个五页的公司网站跑在 4 英镑的方案上、配一层像样的页面缓存，服务器响应时间可以好过一个臃肿网站跑在 200 英镑方案上的成绩。便宜那个在发文件，贵那个在跑 PHP。

要盯的数字是首字节时间，它本身并不是一项核心网页指标。Google 的 Web Vitals 总览把它归入辅助指标，用于“诊断由服务器响应慢引起的 LCP 问题”。那恰恰是主机商能控制的那一小片页面速度。

WordPress 也大体同意，同意到把它写进了核心。WordPress 6.1 新增的站点健康整页缓存检测，会检查“网站是否在使用整页缓存方案，以及响应时间是否可以接受”，默认阈值是 600 毫秒。如果你号称启用了页面缓存却仍高于这个值，那就是缓存没在工作，多加 CPU 也掩盖不了。

所以对展示型网站来说，升级主机通常是买错了东西。让它慢的更常是一张过大的首屏图、一个发送数百千字节 CSS 的页面构建器，或者六种字重，这正是我们在Elementor 与定制主题的对比里给出的论点。

登录流量与 WooCommerce 打破了这个模型

上面的一切都假设页面缓存能够答复。访客一登录，这个假设就崩塌，主机的经济学也随之反转。

WooCommerce 把这点写得很清楚。它的缓存指南要求你把购物车、我的账户和结账页排除在页面缓存之外，因为这些页面“必须保持动态，因为它们显示的是当前顾客及其购物车的专属信息”。它还列出了必须绕过缓存的 Cookie，包括 woocommerce_cart_hash、woocommerce_items_in_cart 和 wp_woocommerce_session_，并建议把 _wc_session_ 排除在数据库缓存之外。

把它当作一份主机规格来读，它说的话相当不客气。在一家商店里，产生营收的页面恰恰是页面缓存碰不到的页面。目录页和商品页可以为匿名浏览者缓存。购物车和结账不行，对任何人、任何时候都不行。

会员站、学习平台、论坛，以及任何带客户门户的网站，情况完全一样。会话 Cookie 一旦设置，多数缓存插件就彻底不再向该访客提供缓存过的 HTML，于是每一次点击都在执行 PHP 并打到数据库。正是在这里，对象缓存不再是优化而成为承重结构，也正是在这里，廉价方案会以任何合成首页测试都看不出的方式让你受伤，详见你的 WooCommerce 商店为什么慢。

托管型 WordPress 主机实际包含什么

剥掉形容词，托管型主机会收敛成一组相当一致的运维工作。诚实地为这份工作定价是值得的，因为对一家没有技术人员的企业来说，买它往往比自己做便宜。

更新

托管型方案通常会自动应用核心更新，有时也管插件更新，偶尔还会在前后做一次视觉回归检查。这里有用的一点，是先弄清 WordPress 自己已经免费做了多少。

WordPress 多年来默认自动更新次要核心版本和翻译文件，而且自 5.6 起，新安装默认启用自动更新，除非检测到版本控制检出，否则次要和主要核心版本都在内；已有安装则保持旧行为。所以你付费买到的不是核心的次要更新，而是插件更新、其中某个更新出问题时的回滚，以及有人注意到它出了问题。

预发布环境与备份

一键预发布环境确实有价值，也确实很难自己搭。请用两个细节而不是它是否存在来判断：把预发布推回生产时会不会覆盖线上数据库，那会丢掉自复制以来收到的订单和评论；以及预发布站点是否已被屏蔽搜索引擎并禁止发信。

防火墙与恶意软件扫描

多数托管型方案都在边缘包含一层 Web 应用防火墙和某种恶意软件扫描。防火墙是实打实的价值，因为网络层的虚拟补丁能在一个插件漏洞被披露到你完成更新之间买到时间。

扫描比听起来弱。它通常检测已知的恶意文件特征，也就是说能抓到批量传播的感染，会漏掉针对性的入侵。请把它当成烟雾报警器而不是锁，把加固工作留在自己这一侧。

托管型主机拿走了什么

限制是没人读的那一半，而且通常比功能更有后果。它们的存在有站得住脚的理由，只是那些理由属于服务商，不属于你。

公开材料里最清楚的例子是 WP Engine 的禁用插件清单，它封禁的是整类插件而不是个别害群之马。缓存插件被禁，因为它们“可能与我们平台内建的缓存结构冲突”。备份插件被禁，理由是它们“毫无必要地让你的网站变臃肿”。相关文章插件被禁，因为“对数据库的消耗极大”。有已知漏洞的插件被直接封禁，与平台功能重复的插件同样如此。

其中每一条都是合理的工程决定。但它们合起来意味着：你的网站并不像你以为的那样可以随时搬走。如果你的构建依赖某个缓存插件的具体配置，那份配置不会跟着你走。

Shell 访问是另一个常见的缺项。不少托管型方案完全不提供 SSH，或者只给一个没有 WP-CLI 的受限 shell，于是换域名后做一次批量查找替换这样的日常工作，就变成了一张支持工单。还有两点会让人吃亏：长时间运行的进程常被设上限，因此导入 50,000 件商品必须分批；出站邮件也经常被屏蔽或限速，前提假设是被入侵的网站会被拿去发垃圾邮件。

经不起测试的性能主张

主机营销靠的是一小组主张，而它们在你追问究竟测了什么的那一刻就散架了。

“快 20 倍”几乎从不说明基准。比什么快，在哪个页面上，带哪些插件，在多大并发下？没有这四点，这个数字只是两个未命名的量之间的比值。

“无限带宽”就摆在同一张表里的月访问量额度旁边。反正带宽很少成为 WordPress 网站的瓶颈。瓶颈是并发的 PHP 执行能力，而方案通常压根不提它。

“99.9% 可用性”听上去是绝对的，其实不是。在一个三十天的月份里，它允许大约 43 分钟的停机。三个九是共享主机的正常水平，四个九每月只允许约四分钟，二者的差别就是不便与无人察觉之间的差别。请读清楚没有达标时那份赔偿实际赔什么，这个题目我们在有意义的可用性 SLA里单独处理过。

最后一个主张最常见也最有误导性：一张在缓存过的首页上跑速度测试的截图。它测的是页面缓存，不是主机，而页面缓存恰恰是各家大同小异的那个部件。

如何正确地测试一家主机

测试主机并不难，但必须走真正让服务器干活的路径。按顺序五步。

第一，测一条不走缓存的路径。附加一个唯一的查询字符串来击穿页面缓存，或者请求一个从不缓存的页面，比如购物车或账户页。如果你造不出一个会执行 PHP 的请求，那你测的是一台文件服务器。

第二，重复它。单次请求什么也说明不了方差，而方差正是廉价主机露馅的地方。至少取 20 个样本，并读第 75 百分位，这是 Google 在现场数据里使用的统计量。

第三，从访客所在的位置测。在服务器隔壁的数据中心量到的响应，不是你在利兹的顾客收到的响应。

第四，在并发下测。同时发起 10 到 20 个不可缓存的请求。这是唯一能暴露 PHP 工作进程耗尽的测试，而工作进程耗尽正是促销期间放倒商店的东西。

第五，同类相比：同一个 PHP 分支、同一套插件、同一个主题、同样的内容量。一次在换主机的同时也换掉插件栈的迁移，对两者都什么都没证明。如果你想把这套流程跑在一个真实站点而不是候选主机上，那正是WordPress 性能审计在做的事。

主机真正能影响哪些核心网页指标

核心网页指标是主机主张与搜索排名最容易被混为一谈的地方，所以有必要说清楚服务器究竟能影响哪一项。

一共三项，在页面加载的第 75 百分位上评估，并按移动端和桌面端分别统计。Largest Contentful Paint 衡量加载，2.5 秒及以内为良好，2.5 秒到 4.0 秒之间需要改进，超过 4.0 秒为差。Interaction to Next Paint 衡量响应性，200 毫秒及以内为良好，到 500 毫秒为需要改进，超过则为差。Cumulative Layout Shift 衡量视觉稳定性，0.1 及以内为良好，到 0.25 为需要改进，超过则为差。First Input Delay 已被淘汰并由 INP 取代，INP 在 2024 年成为正式的核心网页指标。

主机直接影响的只有其中一项。服务器响应时间是 LCP 的一部分，所以一家把它削掉 400 毫秒的主机商，就为每一位访客的 LCP 削掉 400 毫秒。在一台慢主机上，这可能就是通过与不通过的差别。

它对 CLS 几乎没有作用，那来自没有尺寸的图片和加载过晚的字体；对 INP 也作用很小，那由主线程上的 JavaScript 主导。规则是：如果 LCP 为差，而你未缓存的服务器响应高于 WordPress 标出的 600 毫秒，那么主机是问题的一部分。如果响应很宽裕而 LCP 仍然为差，问题就在页面里，我们的2026 年如何通过核心网页指标指南才是更该花预算的地方。

备份，以及没人核对的那部分

除了最便宜的方案，每个方案都宣传备份。而买下它的人几乎没有谁去问那些真正决定备份是否值钱的问题。

有没有人真的还原过一次

NCSC 在其小型组织指南里说得很直白：做完备份之后，“重要的是你知道如何还原它，并检查它是否包含你全部的重要数据”。没有测试过的备份是一种信念，不是一项控制措施。

请询问服务商还原如何发起、对你这种规模的站点要多久，以及还原数据库是否也会还原上传目录。然后在你真正需要它之前，在预发布环境上做一次。要留意的失败形态是：还原回来了文件却没有数据库，或者还原“成功”了却悄悄丢掉了自复制以来产生的一切。

保留期与频率

每日备份加七天保留听起来很慷慨，直到你想清楚一个 WordPress 网站实际是怎么出事的。被涂改的网站几小时内就会被发现。而一次安静地往旧文章里注入垃圾链接的入侵，往往几周后才被发现，那时保留下来的每一份副本都已经含有注入。

对任何商业站点来说，三十天是更实用的下限，另外单独留一份月度副本是很便宜的保险。商店还需要按订单量来定数据库备份间隔，因为丢掉四小时的订单和丢掉四小时的博客编辑，不是同一类问题。

副本存放在哪里，以及以什么格式

NCSC 的另一个要点是：仍然连在生产系统上的备份并不算分离。存放备份的设备“不使用时不应保持与你的设备相连”，因为凡是能攻陷源头的东西也够得到它。套到主机上，一份存在同一个账户里、只能通过同一个面板还原的备份，与它所保护的对象共享同一种命运。

格式是同一个问题更隐蔽的版本。如果读取备份的唯一方式是服务商自己的还原按钮，那你拿到的是一个便利功能，而不是一份可携带的副本。检验标准是：你今天能否下载一份纯 SQL 转储和一个文件归档，让一位称职的开发者可以在别处把它跑起来。如果不能，迁移就不再是技术决定，而变成一场谈判。

数据放在哪里，以及为什么这对英国买家重要

主机决策就是数据保护决策，而对一家英国企业来说，问题不是这家公司注册在哪里，而是个人数据存放在哪里、谁够得到它。

英国信息专员办公室 ICO 的国际传输指南给出了三步判断。如果英国 GDPR 适用于你的处理活动，发起传输的是你，而接收方是一个独立法律实体，那么你正在进行一次受限传输。ICO 明确指出，这些规则“适用于所有受限传输，即使是小规模、不频繁的传输”，并覆盖每一个处理个人数据的组织，“包括个体经营者和自雇人士”。

也要注意什么算作传输。ICO 把传送个人数据和让英国境外的组织“能够访问”这些数据都算在内。一支能进你后台的境外支持团队，或一份复制到另一个区域的异地备份，都可能各自满足这个定义。

每一次受限传输都必须由三样东西之一覆盖：目的地的英国充分性认定，适当的保障措施如国际数据传输协议、附录或有约束力的公司规则，或者某项例外。当你依赖保障措施时，ICO 还要求一份传输风险评估，证明传输之后保护水平没有实质降低。这些都不会让境外主机变得不可用，只是让它成为一个需要留下文档的决定，而在迁移之前留文档，远比迁移之后或在一次主体访问请求进行中留文档便宜。

一份处理者协议该写些什么

你的主机商是处理者，你是控制者，所以书面合同不是可选项。ICO 列出了合同必须包含的内容，其中四条可以直接读作对主机商的提问。

首先是次级处理者。根据第 28 条 (3)(d)，处理者未经你的授权不得聘用另一个处理者，必须把打算做的变更告知你以便你提出异议，并且必须把等同的义务施加到整条链路上。落到主机上，那就是 CDN、备份目的地、邮件中继和底层云服务商。请索要清单。

其次是安全。第 28 条 (3)(c) 要求措施满足第 32 条，而 ICO 把这些措施说得很具体：加密与假名化，处理系统的韧性，“在发生事故时恢复对个人数据访问的能力”，以及“定期测试和评估这些措施有效性的流程”。这就是把还原演练写进了法律，而不是写进一篇最佳实践文章。

第三是退出。根据第 28 条 (3)(g)，合同结束时处理者必须按你的选择删除或返还全部个人数据，并删除现有副本。一家备份无法离开其平台的服务商，除了实务问题之外还有合同问题。第四是审计，根据第 28 条 (3)(h)，你有权取得证明合规所需的信息，以及他们的认证与报告。

各个档位，以及它们在英国的价格

四个档位覆盖了几乎每一个 WordPress 网站，而档位之间的界线由不可缓存的负载划定，不是由流量划定。下面的区间是英国买家通常每月支付的金额。它们是类别区间而不是任何单一厂商的价目表，所以请把它们当作对报价的合理性检查，而不是报价本身。

共享主机，每月 3 到 15 英镑

对可缓存的展示型网站完全够用，一旦有人登录就是真正的差价值。你和看不见的邻居共享 PHP 容量，所以咬人的是负载下的方差而不是平均值。先查 PHP 分支，因为生命周期终结的解释器最集中的就是这一档。

托管型 WordPress，每月 20 到 400 英镑

内容站和小型商店的正确默认选项。你买的是更新、预发布环境、防火墙、持久化对象缓存和一支支持团队，代价则是上文那些限制。20 到 100 英镑这一段覆盖一个流量中等的单站。再往上，你通常是在为更多站点、更多访问量或更多 PHP 工作进程付费。

VPS 或云上自建技术栈，15 到 120 英镑外加代管费

一个不算大的云实例每月 15 到 120 英镑，但机器是便宜的那部分。总得有人给操作系统打补丁、调反向代理、运行对象缓存和处理备份，把这份工作买进来每月还要再花 150 到 600 英镑。当不可缓存的负载真实存在，或者你的技术栈有托管平台禁止的需求时，它就值这个钱。

定制基础设施，每月 400 英镑起

多区域部署、高并发活动、严格的数据驻留要求，或者一种 WordPress 只是众多组件之一的架构。主机不再是一次产品选择，而成为构建的一部分，这也正是我们在网站开发项目里对待它的方式。

按不可缓存请求而不是按页面浏览量来估容量

主机方案按月访问量出售，因为那是买家认得的数字。它对容量规划几乎没用，因为十万次缓存过的匿名页面浏览几乎不花什么成本，而一万次登录状态的浏览就能压垮一台小服务器。

真正重要的数字是并发的不可缓存请求数，而算术很简单。一个 PHP 工作进程一次处理一个不可缓存请求。所需工作进程数大约等于峰值每秒不可缓存请求数乘以以秒计的平均 PHP 响应时间。每秒 20 个不可缓存请求、每个 400 毫秒，大约需要八个工作进程才跟得上，而你还想再留出至少一半作为余量。

所以请提两个方案页面回答不了的问题：这个方案跑几个 PHP 工作进程，单进程内存上限是多少？这两个数字都存在，而且通常都不公开。你直接问，支持一般会告诉你，而这个答案比页面上所有基准测试加起来更能说明这个方案。

然后诚实地估算你自己这一侧。数一数处于登录状态的会话比例，取最忙那一小时而不是平均值的结账与账户流量，以及你的插件在后台产生的 admin-ajax 或 REST 流量，后者在分析工具里看不见，在服务器日志里却非常显眼。

插件数量与内容产出量都是主机决策

网站内部有两样东西决定了它需要多少主机资源，而这两样通常被当作内容决策，由从来看不到账单的人来定。

第一是插件栈。每一个启用的插件都会增加每次请求都要加载的自动加载选项、因为 WordPress 的 cron 不是真正的 cron 而在访客请求上触发的计划任务，以及每次页面构建的查询数。一个有缓存的展示型网站上三十个插件还活得下去。一家什么都缓存不了的商店上三十个插件，意味着结账的每一步都要执行三十个插件。WordPress 核心对这从什么时候开始咬人有个粗略判断：持久化对象缓存的站点健康检测建议，一旦站点越过诸如 2,000 篇文章、2,000 个用户或 600 个自动加载选项这样的门槛，就启用对象缓存。

第二是内容产出量。修订版本默认无上限地堆积，媒体库会长成数以万计的文件、每个还带好几个生成尺寸，两者都会撑大数据库和备份窗口。一个连续五年每天发布的网站，和同样设计但每月发布一次的网站，是实质不同的主机问题，而方案页面丝毫反映不出这一点。在为一次迁移报价之前，WordPress 开发者该做的是审计这个构建，而不是审计这个方案。

按顺序做选择

按这个次序走一遍，决定通常会自己浮现。先确定你的流量里有多大比例不可缓存，因为这一个数字就决定了你的档位。确认 PHP 分支和数据库版本达到公布的基线，因为在这里不合格的方案无论价格如何都出局。确定哪些缓存层已包含、哪些必须你自己提供。问清楚备份放在哪里、是什么格式、你今天能否下载一份。然后阅读处理者条款中关于次级处理者、数据位置和合同终止时删除的部分。走完这一切之后，价格才开始有意义，因为在那之前你比较的根本不是同一种产品。

Mecanik 把这件事做成任何迁移之前的一项固定工作，通常与一个网站开发项目并行，并通过我们的WordPress 开发者外包服务把它接成长期支持。如果你在权衡这个平台本身要往哪里走，我们关于WordPress 7.0 与进入核心的 AI 客户端的文章是这篇的合适伴读。

常见问题

在英国 WordPress 主机应该花多少钱？ 这几乎完全取决于你的流量有多少可以被缓存。只有匿名访客的展示型网站，在共享主机上每月 3 到 15 英镑就足够。内容站或小型商店通常属于托管型 WordPress 主机，每月 20 到 100 英镑，繁忙或多站方案会升到 100 到 400 英镑。登录流量很重的商店或会员站通常需要 VPS 或云技术栈，机器每月 15 到 120 英镑，若由别人代管则每月再加 150 到 600 英镑。

托管型 WordPress 主机值得多花的钱吗？ 如果你没有运维人员，那就值得，因为你买的是更新、预发布环境、备份、防火墙和一层本来要你自己配置的持久化对象缓存。代价是真实的限制。服务商常规性地封禁缓存插件、备份插件和数据库消耗大的插件，往往不给 shell 访问，对长时间运行的进程设上限，并屏蔽出站邮件。请在签约之前而不是之后，把这些限制对照你的构建核对一遍。

2026 年 WordPress 需要哪个 PHP 版本？ WordPress 推荐 PHP 8.3 或更高。它在 PHP 7.4 及以上仍能运行，但那些分支已到生命周期终点，不再收到安全修复。PHP 8.1 于 2025 年 12 月 31 日结束，PHP 8.0 于 2023 年 11 月 26 日，PHP 7.4 于 2022 年 11 月 28 日，而 PHP 8.2 处于仅安全修复状态直到 2026 年 12 月 31 日。约 38.8% 的 WordPress 安装仍在报告一个完全生命周期终结的分支。

更好的主机能改善核心网页指标吗？ 三项里只有一项，而且只是间接的。服务器响应时间是 Largest Contentful Paint 的一部分，所以更快的主机会为每位访客降低 LCP。它对 Cumulative Layout Shift 几乎没有作用，那来自没有尺寸的图片和加载过晚的字体；对 Interaction to Next Paint 作用也很小，那由主线程上的 JavaScript 主导。如果你的服务器响应已经很宽裕，剩下的问题就在页面里。

为什么我的 WooCommerce 商店在号称很快的方案上却很慢？ 因为真正要紧的页面无法缓存。WooCommerce 要求购物车、我的账户和结账保持动态，并为已登录的购物者设置绕过页面缓存的会话 Cookie。你首页上的速度测试量的是一个缓存过的文件，而结账在每一次请求上都在执行 PHP 并打到数据库。一家商店真正买的是应付不可缓存请求的容量，而不是那个缓存过的首页数字。