前端性能怎么衡量？LCP、INP、CLS 分别反映什么问题？

知识点详解：三个指标，分别对应用户的哪种等待

LCP：主要内容为什么迟迟没出来

假设文章页标题很快出现，但大图和正文区域过了好一会儿才完整呈现。LCP 关注符合条件的主要内容元素呈现时机，不是所有资源下载完的时间。

要沿着关键路径找原因：服务器响应慢，图片发现晚，图片本身很大，还是资源已到但被主线程和渲染工作拖住。

只压缩图片也不一定解决问题。如果主要等待在服务器或资源发现阶段，需要先处理那部分。首屏重要图片也不适合随手套懒加载，把本来就要立即看见的内容延后。

INP：点击以后，卡在哪一段

点击筛选按钮后，有三段可能拖延画面反馈：输入还没开始处理，事件回调执行很久，或者回调结束后仍等渲染呈现。

因此，INP 不是单纯的接口响应时间，也不是只看第一次点击。它观察访问过程中符合条件的交互，取能代表较慢交互的值，并按规则处理高交互量下的极端值。

假如主线程先跑一个长任务，按钮回调就会排队；假如回调同步计算大量数据，处理过程会变长；假如一次改变很多 DOM，后续呈现也可能拖延。

异步接口完整完成时间不是 INP 要覆盖的全部终点。先让用户看到加载反馈，再等待结果，与点下去完全没有反应，是不同的体验。

CLS：不是所有移动，都叫意外偏移

图片没预留尺寸，加载后把正文往下推；页面顶部突然插入横幅，按钮换了位置，这些都可能造成布局偏移。

给图片、广告或异步区域预留合理空间，比内容来了再把下面全部挤开更稳。字体切换也要注意尺寸差异。

CLS 有自己的计算和排除规则，不能把滚动距离或所有动画位移都算进去。用户输入之后短窗口内的某些预期变化，会与无提示的意外变化区别处理。

这是一项分数，不是毫秒。把 CLS 0.1 写成“100ms”，就把指标单位说错了。

先定位哪类用户差，再回到实验室复现

真实用户数据可以按页面、设备和交互拆开看。桌面均值很好，不代表低端手机的第 75 百分位也很好。

没有交互的单次加载跑分，无法替代真实 INP。实验室里的 TBT 可以帮助发现主线程阻塞，但不能直接把它改名成 INP。

找到问题路径后，再用性能时间线、资源瀑布和布局偏移来源复现。改完保持测试条件一致，并重新观察真实访问分布。

本题是浏览器体验指标，Python 可以处理收集后的统计数据，但不能代替浏览器产生这些原始事件。本文不伪造线上指标或优化比例。

本题机制参考：web.dev：Web Vitals、web.dev：INP、web.dev：CLS。

面试官继续追问

FID 为什么不在这里？

当前核心交互指标已是 INP。FID 只关注首次输入开始处理前的等待，不能完整反映整次访问的交互反馈。

Lighthouse 高分，就可以不用真实用户数据吗？

不可以。设备、网络和用户操作路径不同，实验室结果只覆盖所设定的场景。

INP 差一定要减少接口耗时吗？

先拆延迟。输入排队和同步处理过长时，接口优化可能不是主要解法。

面试速记卡

• 当前三项：LCP、INP、CLS。
• 良好目标：2.5 秒、200 毫秒、0.1，注意单位。
• 评估：真实访问第 75 百分位，移动与桌面分开。
• INP：输入等待、回调处理、呈现等待。
• 工具分工：真实数据判断分布，实验室复现原因。