WordPress 网站打开慢，大多数情况下不是主机性能不够，而是缓存与静态资源没有配置到位。Hostinger 的独特之处在于整条托管链路跑在 LiteSpeed Web Server（LSWS）上，并预装了 LiteSpeed Cache 插件，这决定了它的加速思路和普通 Apache 主机完全不同。这篇教程按收益顺序讲清楚 Hostinger 上的 WordPress 加速怎么做：三层缓存如何工作、hPanel 里哪些开关真正影响分数、CDN 怎么开，以及 WooCommerce 这类动态站点的专项优化。
一、先搞清 Hostinger 的 LiteSpeed 加速栈
Hostinger 使用 LiteSpeed Web Server 而不是 Apache 或 Nginx，所以它和传统 cPanel 主机的缓存体验不一样。LSWS 内置了服务器级页面缓存，由 WordPress 后台里的 LiteSpeed Cache（LSCWP）插件统一控制。按 LiteSpeed 官方文档的说明，LSCWP 可以直接集成服务器缓存，并在页面缓存之外额外提供对象缓存（LSMCD），帮助站点在查询结果层提速。
整套缓存机制可以拆成三层，理解每一层负责什么，才知道该调哪里：
| 缓存层 | 实现机制 | 对访客的影响 | 默认状态 |
|---|---|---|---|
| 服务器级页面缓存 | LSWS 把渲染好的完整 HTML 存在内存里，命中时直接输出，完全跳过 PHP | 缓存命中率可达 90% 以上，预热后访客 TTFB 可低于 100ms | 随 LSCWP 启用 |
| 浏览器缓存 | LSCWP 自动为 CSS、JS、图片设置长过期缓存头，浏览器本地复用 | 二次访问静态资源几乎零延迟 | 默认开启 |
| 对象缓存（LSMCD） | 用 LiteSpeed Memcached 守护进程缓存数据库查询结果，重复查询直接从内存返回 | WooCommerce 购物车、会员区、后台编辑等高动态页面提速最明显 | 默认关闭，需在 hPanel 开启 |
Hostinger 帮助中心在介绍 WordPress 提速方法时也提到，LiteSpeed 的缓存插件不同于一般缓存插件，它直接与 Web 服务器集成，会记录条目并分析依赖关系来做更智能的缓存管理；对象缓存（LSMCD）能提升站点响应时间约 10%，并显著缩短查询结果的获取时间。
二、优化前先记录性能基线
没有基线的优化是瞎调。动手之前，先用 PageSpeed Insights 或 GTmetrix 记录三个数字：TTFB（首字节时间）、LCP（最大内容绘制）、整页体积。这三个数字决定了优化方向：如果未缓存请求的 TTFB 已经超过 1500ms，问题在主机上游而不是缓存；如果首页体积超过 3MB，先压图片和字体，缓存只能省毫秒，删掉 2MB 无用 JS 能省几秒。
记录基线时要在无痕窗口测试三次取中位数，并且先在 WordPress 后台的 LiteSpeed Cache > Toolbox > Purge All 清一次缓存，否则测到的是热缓存结果，数值会虚高。
三、hPanel 里真正影响分数的开关
Hostinger 的 hPanel 里和速度相关的设置分布在几个菜单，按收益从高到低排，下面这几个是最值得动的：
| 设置项 | 位置 | 建议值 | 收益说明 |
|---|---|---|---|
| PHP 版本 | Advanced > PHP Configuration | 8.2 或 8.3 | 从 7.4 升到 8.x，真实 WordPress 负载吞吐提升约 15%-25% |
| OPcache | Advanced > PHP Configuration | 开启 | 缓存编译后的 PHP 字节码，避免每次请求重新编译 |
| Brotli 压缩 | Advanced > PHP Configuration | 开启 | 文本类资源比 Gzip 再小 15%-25%，不支持的浏览器自动回退 Gzip |
| 对象缓存 LSMCD | WordPress > Overview | 开启 | 数据库查询结果入内存，动态页面收益最大，官方口径约 10% 响应提升 |
| Hostinger CDN | Website > Performance > CDN | Business 及以上套餐开启 | 距机房 1000km 以上访客 LCP 可改善 200-600ms |
升级 PHP 前，先在 WordPress 后台跑一遍 Site Health 检查，确认主题和插件兼容。主题只要是 2022 年后发布的，插件在正常维护的，基本都已兼容 PHP 8。切换在 hPanel 里大约 30 秒完成，出问题可以随时切回。OPcache 在生产环境没有实际副作用，唯一需要注意的是开发环境里改代码可能不会立即生效，部署后记得清缓存。
四、对象缓存 LSMCD：动态站点的提速大头
对象缓存是按站点开启的，不是全服务器统一开。在 hPanel 打开对应网站的 WordPress > Overview 面板，把 Object Cache 开关打开即可。前提是 LiteSpeed Cache 插件必须安装并处于启用状态——如果你换成了 WP Rocket 或 W3 Total Cache，LSMCD 守护进程无法和它们的钩子通信，对象缓存不会生效。
验证是否生效：回到 WordPress 后台 LiteSpeed Cache > Info，如果 Object Cache 一行显示绿色 Enabled 就说明成功了。如果 hPanel 开了但这里仍显示 Disabled，等五分钟后刷新，Hostinger 的守护进程配置更新会比界面提示慢几秒。
两个容易踩的坑：一是某些老的会员插件或论坛插件直接写数据库而不清对象缓存，可能显示过期数据，建议先在预发布环境开启并完整测试购物车流程；二是 LSCWP 必须保持启用状态，对象缓存依赖它的钩子工作。
五、CDN：按套餐分叉的加速手段
Hostinger CDN 从 Business Web Hosting 及以上套餐开始包含，Premium 套餐的开关是灰的。如果你在 Premium 套餐上想要 CDN，有两条免费路线：Cloudflare 免费版手动接入，或者 QUIC.cloud 免费版——后者是 LiteSpeed 团队做的，和 LSCWP 配合最顺。
QUIC.cloud 的免费额度每月前 20GB 流量，对大多数中小站点足够。它在 CDN 之外还提供 LSCWP 单独做不到的页面级优化：关键 CSS 生成、边缘 WebP 转换、按页生成 UCSS（Unique CSS）。接入方式是在 hPanel 的 DNS Zone Editor 里给域名加一条 CNAME 指向 QUIC.cloud，插件后台会给出具体值。
Cloudflare 适合已经在 Cloudflare 管理多个域名 DNS、需要 WAF、或者想在一个面板里同时代理邮件记录的场景。用 Cloudflare 前置 Hostinger 站点时要注意：如果开了 WooCommerce，Cloudflare 的缓存规则要设置 Bypass Cache on Cookie，否则登录用户会被命中缓存页，购物车显示错误数据。关于两种 CDN 的详细取舍，可以参考站内的 CDN 与 Cloudflare 对比文章。
六、图片优化：LCP 是命门
LSCWP 的图片优化走 QUIC.cloud 的队列，会自动转 WebP，但它是队列机制，新上传的图可能要等一小时左右才处理完。频繁更新的站点建议配合本地压缩插件（ShortPixel、Imagify 或 Smush）在传图时就压一遍，等 QUIC.cloud 缓存好 WebP 版本后再由 LSCWP 输出。
几个关键设置：懒加载由 LSCWP 自动处理，但 LCP 图片（通常是首屏大图或第一张产品图）绝不能懒加载，要在 LiteSpeed Cache > Page Optimization > Media 里把它加入 Exclude from Lazy Load 列表；通过 LSCWP 的关键 CSS 功能或主题头部加 <link rel="preload"> 预加载 LCP 图，图片多的页面 LCP 能再快 150-400ms；很多主题每张上传图会生成 6-10 个尺寸，大多数模板根本用不到，去设置 > 媒体把大图/中图宽度改成实际内容栏宽度，再用 Regenerate Thumbnails 插件重生成一次，能显著减小页面体积。
七、数据库清理：被忽略的慢性拖累
跑了两年以上的站点，文章修订、自动草稿、临时数据、垃圾评论轻松堆出 200MB 以上的冗余，拖慢每一次后台查询。推荐装 WP-Optimize，设置成每月自动清理一次，在设置里保留最近 5 条修订而不是全删，留一条回滚余地。一次性大清理也可以走 hPanel 的 Databases > phpMyAdmin，全选表执行 Optimize Table，能回收碎片化存储，尤其是 wp_options 和 wp_postmeta 这两张在活跃 WooCommerce 或 Elementor 站点上膨胀最快的表，整个过程不到一分钟，500MB 以下的库几乎无感。
八、WooCommerce 专项：动态页面的加速规则
WooCommerce 站点和纯内容站的加速逻辑完全不同：每个访客都有会话，购物车 Cookie 会触发缓存绕过，结账页根本无法缓存。LSCWP 检测到 WooCommerce 后会自动排除 /cart、/checkout、/my-account，但它是靠 woocommerce_items_in_cart Cookie 判断的，如果你的主题或插件做了自定义迷你购物车，需要去 LiteSpeed Cache > Cache > Excludes 手动把这些路径加进排除列表，否则会出现访客看到别人缓存账户页的严重问题。
会话数据默认存在数据库的 wp_woocommerce_sessions 表里，高流量店铺这张表会无限膨胀，超过 100MB 就明显拖慢后台查询。在 WooCommerce > Status > Tools 里清理客户会话，并在 hPanel 的 PHP Configuration 里把会话保存路径保持为文件系统（比数据库会话快）。产品图方面，woocommerce_thumbnail 大多数主题 300x300 就够，很多店铺默认 600x600，缩略图场景下文件大小直接翻倍却看不出差别，改完记得重生成缩略图。
另外两张 WooCommerce 专属表值得关注：wp_wc_order_stats 和 wp_wc_order_product_lookups 在订单超过一万的店铺容易索引碎片化，建议每月优化一次；wp_actionscheduler_actions 会被订阅插件和 WooCommerce Payments 疯狂写入，在 WooCommerce > Status > Scheduled Actions 里按 Complete 过滤，删除 30 天前的记录，有些店铺这张表有上百万行，清一次后台查询速度立竿见影。收款环节的完整配置可以参考站内的 WooCommerce 收款全流程文章。
九、持续追踪：测一次不算优化
GTmetrix 免费版支持一个定时监控 URL，每天自动测试并在分数跌破阈值时发邮件，建议把首页和最核心的产品页或落地页都纳入监控。Google Search Console 的 Core Web Vitals 报告每月更新一次真实 Chrome 用户的 field data，这才是 Google 真正用来排名的数据。实验室测试（GTmetrix、PageSpeed Insights）和真实用户数据要交叉对照：实验室看着很快但 Core Web Vitals 显示 Poor，通常是渲染阻塞资源在真实网络环境下才暴露。
按站点类型设目标：内容站/联盟站，移动端 LCP 控制在 2.5 秒内、TTFB 600ms 以内是 Business 套餐能达成的现实目标；WooCommerce 店铺，产品页和结账页的 TTFB 比首页更重要，结账页是真正无法缓存、决定下单转化的页面，要带着 WooCommerce Cookie 单独测，目标 1 秒以内。
十、什么时候该升级套餐
如果热缓存下 TTFB 仍然超过 1 秒，每个开关都试过了，瓶颈大概率是共享服务器上的 CPU 和 I/O 争抢。三条升级路径：流量稳定增长、跑 WooCommerce、月访问 5 万以内的站点，升到 Business Web Hosting，拿到 Hostinger CDN、更多 CPU 和对象缓存余量；峰值并发几百人的站点，上 Hostinger Cloud Hosting 拿独立资源；再往上就该考虑托管 WordPress 主机了。关于套餐价格与续费，可以看站内的 价格详解文章；国内访问速度问题可以先看自查清单。
如果你确认要长期用 Hostinger，购买 Hostinger 主机时使用优惠码 1RAY132 可享 20% 折扣，直接访问 Hostinger 官网 下单时输入即可，建议按 48 个月周期购买把单价压到最低。
常见问题
Hostinger 的 WordPress 托管自带 CDN 吗？
Business Web Hosting 及以上套餐自带 Hostinger CDN；Premium 套餐不含，可以免费接 Cloudflare 或 QUIC.cloud。
LiteSpeed Cache 够用吗，还要装 WP Rocket 吗？
在 Hostinger 上 LiteSpeed Cache 就够了，它能直接对接 LSWS 服务器缓存，这是 WP Rocket 做不到的。两个缓存插件同时开是最常见的翻车方式，二选一，Hostinger 上选 LiteSpeed Cache。
对象缓存对 WooCommerce 有效吗？
有效，但有限制。LSMCD 能加速购物车、结账、账户区这些不可缓存页面里反复执行的数据库查询，前提是 LiteSpeed Cache 是启用的缓存插件，换成 WP Rocket 后对象缓存就不可用了。
按上面十步走下来，绝大多数 Hostinger WordPress 站点能把 TTFB 压到 500ms 以内、LCP 压到 2.5 秒内。缓存架构的完整原理可以参考站内的 四层缓存架构文章，hPanel 后台操作不熟的话先看 hPanel 使用教程。加速这件事的秘诀就一条：每改两三个设置就重测一次，方便回滚，别攒一堆改动最后一起排查。
