Front-End-Checklist 页面权重优化指南将页面总重量控制在 1500KB 以内理想 500KB【免费下载链接】Front-End-Checklist The essential checklist for modern web development, for humans and AI agents项目地址: https://gitcode.com/gh_mirrors/fr/Front-End-Checklist页面权重Page Weight指渲染一个页面所需的全部资源HTML、CSS、JavaScript、图片、字体等的总字节数它与加载速度直接相关。本文基于 Front-End-Checklist 仓库中的page-weight规则定义于 skills/page-weight/SKILL.md 与 packages/content/rules/en/performance/page-weight.mdx系统讲解权重基准、典型构成、分资源类型的优化手段、CI/CD 性能预算以及页面权重的测量与验证方法。读完本文你将能够为任意页面建立可量化、可监控、可复现的页面瘦身流程。规则速览目标阈值与优先级page-weight规则在仓库中属于performance/assets分类优先级为 high难度为 beginner预估耗时 20 分钟。其核心结论浓缩在 Quick Reference 中目标整页总权重控制在500KB 以内为最优1500KB 为可接受上限图片通常占页面总权重的50%–70%是头号优化对象JavaScript bundle 通常是第二大贡献者必须通过CI/CD 中的性能预算performance budgets持续监控防止回归。规则给出的Check / Fix / Explain / Code Review四段式提示详见 skills/page-weight/SKILL.md是任何 AI Agent 或工程师处理该问题时的标准工作流先分析包含所有资源的页面总权重并判断是否低于阈值再通过图片优化、代码压缩、移除多余资源来瘦身并向团队解释权重对移动网络加载体验的影响Code Review 阶段则要求精确指出造成网络、CPU 或布局开销的文件、请求与渲染步骤并说明确认问题所用的测量方法。为什么页面权重如此重要页面权重与加载时间呈直接正相关一个 1.5MB 的页面在 4G 移动网络下需要 3–5 秒才能加载完成。权重每减少 100KB用户体验都会随之改善尤其是在较慢的网络环境下。这也解释了为什么该规则与http-requests、compression规则在仓库中被标记为通常一起审查的关联规则见 page-weight.mdx并在 performance-quick-wins 清单 中被列为优先级最高的快速优化项之一。从仓库的 性能快速清单 可以看出权重问题的连锁影响更快站点带来更高参与度、更好的 Core Web Vitals SEO 排名、更高的转化率以及弱网环境下更好的可用性。因此页面权重不是孤立的大小问题而是性能指标的底座——先解决传输成本再谈框架级的微观优化。权重基准表每个资源类型的健康区间规则给出了完整的分资源基准这是判断哪个环节超重的量化依据原文见 references/rule.md类别目标可接受较差页面总量 500KB 1500KB 1500KBHTML 50KB 100KB 100KBCSS 50KB 100KB 100KBJavaScript 200KB 400KB 400KB图片 200KB 500KB 500KB字体 100KB 200KB 200KB同时规则给出了典型页面的权重构成与优化优先级排序资源类型平均占比优化优先级图片50–70%高JavaScript15–25%高CSS5–10%中字体5–10%中HTML2–5%低这张表揭示了核心策略优先处理图片和 JavaScript两者合计通常占页面总权重 65%–95%HTML 占比最低优化收益有限应最后处理。图片优化权重最大头的降本手段图片占据页面权重的一半以上因此图片优化是控制页面权重最有效的手段。仓库配套的 image-optimization 规则 提供了一系列可落地的组合拳选择现代格式AVIF 通常比同等质量 JPEG 小约 50%WebP 小约 25–35%格式优先级为 AVIF WebP JPEG/PNG。使用picture元素为旧浏览器提供回退picture source srcsetimage.avif typeimage/avif source srcsetimage.webp typeimage/webp img srcimage.jpg altDescription loadinglazy /picture响应式尺寸通过srcset与sizes让不同屏幕只下载所需大小的文件避免移动端下载桌面级大图img srcimage-800w.jpg srcset image-400w.jpg 400w, image-800w.jpg 800w, image-1200w.jpg 1200w, image-1600w.jpg 1600w sizes(max-width: 600px) 100vw, (max-width: 1200px) 50vw, 800px altResponsive image loadinglazy 显式声明宽高避免图片加载引起布局偏移CLS这是 Core Web Vitals 的关键指标之一。懒加载折叠线以下的图片设置loadinglazy首屏图片不要懒加载并优先加载。补充参考image-file-size 技能 给出了更细的文件大小建议——照片目标 200KBWebP 80% 质量、整幅 hero 图 400KB、图形/图标 50KB 并优先使用 SVG并通过 Squoosh、Sharp、ImageOptim、oxipng、SVGO 等工具落地。JavaScript 与代码分割控制第二大头JavaScript 是权重第二大的贡献者通常占 15–25%。规则提供了两条主路径构建期的手动分包和运行期的动态导入。构建期手动分包Vite// vite.config.js export default { build: { rollupOptions: { output: { manualChunks: { // Split vendor code vendor: [react, react-dom], // Split by feature charts: [recharts, d3], } } }, // Warn if chunk exceeds size chunkSizeWarningLimit: 200 } }manualChunks将第三方库按用途拆分为独立 chunkchunkSizeWarningLimit: 200让构建工具在单个 chunk 超过 200KB 时发出警告——这与权重基准表中 JavaScript 200KB 的目标阈值保持一致。运行期动态导入Reactimport { lazy, Suspense } from react const HeavyChart lazy(() import(./HeavyChart)) const AdminPanel lazy(() import(./AdminPanel)) function Dashboard() { return ( Suspense fallback{Skeleton /} {showChart HeavyChart /} {isAdmin AdminPanel /} /Suspense ) }配合路由级拆分、按需加载组件可以显著缩小首屏 JavaScript 体积。前端生态中常见的optimizePackageImports、按需引入图标库等做法也属于同类优化——仓库自身的 next.config.js 就配置了optimizePackageImports来处理lucide-react等图标库的打包体积。CSS 与字体优化CSS清除未使用样式拥抱设计令牌/* Remove unused CSS with PurgeCSS */ /* After: Only critical styles remain */ /* Use CSS custom properties to reduce repetition */ :root { --color-primary: #3b82f6; --spacing-md: 1rem; } /* Avoid large frameworks entirely if possible */ /* Tailwind CSS with purging typically produces 10KB */规则建议用 PurgeCSS 等工具剔除未使用样式用 CSS 自定义属性设计令牌消除重复声明尽可能避免引入整站 CSS 框架——清理后的 Tailwind 通常能控制在 10KB 以内。仓库还提供 css-file-size 规则 作为本条的配套细化。字体子集化与系统字体兜底/* Subset fonts to only needed characters */ font-face { font-family: CustomFont; src: url(/fonts/custom-latin.woff2) format(woff2); font-display: swap; unicode-range: U0000-007F, U0080-00FF; /* Latin only */ } /* Or use system fonts */ body { font-family: system-ui, -apple-system, BlinkMacSystemFont, Segoe UI, sans-serif; }核心手法将字体裁剪为仅含所需字符集的子集如 Latin使用 woff2 现代格式配合font-display: swap避免阻塞渲染能用系统字体栈时优先使用系统字体直接省掉全部字体请求。在 CI/CD 中落地性能预算性能优化最怕回归。规则提供了 Lighthouse 预算配置与 CI 集成的完整示例// lighthouse.config.js module.exports { extends: lighthouse:default, settings: { budgets: [ { resourceSizes: [ { resourceType: total, budget: 500 }, { resourceType: script, budget: 200 }, { resourceType: image, budget: 200 }, { resourceType: stylesheet, budget: 50 }, { resourceType: font, budget: 100 }, ] } ] } }# GitHub Actions performance check - name: Run Lighthouse uses: treosh/lighthouse-ci-actionv10 with: budgetPath: ./lighthouse-budget.json uploadArtifacts: true注意这里的预算值与权重基准表一一对应total 500KB、script 200KB、image 200KB、stylesheet 50KB、font 100KB相当于把优化目标直接固化到流水线中一旦某个 PR 使资源大小超预算CI 即失败从而在合并前拦截权重回归。用代码测量页面权重除了外部工具规则还给出了一个可在浏览器控制台直接运行的测量函数基于 Performance API 精确统计各类资源的传输大小transferSize为实际线上传输字节数已含压缩// Check total page weight function measurePageWeight() { const resources performance.getEntriesByType(resource) const navigation performance.getEntriesByType(navigation)[0] const breakdown { html: navigation?.transferSize || 0, css: 0, js: 0, images: 0, fonts: 0, other: 0 } resources.forEach(r { const size r.transferSize || 0 if (r.initiatorType css || r.name.includes(.css)) { breakdown.css size } else if (r.initiatorType script || r.name.includes(.js)) { breakdown.js size } else if (r.initiatorType img || /\.(jpg|png|webp|avif|gif|svg)/.test(r.name)) { breakdown.images size } else if (/\.(woff2?|ttf|otf|eot)/.test(r.name)) { breakdown.fonts size } else { breakdown.other size } }) const total Object.values(breakdown).reduce((a, b) a b, 0) console.table({ ...Object.fromEntries( Object.entries(breakdown).map(([k, v]) [k, ${(v / 1024).toFixed(1)} KB]) ), total: ${(total / 1024).toFixed(1)} KB }) return { total, breakdown } }该函数按 HTML/CSS/JS/图片/字体/其他对资源归类求和并以 KB 为单位输出明细表格——既可用于单次审计也可嵌入自动化脚本做持续监控实现先测量、再优化、后验证的闭环。仓库实践Front-End-Checklist 自身的图片与打包配置作为佐证仓库自身的 Next.js 应用在 apps/web/next.config.js 中实践了本规则的多项要点现代图片格式images.formats: [image/avif, image/webp]优先输出 AVIF/WebPL82-L84设备尺寸约束deviceSizes: [640, 828, 1200, 1920]与imageSizes: [32, 64, 128, 256]限制生成图片的尺寸档位避免无谓的过大变体L84-L85远程图片白名单通过remotePatterns只允许信任域GitHub avatars、Open Collective的图片走优化管线L86-L97生产环境剔除 consolecompiler.removeConsole在生产构建中移除日志代码进一步削减 JS 体积L101-L104图标库按需打包optimizePackageImports优化lucide-react、radix-ui/react-icons等图标库的引入体积L74-L78。这些配置展示了页面权重规则在真实 Next.js 应用中的落地形态不是靠一两个技巧而是格式、尺寸、打包、运行时代码四管齐下。验证与持续监控最后规则提供了完整的验证手段自动化检查打开 DevTools Network 面板按 Size 列排序直接查看各资源体积运行 Lighthouse 性能审计使用 WebPageTest 获取详细的资源分解在 CI 中配置性能预算如前文 Lighthouse budget 示例。人工检查通过 Real User MonitoringRUM监控真实用户的传输量与加载体验。结合 performance-quick-wins 清单 的建议推荐的工作顺序是先启用 gzip/brotli 压缩与缓存头获得即时收益再集中处理图片等重型资源最后才是框架层面的微观调优——因为压缩、缓存与加载顺序的投入产出比通常远高于孤立的压缩任务。小结页面权重是移动端性能的第一道关口。按照 Front-End-Checklist 的page-weight规则你可以将工作拆解为四个可执行步骤测量Performance API 脚本或 DevTools Network 面板→对标对照 500KB/1500KB 及各资源类型的基准表→优化图片格式与响应式、JS 分包与动态导入、CSS 清理、字体子集化→固化在 CI/CD 中写入 Lighthouse 性能预算。这套方法论在仓库中既有规则文档、技能文件与配套清单的完整支撑也在 apps/web/next.config.js 中得到了工程化的实践验证。【免费下载链接】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 页面权重优化指南：将页面总重量控制在 1500KB 以内（理想 500KB）
Front-End-Checklist 页面权重优化指南将页面总重量控制在 1500KB 以内理想 500KB【免费下载链接】Front-End-Checklist The essential checklist for modern web development, for humans and AI agents项目地址: https://gitcode.com/gh_mirrors/fr/Front-End-Checklist页面权重Page Weight指渲染一个页面所需的全部资源HTML、CSS、JavaScript、图片、字体等的总字节数它与加载速度直接相关。本文基于 Front-End-Checklist 仓库中的page-weight规则定义于 skills/page-weight/SKILL.md 与 packages/content/rules/en/performance/page-weight.mdx系统讲解权重基准、典型构成、分资源类型的优化手段、CI/CD 性能预算以及页面权重的测量与验证方法。读完本文你将能够为任意页面建立可量化、可监控、可复现的页面瘦身流程。规则速览目标阈值与优先级page-weight规则在仓库中属于performance/assets分类优先级为 high难度为 beginner预估耗时 20 分钟。其核心结论浓缩在 Quick Reference 中目标整页总权重控制在500KB 以内为最优1500KB 为可接受上限图片通常占页面总权重的50%–70%是头号优化对象JavaScript bundle 通常是第二大贡献者必须通过CI/CD 中的性能预算performance budgets持续监控防止回归。规则给出的Check / Fix / Explain / Code Review四段式提示详见 skills/page-weight/SKILL.md是任何 AI Agent 或工程师处理该问题时的标准工作流先分析包含所有资源的页面总权重并判断是否低于阈值再通过图片优化、代码压缩、移除多余资源来瘦身并向团队解释权重对移动网络加载体验的影响Code Review 阶段则要求精确指出造成网络、CPU 或布局开销的文件、请求与渲染步骤并说明确认问题所用的测量方法。为什么页面权重如此重要页面权重与加载时间呈直接正相关一个 1.5MB 的页面在 4G 移动网络下需要 3–5 秒才能加载完成。权重每减少 100KB用户体验都会随之改善尤其是在较慢的网络环境下。这也解释了为什么该规则与http-requests、compression规则在仓库中被标记为通常一起审查的关联规则见 page-weight.mdx并在 performance-quick-wins 清单 中被列为优先级最高的快速优化项之一。从仓库的 性能快速清单 可以看出权重问题的连锁影响更快站点带来更高参与度、更好的 Core Web Vitals SEO 排名、更高的转化率以及弱网环境下更好的可用性。因此页面权重不是孤立的大小问题而是性能指标的底座——先解决传输成本再谈框架级的微观优化。权重基准表每个资源类型的健康区间规则给出了完整的分资源基准这是判断哪个环节超重的量化依据原文见 references/rule.md类别目标可接受较差页面总量 500KB 1500KB 1500KBHTML 50KB 100KB 100KBCSS 50KB 100KB 100KBJavaScript 200KB 400KB 400KB图片 200KB 500KB 500KB字体 100KB 200KB 200KB同时规则给出了典型页面的权重构成与优化优先级排序资源类型平均占比优化优先级图片50–70%高JavaScript15–25%高CSS5–10%中字体5–10%中HTML2–5%低这张表揭示了核心策略优先处理图片和 JavaScript两者合计通常占页面总权重 65%–95%HTML 占比最低优化收益有限应最后处理。图片优化权重最大头的降本手段图片占据页面权重的一半以上因此图片优化是控制页面权重最有效的手段。仓库配套的 image-optimization 规则 提供了一系列可落地的组合拳选择现代格式AVIF 通常比同等质量 JPEG 小约 50%WebP 小约 25–35%格式优先级为 AVIF WebP JPEG/PNG。使用picture元素为旧浏览器提供回退picture source srcsetimage.avif typeimage/avif source srcsetimage.webp typeimage/webp img srcimage.jpg altDescription loadinglazy /picture响应式尺寸通过srcset与sizes让不同屏幕只下载所需大小的文件避免移动端下载桌面级大图img srcimage-800w.jpg srcset image-400w.jpg 400w, image-800w.jpg 800w, image-1200w.jpg 1200w, image-1600w.jpg 1600w sizes(max-width: 600px) 100vw, (max-width: 1200px) 50vw, 800px altResponsive image loadinglazy 显式声明宽高避免图片加载引起布局偏移CLS这是 Core Web Vitals 的关键指标之一。懒加载折叠线以下的图片设置loadinglazy首屏图片不要懒加载并优先加载。补充参考image-file-size 技能 给出了更细的文件大小建议——照片目标 200KBWebP 80% 质量、整幅 hero 图 400KB、图形/图标 50KB 并优先使用 SVG并通过 Squoosh、Sharp、ImageOptim、oxipng、SVGO 等工具落地。JavaScript 与代码分割控制第二大头JavaScript 是权重第二大的贡献者通常占 15–25%。规则提供了两条主路径构建期的手动分包和运行期的动态导入。构建期手动分包Vite// vite.config.js export default { build: { rollupOptions: { output: { manualChunks: { // Split vendor code vendor: [react, react-dom], // Split by feature charts: [recharts, d3], } } }, // Warn if chunk exceeds size chunkSizeWarningLimit: 200 } }manualChunks将第三方库按用途拆分为独立 chunkchunkSizeWarningLimit: 200让构建工具在单个 chunk 超过 200KB 时发出警告——这与权重基准表中 JavaScript 200KB 的目标阈值保持一致。运行期动态导入Reactimport { lazy, Suspense } from react const HeavyChart lazy(() import(./HeavyChart)) const AdminPanel lazy(() import(./AdminPanel)) function Dashboard() { return ( Suspense fallback{Skeleton /} {showChart HeavyChart /} {isAdmin AdminPanel /} /Suspense ) }配合路由级拆分、按需加载组件可以显著缩小首屏 JavaScript 体积。前端生态中常见的optimizePackageImports、按需引入图标库等做法也属于同类优化——仓库自身的 next.config.js 就配置了optimizePackageImports来处理lucide-react等图标库的打包体积。CSS 与字体优化CSS清除未使用样式拥抱设计令牌/* Remove unused CSS with PurgeCSS */ /* After: Only critical styles remain */ /* Use CSS custom properties to reduce repetition */ :root { --color-primary: #3b82f6; --spacing-md: 1rem; } /* Avoid large frameworks entirely if possible */ /* Tailwind CSS with purging typically produces 10KB */规则建议用 PurgeCSS 等工具剔除未使用样式用 CSS 自定义属性设计令牌消除重复声明尽可能避免引入整站 CSS 框架——清理后的 Tailwind 通常能控制在 10KB 以内。仓库还提供 css-file-size 规则 作为本条的配套细化。字体子集化与系统字体兜底/* Subset fonts to only needed characters */ font-face { font-family: CustomFont; src: url(/fonts/custom-latin.woff2) format(woff2); font-display: swap; unicode-range: U0000-007F, U0080-00FF; /* Latin only */ } /* Or use system fonts */ body { font-family: system-ui, -apple-system, BlinkMacSystemFont, Segoe UI, sans-serif; }核心手法将字体裁剪为仅含所需字符集的子集如 Latin使用 woff2 现代格式配合font-display: swap避免阻塞渲染能用系统字体栈时优先使用系统字体直接省掉全部字体请求。在 CI/CD 中落地性能预算性能优化最怕回归。规则提供了 Lighthouse 预算配置与 CI 集成的完整示例// lighthouse.config.js module.exports { extends: lighthouse:default, settings: { budgets: [ { resourceSizes: [ { resourceType: total, budget: 500 }, { resourceType: script, budget: 200 }, { resourceType: image, budget: 200 }, { resourceType: stylesheet, budget: 50 }, { resourceType: font, budget: 100 }, ] } ] } }# GitHub Actions performance check - name: Run Lighthouse uses: treosh/lighthouse-ci-actionv10 with: budgetPath: ./lighthouse-budget.json uploadArtifacts: true注意这里的预算值与权重基准表一一对应total 500KB、script 200KB、image 200KB、stylesheet 50KB、font 100KB相当于把优化目标直接固化到流水线中一旦某个 PR 使资源大小超预算CI 即失败从而在合并前拦截权重回归。用代码测量页面权重除了外部工具规则还给出了一个可在浏览器控制台直接运行的测量函数基于 Performance API 精确统计各类资源的传输大小transferSize为实际线上传输字节数已含压缩// Check total page weight function measurePageWeight() { const resources performance.getEntriesByType(resource) const navigation performance.getEntriesByType(navigation)[0] const breakdown { html: navigation?.transferSize || 0, css: 0, js: 0, images: 0, fonts: 0, other: 0 } resources.forEach(r { const size r.transferSize || 0 if (r.initiatorType css || r.name.includes(.css)) { breakdown.css size } else if (r.initiatorType script || r.name.includes(.js)) { breakdown.js size } else if (r.initiatorType img || /\.(jpg|png|webp|avif|gif|svg)/.test(r.name)) { breakdown.images size } else if (/\.(woff2?|ttf|otf|eot)/.test(r.name)) { breakdown.fonts size } else { breakdown.other size } }) const total Object.values(breakdown).reduce((a, b) a b, 0) console.table({ ...Object.fromEntries( Object.entries(breakdown).map(([k, v]) [k, ${(v / 1024).toFixed(1)} KB]) ), total: ${(total / 1024).toFixed(1)} KB }) return { total, breakdown } }该函数按 HTML/CSS/JS/图片/字体/其他对资源归类求和并以 KB 为单位输出明细表格——既可用于单次审计也可嵌入自动化脚本做持续监控实现先测量、再优化、后验证的闭环。仓库实践Front-End-Checklist 自身的图片与打包配置作为佐证仓库自身的 Next.js 应用在 apps/web/next.config.js 中实践了本规则的多项要点现代图片格式images.formats: [image/avif, image/webp]优先输出 AVIF/WebPL82-L84设备尺寸约束deviceSizes: [640, 828, 1200, 1920]与imageSizes: [32, 64, 128, 256]限制生成图片的尺寸档位避免无谓的过大变体L84-L85远程图片白名单通过remotePatterns只允许信任域GitHub avatars、Open Collective的图片走优化管线L86-L97生产环境剔除 consolecompiler.removeConsole在生产构建中移除日志代码进一步削减 JS 体积L101-L104图标库按需打包optimizePackageImports优化lucide-react、radix-ui/react-icons等图标库的引入体积L74-L78。这些配置展示了页面权重规则在真实 Next.js 应用中的落地形态不是靠一两个技巧而是格式、尺寸、打包、运行时代码四管齐下。验证与持续监控最后规则提供了完整的验证手段自动化检查打开 DevTools Network 面板按 Size 列排序直接查看各资源体积运行 Lighthouse 性能审计使用 WebPageTest 获取详细的资源分解在 CI 中配置性能预算如前文 Lighthouse budget 示例。人工检查通过 Real User MonitoringRUM监控真实用户的传输量与加载体验。结合 performance-quick-wins 清单 的建议推荐的工作顺序是先启用 gzip/brotli 压缩与缓存头获得即时收益再集中处理图片等重型资源最后才是框架层面的微观调优——因为压缩、缓存与加载顺序的投入产出比通常远高于孤立的压缩任务。小结页面权重是移动端性能的第一道关口。按照 Front-End-Checklist 的page-weight规则你可以将工作拆解为四个可执行步骤测量Performance API 脚本或 DevTools Network 面板→对标对照 500KB/1500KB 及各资源类型的基准表→优化图片格式与响应式、JS 分包与动态导入、CSS 清理、字体子集化→固化在 CI/CD 中写入 Lighthouse 性能预算。这套方法论在仓库中既有规则文档、技能文件与配套清单的完整支撑也在 apps/web/next.config.js 中得到了工程化的实践验证。【免费下载链接】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），仅供参考