chrome devtools 录制聚焦主线程火焰图，紧盯 fcp＜1.2s、tti＜3.8s、cls＜0.1、内存＜300mb 四指标，通过“行为—录制—分析—代码”闭环定位卡点，识别典型性能模式并嵌入开发流程。
直接用 Chrome DevTools 录制真实操作，聚焦主线程火焰图，盯紧 FCP＜1.2s、TTI＜3.8s、CLS＜0.1、内存＜300MB 这四个可测可改的指标，把“代码改动”和“性能变化”连成因果链，而不是背指标定义。
带着问题去录，别盲目点开始
录制不是目的，定位卡点才是。每次只测一个明确行为：
- 点击按钮后卡顿？关闭其他标签页，只点那一下，勾选“Screenshots”看是否掉帧
- 滚动不跟手？开启“Rendering”轨道，观察 Layout/Paint 是否频繁且抖动
- 首屏发白太久？勾选“Network”和“JS Profile”，确认是脚本没下完，还是下载完却卡在解析执行
- 操作后内存不降？在 Memory 面板拍两个堆快照，对比“Constructor”里 Detached DOM 或 Closure 是否异常增长
看懂火焰图，重点不是颜色，而是结构
火焰图不是越红越糟，而是“又长又深”的块最危险：
wechat-article-extraction-mp-weixin-qq-com news-webpage-cleaning blog-post-parsing metadata-extraction-title-author-date multiple-output-formats-markdown-json-plain-text batch-processing-support
下载
基于三引擎设计，从微信文章、新闻和博客网页提取干净内容，支持标题作者日期元数据，多格式和批量处理。
- 顶部横轴是时间线，中间竖向堆叠是调用栈：从左到右是执行顺序，从上到下是函数嵌套深度
- 看到一个 180ms 的紫色长条？右键“Zoom to selection”，再点进去看最底下的函数——它大概率是同步阻塞源头
- 发现大量浅层黄色块（Recalculate Style）？说明 CSS 选择器太重或样式频繁变更，不是 JS 问题
- 主线程下方有“Event Log”，点开一次 click，往右看它触发了哪些 Layout → Paint → JS，能立刻理清交互因果
四个指标要对应到具体代码动作
每个指标背后都有典型代码模式，识别它们比记数值更重要：
-
FCP 超 1.2s → 检查是否有未加
async或defer的大 JS 文件，或内联 CSS 阻塞了 HTML 解析 - TTI 超 3.8s → 找主线程里＞50ms 的长任务，比如初始化时遍历千条数据+同步渲染+绑定百个事件监听器
- CLS ＞ 0.1 → 查图片/视频是否缺宽高、广告位是否异步插入、字体加载是否导致文字重排（FOUT/FOIT）
-
内存持续涨 → 看定时器是否没
clear、事件监听器是否没remove、闭包是否无意中持有大数组或 DOM 引用
养成测量习惯，从写第一行逻辑就开始
优化不是上线前补救，而是开发中就嵌入反馈闭环：
- 核心函数开头加
const start = performance.now()，结尾算差值，控制台一眼可见耗时 - 模块初始化用
console.time('init')/console.timeEnd('init')快速验证 - CI 流程里跑 Lighthouse，把 FCP 和 INP 设为门禁：超阈值自动失败，不靠人盯
- 关键用户路径（如登录、下单）加轻量埋点，上报到内部看板，趋势比单次值更有意义
