网页源代码有多大：27 个首页中位 561 KB，能看见的字只占 1.9%

实测 · 2026-08-23 · 27 个首页 · 单次抓取 · 字节数了两遍

样本 / 口径：2026-08-15 以来一直在用的那批 30 个站，2026-08-23 当天每个首页抓一次，浏览器 UA，请求头带 Accept-Encoding: gzip, deflate, br。先记下线上传输的字节数，再解压，再数一遍。只算 HTML —— 图片、脚本、样式表一个都没取。

右键看网页源代码，那一大坨到底有多大？27 个首页量下来，解压后中位 574,601 字节，最大的一个 2,187,316 字节，而其中人眼能看见的文字中位只占 1.9%。这个数值得单独量，是因为 Googlebot 的抓取上限就卡在这里，而且是按解压后算的。

怎么测的

每站一次请求，不渲染、不重试。纳入规则跑数前写死：状态 200、响应体不小于 10,000 字节、含 <body。30 个里 3 个没过 —— stackoverflow.com 与 medium.com 返回 403，www.reddit.com 返回 8,393 字节空壳 —— 剩 27 个，与前几批被剔的是同样三个。

线上字节是响应体交付时的长度。HTML 字节是按 Content-Encoding 解压之后同一份响应体的长度。可见文字是去掉 script、style、noscript、template、svg 之后文本节点里的字符数，空白折叠。内联脚本字节指文档里 <script> 标签内部的内容，它和这些页面另外加载的外部 bundle 体积不是一回事。

上限是 2MB，而且按解压后算

Google 的 Googlebot 文档（页面标注 2026-02-03 更新，2026-08-23 读）把这条写得很直白：「When crawling for Google Search, Googlebot crawls the first 2MB of a supported file type, and the first 64MB of a PDF file.」再往下两行那句更要紧：「The file size limit is applied on the uncompressed data.」

所以线上那个数字是看错了对象。一个 188 KB 传过去的首页，解析时可能已经是 2 MB，而截断规则读的是后一个。超了会怎样文档也写了：「Once the cutoff limit is reached, Googlebot stops the fetch and only sends the already downloaded part of the file for indexing consideration.」

压缩省的是你的带宽账单，省不了单个文档的抓取额度。

已经有一个站过线了

www.framer.com 在 2026-08-23 这天发出 2,187,316 字节的 HTML，线上只有 188,641 字节。不管文档说的 2MB 指 2,000,000 还是 2,097,152，它都过了 —— 文档没定义单位，而到了这个体积，怎么算都救不回来。另有六个站在 1 到 2 MB 之间。

最后一行是样本的另一端。Hacker News 用 5,651 字节传完一个完整首页，解压后 34,509 字节，是 Framer 的 1.6%。拿它比设计野心不公平。拿它比爬虫要读多少字节才能拿到同一类信息，是公平的。

全都压了，Brotli 已经赢了

27 个站返回的都是压缩过的响应体。18 个用 Brotli，9 个用 gzip，未压缩的一个没有。压缩倍数从 stripe.com 的 3.6 到 www.theverge.com 的 14.5，中位 7.9。

加起来，这批面板发出 18,739,396 字节的 HTML，线上只有 2,431,758 字节。所以你在浏览器网络面板里看到的那个传输大小，和 Googlebot 上限所针对的那个数字，差着大约八倍，而且文档越大差得越多。

网页源代码里，可见文字只占 1.9%

这批首页里，中位只有 1.9% 的 HTML 字节用在读者能看见的文字上。范围从 figma.com 的 0.2% 到 news.ycombinator.com 的 11.7%。内联 <script> 的内容中位占 21.3%，有五个站超过一半：figma.com 82.5%、www.nytimes.com 77.5%、railway.com 57.6%、vercel.com 56.9%、www.wired.com 56.1%。

这些内联脚本大多是序列化的状态数据 —— 前端框架把刚渲染好的页面重新接管所需要的那份数据。从工程上说它不是浪费。它只是不算内容，而且照样占那 2 MB。至于内联脚本占比小的那些站，剩下的字节是标记、内联样式还是 SVG 路径，这次没有拆开，我们答不了。

这对你的站意味着什么

三条检查，只有第一条是急的。

• 量你最重的那套模板的解压后体积，不是量首页。一条命令：curl -s --compressed URL | wc -c。
• 解压后超过 1.5 MB 左右的页面，先查内联脚本里装的是什么，再动别的。这 27 个站里有五个，它已经是文档的大半。
• 别把网络面板里的传输大小当成 Google 用的那个数。在这批样本上它小了大约八倍。

字节数说明不了正文能不能被读到 —— 那是另一件事，量在 AI 爬虫实际读到了什么 那一篇。同一批首页响应有多快而不是发了多少，见 网站速度实测。要判断先修哪一个，诊断路径从这里开始。

常见问题

你们是怎么测的

2026-08-23 每站一次首页请求，请求头带 Accept-Encoding: gzip, deflate, br，跟随重定向，不执行 JavaScript。线上字节取响应体长度，HTML 字节是按声明的编码解压之后再数。

网页体积影响排名吗

Google 没有把 HTML 体积描述成排名因素，它描述的是抓取上限 —— 这是另一套机制：过了截断点，文档剩下的部分根本不会被送去做收录判断。排名效应我们没测，也推不出来。

2MB 是按十进制还是二进制算

文档只写了 2MB，没定义单位。对本样本里唯一超标的那个站，怎么算都超。要是一个页面正好卡在 2.05 MB，这就有区别了，而我们答不了它往哪边落。

要不要从 gzip 换成 Brotli

能省传输字节，这批样本里三分之二的站已经换了。但它改变不了 Googlebot 上限针对的那个数字，因为那个数字是解压之后才量的。