critical rendering path 实测：29 个首页第一屏之前排了 329 个阻塞资源

实测 · 2026-10-04 · 29 个首页 · 单次 HTML 抓取

样本与口径：一共尝试 34 个首页——沿用 2026-08-15 起的那份 30 站面板，加上我们自己的四个站。每个站在 2026-10-04 用 curl 走 HTTPS、带桌面浏览器 UA 抓一次原始 HTML。其中 4 个返回 403、reddit.com 返回一个 8 KB 的空壳（连 head 都没有），剔除后剩 29 个。我们从每份原始 HTML 里数 <head> 中的阻塞样式表和同步脚本。每站一次、不渲染、不复测。

critical rendering path 是浏览器画出第一像素之前必须按顺序走完的那条链：连接、HTML、样式表，以及任何会打断解析的脚本。29 个首页各抓一次，head 里一共背着 329 个阻塞资源——307 张样式表加 22 个同步脚本，中位数每页 5 个，最多的一个站发了 66 个。

怎么测的

一个资源算不算阻塞，看浏览器能不能在它完成之前画东西。head 里有两样会挡：样式表，因为布局算不出来；以及带 src、既没 defer 也没 async 的经典脚本，因为解析会停下来等它执行完。两样都从原始 HTML 里数；脚本只要是 defer、async 或 type="module"，就不计入。

我们还记了「有没有一个内联 <style> 块出现在第一张阻塞样式表之前」，作为「临界 CSS 是否被内联在前」的粗略信号。这只是信号、不是证据：一个页面可以内联了样式块，却仍可能被别的东西挡住。下面所有数字都来自同一天、同一台机器，是从标记里数出来的计数，不是 Lighthouse 那种「浪费多少毫秒」的数。

critical rendering path：29 个首页在第一屏之前排了什么

把整面板加起来，阻塞的活几乎全是 CSS。307 张样式表占了 329 个资源里的 93%；22 个同步脚本是剩下那 7%，散在 29 个站里的 13 个上。下表是最重的十一个首页（重的在前）加面板合计。

有四个首页一个阻塞资源都不发：www.framer.com、www.shopify.com、www.wired.com、www.bbc.com。它们 head 里根本没有外部样式表——把样式全内联了。另一头，29 个里有 11 个发了十个以上阻塞资源。这两组之间的差，差不多就是第一屏的全部成本，所以「数了几个」比「一共多少 KB」更值得看。

真正挡路的是样式表，不是脚本

脚本在这批站上不是问题。29 个里只有 13 个 head 里有同步脚本，平均不到两个。拉开差距的是样式表数量：中位数 5，最多 66。head 里挂 66 张独立样式表链接的页面不是一次请求，是 66 次等待机会。

29 个页面里有 9 个至少内联了一个出现在第一张阻塞样式表之前的 <style> 块，而那 4 个零阻塞的页面正是这种做法的极端版。内联是面板里唯一能「真正移走」阻塞链接、而不是把它推后的动作。它值不值，取决于内联块会涨到多大——这正是手册那篇要算的账。

这些数字证明不了什么

第一，原始计数不等于绘制耗时。两张并行取回的样式表，和一张从冷主机取回的，可能一样、也可能差很多，光看标记看不出来。第二，这是每站一次、一个下午的抓取，没有复测；用 JavaScript 懒加载样式表的站会被我们少算，本次也没量离散度。第三，这 29 个首页是便利面板，不是全网抽样——这些份额描述的是这批站，不是对任何别人的估计。

我们也分不清「有意内联临界 CSS」和「构建工具默认把所有样式都内联了」。计数只说明在第一张样式表链接之前有一个内联块，不说明有人这么决定过。

常见问题

critical rendering path 到底是什么？

它是浏览器画出第一像素之前按顺序跑的那组步骤：取回 HTML、建立文档树和渲染树、算清布局需要的 CSS、执行任何打断解析的脚本。把它缩短，是减少这条链上的步骤，而不是让后面的步骤更快。

怎么找到自己页面上的阻塞资源？

打开开发者工具、刷新，看网络瀑布图：第一屏在等的东西，都排在 first contentful paint 标记之前。如果想拿一个跟搜索爬虫看到的一致的抓取层计数，就直接抓原始 HTML、数 head 里的样式表元素和同步脚本元素——也就是这次数的两类。

样式表越多页面就越慢吗？

不一定，这次面板也下不了这个结论。走同一条连接的多张样式表可能几乎同时到达，而一张来自慢速第三方的样式表可能更糟。这个计数是个「值得去看一眼」的信号，不是判决；瀑布图才告诉你顺序和等待。

我应该把所有 CSS 都内联吗？

不要。内联块会随每一份 HTML 文档一起下发，没法跨页缓存，块一大，每次导航都更重。只内联首屏，其余仍作为正常的可缓存样式表，并且复测，别凭感觉。

边界说清楚：这是一次对标记的普查，而首页也不是访客最常用的那个页面。接下来值得做的，是把同一套计数对「访客真正落地的那些页」跑一遍，看看阻塞清单会不会不一样，而不是只优化首页。把这种差异盯下来，是 QueryWin 在量的一部分；顺着这个指标往下，34 个首页的 first contentful paint 实测 给的是同批面板的绘制侧读数，更早的 render blocking 实测 只数了这件事的样式表那一半，而 render blocking resources 是把清单变成修复顺序的那一章。