minimize main thread work 实测：33 个首页里脚本执行占了一半

实测 · 2026-10-03 · 34 个首页 · 单次 Lighthouse 运行

样本与口径：34 个首页（2026-08-15 以来沿用同一个 30 站面板，加我们自己的四个站），2026-10-03 每站跑一次 Lighthouse 13.5.0（mobile 配置），读标题为 Minimize main thread work 的那条审计，把它的七个分类加总。每站一次，不重跑。stackoverflow.com 没有可用报告，剔除后余 33 个，下面所有数字都来自这 33 个。

minimize main thread work 是 Lighthouse 里那条把页面加载期间主线程做过的每一件活都加总起来的审计。33 个首页各测一次，这个总量的中位数是 20,720 毫秒。其中脚本执行占 49%，样式与布局再占 17%，而 33 个里有 32 个，主线程忙碌的时间超过了 Lighthouse 划线用的四秒。

怎么测的

这条审计出自 Lighthouse 的性能分类，给出一个总量加七个有名字的分类：脚本执行、脚本解析与编译、样式与布局、渲染、解析 HTML 与 CSS、垃圾回收，以及一个叫 Other 的残余组。总量就是这七类之和，单位是加载期间花在主线程上的毫秒数。

我们在每台主机上跑一次只开这一条审计的无头 Lighthouse，从各自的 JSON 里直接读七类的值，再把这一站的总量加出来。因为这台机器所在地的关系，有几个站被重定向到了本地化路径 —— developer.mozilla.org 落到 /zh-CN、canva.com 落到 /zh_cn、我们自己的 querywin.com 落到 /zh —— 落到哪里就算哪里。Lighthouse 自己的文档写的是主线程忙碌超过四秒就标记该页，我们只把它当那条线本身，不当及格线。

minimize main thread work：33 个首页把时间花在哪

把七类在 33 个站上加总，得到的不是一个平均分配。脚本执行几乎占了一半，而「脚本解析与编译」这一类又有 5.5%，它存在的唯一原因就是 JavaScript。两样加到一起，代码是主线程忙碌的最大单一原因。

两点跟着来。第一，在这批站上，最有余量的那根杆是你发出去、让它跑的代码，不是 CSS。第二，中位数讲的是另一个故事：在一个典型页面上，样式与布局（中位 4,208 毫秒）跟脚本执行的中位（9,087 毫秒）是同一量级，因为少数极重的脚本页把总量拉高了。总量回答「这批站总的花在哪」，中位数回答「一个典型页花在哪」。两个都值得读。

脚本执行是最大的那一块

33 个首页里有 11 个，把主线程一半以上的时间花在脚本执行上；有 21 个超过四成。最重的那一页做了大约 105 秒的主线程工作，其中 62 秒是脚本执行。下表是十个最重的页面，最重的在前。

但页面重不重，不是被标记的唯一原因。唯一一个留在四秒以内的首页是 news.ycombinator.com，总共只做了 2,006 毫秒的活，几乎没有脚本执行。另一头，我们自己的四个站落在面板中间：sizemarker.com 17,655 毫秒、byerisk.com 15,237、biaojixia.com 13,503、querywin.com 7,689。没有一个干净——把这些数字公开出来、而不是一笔带过，正是这个理由。

这些数字证明不了什么

动手之前有三条边界要记住。运行是单次、没有复测，同一页第二次加载可能不同，这次没测离散度，所以给不出一个波动范围。这批 33 个首页是随手挑的、不是全网抽样，所以那些占比是这批站的描述，不是对任何别家站的估计。而主线程工作是 lab 量：它是合成运行做的功，不是访客设备做的功。

光看总量，我们也说不出哪一行脚本最该删。审计只告诉你脚本执行很大，不告诉你大在哪一段。要那个得看覆盖率视图或逐脚本审计，这次两个都没收。

常见问题

minimize main thread work 是什么意思？

它是 Lighthouse 的一条审计，名字是动作提示、不是数字。审计量的是加载期间浏览器那条唯一的主线程忙了多久，加总，并显示这些时间分给了哪几类活。「minimize」是它建议你做的动作，毫秒是它报出来的东西。

怎么减少主线程工作？

在这批站上最大的单一目标是脚本执行，所以最先要动的是少发 JavaScript、晚点跑、把重活挪出主线程。拆包、删掉没用的代码能减少要解析和执行的脚本量；把非关键脚本延后，能让它们不挤进加载。第二目标是样式与布局，它响应的是更小的 DOM 与更简单的选择器，不是更多的缓存。

主线程工作量和 total blocking time 是一回事吗？

不是，这个区别重要。total blocking time 只算每个长任务超出 50 毫秒的部分，量的是主线程被占住、无法响应的时长。主线程工作量算的是主线程做过的全部活，包含那些短到从不阻塞交互的任务。一个页面可以总量很大而阻塞时间很小，也可以反过来。

主线程工作影响 Core Web Vitals 吗？

它喂给 interaction to next paint 这条响应性指标：主线程上的活越少，浏览器画出回应之前的延迟越短。它本身不是一个 Core Web Vital，也没有一个换算成排名的已公布阈值。把总量当排查数字，把 interaction to next paint 当随之而来的 field 数字。

值得留住的边界：这是某天下午、某台机器上的一次快照，而且首页并不是访客最常用的那个页面。真正值得做的下一步，是拿同一条审计去跑用户真正落地的页面，比较两边的占比，而不是在首页上追一个最低的总量。把这种差异在一个站上看住，是 QueryWin 在做的事；这个工作量喂给的那条指标，下一篇读 interaction to next paint，一批相近面板的「被阻塞多久」读数在 total blocking time 实测里。如果找到的是样式表挡住了首屏，那更该看 render blocking resources。