JavaScript性能监控核心是优化关键渲染路径（CRP），即HTML→DOM→CSSOM→渲染树→布局→绘制→合成流程；通过DevTools分析长任务、FCP阻塞资源及Navigation Timing，内联关键CSS、defer/async脚本、压缩资源、避免强制重排，并用web-vitals持续验证Core Web Vitals指标。
JavaScript中的性能监控，核心是观察和分析代码执行对页面渲染速度的影响，尤其聚焦在关键渲染路径（Critical Rendering Path, CRP）——即浏览器从接收到HTML到在屏幕上绘制出首帧所经历的最短路径。测量它不是为了堆指标，而是定位阻塞、冗余或低效环节；优化它不等于删代码，而是让关键资源更快加载、解析、执行和绘制。
识别关键渲染路径的瓶颈在哪
浏览器渲染页面需完成：HTML解析 → 构建DOM → 加载CSS → 构建CSSOM → 合并成渲染树 → 布局（Layout）→ 绘制（Paint）→ 合成（Composite）。JS会中断这个流程——尤其是同步脚本，可能阻塞HTML解析、延迟DOM构建，甚至触发强制同步布局。
- 用Chrome DevTools的Performance面板录制一次页面加载，重点关注Main线程上的长任务（>50ms）、频繁的Layout/Paint事件、以及JS执行与解析耗时
- 查看Network选项卡，筛选Waterfall图中阻塞First Contentful Paint（FCP）的资源：未标记
async或defer的script、未内联的关键CSS、过大的字体或图片 - 运行
performance.getEntriesByType('navigation')[0]，检查domContentLoadedEventStart和loadEventStart时间差，辅助判断JS执行是否拖慢交互就绪
减少关键资源数量与大小
关键资源越少、越小，CRP越短。所谓“关键”，指影响首屏渲染的HTML、CSS、JS、字体等最小集合。
- 把首屏必需的CSS提取出来，内联到
中；其余CSS用link rel="preload"或异步加载 - JS脚本默认加上
defer（保证执行顺序且不阻塞解析），非关键逻辑用async，彻底不需要立即执行的移至前或动态导入（import()） - 压缩HTML/CSS/JS（Terser、CSSNano），启用Brotli压缩，合理设置HTTP缓存头（如
Cache-Control: public, max-age=31536000）
避免运行时渲染阻塞操作
即使资源加载快，不当的JS执行仍会让页面“卡住”——比如读写交错的样式操作、大量同步DOM更新、未节流的resize/scroll监听器。
立即学习“Java免费学习笔记（深入）”；
- 批量DOM操作：用
DocumentFragment或innerHTML一次性插入，而非循环appendChild - 读写分离：先集中读取
offsetHeight等布局信息，再统一修改样式，避免强制同步重排（Forced Synchronous Layout） - 用
requestIdleCallback处理非紧急任务（如日志上报、预加载），用IntersectionObserver替代scroll监听懒加载
用真实用户数据持续验证
Lighthouse跑分只是模拟，真实体验要看用户设备、网络和行为。CRP优化效果最终反映在Core Web Vitals上。
- 接入
web-vitals库，在用户侧采集FCP、LCP、CLS等指标，按设备类型、地区、网络条件分组分析 - 对LCP元素（通常是大图或标题）添加
loading="eager"，关键字体使用font-display: swap防止FOIT - 上线后对比A/B版本的
Navigation Timing API数据，确认responseEnd到domInteractive是否缩短
基本上就这些。性能监控不是一次性的优化动作，而是把CRP当作一条可测量、可拆解、可迭代的链路来对待——每次改一行defer、少一个同步getComputedStyle，都在让这条路径更直一点。
