结论先行：前端 Long Task 里最容易被忽略的一类，不是渲染、不是 setState，而是
JSON.parse本身——它对 30 万+ 字节的响应在主线程同步执行，单次耗时可达 800ms+，且 DevTools 的 Long Task 归因里往往只显示JSON.parse一行，让人误以为"没代码可优化"。本文给出一次真实劣化的完整排查，以及把解析卸载到 Worker 后 INP P75 从 640ms 回到 190ms 的 4 组可复现参数。
一、现象与背景：接口 P99 很快，但页面就是卡
先摆数字。我们一个 B 端运营后台（React 18.2 + Vite 5.1），单页平均 DOM 节点约 6,000，首屏并行 14 个接口。其中「订单聚合」接口返回 38 万字节 JSON（约 4,200 条订单 × 每条约 90 字段），网关侧 P99 86ms、网络传输 210ms——服务端和网络都很健康。
但 2024 年 11 月 RUM 大盘（n=38,400 次交互样本）显示：
- 该页 INP P75 从 9 月的 220ms 爬到 640ms，LCP 只动了 +40ms；
- 翻页 / 筛选操作期间的 Long Task（>50ms）占比 37%；
- 最长单次 Long Task 903ms，全部集中在「接口响应到达 → 列表可交互」这个窗口；
window.onerror零报错，用户体感是"点了没反应"，不是"页面崩了"。
接口越快，卡顿反而越明显——这是本次排查最反直觉的起点。
二、原理：为什么 parse 会是 900ms 的长任务
三层机制叠加：
JSON.parse是同步、不可中断的。它运行在主线程的普通 JS 任务里，V8 不会在其中插入微任务边界，任务期间所有输入事件、requestAnimationFrame、setTimeout全部排队。React 18 的并发渲染能打断组件更新，但打断不了一个正在跑的 parse 调用——并发渲染的"让出"只发生在 React 自己的调度点。- 耗时随字节数超线性增长。parse 不是 O(n) 的纯拷贝：对象要分配、字符串要 intern/decode（非 ASCII 更贵）、嵌套层级越深临时对象越多。我们实测同一接口：12 万字节 ≈ 180ms，26 万字节 ≈ 430ms，38 万字节 ≈ 900ms（Chrome 126，M1 Mac，冷缓存）。也就是说接口数据量 +60%，parse 耗时 +110%。
- 它和渲染在同一帧里串行排队。parse 完成 → setState → 组件 diff → DOM 提交，整条链路的耗时是相加的。当 parse 占 900ms，后面哪怕渲染只要 80ms，用户感知到的"输入到下一帧"也是 900ms+。
一个容易忽略的细节：这个长任务只发生在主线程，CPU 负载不高（parse 是单核密集），所以"CPU 打满"这种告警规则永远抓不到它——它只能从 Long Task / INP 侧暴露。
三、具体做法：把 parse 移进 Worker，4 组参数都可复现
1) Worker 里 parse，主线程只收成品
// parse.worker.ts
self.onmessage = (e: MessageEvent) => {
const { id, text } = e.data;
const t0 = performance.now();
const data = JSON.parse(text); // 在 Worker 线程，主线程零阻塞
self.postMessage({ id, data, cost: performance.now() - t0 });
};
// main.ts
const worker = new Worker('./parse.worker.ts');
worker.onmessage = ({ data: { id, data } }) => {
if (id === pendingId) setOrders(data); // 回主线程只做一次 setState
};
async function loadOrders() {
const resp = await fetch('/api/orders');
const text = await resp.text(); // 注意：先取 text，不是 resp.json()
pendingId = ++seq;
worker.postMessage({ id: pendingId, text });
}
实测效果（同 38 万字节响应）：主线程侧的 Long Task 从 903ms → 41ms（只剩 setState + diff），INP P75 从 640ms → 190ms。Worker 侧 parse 本身耗时 780ms——没省 CPU，只是换了线程，这正是关键：INP 度量的是主线程响应性，不是总计算量。
2) 并发控制：Worker 池开 2 个就够，别按 CPU 核数开
new Worker 单实例串行处理消息，页面同时有 3 个大接口在飞时，第 3 个要等前两个 parse 完。我们试过按 navigator.hardwareConcurrency（M1 是 8）开 8 个 Worker，收益 +3%（总耗时几乎不变），但常驻内存多占约 90MB（每个 Worker 基础开销 ~11MB）。最终固定 2 个 Worker 轮换，覆盖"两个大接口并发"的 95 分位场景，多出来的并发交给后端限流。
3) 请求侧止血：把 38 万字节砍到 6 万
治本还是减数据。和后端约定列表接口只回 12 个展示字段（原来 90 个），明细字段按需在行展开时再拉单条。响应体 380KB → 62KB，主线程 parse 直接掉到 23ms——这一步做完，Worker 方案对"该接口"都不再必需，但 Worker 通道保留，兜住其他历史接口。
4) 可观测性：给 parse 单独打 mark，进 RUM
performance.mark('parse:start');
worker.postMessage({ id, text });
worker.onmessage = () => {
performance.mark('parse:end');
performance.measure('json-parse', 'parse:start', 'parse:end');
};
RUM 侧按 duration > 50 过滤上报，字段带 payloadBytes（new Blob([text]).size）。这是后文踩坑 2 的教训：没有这个指标，你根本不知道 parse 是元凶。
四、踩过的坑（都花过真实时间）
- DevTools 里
JSON.parse显示耗时比实际小 40%。Performance 面板对内置函数的计时不含 V8 内部的对象分配峰值，真实阻塞以 Long Task 事件（PerformanceObserver的longtaskentry，含blockingDuration）为准。我们按面板数字做的第一次"优化"（减少对象访问）完全无效。 - 第一次上 Worker 时 INP 反而涨了 15ms。原因：
postMessage传的是字符串，结构化克隆对 38 万字节字符串本身要拷贝一次，约 28ms，发生在主线程。解法是接受这次拷贝（比 900ms 可忽略），但不要把 parse 完的对象再传回时同时保留主线程的 text 引用——两副本共存让该 tab 内存峰值从 240MB 涨到 410MB。 resp.json()和resp.text()别混用：resp.json()内部也是主线程 parse，很多框架封装（axios 默认transformResponse）会在你拿到 text 之前就 parse 掉。我们要在 adapter 层关掉transformResponse，否则 Worker 方案直接失效——这次排查里最大的"静默回退"。- Worker 在低版本 Safari 里
self.onmessage冷启动要 60~90ms，首次请求会明显变慢。解法：页面空闲时（requestIdleCallback）预热 Worker，而不是首请求时再创建。
五、结论与可复用清单
治理后一周稳态：该页 INP P75 640ms → 190ms（-70%），Long Task 占比 37% → 9%，弱机（中端 Android，4GB RAM）上的"点击无响应"工单从周均 6 单降到 0。
可复用清单（按投入产出比排序）：
- 先给 JSON parse 打独立 measure：没有数据，一切优化都是猜；阈值建议 50ms 进 RUM；
- 能用字段裁剪解决就别上 Worker：380KB → 62KB 收益最大且零架构成本；
- 必须上 Worker 时：传 text 进、传对象出；Worker 池固定 2 个；首请求前
requestIdleCallback预热； - 检查 HTTP 层的默认
transformResponse：这是 Worker 方案最常见的静默失效点； - 告警规则盯 Long Task 的
blockingDuration，不要盯 CPU——parse 型卡顿 CPU 不高。
一句话：INP 的敌人是"主线程上任何一段不可打断的同步代码"，JSON.parse 只是其中最隐蔽的那一个——它不报错、不崩、CPU 不红，只在用户的手指上兑现。