控制 HTML 文档体积Front-End-Checklist 中基于 Googlebot 爬取上限的页面瘦身指南【免费下载链接】Front-End-Checklist The essential checklist for modern web development, for humans and AI agents项目地址: https://gitcode.com/gh_mirrors/fr/Front-End-Checklist本篇指南围绕 Front-End-Checklist 仓库中的html-sizeSEO 规则展开说明 Googlebot 约 15MB 的 HTML 单文档解析上限如何影响索引完整性与爬取预算并提供从测量、定位到修复的一整套可落地方案。读完本文你将掌握用curl精确测量原始 HTML 体积、识别__NEXT_DATA__等内联 JSON 与内联 SVG 等体积来源以及通过裁剪服务端数据、外置资源、gzip/Brotli 压缩与 HTML 压缩把页面压回安全区间的实战能力。规则背景为什么 HTML 文档体积是一个爬取问题html-size是 Front-End-Checklist 中的一条 SEO 类规则属于seo/technical子分类难度为中级intermediate、优先级为中等medium预估耗时 10 分钟。该规则的核心事实定义在规则主文件 html-size.mdx 中Googlebot 对每个 HTML 文档有约 15MB 的解析上限。超过该阈值的内容会被静默忽略不会被解析或索引。这意味着一个 20MB 的 HTML 页面其尾部的数 MB 内容对 Google 而言不存在。即使页面体积远低于硬性上限臃肿的 HTML 也会拖慢 Googlebot 的单次抓取与解析速度在固定的爬取预算周期内减少被爬取的页面数量。在仓库中这条规则同时以多种形态存在供人机共同使用规则正文packages/content/rules/en/seo/html-size.mdxAgent 技能定义skills/html-size/SKILL.md并在 skills/html-size/references/rule.md 中提供了完整的代码示例与验证方法清单条目README.md 中列为Keep HTML documents under crawl limits检查 HTML 文档体积是否在 Googlebot 爬取上限之内判定标准你的页面处在哪个区间规则给出了一个清晰的体积分级用于指导哪些页面需要调查、哪些已经构成风险原始 HTML 体积压缩前判定100KB 以下优秀Excellent100KB – 2MB可接受Acceptable但应调查体积较大的区块2MB – 5MB需要优化Needs optimisation建议调查5MB 以上严重Critical——存在部分内容无法被索引的风险约 15MB 以上触发 Googlebot 解析硬上限超出内容不会被索引对应到实操口径超过 2MB 的页面需要调查超过 5MB 视为严重问题。常见体积来源五个典型的HTML 发胖原因规则将超大 HTML 的成因归纳为五类并给出了每一类的典型体积贡献成因典型体积贡献内联 Next.js__NEXT_DATA__JSON100KB – 5MB内联 SVG 文件每个 10KB – 500KBBase64 编码的内联图片不固定比二进制大约 33%未压缩的script代码块50KB – 1MB大量工具类造成的内联 CSS50KB – 300KB其中内联 JSON 数据转储是服务端渲染SSR站点最常见的元凶框架把服务端数据序列化后写入 HTML 的script标签供客户端水合hydration使用。数据越多页面越胖而其中大部分数据可能根本没有被首屏渲染使用。如何测量 HTML 的真实体积规则的检查步骤要求测量每个页面的原始 HTML 响应体积压缩前。仓库提供了可直接复制的两条命令# 测量未压缩的 HTML 体积字节数 curl -so /dev/null -w %{size_download}\n https://yoursite.com/page # 携带 Accept-Encoding 请求观察 Googlebot 实际收到的压缩后体积 curl -H Accept-Encoding: gzip, br -so /dev/null -w %{size_download}\n https://yoursite.com/pageSKILL.md 中还给出了带单位换算的常用写法curl -so /dev/null -w %{size_download} https://yoursite.com/page | awk {print $1/1024 KB}两点需要注意必须在压缩前测量原始字节。%{size_download}默认得到的是你收到的字节数若服务器已经开启了 gzip/Brotli需要去掉Accept-Encoding或使用原始响应判断第二条命令则是刻意模拟 Googlebot 的抓取方式观察启用压缩后实际传输的体积。用Content-Length响应头做快速巡检。代码审查阶段可以直接检查响应头中的Content-Length或对渲染后的 HTML 统计字节数先粗筛出超标的 URL再逐页定位。修复方案一裁剪服务端渲染的内联 JSON这是 Next.js 类框架最常见的问题。__NEXT_DATA__标签会把getServerSideProps/getStaticProps返回的全部 props 序列化进 HTML一旦在 props 中塞入了全量数据集页面体积会迅速膨胀。❌ 反面示例一次性内联 10MB 数据!-- Next.js pages router 在 getServerSideProps 中塞入过多数据 -- script id__NEXT_DATA__ typeapplication/json { props: { pageProps: { allProducts: [/* 5,000 个商品 × 每个 2KB 10MB JSON */} ] } } /script✅ 修复只传递页面真正渲染的数据// pages/products/index.tsx // 只传递当前页面可见的 20 个商品 const products await getProducts({ limit: 20, page: 1 }) return { props: { products } } // 后续分页数据通过客户端 API 请求加载原则是只传递页面渲染所需的最小数据集其余数据改为客户端按需请求。更进一步的方案是使用 React Server ComponentsNext.js 13减少客户端水合负载——把不需要交互的渲染留在服务端避免把整棵组件树的数据灌进 HTML对确实需要下发的 JSON检查是否存在单个超过 500KB 的script typeapplication/json或script id__NEXT_DATA__块——规则明确要求对任何超过 500KB 的单一数据块标记问题。修复方案二内联 SVG 外置化把大型 SVG 直接内联进 HTML 会让文档体积快速增长。❌ 反面示例200KB 的 SVG 内联在 HTML 中svg xmlnshttp://www.w3.org/2000/svg viewBox0 0 1000 500 !-- 数千个 path 元素…… -- /svg✅ 修复按用途选择外部加载方式!-- 作为普通图片资源加载无法用 CSS 修改内部样式 -- img src/images/illustration.svg altProduct illustration width500 height250 !-- 或者作为可复用的内联 SVG 图标 sprite适合小图标可复用 -- svg aria-hiddentrueuse href/icons.svg#arrow-right/use/svg判断依据整幅大插图应外置为img资源小尺寸、需要复用且希望被 CSS 控制样式的图标可以用 sprite 方式集中引用。注意外置后需要通过alt或aria-hidden正确处理可访问性语义。修复方案三Base64 图片改走 CDN 引用Base64 编码会让图片体积比二进制约增大 33%且完全无法利用浏览器缓存与 HTTP 缓存。规则的修复建议是将图片交给 CDN 托管在 HTML 中通过 URL 引用这样既减小 HTML 体积又能获得 CDN 的缓存、压缩与就近分发能力。修复方案四开启 gzip/Brotli 文本压缩规则明确强调Googlebot 抓取的是压缩后的响应因此服务端启用压缩可以直接降低爬取成本。这也是该规则在仓库中的首要关联规则 compression.mdxEnable text-based compression性能分类、优先级高所做的事情用 gzip 或 Brotli 压缩 HTML/CSS/JS 等文本资源通过Content-Encoding: gzip或br响应头交付。Brotli 在现代浏览器中压缩率更优。需要注意的是压缩只减少传输体积并不会消除超大数据集带来的解析与执行成本——正如 compression 规则本身所强调的压缩有助于网络成本但不会消除超大 bundle 的解析和执行成本。因此压缩应与数据裁剪配合使用而不是互相替代。修复方案五生产环境压缩 HTML 输出移除 HTML 中的空白字符与注释minify是规则的第六个修复动作。通常由构建工具链在发布阶段完成例如 Next.js 生产构建默认会对 HTML 输出做一定处理对于自建 SSR 管线可在服务端对渲染结果做空白与注释剥离后输出。代码审查清单规则给出了执行审查时的具体检查点检查响应Content-Length头或直接测量原始 HTML 字节数检查script typeapplication/json或script id__NEXT_DATA__数据块统计其字节数任何单个块超过 500KB 即标记问题检查body中是否存在应外置的svg内联元素确认 HTML 是否以 gzip 或 Brotli 编码交付。例外与信号冲突处理规则同时定义了审查时的例外情况避免误报登出页、工具页、登录页、账号页或站内搜索页等不参与排名的页面可以有意识地使用不同的爬取/索引信号迁移期间的临时状态会产生噪音信号应针对线上生产的 URL 模式做标记而不是针对一次性过渡产物当重定向、canonical、robots 指令或可索引性信号互相冲突时优先修复最强的最终信号而不是把每个下游症状都当作独立阻塞项上报。验证与后续动作部署修复后按以下步骤验证自动化检查检查渲染后的 HTML 与 HTTP 头确认预期的可抓取性信号体积、压缩编码已经满足工具验证用 Google Search Console 或等价工具测试受影响的 URL重新抓取部署后对代表性页面集合发起重新爬取确认体积指标回落人工复核确认改动没有引入 canonical、robots 或结构化数据信号之间的冲突。与本规则一起使用的关联规则在 html-size.mdx 的relatedRules中该规则与以下条目成组出现适合在 SEO 技术审计中一并排查compressionpackages/content/rules/en/performance/compression.mdxgzip/Brotli 压缩是缓解大 HTML 传输体积的首要手段llm-parsability带有注入数据噪音的超大 HTML 同样会损害 LLM 内容提取质量pdf-size与broken-links同属seo/technical区域常被同时评审。综合来看html-size规则的实际价值不在于把体积压到多小而在于确保 Googlebot 在硬性解析上限内完整读取页面内容、为站内更多页面保留爬取预算并顺带改善 TTFB 与 LCP 等 Core Web Vitals 指标——一次测量即可同时覆盖索引完整性、爬取效率与用户体验三个维度。【免费下载链接】Front-End-Checklist The essential checklist for modern web development, for humans and AI agents项目地址: https://gitcode.com/gh_mirrors/fr/Front-End-Checklist创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
控制 HTML 文档体积：Front-End-Checklist 中基于 Googlebot 爬取上限的页面瘦身指南
控制 HTML 文档体积Front-End-Checklist 中基于 Googlebot 爬取上限的页面瘦身指南【免费下载链接】Front-End-Checklist The essential checklist for modern web development, for humans and AI agents项目地址: https://gitcode.com/gh_mirrors/fr/Front-End-Checklist本篇指南围绕 Front-End-Checklist 仓库中的html-sizeSEO 规则展开说明 Googlebot 约 15MB 的 HTML 单文档解析上限如何影响索引完整性与爬取预算并提供从测量、定位到修复的一整套可落地方案。读完本文你将掌握用curl精确测量原始 HTML 体积、识别__NEXT_DATA__等内联 JSON 与内联 SVG 等体积来源以及通过裁剪服务端数据、外置资源、gzip/Brotli 压缩与 HTML 压缩把页面压回安全区间的实战能力。规则背景为什么 HTML 文档体积是一个爬取问题html-size是 Front-End-Checklist 中的一条 SEO 类规则属于seo/technical子分类难度为中级intermediate、优先级为中等medium预估耗时 10 分钟。该规则的核心事实定义在规则主文件 html-size.mdx 中Googlebot 对每个 HTML 文档有约 15MB 的解析上限。超过该阈值的内容会被静默忽略不会被解析或索引。这意味着一个 20MB 的 HTML 页面其尾部的数 MB 内容对 Google 而言不存在。即使页面体积远低于硬性上限臃肿的 HTML 也会拖慢 Googlebot 的单次抓取与解析速度在固定的爬取预算周期内减少被爬取的页面数量。在仓库中这条规则同时以多种形态存在供人机共同使用规则正文packages/content/rules/en/seo/html-size.mdxAgent 技能定义skills/html-size/SKILL.md并在 skills/html-size/references/rule.md 中提供了完整的代码示例与验证方法清单条目README.md 中列为Keep HTML documents under crawl limits检查 HTML 文档体积是否在 Googlebot 爬取上限之内判定标准你的页面处在哪个区间规则给出了一个清晰的体积分级用于指导哪些页面需要调查、哪些已经构成风险原始 HTML 体积压缩前判定100KB 以下优秀Excellent100KB – 2MB可接受Acceptable但应调查体积较大的区块2MB – 5MB需要优化Needs optimisation建议调查5MB 以上严重Critical——存在部分内容无法被索引的风险约 15MB 以上触发 Googlebot 解析硬上限超出内容不会被索引对应到实操口径超过 2MB 的页面需要调查超过 5MB 视为严重问题。常见体积来源五个典型的HTML 发胖原因规则将超大 HTML 的成因归纳为五类并给出了每一类的典型体积贡献成因典型体积贡献内联 Next.js__NEXT_DATA__JSON100KB – 5MB内联 SVG 文件每个 10KB – 500KBBase64 编码的内联图片不固定比二进制大约 33%未压缩的script代码块50KB – 1MB大量工具类造成的内联 CSS50KB – 300KB其中内联 JSON 数据转储是服务端渲染SSR站点最常见的元凶框架把服务端数据序列化后写入 HTML 的script标签供客户端水合hydration使用。数据越多页面越胖而其中大部分数据可能根本没有被首屏渲染使用。如何测量 HTML 的真实体积规则的检查步骤要求测量每个页面的原始 HTML 响应体积压缩前。仓库提供了可直接复制的两条命令# 测量未压缩的 HTML 体积字节数 curl -so /dev/null -w %{size_download}\n https://yoursite.com/page # 携带 Accept-Encoding 请求观察 Googlebot 实际收到的压缩后体积 curl -H Accept-Encoding: gzip, br -so /dev/null -w %{size_download}\n https://yoursite.com/pageSKILL.md 中还给出了带单位换算的常用写法curl -so /dev/null -w %{size_download} https://yoursite.com/page | awk {print $1/1024 KB}两点需要注意必须在压缩前测量原始字节。%{size_download}默认得到的是你收到的字节数若服务器已经开启了 gzip/Brotli需要去掉Accept-Encoding或使用原始响应判断第二条命令则是刻意模拟 Googlebot 的抓取方式观察启用压缩后实际传输的体积。用Content-Length响应头做快速巡检。代码审查阶段可以直接检查响应头中的Content-Length或对渲染后的 HTML 统计字节数先粗筛出超标的 URL再逐页定位。修复方案一裁剪服务端渲染的内联 JSON这是 Next.js 类框架最常见的问题。__NEXT_DATA__标签会把getServerSideProps/getStaticProps返回的全部 props 序列化进 HTML一旦在 props 中塞入了全量数据集页面体积会迅速膨胀。❌ 反面示例一次性内联 10MB 数据!-- Next.js pages router 在 getServerSideProps 中塞入过多数据 -- script id__NEXT_DATA__ typeapplication/json { props: { pageProps: { allProducts: [/* 5,000 个商品 × 每个 2KB 10MB JSON */} ] } } /script✅ 修复只传递页面真正渲染的数据// pages/products/index.tsx // 只传递当前页面可见的 20 个商品 const products await getProducts({ limit: 20, page: 1 }) return { props: { products } } // 后续分页数据通过客户端 API 请求加载原则是只传递页面渲染所需的最小数据集其余数据改为客户端按需请求。更进一步的方案是使用 React Server ComponentsNext.js 13减少客户端水合负载——把不需要交互的渲染留在服务端避免把整棵组件树的数据灌进 HTML对确实需要下发的 JSON检查是否存在单个超过 500KB 的script typeapplication/json或script id__NEXT_DATA__块——规则明确要求对任何超过 500KB 的单一数据块标记问题。修复方案二内联 SVG 外置化把大型 SVG 直接内联进 HTML 会让文档体积快速增长。❌ 反面示例200KB 的 SVG 内联在 HTML 中svg xmlnshttp://www.w3.org/2000/svg viewBox0 0 1000 500 !-- 数千个 path 元素…… -- /svg✅ 修复按用途选择外部加载方式!-- 作为普通图片资源加载无法用 CSS 修改内部样式 -- img src/images/illustration.svg altProduct illustration width500 height250 !-- 或者作为可复用的内联 SVG 图标 sprite适合小图标可复用 -- svg aria-hiddentrueuse href/icons.svg#arrow-right/use/svg判断依据整幅大插图应外置为img资源小尺寸、需要复用且希望被 CSS 控制样式的图标可以用 sprite 方式集中引用。注意外置后需要通过alt或aria-hidden正确处理可访问性语义。修复方案三Base64 图片改走 CDN 引用Base64 编码会让图片体积比二进制约增大 33%且完全无法利用浏览器缓存与 HTTP 缓存。规则的修复建议是将图片交给 CDN 托管在 HTML 中通过 URL 引用这样既减小 HTML 体积又能获得 CDN 的缓存、压缩与就近分发能力。修复方案四开启 gzip/Brotli 文本压缩规则明确强调Googlebot 抓取的是压缩后的响应因此服务端启用压缩可以直接降低爬取成本。这也是该规则在仓库中的首要关联规则 compression.mdxEnable text-based compression性能分类、优先级高所做的事情用 gzip 或 Brotli 压缩 HTML/CSS/JS 等文本资源通过Content-Encoding: gzip或br响应头交付。Brotli 在现代浏览器中压缩率更优。需要注意的是压缩只减少传输体积并不会消除超大数据集带来的解析与执行成本——正如 compression 规则本身所强调的压缩有助于网络成本但不会消除超大 bundle 的解析和执行成本。因此压缩应与数据裁剪配合使用而不是互相替代。修复方案五生产环境压缩 HTML 输出移除 HTML 中的空白字符与注释minify是规则的第六个修复动作。通常由构建工具链在发布阶段完成例如 Next.js 生产构建默认会对 HTML 输出做一定处理对于自建 SSR 管线可在服务端对渲染结果做空白与注释剥离后输出。代码审查清单规则给出了执行审查时的具体检查点检查响应Content-Length头或直接测量原始 HTML 字节数检查script typeapplication/json或script id__NEXT_DATA__数据块统计其字节数任何单个块超过 500KB 即标记问题检查body中是否存在应外置的svg内联元素确认 HTML 是否以 gzip 或 Brotli 编码交付。例外与信号冲突处理规则同时定义了审查时的例外情况避免误报登出页、工具页、登录页、账号页或站内搜索页等不参与排名的页面可以有意识地使用不同的爬取/索引信号迁移期间的临时状态会产生噪音信号应针对线上生产的 URL 模式做标记而不是针对一次性过渡产物当重定向、canonical、robots 指令或可索引性信号互相冲突时优先修复最强的最终信号而不是把每个下游症状都当作独立阻塞项上报。验证与后续动作部署修复后按以下步骤验证自动化检查检查渲染后的 HTML 与 HTTP 头确认预期的可抓取性信号体积、压缩编码已经满足工具验证用 Google Search Console 或等价工具测试受影响的 URL重新抓取部署后对代表性页面集合发起重新爬取确认体积指标回落人工复核确认改动没有引入 canonical、robots 或结构化数据信号之间的冲突。与本规则一起使用的关联规则在 html-size.mdx 的relatedRules中该规则与以下条目成组出现适合在 SEO 技术审计中一并排查compressionpackages/content/rules/en/performance/compression.mdxgzip/Brotli 压缩是缓解大 HTML 传输体积的首要手段llm-parsability带有注入数据噪音的超大 HTML 同样会损害 LLM 内容提取质量pdf-size与broken-links同属seo/technical区域常被同时评审。综合来看html-size规则的实际价值不在于把体积压到多小而在于确保 Googlebot 在硬性解析上限内完整读取页面内容、为站内更多页面保留爬取预算并顺带改善 TTFB 与 LCP 等 Core Web Vitals 指标——一次测量即可同时覆盖索引完整性、爬取效率与用户体验三个维度。【免费下载链接】Front-End-Checklist The essential checklist for modern web development, for humans and AI agents项目地址: https://gitcode.com/gh_mirrors/fr/Front-End-Checklist创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
