按证据的先后顺序使用这份清单
这份 47 项检查清单是 WordPress 网站的实用审计表。它不承诺特定的加载时间或分数：托管、内容、访客设备和业务需求各不相同。请从出问题的用户体验入手，选择相关的检查项，并且每次只验证一类改动。
先处理经过测量确认的瓶颈，再考虑高级的服务器调优。一项改动如果省掉了一个小请求却让结账失效，那就是倒退，即使实验室分数有所提升。
建立基线
- 选择有代表性的首页、文章、归档、商品和结账 URL；同时包含已登录和匿名会话。
- 记录托管区域、设备、网络条件、浏览器和发布版本，以便之后的测试可以相互比较。
- 多次运行可重复的实验室测试，保留结果范围，而不只是最快的那一次。
- 在有实测数据时查看真实用户的 LCP、INP 和 CLS；区分 URL 级数据和源站级数据。
- 检查文档请求，分别拆出 DNS、连接和服务器响应的延迟。
- 在复现缓慢交互时记录主线程跟踪，而不只是在首次加载时记录。
- 找出实际的 LCP 元素，以及显示它所需的请求链。
- 保存一份可恢复的备份，并定义改动后仍必须正常工作的关键用户流程。
减少源站的工作量
- 使用受支持且与网站兼容的 PHP 版本；先在预发布环境中验证升级，再用于生产环境。
- 检查 OPcache 的状态和容量。除非部署流程会显式清除缓存，否则不要关闭时间戳校验。
- 在修改服务器设置之前，先分析缓慢的 PHP 路径和重复的数据库查询。
- 检查页面渲染过程中的远程 API 请求；使用合适的缓存和有上限的超时时间。
- 与托管服务商确认持久化对象缓存，并验证内容变更时的缓存失效。
- 只在安全的情况下缓存公开 HTML；绕过已认证、购物车、结账和个性化的响应。
- 确认两个不同的用户无法拿到彼此的缓存数据。
- 在提高并发之前，先在有代表性的负载下检查 CPU、内存和工作进程的饱和情况。
- 验证计划任务的执行情况。如果把 WP-Cron 迁移到系统调度器，要监控遗漏和失败的任务。
- 添加索引前先查看查询计划；评估写入开销，并在有代表性的数据副本上测试。
- 与所属插件一起检查体积过大的自动加载选项。在有针对性地清理之前先做备份。
- 对大型查询进行分页，避免把没有上限的集合加载到内存中。
改善渲染和交互
- 只有在检查过菜单、表单、结账和编辑器需求之后，才删除未使用的脚本和样式。
- 在保持依赖顺序的前提下延迟加载兼容的脚本；async 不能替代有序执行。
- 检查阻塞渲染的样式。任何关键 CSS 方案都要在所有模板和屏幕尺寸上测试。
- 让 LCP 图片在初始 HTML 中即可被发现，而不是之后再用 JavaScript 插入。
- 不要对 LCP 图片使用懒加载。有选择地使用高获取优先级，然后检查请求瀑布图。
- 把开销大的 JavaScript 拆分成经过测量的小块，并在适当时在块与块之间把控制权交还给浏览器。
- 批量处理布局的读取和写入，避免反复触发强制重排。
- 移除不必要的第三方小部件；只有在其行为和同意规则允许时，才延迟加载可选的部件。
- 在资源到达之前，为图片、嵌入内容和广告预留尺寸。
- 检查备用字体的度量和布局偏移；有意识地使用 font-display。
- 确保交互控件在键盘导航和减少动态效果的设置下依然可用。
- 测试长页面和低性能设备；首页快并不代表每个模板都快。
提供尺寸合适的资源
- 根据图片的显示位置和预期像素密度来选择宽度。
- 用实际文件比较 AVIF、WebP 和现有格式，而不是假设固定的节省比例。
- 提供响应式的 srcset 候选项，以及反映布局的 sizes 值。
- 对屏幕外的图片使用懒加载，并在适当时使用异步解码。
- 把重要的标签和说明保留为 HTML；图片中的小字很难阅读。
- 自行托管字体或以其他方式减少字体请求；只加载网站需要的字重和字符集。
- 在核实请求瀑布图之后，只预加载真正关键的资源。
- 检查文本资源是否通过 gzip 或 Brotli 传输，并避免对已压缩的图片再次压缩。
- 为带版本号的静态资源设置长期缓存，并在内容变化时更改其 URL。
- 有意识地加载视频。仅用 CSS 隐藏视频，并不能保证停止下载。
验证发布
- 启用任何优化后，都要测试登录、搜索、联系表单、购物车和结账。
- 在已编辑的页面上检查缓存响应头和内容失效。
- 在相同条件下重复基线实验室测试，并同时记录改进和倒退。
- 持续跟踪实测指标；滚动的数据窗口不会立即反映一次发布。
- 设定性能预算并保留变更日志，以便把之后出现的性能倒退追溯到具体的发布。
常见问题
应该先修复什么？
如果初始文档很慢，就分析源站和缓存行为。如果文档很快送达但主要内容出现得晚，就检查 LCP 资源和渲染路径。如果加载完成后点击仍感觉迟钝，就调查交互过程中的 JavaScript 和布局工作。在审计记录中把这些区别写清楚。
Lighthouse 分数低会触发固定的排名惩罚吗？
没有任何公开规则规定，Lighthouse 分数低于某个数值就会在 Google 中受到固定的排名惩罚。用分数来寻找技术上的改进机会，用实测数据来了解真实访客。
每个 WordPress 网站都需要执行全部 47 项检查吗？
不需要。用这份清单找出相关的排查项，然后优先处理影响重要用户路径的瓶颈。企业展示网站和访问量很大的 WooCommerce 商店，需求并不相同。请记录每项检查为何适用、推迟或不需要。
修改缓存或脚本设置后应该测试什么？
检查菜单、搜索、表单、登录，以及适用时的结账流程。用不同的会话测试，编辑并取消发布内容以检查缓存失效，并与最初的基线比较性能。准备好回滚方案，以防某项优化破坏了必要的交互。
参考资料与延伸阅读
继续阅读
深入了解 TTFB 与 Core Web Vitals 诊断以及响应式图片交付。
Leave a Reply