寻求适用于页面全生命周期的长任务阻塞度量公式（替代TBT）

1. 累计长任务阻塞时长（全生命周期版） #

公式：TotalBlockingDuration = sum(long_task.duration for all long_tasks in page_lifecycle)

• 计算方式：把页面从加载到卸载期间，所有时长≥50ms的长任务的持续时间累加，得到UI线程被阻塞的总时长。
• 优势：简单直观，能直接反映页面整个生命周期内的总阻塞开销，适合做整体性能评估。
• 优化提示：可通过长任务的归因信息，过滤掉用户主动操作触发的任务（如大文件上传），只统计后台自动执行的任务，避免误判。

2. 平均阻塞时间占比 #

公式：AverageBlockingRatio = (sum(long_task.duration) / total_page_lifecycle_time) * 100%

• 计算方式：用所有长任务的总时长，除以页面从加载到卸载的总时间，得到UI线程被阻塞的时间占比。
• 优势：能体现阻塞的相对严重程度——比如两个页面总阻塞时长相同，但生命周期更短的页面，阻塞问题实际更突出。

3. 最长连续阻塞窗口时长 #

公式：MaxConsecutiveBlockingWindow = max(end_time_of_last_task - start_time_of_first_task for consecutive_long_tasks)

• 计算方式：找出页面中连续出现的长任务组，计算每组从第一个任务开始到最后一个任务结束的总时长，取最大值。
• 优势：连续阻塞是用户感知最强烈的卡顿场景，这个指标能直接定位页面最卡顿的时段，方便针对性优化。

4. 高频阻塞加权得分 #

公式：WeightedBlockingScore = sum(long_task.duration * (1 + log10(count_of_long_tasks_in_last_10s + 1)))

• 计算方式：给短时间内密集出现的长任务增加权重——比如10秒内出现的长任务越多，每个任务的权重越高，最终得分能反映阻塞的密集程度。
• 优势：区分“偶尔单次卡顿”和“连续频繁卡顿”，后者对用户体验的破坏远大于前者，这个公式能更精准捕捉这类核心问题。

实现要点 #

• 借助PerformanceLongTaskTiming API监听所有长任务，记录每个任务的开始时间、时长和归因信息（如脚本执行、渲染等阻塞原因）。
• 结合页面生命周期事件（load、visibilitychange、beforeunload），确保测量覆盖从页面加载到卸载的全流程。

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