网页加载顺序实测：12个首页的前14KB里浏览器无事可做

摘要：131个海外品牌站的首页各抓两轮，能用于计时的107个和109个。首字节的等待中位1.081秒，首字节到末字节的下载窗口中位只有0.0846秒，占整段等待的9.3%。看上去下载不值一提，可这段时间里发生的事决定了浏览器什么时候能去下第二样东西。把112份首页HTML按字节位置摊开数：第一个能被预扫描发现的资源引用中位落在第531字节，71个站在1024字节之内，但有12个站要读过14336字节才第一次有活干，最晚的一个在第612968字节。挡在这12个站前面的字节，99.5%是内联脚本和内联样式；其余100个站的这个比例中位数是0。

上一轮量首页里那些内联字节的时候，一直是从缓存的角度看它们：不产生请求，所以没有独立的缓存条目，寿命只能跟着文档走。

这一轮换了个位置站。同样是那些内联字节，如果它们排在文档的最前面，就还有第二重身份——它们是浏览器读到第一个可下载资源之前，必须先啃完的那一截。

于是这一轮把两件事一起量了：一份首页HTML在网络上是怎么到的，以及它到了之后，浏览器要走到字节流的第几个位置才第一次有活可干。前一件事量了两轮，后一件事离线数了112份文档。

抓一份首页HTML，时间到底花在哪几段？

口径先说死。这里把一次首页请求切成两段：首字节之前，是解析域名、建连接、握手，加上服务器自己想的时间；首字节之后，是响应体一块一块到达手里的时间，本文把它叫下载窗口。两段加起来是整个请求的时长。

样本与量法

131个海外品牌电商域名，每站首页发一个请求，全部打各站自有域名，单线程、请求之间隔2.0秒，整套跑两轮。客户端用的是支持HTTP/2的Python库，流式读取，逐块记下到达时刻与字节数，同时把响应头整份留下来。

第一轮119个站返回200，第二轮121个。返回200还不等于能用：其中12个站的响应体不到20000字节，像aliexpress.com只有828字节、temu.com只有1357字节、innisfree.com只有751字节，这些是地区跳转页或者风控中间页，正文根本不在里面，拿它们算时间没有意义。这类页面的形态在首页空壳那一轮里单独量过。剔掉之后，两轮各剩107个和109个站。

掉出样本的另一批是直接被挡的：10个站返回403，1个返回418，1个连接中途被重置。这个名单两轮几乎一样，都是aboutyou、farfetch、madewell、pandora这类做了较强机器人识别的大牌站。

三段时间的分布

前两行的对比就是这一轮最直白的结论：一次首页请求里，九成以上的时间花在第一个字节到来之前。首字节超过2秒的有15个站，超过3秒的4个，最慢的vaude.com要等25.106秒；另一头，10个站在0.5秒之内就出了第一个字节。这个方向跟多层缓存怎么左右首字节那一轮讲的机制一致，这次多了一份跨站分布。

协议这一栏没什么悬念：104个和106个走HTTP/2，只剩3个还在HTTP/1.1上。压缩这一栏也很集中，86个站用brotli，20个用gzip，1个没压。这个比例比服务器出厂只压哪几种类型那一轮量到的中小站要好得多，说明大站在这一层基本做到位了。

下载那一段只占9.3%，是不是就不用管了？

不能这么读。中位数说的是中间那个站，两头的差距大得多。

响应体是分批落地的，不是一坨

中位13块，四分位9块和20块，最多的一个分了161块。块与块之间有间隔，浏览器就是在这些间隔里干活的——收到一段解析一段，不会等最后一块到齐才动手。

2102个块间隔里，中位数只有0.0017秒，九成在0.0165秒以内。也就是说绝大多数情况下，字节是连着来的，间隔小到可以忽略。真正拖长窗口的是少数几个大空档：只有5个站出现过超过0.3秒的空档，cybex-online.com一次空了0.892秒，eufy.com空了0.748秒，vuoriclothing.com、soundcore.com、byredo.com各有一次。窗口长的站，长在一两个卡顿上，不是整段均匀地慢。这个区别很要紧，因为均匀慢通常是带宽问题，一两个大空档通常是服务端在中途等某个东西。

窗口的尾部

第一轮有2个站的下载窗口超过1秒，第二轮4个。eufy.com两轮分别是5.048秒和4.650秒，349043个字节在路上走了将近5秒；soundcore.com是0.937秒和1.467秒；ouraring.com的响应体分成94块走了0.814秒。这三个站有个共同点，响应体都在25万字节以上，属于样本里最胖的一档。

