前端工程化（八）：性能指标与加载优化

三个核心体验指标

LCP（Largest Contentful Paint）衡量视口内主要内容何时完成渲染，主要反映加载体验。排查 LCP 时，不能只盯着 JavaScript 体积，还要先确认实际的 LCP 元素，再检查服务器响应、首屏数据请求、CSS 或字体阻塞、图片优先级、主线程任务和最终绘制时刻。

INP（Interaction to Next Paint）衡量用户交互之后，页面完成下一次可见更新所经历的延迟，主要反映交互响应性。一次点击响应慢，可能是点击前主线程已有长任务导致输入排队，也可能是事件处理函数中的同步计算、状态更新或后续布局绘制耗时。

CLS（Cumulative Layout Shift）衡量页面生命周期内非预期的布局位移，主要反映视觉稳定性。图片或视频没有预留尺寸、异步内容把已有内容推开、字体切换导致重新排版，以及在已展示内容上方插入元素，都可能造成 CLS。设置宽高或 aspect-ratio、为异步区域预留空间和避免顶部动态插入，是常见治理方式。

如何分层排查首屏慢

第一步是固定测量条件：页面 URL、代码版本、浏览器、视口、设备、网络、登录状态和缓存策略都要记录清楚。冷缓存和热缓存需要分开测量，并且每种条件最好运行多次，比较中位数或 p75，而不是只看一次最好的结果。

第二步看 Network 面板。记录 TTFB、请求数量、Transferred、资源大小、状态码、缓存命中情况和请求瀑布，区分问题来自服务器、网络、资源体积还是串行依赖。缓存命中可以减少重复传输，但 304 仍然发生了重新验证；压缩可以减少传输字节，却不能解决 TTFB、脚本执行或主线程阻塞。

第三步看 Performance 面板。确认 LCP 元素之前发生了什么，观察脚本执行、样式计算、布局、绘制和主线程长任务。Long Task 需要在 Main 轨道确认单个连续任务是否超过 50 ms，不能仅凭 Bottom-up 或 Call tree 中某个聚合时间超过 50 ms 就下结论。

第四步才是改动。preload 只适合当前页面很快就会使用的关键资源，prefetch 面向未来可能访问的资源，懒加载只适合非首屏资源。把首屏主图或 LCP 元素懒加载，可能让浏览器更晚发现资源，反而推迟 LCP。

缓存、压缩和加载策略的边界

缓存解决的是重复传输问题，压缩解决的是传输字节数问题，懒加载解决的是资源加载时机问题。它们分别作用于不同环节，不能互相替代。

例如，资源已经命中缓存时，继续压缩并不会减少本次传输；请求已经被长任务阻塞时，继续拆分资源也不一定改善交互；首屏内容本来就很小的时候，盲目增加预加载反而可能抢占其他关键请求。因此每个优化动作都应该对应一个已观察到的瓶颈。

shine4j.top 首页实测

我在 Chrome 153.0.8010.53、当前电脑和当前网络下访问 https://shine4j.top/。

严格冷缓存的一次记录为：42 个请求、8.4 MB transferred、9.1 MB resources、DOMContentLoaded 351 ms、Load 717 ms、Finish 897 ms，LCP 0.48 s，CLS 0。实际 LCP 元素是首页的标题：BUILDING REAL SYSTEMS.。

之后使用无痕窗口、未勾选 Disable cache 重新测量，得到 36 个请求、33.1 kB transferred、930 kB resources、DOMContentLoaded 79 ms、Load 120 ms、Finish 279 ms，LCP 0.10 s、INP 31 ms、CLS 0。这个结果应标记为“无痕窗口首次访问基线”，不能直接等同于 DevTools 的严格冷缓存，也不能和前一次数据简单做优劣比较，因为缓存、扩展和请求状态可能不同。

Performance 的 summary 视图显示 shine4j.top 约 37.1 kB，之前 Network 中约 4,145 kB 的 content_main.js 及其 content_guard.js 触发来源更像浏览器扩展注入脚本，不能直接归因于网站。后续分析第三方脚本时，应先看 Request URL 的域名，并优先用无痕窗口或禁用扩展复核。

主题切换交互的一次 INP 为 44 ms，另一轮无痕窗口记录为 31 ms，均说明这次交互响应很快。Bottom-up 中虽然出现了 Recalculate style、Commit、Pre-paint 和 Animation frame fired，但这些数值可能是跨事件和子任务的聚合时间。只有回到 Main 轨道确认单个连续任务超过 50 ms，才能记录为 Long Task。

当前结论：不必为了优化而优化

这次实测没有发现明确的首页性能瓶颈：LCP、INP 和 CLS 都表现良好，网站自身传输体积较小，也没有证据表明主题切换存在用户可感知的阻塞。因此当前更合理的工程动作不是继续压缩或拆分，而是保存基线，记录测试条件，并在后续页面改版、依赖增长或用户反馈出现时复测。

性能工程的目标不是让某个数字无限变小，而是在真实用户场景下用较低成本维持稳定体验。没有证据支持的优化，可能增加请求数量、复杂度和维护成本，甚至让性能变差。