大多数 WordPress 速度问题不是插件问题——而是配置问题
Source: Dev.to
许多 WordPress 站点感觉慢的真正原因
在我做的大多数审计中，问题很少出在 WordPress 本身。通常是以下因素的组合：
- 服务器配置错误
- 过多相互重叠的性能插件
- 重型页面构建器生成了不必要的标记
- 未优化的图片和字体
- 缺乏明确的资源加载策略
插件可以帮助——但前提是基础已经正确。
我的性能栈（刻意保持简洁）
我有意保持一切简约。
服务器优先：LiteSpeed Web Server
在动 WordPress 设置之前，我总是先检查服务器。
使用 LiteSpeed 时：
- 正确的 PHP 版本至关重要
- 必须启用 OPcache
- 压缩应在服务器层面完成
- TTFB（首字节时间）问题常常在这里消失
许多站点尝试用 WordPress 插件来修复服务器问题——这几乎从不奏效。
FlyingPress：强大，但前提是正确配置
FlyingPress 是少数几个尊重你原有设置而不是强行覆盖一切的性能插件之一。
我的关注点：
- 干净的缓存配置
- 谨慎处理 CSS 与 JS
- 仅延迟加载非关键脚本
- 避免可能破坏布局的激进选项
打开所有开关并不会让站点更快；理解每个选项的作用才是关键。
Flying Pages：速度不只是指标
Flying Pages 不仅提升分数——更提升站点的实际感受。
通过预加载用户可能点击的链接：
- 导航瞬间响应
- 页面看起来加载更快
- 在不增加臃肿的情况下提升用户体验
感知性能和实际加载时间同等重要。
图片：WebP、正确缩放、别走捷径
图片往往是隐藏在显眼位置的最大性能杀手。
我的基本规则：
- 使用 WebP 格式
- 上传尺寸合适的图片（不要上传过大的文件）
- 避免使用沉重的主视觉图片
- 始终定义宽高以防止布局位移
没有插件能修复准备不当的图片；这必须在上传时就做好。
为什么我避免使用页面构建器
大多数页面构建器会生成：
- 巨大的 DOM 树
- 额外的 CSS 与 JavaScript
- 布局位移问题
相反，我依赖：
- Gutenberg
- GenerateBlocks
这组合产出干净的 HTML、最小化的资源，并在不牺牲性能的前提下提供完整的布局控制。页面重量的差异立刻可见。
正确使用预制模板（Otter Blocks）
在首页，我使用了 Otter Blocks 的预制模板。预制模板本身不是问题——糟糕的实现才是。
我确保：
- 结构保持简洁
- 样式最小化
- 不加载不必要的脚本
谨慎使用时，它们能省时且不影响性能。
字体：要么本地，要么不使用
字体是另一个常见的性能陷阱。
我的做法：
- 优先使用系统字体
- 如需自定义字体 → 本地托管
- 只加载实际使用的字重
- 避免阻塞渲染的字体请求
仅此一步就能显著提升首次绘制和 CLS（累计布局偏移）。
Cloudflare：解决网络层面的难题
Cloudflare 能处理 WordPress 无法做到的事情：
- CDN 分发
- DNS 速度
- 全球延迟
配置得当时，它能与 LiteSpeed 顺畅协作，提供强大的性能层，而无需额外插件。再一次——配置比工具更重要。
为什么这种方法能长期奏效
该配置始终能够提供：
- 快速的真实世界加载时间
- 低布局位移
- 更新后性能稳定
- 不会每隔几个月就崩溃的站点
最关键的是，站点保持快速是因为它建立在坚实的基础之上。
这些数据高于我自己的作品集站点。很多人问我为何不展示自己站点的速度测试——于是我加入了实时速度测试。
最后思考
WordPress 性能不在于：
- ❌ 安装更多插件
- ❌ 追求完美的 Lighthouse 分数
- ❌ 每次感觉慢就换工具
而在于：
- ✅ 理解整个技术栈
- ✅ 做出干净的架构选择
- ✅ 正确配置已有的资源
一旦配置到位，插件就成了帮手——而不是临时止血的创可贴。
作者说明
我经常从事 WordPress 性能优化、基于块的干净构建以及服务器层面的调优。我的作品集中还有一些真实的工作流程和案例研究可供参考。