还有一个更极端的读数：窗口占整段时长的比例，最大值是78.5%。存在这样的站，服务器答得挺快，可字节在路上磨蹭掉了整段等待的四分之三。把这类站的问题归到服务器响应慢，方向就找错了。

为什么不报总长度的那批站，第一个字节反而来得更晚？

HTTP/2里没有分块传输编码这个头，RFC 9113明确禁止了连接专用的头字段，分块是靠数据帧本身实现的。所以在HTTP/2上判断一份文档是不是边生成边发，只剩一个可用信号：MDN对Content-Length的说明写得很清楚，这个头报的是响应体的确切字节数——能报出这个数，说明发之前整份已经在手上了；报不出来，说明是一边生成一边往外送。

第一轮107个站里，58个报了总长度，49个没报。原本的预期是没报的那批更快出第一个字节，因为它不用等全文生成完。

实测反过来。

为什么要把范围收进同一家边缘网络

因为整个样本里平台分布很不均。Vercel后面那3个站一个都没报，CloudFront后面的也没有，Netlify是混着来，而报了的绝大多数在Cloudflare后面。直接拿全样本比，比出来的是平台差异不是机制差异。收进Cloudflare那78个站之后，51对27才算可比。收窄之后差距还在，而且两轮都在——没报总长度的那批，首字节晚了0.5秒上下。

我第一版的解释被自己的数据推翻了

看到这张表的时候，第一反应是：报得出总长度，多半因为这份文档已经在边缘节点上躺着了，直接吐出来就行。这个解释听着顺，写进草稿之前顺手查了一眼缓存状态头，当场作废。

107个响应里有69个带着Cloudflare的缓存状态头，其中62个写的是不缓存动态内容，命中边缘缓存的只有3个，另有1个未命中、2个被绕过、1个重新验证后命中。也就是说报了总长度的那51个站，绝大多数并没有命中边缘缓存。差异不在缓存命中，在源站怎么吐这份响应：把整页渲染完再交出去的，长度是现成的；一边渲染一边往外冲的，交出去的时候自己也不知道最后有多长。前者慢在生成，快在传输起点确定；后者理论上该更早出第一个字节，实测却没有——大概率是因为它们本来就在做更重的服务端渲染。

顺带说，这批首页的缓存指令本身也很统一：58个站压根没写这个头，写了的绝大多数是各种写法的“别缓存”。这跟响应头自相矛盾那一轮看到的分布对得上，也解释了为什么首字节普遍在1秒上下。

同一个站跑两遍，哪些数字会变，哪些不会？

上一轮的教训是单次浏览器实测不能当尺子。这一轮开工就按两轮设计，结果比预想的更有意思——同一次请求里，有的读数是常量，有的读数是随机变量，它们混在同一张表上。

字节是常量

两轮都拿到200的107个站，压缩后的响应体字节数相对差中位0.012%，超过1%的只有1个站。同一个页面隔一轮再抓，传过来的还是那么多字节。所以凡是以字节为单位的结论——体积、占比、成分构成——单次测量就够，这也是上一轮量内联字节敢只跑一遍的原因。

时间不是

下载窗口两轮差值的中位数是0.0075秒，看着很稳，可尾部有8个站两轮相差3倍以上：

最后那一行是对照组。eufy.com两轮都慢，慢得稳定，那才是这个站的属性；前面四行是偶发，单跑一次就下结论会写出方向完全相反的两篇文章。这条判据跟首页视频那一轮得到的是同一条，只是那边摆动的是字节，这边摆动的是时间。

连响应头本身都会翻面

这是这一轮意外抓到的：有没有Content-Length这个头，也不是站的属性，是这一次响应的属性。107个站里103个两轮一致，4个翻了面——anker.com第一轮没报、第二轮报了250277；babybjorn.com第一轮报了96103、第二轮没报；sulwhasoo.com和vuoriclothing.com各翻一次。同一个地址、同样的请求头，这个头就是会变。所以上一节那张对照表，严格说比的是这一批响应的状态，不是这批站的固定配置，报结论的时候得把这句话带上。响应头里这种“说的和做的不是一回事”的现象并不罕见，响应头死字段那一轮把另外一类记了下来。

首字节到了，浏览器就有活干了吗？

这是本轮真正想问的问题。

