长任务会使主线程保持繁忙，延迟用户交互。Chrome DevTools现在可以可视化长任务，更容易看到需要优化的任务。
如果使用Lighthouse审计页面，您可能熟悉交互时间(Time to Interactive)，这是表示用户与页面交互并获得响应的时间。但是您知道长(JavaScript)任务对糟糕的TTI有很大影响吗?
什么是长任务？
Long Task 是JavaScript代码长时间独占主线程，导致UI“冻结”。
当一个网页正在加载时，长任务可能会占用主线程，使页面对用户输入没有响应，即使它看起来准备好了。点击通常不起作用，因为事件监听器、点击处理程序等尚未附加。
cpu负荷大的长任务(Long task)是由于复杂的工作需要超过50ms。为什么50毫秒? The RAIL model 这样做，作用和反应直接的联系就被打破了。
在我的页面中是否有可能延迟交互性的长任务?
到目前为止，你还需要在 Chrome DevTools 中手动查找长度超过50ms的“黄色长块”脚本，或者使用 Long Tasks API 来找出哪些任务延迟了交互性。这可能有点麻烦。
为了帮助简化您的性能审计工作流，DevTools现在可视化了长任务（DevTools now visualizes Long Tasks）。如果任务(以灰色显示)是长任务，则有红色标志。
-
在“性能”面板（Performance panel）中记录加载网页的跟踪。
-
在主线程视图中寻找一个红旗。您应该看到任务现在是灰色的(“任务”)。
-
将鼠标悬停在一个栏上可以让你知道任务的持续时间以及它是否被认为是“长”的。
是什么导致了我的长任务?
要发现导致长任务的原因，请选择灰色任务栏。在下面的抽屉中，选择自下而上和按活动分组。这使您可以看到哪些活动对耗时如此之久的任务贡献最大(总体上)。下面，它似乎是一组开销很大的DOM查询。
通常用什么方法优化长任务？
大型脚本通常是长任务的主要原因，所以考虑将它们拆分（splitting them up.）。还要留意第三方脚本;他们的长任务会延迟主要内容的交互性。
将所有工作分解成小块(运行时间小于50ms)，并在正确的地点和时间运行这些块;正确的位置甚至可能在主线程之外的工作线程中。菲尔·沃尔顿的《Idle Until Urgent》是一本关于这个话题的好书。
保持页面的响应性。最小化长任务是确保用户在访问站点时获得愉快体验的好方法。有关长任务的更多信息，请查看以用户为中心的性能度量（User-centric Performance Metrics）。
