优化INP：如何分析Performance面板中耗时久且90%在等待的函数？

1. 函数长时间等待的常见原因 #

• 等待异步操作结果：比如函数内用await等待网络请求（fetch/XHR）、文件读取、IndexedDB查询、Web Worker消息响应，或是等待定时器触发。这类异步操作的耗时不会计入函数自身执行时间，但会被统计到函数总耗时里。
• 主线程被阻塞：函数本身是异步回调（比如setTimeout回调、Promise的then回调），但主线程正在执行其他长任务（比如大型DOM渲染、复杂计算），导致回调排队等待执行，总耗时被拉长，但自身实际执行时间很短。
• 等待共享资源/锁：比如多个线程或函数竞争同一资源（如SharedArrayBuffer锁、第三方库内部锁），导致当前函数处于等待资源释放的状态。

2. 等待时间不被判定为idle的原因 #

浏览器的idle状态指主线程没有任何待处理的宏任务、微任务，且没有未完成的异步任务关联。你的函数等待时完全不符合这个条件：

• 如果是async/await的暂停状态：函数的执行上下文并未完全结束，关联的Promise仍处于pending状态，浏览器会认为这个任务链还未完成，不会标记这段时间为idle。
• 如果是回调排队等待：此时主线程可能在处理其他任务（本身不空闲），或者任务队列里还有待执行的任务，自然不算idle。
• 即使主线程暂时没任务，但只要有未完成的异步操作（比如正在进行的网络请求）关联到这个函数，浏览器也不会把这段时间算作idle——因为该函数的执行依赖于异步操作的结果，属于未完成的任务环节。

3. 关于面板选项的选择（基于Performance面板常见场景） #

假设你看到的是Performance记录相关的选项，推荐按以下场景选择：

• 若要捕捉完整的异步栈追踪：勾选「Async stacks」选项，这样能看到函数等待的异步操作关联的调用链，定位具体等待的资源。
• 若要高分辨率时间线：选择「High resolution」采样模式，能更精准地看到等待阶段的细节。
• 若要聚焦JavaScript执行：过滤选项选「JavaScript」，排除无关的渲染、网络事件干扰。
• 记录模式选「Performance」（而非Memory或其他），确保捕获所有任务、异步事件的时间线。

内容的提问来源于stack exchange，提问作者AGamePlayer