移动端页面启动卡顿？用 Web Worker 避免主线程阻塞

排查页面启动时的卡顿现象

在手机浏览器中打开页面，观察页面完全加载完成前是否出现界面冻结或无法点击的情况。如果用户在等待页面显示时感觉设备或浏览器被锁死，这通常意味着主线程被长时间占用。这种假性卡死会让用户误以为应用崩溃，从而产生焦虑情绪。

使用 Chrome DevTools 的 Performance 面板录制页面加载过程，查看主线程的火焰图。如果发现某段 JavaScript 代码执行时间过长，导致主线程长时间处于忙碌状态，这就是造成卡顿的直接原因。此时需要确认该段代码是否属于启动时的关键路径。

Web Worker 是一种允许在后台线程中运行脚本的技术，它不能直接操作 DOM 或 WebGL，但非常适合执行纯计算任务。通过将启动时的数据处理、解码等任务放入 Worker，主线程可以继续响应用户事件和渲染界面。这能有效防止页面和界面在启动过程中变得无响应。

MDN 指出，将任务转移到 Worker 可以释放主线程，使其专注于用户交互和渲染。同时，主线程的事件应包含许多小任务，而不是耗时较长的任务。异步加载有助于防止页面和用户界面出现冻结，确保应用的事件循环在启动期间持续运行。

将启动过程中涉及的大量数据处理或文件解码逻辑提取出来，编写为独立的 Worker 脚本。在主页面中创建 Worker 实例并传递数据，完成后通过消息机制接收结果。对于需要解码资源文件的情况，利用浏览器内置的解码器在 Worker 中处理，可以显著减少主线程负担。

对于从原生应用移植到 Web 的项目，如果无法完全将代码移至 Worker，可以尝试将启动过程拆分为多个小块。通过分批执行这些代码块，让主线程有机会处理输入事件。这种分块策略能避免单次任务阻塞主线程过久，从而改善启动时的流畅度。

重新录制页面加载的性能分析，对比优化前后的主线程占用时间。如果发现主线程不再出现长时间的高负载区间，且页面能够快速响应用户的点击操作，说明优化有效。此时用户感知的页面启动速度应该明显加快，不再出现冻结现象。

在真实设备上测试，观察页面从点击到内容首次可见的时间。如果页面在 1 到 2 秒内变得可用，且用户输入响应延迟在 50 毫秒以内，说明启动体验已达到良好标准。任何超过 200 毫秒的延迟都会让用户感觉页面迟缓，因此持续监控主线程的执行情况至关重要。