页面为什么慢？先看清，再优化

“页面很慢”可能是首屏迟迟不出现，也可能是点击按钮后没有反应。先把感受翻译成具体场景，优化才能有方向。

区分三种体验

• **加载：**主要内容多久可见？LCP 关注视口内最大内容元素的呈现时间。
• **响应：**用户点击或输入后，多久得到下一次视觉反馈？INP 衡量交互延迟。
• **稳定：**阅读时内容会不会突然跳动？CLS 统计意外布局偏移。

常用的良好体验阈值是 LCP 不超过 2.5 秒、INP 不超过 200 毫秒、CLS 不超过 0.1。实际用户数据通常按第 75 百分位评估；本机一次测量不能代表所有访问者。

先留下基线

打开 DevTools，记录测试页面、设备、网络条件和缓存状态。使用 Performance 录制一次具体操作，在 Network 中观察关键资源的请求顺序和大小。

Lighthouse 的实验室报告适合找线索，但不能替代真实用户的交互数据。不要为了一个分数，牺牲页面实际需要的功能。

图片和脚本分别处理

首屏重要图片应尽早被浏览器发现，不要无差别懒加载；下方图片可以延迟加载。为图片提供宽高，有助于预留正确的空间。

<!-- 示例路径；使用时替换为你自己的真实图片。 -->
<img
  src="/images/article-cover.webp"
  width="960"
  height="640"
  alt="展示两列网页布局的示意图"
  loading="lazy"
/>

脚本方面，先查哪些 JavaScript 在首屏实际执行。一个只用于文章底部的小组件，通常不值得拖慢整个首页。耗时的事件处理函数则需要缩小工作量，必要时拆分任务。

一次改动，一个假设

写下预期：例如“缩小首屏图片会降低传输时间”。修改后在相同条件下重复测量，比较多个样本。没有改善就重新检查假设，而不是继续堆叠优化。

性能优化的产物不只是更快的页面，还应当是一条别人可以复现的证据链。