Marico's space
客户第一次找你，说网站慢，十有八九会甩过来一张 Lighthouse 截图。Performance 面板截图，评分卡在红区或者黄区，然后问你："能修吗？"
老实说：这取决于你说的"修"是什么意思。
Lighthouse 跑的是 Google 服务器上 headless Chrome 的模拟环境，在限速移动网络下测一个虚拟场景。是个挺好用的诊断工具。但它也是一个可以被玩出花的数字，跟真实用户的体验可能毛关系都没有。
这篇文章聊的是 Lighthouse 报告的数据和真实用户体验之间的鸿沟，以及当你真的要给一个线上 WordPress 站点做性能优化时，应该把精力放在哪里。
Lighthouse 报告六个指标，但真正直接影响用户体验和 Google 排名的只有三个：LCP（最大内容绘制）、INP（与下一绘制的交互，2024 年取代了 FID）和 CLS（累计布局偏移）。
LCP 测量最大可见元素（通常是首图或者大标题）完全渲染所需的时间。Google 认为 2.5 秒以内是良好区间。对大多数 WordPress 站点来说，LCP 主要被特色图片或者 hero 区域背景图主导，基本是优化时要搞定的第一件事。
INP 测量响应性：用户与页面交互后，页面需要多久才能响应。这是 JavaScript 密集型 WordPress 站点的重灾区。每个往前端加 JS 的插件都可能成为 INP 杀手。
CLS 测量视觉稳定性：页面加载时元素会不会跳来跳去。WordPress 里常见的坑是没有显式尺寸的图片、加载时导致布局偏移的网络字体，还有广告或嵌入内容把正文挤下去。
把精力集中在这三个上，忽略其他的，已经完成了 80% 有意义的优化工作。
WordPress 站点最常见的 LCP 问题，是 hero 图片没有被当作优先资源处理。WordPress 默认会对图片启用懒加载，意味着浏览器会延迟加载，直到图片接近视口。对于首屏已经可见的图片——比如 hero 图——懒加载反而会拖 LCP 后腿。
直接在主题或页面构建器输出的 hero 图片标签上加 loading="eager" 和 fetchpriority="high"。这告诉浏览器把它当作高优先级资源，立刻开始加载。
<img src="hero-800.webp" srcset="hero-400.webp 400w, hero-800.webp 800w, hero-1200.webp 1200w" sizes="100vw" width="1200" height="600" fetchpriority="high" loading="eager" alt="Your descriptive alt text here"
>
注意显式的 width 和 height 属性。这能在图片加载前就为布局预留正确的空间，防止 CLS。
第二个 LCP 杀手是图片格式和大小。在移动网络下，一张 2MB 的 JPEG hero 图，无论你做多少其他优化，LCP 都不会好看。WebP 格式加上合适尺寸和正确的 srcset 实现，不是可选项，是基准线。
如果你需要在 WordPress 里用代码移除特定图片的懒加载：
add_filter( 'wp_lazy_loading_enabled', function( $default, $tag_name, $context ) { if ( $tag_name === 'img' && $context === 'the_content' ) { return false; } return $default;
}, 10, 3 );
线上环境要精细化处理。全局禁用懒加载会伤害视口下方图片的性能。
大多数 WordPress 性能讨论只关注页面加载速度，忽略了交互响应能力。INP 把响应性变成了影响排名的 Core Web Vital，这才让业界开始重视这个问题。
WordPress 站点 INP 差的根本原因几乎永远是主线程上的 JavaScript 执行。每个在前端加载 JS 的插件都在抢同一个线程。当用户点击了某个东西，而浏览器正在忙着用插件脚本，那响应就会延迟。
诊断方法很简单：打开 Chrome DevTools，进 Performance，记录一次交互（比如点击或者表单输入），找那些阻塞主线程的长任务。罪魁祸首的脚本基本一眼就能认出来。
如果这个脚本不是首屏渲染或者首屏交互必需的，就给它加 defer：
<script src="plugin-script.js" defer></script>
如果是等用户交互后才需要加载的（比如统计、客服组件、非关键功能），就在用户触发时再加载：
document.addEventListener('click', function loadScript() { const script = document.createElement('script'); script.src = 'heavy-widget.js'; document.head.appendChild(script); document.removeEventListener('click', loadScript);
}, { once: true });
针对 WordPress 的具体情况：审计每个激活的插件，问自己它是否真的需要在每个页面都加载 JS。很多插件全局加载脚本，但实际上只在特定页面或者文章类型下才有用。通过 wp_enqueue_scripts 配合正确的条件标签做条件加载，能砍掉大量不必要的 JS。
add_action( 'wp_enqueue_scripts', function() { if ( is_singular( 'post' ) ) { wp_enqueue_script( 'my-plugin-script', get_template_directory_uri() . '/js/plugin.js', array(), '1.0', true ); }
});
由网络字体引起的累计布局偏移是 WordPress 主题里最常见、也最容易被忽视的问题之一。浏览器加载页面，先用系统默认字体渲染文字，字体文件加载完成后再切换到网络字体，这个过程中布局会发生可见的偏移。
现代解决方案是 CSS 属性 font-display: swap 配合预加载关键字体：
<link rel="preload" href="/fonts/primary-font.woff2" as="font" type="font/woff2" crossorigin>
@font-face { font-family: 'PrimaryFont'; src: url('/fonts/primary-font.woff2') format('woff2'); font-display: swap;
}
font-display: swap 告诉浏览器先用回退字体立即显示文字，等网络字体就绪后再替换。配合预加载，替换过程快到大多数用户根本感知不到。
如果你用的是 Google Fonts，自托管能省掉一次 DNS 查询，还能自己控制缓存策略。对于 LCP 和 CLS 来说，两项都是实打实的优化，在有一定规模的站点上效果会叠加。
没有proper服务端缓存的 WordPress 站点，每一次请求都在做重复劳动。PHP 执行、数据库查询、HTML 拼装，每个访客、每次访问都来一遍。在共享主机上，这给每个页面加载增加了可观的延迟。
对象缓存（Redis 或 Memcached）能省掉重复请求的数据库查询开销。页面缓存直接返回预构建的 HTML 文件，完全绕过 PHP。CDN（内容分发网络）缓存从离访客最近的边缘节点提供静态资源。
优化优先级顺序：页面缓存优先，对象缓存其次，CDN 最后。每一层都在前一层的基础上叠加效果。
对于大多数配置了服务端缓存的托管 WordPress 主机，插件级别的缓存层就不那么关键了。先搞清楚你的托管环境提供了什么，再决定要不要用额外的插件给自己加复杂度。
Lighthouse 得分 95 说明不了什么，如果 Google Search Console 里的真实用户数据显示 LCP 平均 4 秒。实验室得分只测量一次模拟加载。真实用户访问时连接可能是热的、资源已经被缓存、设备和网络条件各式各样。
Search Console 里的 CrUX（Chrome 用户体验报告）数据反映的是过去 28 天的真实用户体验。这是 Google 用于排名的数据。也是你应该优化的方向。
WordPress 性能审计的标准流程：
28 天的周期是 Core Web Vitals 优化的现实困境。你今天做的改动，要一个月后才能在 Search Console 数据里看到反馈。把优化工作流建立在这个时间线上，而不是围着 Lighthouse 截图转。