本文约 3,710 字，预计阅读 10 分钟。文中命令与配置均经过实测，可直接参考执行。
引言：又一款”一键全开就能提速”的插件，但全开还是会出事
FlyingPress 是 Gijo Varghese（WP Speed Matters）开发的付费加速插件，把缓存、CSS 优化、JS 延迟、关键 CSS 生成、字体优化、图片懒加载、CDN 集成打包在一起。它的界面比 WP Rocket 更简洁，选项也更少，主打”默认配置就够好”。
但”选项少”不等于”没有坑”。实测下来，最容易出问题的仍然是两项：Delay JavaScript（延迟执行 JS） 和 Remove Unused CSS / Critical CSS。前者会让统计代码、客服窗口、评论框在用户交互前不工作；后者可能把交互后才出现的样式当成无用 CSS 删掉。本文按板块讲清每项设置，并给出一套可复用的实测方法。
原理分析：FlyingPress 提速靠哪几件事
FlyingPress 的提速手段可以分成三层：
第一层：缓存。 生成静态 HTML，通过 .htaccess（Apache）或 Nginx 规则直接返回，跳过 PHP。这是收益最大的一层，风险最低。
第二层：渲染路径优化。 包括：
- Load CSS Files Asynchronously（异步加载 CSS）：把
<link rel="stylesheet">改成异步加载，避免阻塞渲染； - Generate Critical CSS（生成关键 CSS）：自动提取首屏所需样式内联进
<head>，其余 CSS 异步加载。这一项解决的是”异步加载 CSS 会造成的样式闪动（FOUC）”； - Remove Unused CSS（移除未使用 CSS）：在关键 CSS 基础上进一步裁剪，风险更高。
第三层：脚本与资源延后。
- Defer JavaScript：给脚本加
defer； - Delay JavaScript：更强的手段——把第三方脚本的执行推迟到”用户产生交互（滚动、点击、触摸）或超时”之后。对统计、广告、客服这类非首屏必需脚本收益极大；
- Lazy Render Elements：延迟渲染页面下方的元素。
风险排序大致是：缓存 < 图片懒加载 < JS defer < 关键 CSS < 延迟 JS < 移除未使用 CSS。配置时应按风险从低到高逐项开启并验证。
保姆级实操
第一步：建立可对比的实测基线
在改任何设置之前先记录数据，否则”提速”只是主观感受：
#!/usr/bin/env bash
# 记录 5 次 TTFB 与首屏 HTML 体积
URL="https://mimangfei.com/"
for i in 1 2 3 4 5; do
curl -o /dev/null -s -w "TTFB=%{time_starttransfer}s 总量=%{size_download}B\n" "$URL"
done
SIZE=$(curl -s "$URL" | wc -c)
CSS=$(curl -s "$URL" | grep -c 'rel="stylesheet"')
echo "HTML字节=${SIZE} 外链CSS数=${CSS}"
把这个脚本存成 bench.sh，每改一项设置跑一次，用数据判断收益。
第二步：缓存与基础项
进入 FlyingPress → 配置，优先只开这些：
- Cache Pages：开；
- Cache Bypass Query Strings / Cookies：按站点情况配置；
- Purge Cache on Content Update：开；
- Preload Cache：开（小站）；
- Lazy Load Images / Iframes：开；
- Defer JavaScript：开；
- Preload Critical Images：开。
第三步：CSS 配置（最需要验证的部分）
- Load CSS Files Asynchronously：开；
- Generate Critical CSS：开，保存后点 Regenerate Critical CSS 并等待生成完成；
- Remove Unused CSS：先关，跑一周没问题再考虑开启。
生成完成后前台验证有没有样式闪动：
# 看首屏是否内联了关键 CSS
curl -s https://mimangfei.com/ | head -c 4000 | grep -o '<style[^>]*>' | head -5
# 对照异步加载方式是否生效
curl -s https://mimangfei.com/ | grep -oE '<link[^>]*rel="(preload|stylesheet)"[^>]*>' | head -5
第四步：延迟执行 JS 与排除清单
- Delay JavaScript：开；
- Keyword Exclusions：填写不能被延迟的脚本关键词，例如
gtag、googletagmanager、wpcf7、wp-emoji； - Include Inline Scripts：默认关闭更安全。
第五步：手工补充关键 CSS 的兜底方案
如果自动生成的关键 CSS 不完整，可以在子主题里手工内联一段兜底样式，用高优先级插入 <head>：
<?php
add_action( 'wp_head', function () {
?>
<style id="mimangfei-critical-fallback">
.site-header{display:flex;align-items:center;justify-content:space-between}
.hero{min-height:60vh;background:#f5f5f5}
.site-footer{margin-top:40px;padding:24px 0;border-top:1px solid #e5e5e5}
</style>
<?php
}, 1 );
第六步：CDN 与字体
- 若用 Bunny.net / Cloudflare，在 FlyingPress → CDN 里填 CDN URL 和需要改写的文件类型；
- Fonts 板块里勾选 Preload Fonts 与 Self-host Google Fonts（把 Google 字体本地化，国内访问友好）。
第七步：清缓存并复测
wp cache flush
bash bench.sh
常见踩坑
- 开了延迟 JS 后统计代码不上报。必须把
gtag、gtm加进排除关键词，否则用户一跳出就没有数据。 - 关键 CSS 生成不完整导致 FOUC。首屏出现无样式的白屏闪一下，需要手工补关键样式或关掉异步加载 CSS。
- Remove Unused CSS 删掉了弹窗/滑块样式。这些样式只有交互后才用到，自动分析会误判。
- 案例：一个电商站开启了 Delay JavaScript 之后，商品页的”加入购物车”按钮在移动端点了没反应。排查发现加购依赖的 Ajax 脚本被延后，而按钮的点击监听在页面加载时就绑定了——脚本还没下载，监听自然绑不上。修复是把
/wp-content/plugins/woocommerce/相关脚本关键词加入排除清单，并只对第三方统计和广告保留延迟。 - Nginx 环境没配缓存规则。FlyingPress 在 Apache 下自动写
.htaccess，Nginx 需要手动添加规则，否则缓存不生效。 - CDN 配置了但没清 CDN 缓存。前台还是旧资源。
- 和别的缓存插件同时启用。FlyingPress 本身就是完整缓存方案，不要和 WP Rocket、LiteSpeed Cache 并存。
总结
FlyingPress 的配置原则是”按风险从低到高逐项开启，每开一项用 bench.sh 复测一次“。必开且安全的：页面缓存、图片懒加载、JS defer、字体本地化。需要验证的：关键 CSS（检查是否出现 FOUC）。高风险的：移除未使用 CSS、延迟执行 JS（必须配排除清单）。判断插件是否配好的最终标准不是跑分数字，而是真实用户能用的功能一个都没坏——统计在跑、表单能提交、客服能弹出、购物车能加。
如果你只想延迟第三方脚本而不需要整套缓存，可以看 Flying Scripts 延迟加载第三方脚本；选型阶段也可对比 WP Rocket 与 LiteSpeed Cache 怎么选。
