WordPress 压缩 CSS 和 JS，可以先让一个工具负责处理，从单独的 Minify 开始：先改 CSS，检查布局；再改 JS，检查第一次点击和表单等交互。文件合并、defer、延迟到交互后加载，以及移除未使用 CSS，都应该当成另外的改动验证。
这些选项常挤在同一个“优化”面板里，却改变不同的东西。代码更小，不代表执行工作变少；脚本更晚执行，也不代表它在用户第一次点击时已经准备好。设置前先明确要解决哪一种问题，后面才能判断效果和恢复故障。
先区分文件变小、请求变少和执行变晚
| 选项 | 主要改变什么 | 需要验证什么 |
|---|---|---|
| Minify | 精简不必要的代码表示，如空白和部分注释 | 文件能用，样式与功能保持正确 |
| Gzip / Brotli | 内容在网络上传输时的编码 | 响应编码与实际传输量 |
| Combine / Aggregate | 将多个资源合并 | 请求、依赖与缓存复用是否合适 |
| Defer | 相应脚本的执行安排 | 解析后初始化与依赖顺序 |
| Delay JS | 按插件规则推迟加载或执行，可能等到交互 | 首次操作、必要功能和事件是否正常 |
| Critical CSS / 移除未用 CSS | 提前提供关键样式，或改变保留的样式范围 | 首屏与后续交互状态都没有缺样式 |
Minify 与传输压缩可以同时存在。响应头 Content-Encoding: br 表示使用了 Brotli 编码，不能据此确定文件是否已精简；浏览器会按编码解码后使用内容，参见 MDN Content-Encoding。
对经典外部脚本，defer 允许下载与 HTML 解析并行，并在解析完成后按相应文档顺序执行；async 不保证同样顺序。内联脚本、模块脚本和插件自己的延迟机制有不同规则，不能统一套这句话。具体语义见 MDN script 元素说明。
举个常见依赖情境：页面中的初始化代码需要某个库先存在。如果库被延迟到交互后，但初始化代码仍立即执行，页面可能报错或没有完成绑定。文件即使全部成功下载，也不代表执行顺序正确。这就是为什么“精简 JS”和“延迟 JS”要分开判断。
例如，下面两种写法表达同一个局部样式。Minify 可以去掉不必要的空白，不会因此让页面少一个边框或少执行一项业务功能：
/* 精简前 */
.young-child-note {
border-left: 4px solid #2563eb;
padding-left: 1rem;
}
/* 精简后 */
.young-child-note{border-left:4px solid #2563eb;padding-left:1rem}
这是语义对照，不是测速结果；这段小规则也不值得单独承诺页面会快多少。
保存修改前的资源与功能基线
选一张代表页面，最好包含本站实际使用的菜单、图片和表单。在未登录前台打开开发者工具，分别查看 CSS、JS 请求，记录主要 URL、传输量、状态码与缓存状态，也留意 Console 中已经存在的错误。
文件名里的 .min.js 或 .min.css 通常是精简版本的线索，不是最终证据。查看实际内容和处理来源。主题已经提供精简资源，再让插件生成一份，不一定能获得值得维护的收益。
检查主机加速、缓存插件、独立资源优化插件和 CDN 是否在做同类处理。可以由不同工具承担页面缓存和图片等职责，但同一份 CSS/JS 最好有清楚的处理负责人。插件分工不明时，先按常用插件选择原则整理现有功能。
同时记录几个具体动作：未交互时首屏正常吗，第一次点击菜单会展开吗，表单报错能修正吗，手机弹窗能关闭吗。修改前已经有的问题要单独记下，避免改动后把全部异常都归到 Minify。
复杂或承担交易的站点，先在与线上条件接近的测试环境验证。测试环境通过后，仍要看线上匿名访问，因为正式站可能多出页面缓存、CDN 和同意管理状态。
用一个工具，先单独启用 Minify
LiteSpeed Cache 的测试顺序
在 Page Optimization 的 CSS Settings 中单独打开 CSS Minify，暂不启用 CSS Combine、异步 CSS 等其他处理。保存并按工具流程更新资源，再检查首屏、手机布局、菜单展开与表单错误状态。
CSS 通过后，再在 JS Settings 中测试 JS Minify，保持 JS Combine 与 Load JS Deferred 关闭。这样得到的是精简本身的结果，而不是一组无法区分的组合变化。名称和依赖以当前版本及 LiteSpeed 页面优化说明为准。
后面要尝试关键 CSS 或移除未用 CSS 时，另做一轮验证。首屏正常不够：弹窗、二级菜单、表单报错、产品切换可能在之后才出现新的样式需求。
Autoptimize 的测试顺序
在“设置 → Autoptimize → JS, CSS & HTML”中先测试 CSS 优化，取消合并及额外加载调整；通过后再测试 JS。取消 Aggregate JS-files 还不够，要同时确认非合并脚本的 defer 等设置，避免把加载时机也一起改了。
Autoptimize 支持精简而不合并，新安装也不再默认合并 CSS/JS；HTTP/2 并不意味着不需要优化，也不意味着合并总有收益。相关设置见 Autoptimize 官方说明。
每一轮保存后，都要让页面 HTML 与生成资源保持一致，再用新的访客请求检查。不要只刷新后台编辑器。如果工具把多种操作绑定在一个选项中，就记录为组合改动，不能把全部收益或故障都算给 Minify。
合并、defer 和 delay 应该在什么情况下继续测试
Minify 后资源正常，但请求组织或初始化仍明显拖慢页面，才继续判断下一项。不是所有网站都要走到“所有优化开关开启”这一步。
合并文件可能减少某些请求成本，但也会把原本独立复用的文件绑在一起。某页面只用到少量样式，却下载一个跨页面大合集，未必合适；某个小文件更新，也可能改变整包缓存。HTTP/2 降低了同连接多个请求的一部分成本，因此用实际加载与缓存行为决定，不把“请求越少越好”当成唯一指标。
defer适用于相应脚本可以推迟到文档解析后执行的场景，但仍要保留依赖关系。执行时脚本仍会占用主线程，它没有把计算工作消除。
delay更需要按用途检查。用户点菜单的动作如果只是触发脚本下载，而菜单尚未绑定事件，第一次操作可能没有得到预期结果。不同插件会尝试处理触发与回放，本站必须实际验证，不能根据选项描述就假定首击一定可用。
分析、同意管理、表单防护和其他业务脚本也要遵循原有规则。延迟可以改变它们看到的时机和事件，不应为了让初始测试少加载资源而失去必要功能，或改变已有的用户同意行为。
验收要覆盖刚打开、第一次操作和缓存后的访问
先看页面没有发生任何交互时：标题、字体、图标和首屏布局是否正确，必要正文是否已经出现。随后按本站实际功能操作，而不是只滚动几下。
- 第一次打开和关闭菜单，再展开二级菜单，检查触摸与键盘路径。
- 打开折叠内容和弹窗，确认样式、焦点与关闭功能。
- 让表单出现一次错误，再正确提交，核对前台与后台结果。
- 若存在商品选项、加购、语言或货币切换，检查变化后的内容和金额。
- 在相关同意状态下检查依赖脚本行为，确认事件没有因延迟而漏掉或重复触发。
回到 Network 检查资源有无加载失败，Console 是否出现新的异常，再对比相同条件的传输量与性能。不要因为 Console 安静就跳过实际任务；许多错误不会表现为明显的 JavaScript 报错。
也要测试已经建立页面缓存后的访问。刚清空一切时正常，过一段时间才丢样式，可能是 HTML 与生成资源版本不同步。桌面和手机、匿名和必要的登录场景，应覆盖真实使用范围。
保留设置的条件很清楚：目标问题确实改善，并且相关功能没有回归。若收益很小，却增加了持续维护的排除规则，可以保留较简单的组合，不必让每个功能都处于开启状态。
不确定“相关功能没有回归”怎样判断时，用一次真实访客任务检查：从找到产品到完成询价走一遍，特别保留第一次点击与报错后的结果。
出错后，按变更和资源逐步缩小范围
首先只退回最近启用的选项，更新相关缓存，再重复同一个失败动作。如果恢复，说明这项处理值得继续排查；如果没有恢复，先确认前台是否仍在读取旧 HTML 或旧优化文件，别立刻添加越来越长的排除列表。
样式错乱或交互失败：查原始资源与依赖
分开 CSS 与 JS 后，找到对应原始文件的实际 URL，再按工具提供的排除方式缩小范围。不要只凭文件名像某插件，就排除整个目录的所有代码。
排除也有作用范围。排除合并不一定排除延迟，排除优化有时仍允许精简；Autoptimize 的官方 FAQ 就说明，被排除的文件仍可能受“minify excluded files”影响。需要停止 Minify 时，要确认这一行为也被关闭。
如果初始化脚本依赖另一个库，处理它们的时机要一起检查。只排除其中一个，有可能留下原来的顺序问题。LiteSpeed 的CSS/JS 故障排查提供了从功能与资源逐步定位的方法。
优化资源 404：查旧 HTML 是否还引用已删文件
一种典型情况是插件生成的 CSS/JS 被清理，但页面缓存仍保存引用这些文件的 HTML。浏览器取得旧页面后自然请求不到资源。应恢复可用文件或同步刷新相关页面缓存，并重新生成验证；随手增加“每天删除整个优化目录”的任务可能让它反复发生。
处理时还要分清缺失对象。真正执行的 .js 或 .css 返回 404，需要修复；开发者工具提示缺少 .js.map 源映射文件，通常影响的是调试映射，本身不代表业务脚本没有加载。先看页面功能和实际执行文件，别把所有红色提示都当成同一级故障。
临时恢复业务时可以停用对应优化，保留已验证正常的部分。如果问题已超出资源处理，继续按WordPress 插件冲突排查检查，不要连续装几个替代插件后再猜原因。
文件仍很重时，再判断页面到底需要哪些代码
Minify 精简表示，不会自动删除页面不需要的功能。一个全站加载的轮播库，即使只在首页使用，也可能出现在文章页；是否能按页加载，要看主题和插件怎样声明依赖，而不是按文件大小直接删除。
Chrome 的 Coverage 工具可以帮助观察记录期间使用了哪些 CSS/JS。但“本次未使用”不等于“永远可以删除”。先打开菜单、触发表单报错、切换产品选项，并检查相关设备布局，再判断哪些部分确实不属于这个页面。登录状态、其他页面或稍后交互，也可能需要它们。
开发层面的按需加载或代码拆分，可以降低初始负担，原理参见 web.dev 代码拆分说明。普通站主更适合先使用主题、插件已支持的页面级开关；需要修改加载代码时，由熟悉依赖的人处理并完整复测。
若要修改自己子主题的加载代码，先按子主题CSS加载示例查实际文件和依赖来源。父主题的样式与子样式承担不同职责，不要为了减少一个请求删掉必需资源。
如果主要等待发生在 HTML 响应或首图下载，继续折腾很小的 CSS 文件可能不是优先事项。回到速度优化诊断看当前瓶颈，把改动与具体问题对应起来。
常见问题
文件已经有 min 后缀，还需要再精简吗？
先检查实际内容和请求来源。后缀只是线索；即使还能减少一些字节，也要比较收益和兼容成本。已经精简且稳定的资源，不必为了开启更多选项而重复处理。
HTTP/2 网站还应该合并 CSS 和 JS 吗？
不能默认决定。HTTP/2 降低了同连接多请求的一部分成本，合并又会影响缓存复用和页面下载范围。将合并作为独立测试，用真实请求、加载和功能结果决定是否保留。
defer 是否能让所有 JavaScript 都不再卡顿？
不能。它改变相应脚本的执行安排，执行时仍会消耗主线程资源。脚本类型、依赖和内联初始化也需要分别处理。若问题是工作量太大，还要考虑按需加载或减少不必要功能。
加入排除列表后还是出错，说明定位错了吗？
不一定。先确认排除针对的是 Minify、合并还是延迟，依赖资源是否也被正确处理，以及前台是否仍读取旧缓存。把资源与处理范围核对清楚，再决定是否扩大排查。