浏览器不会等文档收齐再动手。web.dev那篇讲预扫描器的文章把机制说得很细：主解析器一边收字节一边建对象模型，碰到阻塞资源会停下来；与此同时有一个轻量的扫描器提前往后翻原始标记，把能看见的图片、脚本、样式表地址先派出去下载。这个扫描器是浏览器白送的性能红利，前提是它得先在字节流里看见东西。

所以真正决定开工时刻的，不是文档多大，是第一个可下载资源的引用出现在第几个字节。

112份文档的开工点

判据是从文档开头找第一个带src、href或srcset的图片、脚本、样式表、媒体或框架标签，记下字节偏移。语料是这批站的首页HTML全文，剔掉没有标题标签或者不足20000字符的，剩112份。

中位数是第531字节，四分位落在177和1834。绝大多数站没问题，第一个链接标签就在文档头几行。

14336这条线是怎么来的

它对应常见的初始拥塞窗口大小：连接刚建立时服务器一次能发出去的数据量大约是十个报文段，按1460字节算就是14600上下，取整数常写成14KB。粗略地说，这是第一批不需要等确认就能送到的字节。第一个资源引用落在这条线之外，意味着第一批字节送到了，浏览器翻遍了也没找到一件可以顺手去做的事。这条线不是硬阈值，是量级参考——链路条件不同，实际能塞进第一批的字节数也不同。

最晚的三个站：taylorstitch.com在第612968字节，占整份文档的56.5%；buckmason.com在第595698字节，占84.9%；getquip.com在第155286字节。另一头，头部14336字节里已经派出去的资源引用中位是17.5条，最多的一个147条，说明多数站在这一层做得挺好。有15个站在前8192字节里一条都没有。

挡在第一个资源前面的，到底是些什么字节？

把这12个站第一个资源之前的那段字节拆开看。统计口径是内联脚本正文与内联样式块正文求并集——之所以要求并集而不是相加，是因为内联脚本里常常又嵌着样式片段，直接相加会把同一段字节数两遍，第一版就这么错过一次，taylorstitch算出了158%这种不可能的数。

12个站的这个占比中位数是99.5%，最低的一个也有43.6%。而剩下那100个站，第一个资源之前的字节里内联内容占比中位数是0.0%。这不是程度差别，是两种写法。

换句话说，把大段脚本和样式内联进文档，代价不止是它们拿不到独立的缓存条目。只要这些内容排在第一个资源引用前面，它们还会把浏览器的开工时刻整个往后推。内联关键样式这件事本身没错，关键渲染路径那一轮讲过它为什么值得做；出问题的是把六十万字节的东西塞在最前面，而真正该先下的图和样式表排在它后头。这一层跟资源提示那一轮互补：那边讲的是提示写了却指向空处，这边讲的是提示写得再对，也得先让扫描器读到。

六十万字节，换算成时间是多少

字节数写出来挺唬人，但它不是时间，所以又单跑了一轮：挑24个站，这次按解压后的字节流边收边找，记下第一个资源引用是在首字节之后第几毫秒进入视野的。

答案比预想的温和。中位是0毫秒——第一个资源跟首字节在同一块里就到了；最晚的buckmason.com是111毫秒，24个站里超过100毫秒的只有它一个。那59万字节在本地这条链路上，只值零点一秒。

这个数得这么读：它不是说这件事不要紧，是说它的量级在毫秒不在秒。值得管的理由有三个——链路越慢这段放得越大，移动端尤其明显；它挡住的是整条资源链的起点，后面每一样东西都跟着顺延；而且修它几乎不花钱，改个顺序而已。顺带这一轮还做了个交叉核对：这24个站里，今天流式量到的第一个资源字节位，跟两天前那份离线语料算出来的完全一致，24个站一个不差，说明离线那一层的读数没有过期。

head到底该有多长？

顺手把文档头也量了。112份里每一份都能找到head的结束位置，中位落在第82456字节，占整份文档的12.9%。

尾部三个站

dreametech.com的head到第2080487字节才结束，占整份文档的52.5%；brooklinen.com是第1487533字节，占87.1%；reebok.com第965809字节。这三个站的head，单看字节比很多站的整份首页还大。

head里的资源引用中位53条，四分位33和85，最多的一个419条。第一个外部样式表出现的位置中位在第9086字节；112份文档里有72份带着不带异步标记的外部脚本，第一个出现的位置中位落在两万两千多字节处——这类脚本会直接卡住主解析器，位置越靠前，卡得越早。

head过长会牵出的另外两类问题

