---
title: '网站在变胖吗?页面体积、HTML 大小与 Googlebot 抓取上限'
video_id: kype1JQbrks
url: https://youtu.be/kype1JQbrks
title_en: "Are websites getting “fat”? Page weight, HTML size & Googlebot limits explained"
channel: Google Search Central
published: 2026-03-30
duration: "32:13"
topics: [页面SEO与技术基建, 内容策略]
noted: 2026-07-05
value: A
views: '7115'
---
[](https://youtu.be/kype1JQbrks)
> Google Search Central · 32:13 · 发布 2026-03-30 · 7115次观看(截至抓取) · [观看原视频](https://youtu.be/kype1JQbrks)
## 主旨
Google 搜索团队的 Gary 与 Martin 拆解"网页是不是越来越大"这个模糊问题:page weight 没有统一定义、传输层与存储层不是一回事、Googlebot 有 15MB 的 per-URL 抓取上限,并延伸到结构化数据膨胀与元数据分离的取舍。
## 核心论点
1. **"网站在变胖吗"是伪问题**——"胖"只在单页尺度上有意义,整站尺度上无意义,而且"fat"这个词本身就没定义清楚。([[#1-为什么网站在变胖吗是个伪问题-0143|→ 详解1]])
2. **page weight 没有唯一定义**——Web Almanac 口径下移动端首页中位体积十年涨了约三倍(845KB→2.3MB),但不同人心里的"页面大小"根本不是同一个数。([[#2-page-weight-没有唯一定义以及-web-almanac-的三倍增长-0548|→ 详解2]])
3. **传输层字节 ≠ 落盘字节**——压缩让"下载了多少"分裂成过线体积和解压后体积,关心传输时间还是关心手机存储,答案不同。([[#3-传输层-vs-存储层压缩把下载量劈成两个数-1024|→ 详解3]])
4. **Googlebot 默认每个 URL 只抓 15MB 原始字节就停**——这是 per-URL 的,页面引用的每个资源各有自己的 15MB 额度。([[#4-googlebot-的-15mb-per-url-抓取上限-0829|→ 详解4]])
5. **HTML 本身就能很大**——纯文本的 WHATWG HTML 规范单页版就有 14MB;把图片 inline 成 base64 更能把 HTML 撑到 50MB。([[#5-html-自身能有多大14mb-的规范页与-inline-图片-1238|→ 详解5]])
6. **"坏体积"要看内容与标记比**——同样是大体积,满是有用内容的 15MB 未必比只有少量内容、大量标记的 5MB 更糟。([[#6-坏体积取决于内容与标记比-1817|→ 详解6]])
7. **结构化数据是纯为机器、不为用户的膨胀**——堆得越多页面越大,对站点可能带来额外流量,对用户价值存疑。([[#7-结构化数据纯为机器的膨胀两面性-1919|→ 详解7]])
8. **"给可信客户端单独喂元数据"是理想但被 spam 拦住**——IETF 讨论过分离机器可读内容,但滥用者会把它变成新的 spam 入口。([[#8-把元数据分给可信客户端理想设想与-spam-现实-2029|→ 详解8]])
9. **Mobile-first 分离 URL 的历史教训:内容不对等会掉排名**——移动版和桌面版用不同 URL 时,内容/链接/元数据常常对不齐。([[#9-mobile-first-分离-url-的对等性教训-2330|→ 详解9]])
10. **确实在变大、也确实仍然重要**——传输字节的增长跑赢了传输速度的增长;更快的站有更好的留存与转化,减重值得做。([[#10-到底重不重要趋势缓解手段与图片优化-2546|→ 详解10]])
## 知识点详解
### 1. 为什么"网站在变胖吗"是个伪问题 [01:43](https://youtu.be/kype1JQbrks?t=103)
Gary 一上来就说这个问题"甚至不成立"。原因是"胖/大"这个属性只在**单个页面**的语境下有意义,放到**整个网站**的语境下就失去意义——你没法给一个由无数页面组成的站点定义一个单一的"体积"。
节目还先停下来纠结了"fat"这个用词。Martin 承认他故意用"fat"是因为 heavy、big、large 这些词他都拿不准该用哪个,而且在 Bluesky 上一问,发现大家对"page size"的理解各不相同。
所以真正能讨论的问题得先改写成"**网页**是不是在变大",范围收到单页、并且把"大"落到某个可度量的定义上,讨论才站得住。这一节奠定了全片的方法论:先厘清术语和度量单位,再谈趋势。
### 2. page weight 没有唯一定义,以及 Web Almanac 的三倍增长 [05:48](https://youtu.be/kype1JQbrks?t=348)
Martin 引用 2025 Web Almanac:2015 年移动端首页体积中位数是 845KB,到 2025 年 7 月同一中位数变成 2.3MB,约三倍增长(用软盘打比方,从半张多涨到差不多两张 1.44MB 软盘)。
关键在于 Web Almanac 对 page weight 的定义是"用户为查看某页而必须下载的数据总量",这在 Martin 看来应当**包含图片等资源**;但这份数据其实只统计了首页父 HTML,不含子资源,所以 Gary 一度对定义边界存疑。
结论不是记住那两个数字,而是记住:当你说"这页很大"时,你和对方脑子里的度量口径可能完全不同。Almanac 的定义对它自己的用途是自洽的,只是**不存在一个放之四海皆准的"页面大小"**。
### 3. 传输层 vs 存储层:压缩把"下载量"劈成两个数 [10:24](https://youtu.be/kype1JQbrks?t=624)
一个常见困惑:有人说"这网站往我硬盘下了 10MB",但如果看**实际过线**的字节,可能只有 5、6MB——因为数据在网络层被压缩,到客户端再解压。
于是同一个页面有了两个不同的"大小":过线体积决定**传输时间**(网慢的人关心这个),解压后体积决定**占用的设备存储**(手机存储紧张的人关心这个)。压缩能缩短传输,但存储该占多少还占多少。
这解释了为什么大家吵不到一起:他们各自盯着不同的层。做技术优化时要分清你在优化哪个数字——省流量和省存储不是一回事。
### 4. Googlebot 的 15MB per-URL 抓取上限 [08:29](https://youtu.be/kype1JQbrks?t=509)
从搜索引擎视角,"页面大小"有个硬性口径:Google 文档里写明,Googlebot 默认抓取一个 URL 的**前 15MB 原始字节**,超过就停。
重点是这个额度是 **per-URL** 的:你 HTML 里引用的每个资源(脚本、样式、图片等)各自另有 15MB 额度,不是整页共享一个 15MB。所以从抓取角度看,真正危险的是**单个文件**超过 15MB 导致尾部内容被截断。
Gary 认为这个口径"从搜索角度比从用户角度更讲得通"——用户根本不关心 15MB 这种数字,他们只想知道"我要下载多少东西"。参见 页面体积的多重定义:抓取口径只是众多口径之一。
### 5. HTML 自身能有多大:14MB 的规范页与 inline 图片 [12:38](https://youtu.be/kype1JQbrks?t=758)
体积不只来自图片和媒体,**HTML 本体**就能很大。WHATWG 的 HTML 规范单页版是纯文本、几乎无图无样式,却有 14MB 之多;Martin 实测点开单页版加载花了约 45 秒,reader mode 还直接把标签页搞崩了。
更极端的是有人把图片 **inline** 进 HTML:把图片编码成一长串字符(base64)直接塞进 HTML,为的是省掉一次网络请求,结果 HTML 文件能膨胀到 50MB。
这提示:审计页面体积时不能只盯图片资源,要单独看**过线的 HTML 本身**有多大,以及里面有没有被 inline 的巨型资源。
### 6. "坏体积"取决于内容与标记比 [18:17](https://youtu.be/kype1JQbrks?t=1097)
体积大不等于坏。那份 15MB 的 HTML 规范,几乎全是有用内容、极少标记开销——"最少标记包住最多内容"。反过来,一个 5MB 却只有很少内容、大量标记的页面,可能才是更浪费的那个。
于是问题变成**内容与标记比**(content-to-markup ratio)。但这个比值也不好一刀切:很多标记是给第三方工具、监管合规或授权用途的元数据,对最终用户不可见却又不得不有——很难说带这类元数据的页面就比"体积几乎全是内容"的页面更糟。
实操上,评判一个页面"重得值不值"要看**重在哪里**:重在真正交付给用户的内容上,和重在纯开销的标记上,是两码事。
### 7. 结构化数据:纯为机器的膨胀,两面性 [19:19](https://youtu.be/kype1JQbrks?t=1159)
Gary 坦言他对结构化数据"历来有点意见":早年 Sergey Brin 认为机器应能从文本本身推断一切、站长不必额外提供什么;而结构化数据的定位恰恰相反——它**明确是给机器、不是给用户**看的。
代价是膨胀:Google 支持的结构化数据类型极多,光把文档链接列全就能填满一页;越往页面上堆,用户永远看不见的字节就越多。
价值判断是两面的:对**站点**可能是好事(结构化数据能通过搜索引擎的富展示带来额外流量),但对**用户**是纯负担。所以要不要堆、堆多少,是一道站点收益 vs 用户体验的取舍题,而非越多越好。参见 [[GEO]]:为机器可读性投入的这类标记,正是被 AI 引用的信号来源之一。
### 8. 把元数据分给可信客户端:理想设想与 spam 现实 [20:29](https://youtu.be/kype1JQbrks?t=1229)
顺着"机器要的东西 vs 用户要的东西"往下,IETF 讨论过一个方向:**把元数据和用户可见内容分离**。设想是给受信任的 HTTP 客户端开一个 API 端点,或用 `?output=JSON-LD` 之类参数,经加密认证后单独返回纯机器可读版本(甚至二进制),普通用户则拿干净的内容版。
对 LLM 尤其合理:处理 HTML 规范时,给人看的排版文字对模型其实无关紧要,它的解析方式和人完全不同。
但这是**乌托邦**:互联网上并非人人守规矩。Google 每天要拦下数以百亿计的 spam URL,一旦开出"喂给机器"的专用通道,几乎必然被滥用、放大喂给搜索引擎和 LLM 的 spam。理想的分离机制被 spam 现实卡住了。
### 9. Mobile-first 分离 URL 的对等性教训 [23:30](https://youtu.be/kype1JQbrks?t=1410)
"给不同消费者不同表示"的思路(早年 hypermedia 那套)听着美好,但 Google 在推 mobile-first indexing 时踩过现实的坑。
当站点把移动版和桌面版放在**不同 URL**(如 `/m/content` 与 `/content`)时,大量页面被观测到**没有内容对等**:内容缺失(最糟,会丢掉桌面版原本的排名)、链接缺失、导航不同、元数据/hreflang/link 元素缺失。Google 为此还做过外联整改活动。
教训直接迁移到"元数据分离"的设想上:一旦同一份内容存在多个面向不同消费者的表示,**保持它们对等**本身就极难,连移动/桌面这种简单场景都会大面积对不齐。
### 10. 到底重不重要:趋势、缓解手段与图片优化 [25:46](https://youtu.be/kype1JQbrks?t=1546)
改写后的问题"网页在变大吗"答案是"是";但"重不重要"取决于语境。慢网络、按流量计费(Martin 举南极科考船上 100MB 花约 20 美元)、手机存储紧张的人都会被体积伤到。而且 Gary 的假设是:近年**传输字节的增长已跑赢移动传输速度的增长**。
缓解手段有:缓存(首次全额命中,重访不必重下)、传输层压缩(省传输不省存储)、lazy loading(只加载滚动到的重内容)。但这些只能减轻痛感,不能免除。
至于该不该主动减重([27:54](https://youtu.be/kype1JQbrks?t=1674)),两人认为该——有研究显示更快的站有更好的留存和转化,而速度部分取决于体积;存储门槛也会排除掉一部分人。落到实处,图片是最大抓手:Google 内部有 linter 拦截 >1MB 的图片,且压缩版与低压缩版肉眼常难分辨——"又不是每张图都是艺术品"。
## 可执行步骤
- [ ] 谈"页面大小"前先明确口径:是过线字节、落盘字节,还是 Googlebot 抓取字节,别混着聊。
- [ ] 用 Web Almanac / HTTP Archive 的 page weight 定义给自己的关键页做一次体积基线,对照 2.3MB 中位数看自己站在哪。
- [ ] 单独测**过线的 HTML 本体**大小,确认没有单个 HTML/资源逼近 15MB(Googlebot 会在此截断)。
- [ ] 排查是否有被 inline 成 base64 的巨型图片撑大 HTML,能外链的改回外链。
- [ ] 审视结构化数据用量:按"这条能否带来富展示流量"取舍,而非无脑堆满。
- [ ] 给图片建一条硬规则(如单图 ≤1MB),用压缩版做 A/B 肉眼比对再决定是否需要例外。
- [ ] 若被迫做移动/桌面分离 URL,逐项核对内容、链接、hreflang、元数据的对等性。
## 关联
- 印证:[[GEO]] 强调为 AI/LLM 生成式答案做内容与信任信号优化——本片的结构化数据与"给可信客户端喂元数据"讨论,正是这类机器可读信号在页面层的具体形态与其膨胀代价。
## 一手来源与延伸
- 2025 Web Almanac(HTTP Archive 年度网页现状报告,Page Weight 章节是本片 845KB→2.3MB 数据来源):https://almanac.httparchive.org/
- WHATWG HTML Living Standard 单页版(本片"14MB 纯 HTML"实例):https://html.spec.whatwg.org/
## 术语
- page weight / 页面重量(用户为查看某页而必须下载的数据总量,Web Almanac 口径)
- over-the-wire / 过线体积(经压缩后实际在网络上传输的字节数)
- content-to-markup ratio / 内容与标记比(页面里有用内容相对于标记开销的比例)
- structured data / 结构化数据(专为机器、不为用户呈现的页面元数据,如 JSON-LD)
- mobile-first indexing / 移动优先索引(Google 以移动版页面为主进行抓取和排名的机制)
- lazy loading / 懒加载(仅在用户滚动到时才加载对应重内容的技术)
## 金句
> "It does not matter in the context of a website if it's fat... In the context of a single page, yes." → "胖不胖"要在单页尺度问才有意义——先校准度量单位,再谈趋势。
> "Minimal markup around maximum content." → 判断页面"重得值不值"的黄金标准:标记最少、内容最多。
## 立场与利益
这是 Google 搜索团队官方播客 Search off the Record,两位主讲是 Google 员工(Gary Illyes、Martin Splitt),内容无第三方赞助或课程推销。需要留意的是**立场偏向**:15MB 抓取上限、结构化数据能带来流量等说法来自 Google 自身文档与产品视角;结构化数据"对站点是好事"这一半是搜索引擎生态的共识但也服务于 Google 的抓取需求。Web Almanac 数据来自独立的 HTTP Archive 项目,相对中立。
## 价值定位
- 适合谁:自己动手建站、想搞清"页面体积到底怎么定义、会不会影响被 Google 抓取和排名"的 solo builder / 技术型 SEO。
- 解决什么:把"page weight"这个被滥用的词拆成过线/落盘/抓取三个口径,并给出 Googlebot 15MB per-URL 这条硬约束——想避免内容被截断、想判断结构化数据堆多少划算的人能直接用。
- 认知 vs 实操:七成是认知层(厘清度量、理解取舍),三成落到实操(15MB 上限、图片 ≤1MB、分离 URL 保对等)。它不是一份优化清单,而是让你在做体积决策前先想清楚"我在优化哪个数字、为谁优化"。
- 与 [[GEO]] 相关笔记重叠于"为机器可读性做的投入",但本片独有的是从**页面体积与抓取上限**这个技术基建角度,量化了这类机器元数据的膨胀代价。
## 自检问题
1. Googlebot 默认的 15MB 抓取上限是针对整个页面还是每个 URL?这对你如何理解"页面过大"有什么影响?
**答案**:是 per-URL 的——HTML 本体和它引用的每个资源各自另有 15MB 额度,所以真正的风险是单个文件超过 15MB 被截断,而非整页字节总和。见详解4 [08:29](https://youtu.be/kype1JQbrks?t=509)
2. 为什么"这个网站往我硬盘下了 10MB"和"实际只传了 5MB"可以同时成立?
**答案**:压缩让传输层和存储层分成两个数——过线体积(经压缩,决定传输时间)和解压后落盘体积(决定占用存储)不是一回事。见详解3 [10:24](https://youtu.be/kype1JQbrks?t=624)
3. 同样体积下,为什么 15MB 的页面未必比 5MB 的页面更"坏"?
**答案**:要看内容与标记比——15MB 若几乎全是有用内容("最少标记包最多内容")就不算坏,5MB 若大部分是标记开销反而更浪费;何况有些标记是合规/第三方所需的元数据。见详解6 [18:17](https://youtu.be/kype1JQbrks?t=1097)
4. "给可信客户端单独返回机器可读元数据"这个设想为什么难以落地?
**答案**:一是 spam——开出喂机器的专用通道几乎必然被滥用(Google 每天拦数百亿 spam URL);二是对等性极难维护,mobile-first 时代分离 URL 就大面积出现内容/链接/元数据对不齐。见详解8、9 [20:29](https://youtu.be/kype1JQbrks?t=1229)
5. 两人对"网页越来越大到底要不要管"的最终结论是什么,依据是什么?
**答案**:该管——传输字节的增长跑赢了移动传输速度的增长,慢网/计费/存储会伤到部分用户;且更快的站有更好留存与转化,速度部分取决于体积,图片优化是最大抓手。见详解10 [25:46](https://youtu.be/kype1JQbrks?t=1546)