Front-End-Checklist 实战将 HTML 文档控制在爬虫抓取限制以内html-size 规则【免费下载链接】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-size规则展开讲解如何将页面 HTML 文档控制在 Googlebot 的爬取解析限制约 15MB以内避免页面尾部内容被搜索引擎静默忽略。你将掌握大体积 HTML 的成因分析、curl实测方法、目标区间判断以及针对内联 JSON、内联 SVG、未压缩脚本等典型问题的修复套路并了解该规则与压缩compression、LLM 可解析性llm-parsability等关联规则的协同关系。该规则定位为 SEO 类category:seo、技术子类subcategory:technical优先级为 medium、难度为 intermediate、预估耗时 10 分钟。规则以 SKILL 形式沉淀在仓库中同时存在于 skills/html-size/SKILL.md面向 Agent 的执行指令与 references/rule.md完整技术细节两份文件中并作为内容资产收录于 packages/content/rules/en/seo/html-size.mdx在项目 README.md 的检查清单中同样占有一席。规则核心Googlebot 的 15MB 解析上限硬性解析限制规则的事实基础来自 Google 官方爬取文档Googlebot 对单个 HTML 文档的解析上限约为 15MB超出该阈值的内容会被静默忽略既不解析也不会进入索引。也就是说即使页面其余部分渲染正常位于 15MB 之后的正文、结构化数据或链接都可能看不见。即使远低于这个硬上限过大的 HTML 同样有害Googlebot 抓取和解析大型页面需要更长时间会消耗更多爬取预算crawl budget导致同一周期内可抓取的页面数量减少。对于大型电商站点、或把大量数据集服务端渲染进 HTML 的页面这一影响尤其明显。为什么重要Why It Matters原文档从三个维度给出影响索引完整性Index completeness超出 Googlebot 解析上限之后的内容不会被索引等于页面尾部内容对搜索隐身爬取预算Crawl budget大页面抓取与解析更慢留给其他页面的资源变少站点整体收录速度下降Core Web Vitals大体积 HTML 会延迟首字节时间TTFB与最大内容绘制LCP直接影响用户体验与核心指标。适用场景依据 SKILL.md 中的aiContext定义该规则适用于以下三类场景审计页面权重page weight以优化爬取效率排查某些页面内容没有出现在 Google 索引中的问题审查服务端渲染页面中内嵌大体积 JSON 载荷的 HTML。大体积 HTML 的常见成因与典型体量原文档给出了一张成因对照表是快速定位问题的重要依据成因典型体积贡献内联 Next.js__NEXT_DATA__JSON100KB–5MB内联 SVG 文件每个 10KB–500KBBase64 编码图片视情况而定比二进制大 33%未压缩的script块50KB–1MB大量工具类utility classes的内联 CSS50KB–300KB值得注意两点Base64 编码会让图片体积比原始二进制增加约 33%且浏览器仍需解码而大量工具类内联 CSS通常来自未开启提取与按需裁剪的 CSS 框架产物。诊断思路是先测量总量再按上表拆分各来源占比找到主导项。实战修复两类典型反模式与正确做法原文档提供了两组可直接对照的反模式 → 修复示例。场景一内联巨型 JSON 载荷Next.js__NEXT_DATA__❌避免——在getServerSideProps中塞入过多数据导致__NEXT_DATA__脚本内嵌数 MB JSON!-- Next.js pages router with too much data in getServerSideProps -- script id__NEXT_DATA__ typeapplication/json { props: { pageProps: { allProducts: [/* 5,000 products × 2KB each 10MB of JSON */] } } } /script✅修复——只把当前页面真正渲染的数据传给前端其余数据改由客户端按需请求// pages/products/index.tsx export async function getStaticProps() { // 只传递当前页面可见的 20 个商品 const products await getProducts({ limit: 20, page: 1 }) return { props: { products } } // 其余页面的数据通过客户端 API 调用按需加载 }依据 SKILL.md 的修复指引处理内联 JSON 还有两个方向一是同时收紧getServerSideProps/getStaticProps传递的数据量只传页面渲染所需二是 Next.js 13 项目可改用 React Server ComponentsRSC把数据保留在服务端避免随 hydration 载荷下发到客户端。场景二本应外置的内联 SVG❌避免——把体积达数百 KB 的 SVG 直接内联进 HTML!-- 200KB SVG inlined directly in HTML -- svg xmlnshttp://www.w3.org/2000/svg viewBox0 0 1000 500 !-- thousands of path elements... -- /svg✅修复——按用途选择外置方案!-- 作为图片加载无法用 CSS 设置样式 -- img src/images/illustration.svg altProduct illustration width500 height250 !-- 或者作为内联 SVG 雪碧图承载图标体积小、可复用 -- svg aria-hiddentrueuse href/icons.svg#arrow-right/use/svg原则是装饰性大图用img外链可复用的图标集合收敛为 SVG sprite 通过use引用既能复用又可缓存且不膨胀 HTML 本体。如何测量 HTML 大小命令行实测原文档给出了两条curl命令分别测未压缩原始大小与Googlebot 实际接收到的压缩后大小# 测量未压缩的 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/page第一条命令得到的是服务端返回的原始字节数未压缩用于判断文档本身是否超限第二条模拟 Googlebot 发送Accept-Encoding: gzip, br看到的是开启压缩后传输层实际字节数——这解释了为什么压缩是缓解传输开销的直接手段。SKILL.md 提供了带单位换算的变体可直接输出 KB 值curl -so /dev/null -w %{size_download} https://yoursite.com/page | awk {print $1/1024 KB}目标区间区间结论100KB 以下优秀Excellent100KB–2MB可接受但需排查大块区域2MB–5MB需要优化5MB 以上严重存在部分索引缺失风险代码审查要点在 SKILL.md 的codeReview中明确了审查动作检查响应的Content-Length头或直接统计原始 HTML 字节数定位script typeapplication/json或script id__NEXT_DATA__块并统计其字节数任何单块超过 500KB 都应标记在 body HTML 中查找svg元素判断是否为应外置的内联 SVG最后确认 HTML 是否以 gzip 或 Brotli 编码返回。六步修复清单综合原文档与 SKILL.md 的fix提示形成可操作的完整修复流程测量用上文curl命令测出每页原始 HTML 大小处理内联 JSONNext.js__NEXT_DATA__常见减少传给getServerSideProps/getStaticProps的数据只传页面渲染所需Next.js 13 改用 React Server Components 避免客户端 hydration 载荷处理内联 SVG迁移到外部文件用img或use加载处理 Base64 图片改为将图片交由 CDN 托管HTML 中只引用 URL开启 gzip/Brotli 压缩Googlebot 会请求压缩后的响应传输体积大幅下降生产环境压缩 HTML 输出去除空白与注释减小原始字节。压缩是缓解而非根治与 compression 规则的协同html-size 规则的relatedRules元数据见 packages/content/rules/en/seo/html-size.mdx将 compression 列为第一关联项理由是Gzip/Brotli 压缩是大体积 HTML 传输开销的主要缓解手段。文本类资源HTML、CSS、JS高度冗余压缩率通常可达 70% 以上。compression 规则performance/assets 类优先级 high给出的服务器配置示例可直接落地# 启用 Gzip 压缩 gzip on; gzip_types text/plain text/css application/javascript application/json image/svgxml; gzip_min_length 1000; # 启用 Brotli需安装对应模块 brotli on; brotli_types text/plain text/css application/javascript application/json image/svgxml;Node.js/Express 场景则可用compression中间件一行开启app.use(compression())。但需要强调压缩规则的边界压缩只解决网络传输侧的开销并不会移除客户端解析与执行超大 bundle 的成本——这正好呼应 html-size 规则控制原始文档体积的必要性压缩后传输再小解析上限按原始 HTML 计算根源仍是把文档本身做小。大 HTML 对 LLM 可解析性的影响html-size 规则的第二个关联项是 llm-parsabilitySEO/content 类优先级 medium原文档给出的关联理由是充满噪声注入数据的超大 HTML 同样损害 LLM 内容抽取。随着 AI 概览AI Overviews与各类答案引擎直接从页面 HTML 抽取内容并引用巨型 JSON 数据块这类注入噪声会稀释正文信号的密度使 LLM 难以准确定位语义段落。因此控制 HTML 体积不仅服务传统搜索引擎也是让页面更易被 LLM 准确引用与检索的一部分——两条规则互为补充一条管不要太大一条管结构要清晰、语义要自包含。例外情况原文档明确了三类不应机械套用的场景非排名意图页面staging、工具类、登录、账户或站内搜索页面若本就不以排名为目标可有意采用不同的抓取/索引信号临时迁移状态迁移过程中会产生噪声化的中间信号应标记线上生产环境的 URL 模式而非一次性过渡产物信号冲突时当重定向、canonical、robots 指令或可索引性信号相互冲突时应优先修复最强、最根本的信号而不是把每个下游症状都当作独立阻塞项上报。验证方式自动化检查检查渲染后的 HTML 与 HTTP 响应头确认预期的元数据或可爬取性信号存在用 Google Search Console 或等价工具测试受影响的 URL部署后对代表性页面集合重新发起爬取。手动检查确认改动没有引入与 canonical-url、robots 或结构化数据冲突的信号。关联规则速览html-size在内容资产中共关联四条规则便于组合排查关联规则关联理由compressionGzip/Brotli 是大 HTML 传输体积的首要缓解手段llm-parsability带噪声注入数据的超大 HTML 损害 LLM 内容抽取pdf-size同属seo/technical区域常一起审查broken-links同属seo/technical区域常一起审查深入阅读规则完整定义与 AI 提示词packages/content/rules/en/seo/html-size.mdx面向 Agent 的执行指令检查/修复/解释/代码审查skills/html-size/SKILL.md技术细节与代码示例原档skills/html-size/references/rule.md压缩缓解方案的完整配置示例packages/content/rules/en/performance/compression.mdx项目检查清单中的对应条目README.md【免费下载链接】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），仅供参考 Front-End-Checklist 实战：将 HTML 文档控制在爬虫抓取限制以内（html-size 规则）
Front-End-Checklist 实战将 HTML 文档控制在爬虫抓取限制以内html-size 规则【免费下载链接】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-size规则展开讲解如何将页面 HTML 文档控制在 Googlebot 的爬取解析限制约 15MB以内避免页面尾部内容被搜索引擎静默忽略。你将掌握大体积 HTML 的成因分析、curl实测方法、目标区间判断以及针对内联 JSON、内联 SVG、未压缩脚本等典型问题的修复套路并了解该规则与压缩compression、LLM 可解析性llm-parsability等关联规则的协同关系。该规则定位为 SEO 类category:seo、技术子类subcategory:technical优先级为 medium、难度为 intermediate、预估耗时 10 分钟。规则以 SKILL 形式沉淀在仓库中同时存在于 skills/html-size/SKILL.md面向 Agent 的执行指令与 references/rule.md完整技术细节两份文件中并作为内容资产收录于 packages/content/rules/en/seo/html-size.mdx在项目 README.md 的检查清单中同样占有一席。规则核心Googlebot 的 15MB 解析上限硬性解析限制规则的事实基础来自 Google 官方爬取文档Googlebot 对单个 HTML 文档的解析上限约为 15MB超出该阈值的内容会被静默忽略既不解析也不会进入索引。也就是说即使页面其余部分渲染正常位于 15MB 之后的正文、结构化数据或链接都可能看不见。即使远低于这个硬上限过大的 HTML 同样有害Googlebot 抓取和解析大型页面需要更长时间会消耗更多爬取预算crawl budget导致同一周期内可抓取的页面数量减少。对于大型电商站点、或把大量数据集服务端渲染进 HTML 的页面这一影响尤其明显。为什么重要Why It Matters原文档从三个维度给出影响索引完整性Index completeness超出 Googlebot 解析上限之后的内容不会被索引等于页面尾部内容对搜索隐身爬取预算Crawl budget大页面抓取与解析更慢留给其他页面的资源变少站点整体收录速度下降Core Web Vitals大体积 HTML 会延迟首字节时间TTFB与最大内容绘制LCP直接影响用户体验与核心指标。适用场景依据 SKILL.md 中的aiContext定义该规则适用于以下三类场景审计页面权重page weight以优化爬取效率排查某些页面内容没有出现在 Google 索引中的问题审查服务端渲染页面中内嵌大体积 JSON 载荷的 HTML。大体积 HTML 的常见成因与典型体量原文档给出了一张成因对照表是快速定位问题的重要依据成因典型体积贡献内联 Next.js__NEXT_DATA__JSON100KB–5MB内联 SVG 文件每个 10KB–500KBBase64 编码图片视情况而定比二进制大 33%未压缩的script块50KB–1MB大量工具类utility classes的内联 CSS50KB–300KB值得注意两点Base64 编码会让图片体积比原始二进制增加约 33%且浏览器仍需解码而大量工具类内联 CSS通常来自未开启提取与按需裁剪的 CSS 框架产物。诊断思路是先测量总量再按上表拆分各来源占比找到主导项。实战修复两类典型反模式与正确做法原文档提供了两组可直接对照的反模式 → 修复示例。场景一内联巨型 JSON 载荷Next.js__NEXT_DATA__❌避免——在getServerSideProps中塞入过多数据导致__NEXT_DATA__脚本内嵌数 MB JSON!-- Next.js pages router with too much data in getServerSideProps -- script id__NEXT_DATA__ typeapplication/json { props: { pageProps: { allProducts: [/* 5,000 products × 2KB each 10MB of JSON */] } } } /script✅修复——只把当前页面真正渲染的数据传给前端其余数据改由客户端按需请求// pages/products/index.tsx export async function getStaticProps() { // 只传递当前页面可见的 20 个商品 const products await getProducts({ limit: 20, page: 1 }) return { props: { products } } // 其余页面的数据通过客户端 API 调用按需加载 }依据 SKILL.md 的修复指引处理内联 JSON 还有两个方向一是同时收紧getServerSideProps/getStaticProps传递的数据量只传页面渲染所需二是 Next.js 13 项目可改用 React Server ComponentsRSC把数据保留在服务端避免随 hydration 载荷下发到客户端。场景二本应外置的内联 SVG❌避免——把体积达数百 KB 的 SVG 直接内联进 HTML!-- 200KB SVG inlined directly in HTML -- svg xmlnshttp://www.w3.org/2000/svg viewBox0 0 1000 500 !-- thousands of path elements... -- /svg✅修复——按用途选择外置方案!-- 作为图片加载无法用 CSS 设置样式 -- img src/images/illustration.svg altProduct illustration width500 height250 !-- 或者作为内联 SVG 雪碧图承载图标体积小、可复用 -- svg aria-hiddentrueuse href/icons.svg#arrow-right/use/svg原则是装饰性大图用img外链可复用的图标集合收敛为 SVG sprite 通过use引用既能复用又可缓存且不膨胀 HTML 本体。如何测量 HTML 大小命令行实测原文档给出了两条curl命令分别测未压缩原始大小与Googlebot 实际接收到的压缩后大小# 测量未压缩的 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/page第一条命令得到的是服务端返回的原始字节数未压缩用于判断文档本身是否超限第二条模拟 Googlebot 发送Accept-Encoding: gzip, br看到的是开启压缩后传输层实际字节数——这解释了为什么压缩是缓解传输开销的直接手段。SKILL.md 提供了带单位换算的变体可直接输出 KB 值curl -so /dev/null -w %{size_download} https://yoursite.com/page | awk {print $1/1024 KB}目标区间区间结论100KB 以下优秀Excellent100KB–2MB可接受但需排查大块区域2MB–5MB需要优化5MB 以上严重存在部分索引缺失风险代码审查要点在 SKILL.md 的codeReview中明确了审查动作检查响应的Content-Length头或直接统计原始 HTML 字节数定位script typeapplication/json或script id__NEXT_DATA__块并统计其字节数任何单块超过 500KB 都应标记在 body HTML 中查找svg元素判断是否为应外置的内联 SVG最后确认 HTML 是否以 gzip 或 Brotli 编码返回。六步修复清单综合原文档与 SKILL.md 的fix提示形成可操作的完整修复流程测量用上文curl命令测出每页原始 HTML 大小处理内联 JSONNext.js__NEXT_DATA__常见减少传给getServerSideProps/getStaticProps的数据只传页面渲染所需Next.js 13 改用 React Server Components 避免客户端 hydration 载荷处理内联 SVG迁移到外部文件用img或use加载处理 Base64 图片改为将图片交由 CDN 托管HTML 中只引用 URL开启 gzip/Brotli 压缩Googlebot 会请求压缩后的响应传输体积大幅下降生产环境压缩 HTML 输出去除空白与注释减小原始字节。压缩是缓解而非根治与 compression 规则的协同html-size 规则的relatedRules元数据见 packages/content/rules/en/seo/html-size.mdx将 compression 列为第一关联项理由是Gzip/Brotli 压缩是大体积 HTML 传输开销的主要缓解手段。文本类资源HTML、CSS、JS高度冗余压缩率通常可达 70% 以上。compression 规则performance/assets 类优先级 high给出的服务器配置示例可直接落地# 启用 Gzip 压缩 gzip on; gzip_types text/plain text/css application/javascript application/json image/svgxml; gzip_min_length 1000; # 启用 Brotli需安装对应模块 brotli on; brotli_types text/plain text/css application/javascript application/json image/svgxml;Node.js/Express 场景则可用compression中间件一行开启app.use(compression())。但需要强调压缩规则的边界压缩只解决网络传输侧的开销并不会移除客户端解析与执行超大 bundle 的成本——这正好呼应 html-size 规则控制原始文档体积的必要性压缩后传输再小解析上限按原始 HTML 计算根源仍是把文档本身做小。大 HTML 对 LLM 可解析性的影响html-size 规则的第二个关联项是 llm-parsabilitySEO/content 类优先级 medium原文档给出的关联理由是充满噪声注入数据的超大 HTML 同样损害 LLM 内容抽取。随着 AI 概览AI Overviews与各类答案引擎直接从页面 HTML 抽取内容并引用巨型 JSON 数据块这类注入噪声会稀释正文信号的密度使 LLM 难以准确定位语义段落。因此控制 HTML 体积不仅服务传统搜索引擎也是让页面更易被 LLM 准确引用与检索的一部分——两条规则互为补充一条管不要太大一条管结构要清晰、语义要自包含。例外情况原文档明确了三类不应机械套用的场景非排名意图页面staging、工具类、登录、账户或站内搜索页面若本就不以排名为目标可有意采用不同的抓取/索引信号临时迁移状态迁移过程中会产生噪声化的中间信号应标记线上生产环境的 URL 模式而非一次性过渡产物信号冲突时当重定向、canonical、robots 指令或可索引性信号相互冲突时应优先修复最强、最根本的信号而不是把每个下游症状都当作独立阻塞项上报。验证方式自动化检查检查渲染后的 HTML 与 HTTP 响应头确认预期的元数据或可爬取性信号存在用 Google Search Console 或等价工具测试受影响的 URL部署后对代表性页面集合重新发起爬取。手动检查确认改动没有引入与 canonical-url、robots 或结构化数据冲突的信号。关联规则速览html-size在内容资产中共关联四条规则便于组合排查关联规则关联理由compressionGzip/Brotli 是大 HTML 传输体积的首要缓解手段llm-parsability带噪声注入数据的超大 HTML 损害 LLM 内容抽取pdf-size同属seo/technical区域常一起审查broken-links同属seo/technical区域常一起审查深入阅读规则完整定义与 AI 提示词packages/content/rules/en/seo/html-size.mdx面向 Agent 的执行指令检查/修复/解释/代码审查skills/html-size/SKILL.md技术细节与代码示例原档skills/html-size/references/rule.md压缩缓解方案的完整配置示例packages/content/rules/en/performance/compression.mdx项目检查清单中的对应条目README.md【免费下载链接】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），仅供参考