head长到这个量级，麻烦不止一处。head提前闭合导致规范标记被解析进body那一轮，量的是同一个部位的解析边界；字符集声明的字节窗口那一轮，量的是声明来晚了会怎样。三件事发生在同一段字节上，但触发条件各不相同，排查的时候别混作一谈。

响应头这一层也顺手记了：字段数中位33个，最多45个；头本身的字节中位3776，最多18420。跟响应体比这不算什么，但它在每一次请求上都要付一遍，请求头里那份重复发送的Cookie那一轮算过这笔账。

这几段时间里，Googlebot在等的是哪一段？

对搜索引擎来说，三段时间的分量完全不一样。

首字节那一段最要紧

Google关于大型站点抓取预算的文档说得直接：服务器响应变慢，抓取速度会自动降下来。这个过程在服务器慢下来那几天抓取速率被调低那一轮里能看到全程，日志里一条错误都没有，速率就是掉了。抓取预算这条线怎么排，抓取频次优化那一篇列过十二项。

下载窗口那一段，用户比爬虫更疼

Lighthouse那条服务器响应时间的审计只盯首字节，窗口这一段它不单列，所以光看审计分数会漏掉eufy.com那种情况——首字节1.4秒不算离谱，可字节还要再走将近5秒。web.dev关于首字节时间的说明把首字节之前那几段拆得很细，但它到首字节就收尾了，后面那段得自己量。

开工时刻影响的是渲染那一步

抓取端跑的是同一套浏览器内核，预扫描器该慢也一样慢。这条线跟页面体积撞上抓取上限是两回事：那一轮讲的是超过多少字节之后内容被截断，这一轮讲的是前面那些字节里有没有能提前派活的东西。两件事可以同时发生在一份文档上，而且往往是同一批站——毕竟把几十万字节塞进头部的站，整份文档通常也不小。渲染这一步各个环节怎么走，抓取与渲染分几步那篇讲过全流程。

我这套量法，在哪几处会骗人？

五处，全都踩过。

第一处，工具本身量不到目标协议。本机那个curl编译时没带HTTP/2支持，一开始拿它跑，131个站清一色报HTTP/1.1，还顺带被十几个站直接403挡掉。换成带HTTP/2的Python客户端之后，同一批站里104个是HTTP/2，403也少了一大半。量协议层的东西，先确认手里的工具能说这门话。

第二处，判据在新协议里已经失效。最初打算用分块传输编码这个头来分辨流式与非流式，跑完发现HTTP/2上根本不存在这个头。判据只好换成有没有Content-Length，而这个替代判据也有软处，就是上文那4个翻面的站。类似的代际失效在HTTP/3那一轮也遇到过，判据得跟着协议版本走。

第三处，块边界不是服务端的帧边界。本文说的“分成13块到”，块的大小中位是8192字节、最大16384——这两个数一看就是本地读缓冲的尺寸，不是服务器发帧的尺寸。所以块数只能用来说明“响应体是分批落地的”，不能拿去反推服务端一次推了多少。真要看帧级别，得抓包或者用浏览器内核自己的记录。

第四处，两套坐标系不能混着用。网络那一层记的是压缩后的字节到达序列，离线那一层数的是解压后的字符偏移。同一份文档经brotli之后可能只剩十分之一，说“第一个资源在第531字节”和说“第几毫秒到”是两把尺子上的刻度，中间没有简单换算。这一轮的做法是两边分开报，不硬凑。

第五处，429是我自己造的。第一版用了两个并发，跑到字母r开头的那批站时连续12个返回429。改成单线程加2.0秒间隔之后，两轮各131个请求，一个429都没有。这不是站方限流严，是自己把节奏踩坏了。顺带说，这类限流规则误伤的第一个受害者常常是robots.txt，限速规则拒掉第4个请求那一轮量过后果。

自己站上怎么量一遍，该改什么

四步，半小时够。

第一步，拿命令行量三个时间点。用curl的写出格式，一次拿到解析、建连、握手、首字节、总时长几个数：curl -s -o /dev/null -w "ttfb=%{time_starttransfer} total=%{time_total} size=%{size_download}\n" https://你的域名/。总时长减首字节就是下载窗口。跑五次取中位，别信单次；先用curl -V确认输出里有HTTP2这一项。

第二步，在浏览器里核一遍。开发者工具网络面板点开主文档，看时序里的等待响应与内容下载两段；或者在控制台执行performance.getEntriesByType('navigation')[0]，里面responseStart与responseEnd之差就是窗口。两边对不上的时候优先信浏览器，它跟真实用户走的是同一条路。

