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