第三步，找自己的开工点。把首页HTML原样存成文件，搜第一个<link、<script src或<img src出现的字节位置。超过14000就值得查一查：前面挡着的是什么，是一段内联脚本，还是一大块序列化好的商品数据。

第四步，决定动不动。判据是那段内联内容首屏用不用得上。用得上的关键样式留着，压到几KB以内；用不上的数据块、模板、埋点脚本往后挪，挪到第一批资源引用之后就行。改动本身很小，风险主要在挪错顺序把首屏样式挪到了后面。

有三样东西不建议动

一是别为了让第一个资源提前，把原本异步的脚本改成同步；那等于用一个更大的阻塞换一个更小的延迟。二是别把已经在用的边缘缓存关掉去追求所谓流式送达，本轮数据说明那多半会让首字节更慢。三是别照抄14336这个数字去设硬阈值，它是量级参考，真正要看的是自己那份文档里挡在前面的是什么。

保哥手上一个户外装备独立站就是这个形态，首页头部压着一段三十多万字节的商品数据，把它挪到样式表和首屏大图的引用后面，主文档本身一个字节没少，首屏图片的请求提前了将近一百毫秒——什么都没删，只是换了个顺序。这种改法的好处是几乎没有回归风险，坏处是它只解决开工时刻，救不了首字节那一秒。

常见问题解答

首字节慢和下载窗口长，我该先修哪一个？

先看比例。本轮中位数是九成时间在首字节之前，多数站确实该先修那一段，方向是缓存命中率和回源逻辑。但如果自己量出来窗口占比超过三成，那就是另一类问题了，通常跟响应体过大或者链路带宽有关，改缓存没用。判据很简单，用上面那条命令跑五次，看两段的比例。

服务器不返回Content-Length，是配置出错了吗？

不一定。边生成边发的响应本来就报不出确切长度，这是正常行为。本轮107个站里49个没报，Vercel和CloudFront后面的站基本都不报。真正要注意的是它跟首字节的关系：同一家边缘网络内部，没报的那批中位晚了0.5秒，多半说明这次响应是现渲染的，而不是把整页做好了再交出去。

把关键样式内联进head，会不会反而拖慢开工？

取决于放在哪儿和放多少。几KB的关键样式放在最前面，代价可以忽略。本轮出问题的12个站是另一个量级——挡在第一个资源前面的内联内容占比中位99.5%，最大的一个六十多万字节。分界线不在要不要内联，在这块内容有没有大到把后面所有资源引用都压住。

用curl量出来的和开发者工具对不上，信哪个？

先确认协议。很多发行版的curl没带HTTP/2支持，跑出来的是HTTP/1.1的成绩，跟浏览器不是一回事。其次curl每次都是新连接，浏览器可能复用已有连接、跳过握手。要对齐就在curl上显式加协议参数，两边都跑多次取中位。真实用户体验以浏览器那一边为准。

head写得长一点，搜索引擎会不会读不完？

解析层面通常读得完，真正的风险在两头。一头是文档整体超过抓取上限被截断；另一头是head里出现了不该出现的标签，导致解析器提前认为head结束，后面的规范标记和元信息就被当成正文了。本轮量到的head中位第82456字节，超过一百万字节的有三个，那种量级值得单独排查一次。

响应体分成几块，这个数有什么用？

它说明这份响应不是一瞬间落地的，浏览器在块与块的间隔里就已经开始解析。中位13块意味着解析和下载是重叠进行的。要留意的是块数多、窗口又长的站，本轮ouraring.com分了94块走了0.814秒，这种形态通常是响应体偏大加上链路不稳。不过块的大小受本地读缓冲影响，别拿它反推服务端行为。

这批数字能不能代表我的站？

只能当参照系。样本是131个国际品牌电商域名，绝大多数挂在成熟的边缘网络后面，测量点在国内，跨洋链路本身就贡献了相当一部分首字节时间。中小站的绝对数值会差很多，但三段时间的结构和开工点的算法是通用的，照上一节那四步在自己站上跑一遍，得到的才是自己的数。

只跑一次行不行？

字节可以，时间不行。本轮两轮对照里，压缩后的字节数相对差中位0.012%，一次就够；下载窗口却有8个站两轮相差3倍以上，最大的一个差20.8倍，连Content-Length这个头都有4个站翻了面。凡是要报时间的结论，至少跑两轮并把区间写出来，只有两轮都指向同一个方向的才算数。

权威参考资料