Front-End-Checklist 页面重量优化实战把整页资源控制在 1500KB 以内【免费下载链接】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是指渲染一个页面所需的全部资源的总大小它直接决定了用户在弱网环境下的加载体验。本文以 Front-End-Checklist 仓库中 performance 分类下的page-weight规则为核心系统讲解 500KB 目标值 / 1500KB 上限的基准划分、典型资源占比、JavaScript/CSS/字体三大优化手段以及如何在 CI/CD 中落地性能预算读完即可在你的项目里建立一套可度量的页面瘦身流程。一、规则解读这条规则到底在检查什么在 Front-End-Checklist 仓库中page-weight规则同时以两种形式存在一种是面向人类读者的规范文档 packages/content/rules/en/performance/page-weight.mdx另一种是面向 Agent 的技能封装 skills/page-weight/SKILL.md。两者核心判定一致包含全部资源在内的整页重量应低于 1500KB理想状态低于 500KB。SKILL.md 的元数据给出了这条规则的定位priority: high高优先级、difficulty: beginner入门难度、estimatedTime: 20约 20 分钟可完成整改。它被归类到performance分类下的assets资源子类对应的检查思路是Check检查分析整页所有资源的总大小确认是否低于 1500KB理想为 500KBFix修复通过图片优化、代码压缩、移除不必要的资源来降低总重量Explain解释说明页面重量如何影响加载时间尤其在移动网络上以及如何影响用户体验Code Review评审审查影响该指标的路由、资源与加载行为明确指出增加网络、CPU 或布局开销的具体文件、请求或渲染步骤并说明用于确认问题的测量方法。这条规则在仓库的检查清单体系中也占据核心位置packages/content/checklists/en/performance-quick-wins.mdx 将performance/page-weight与compression、browser-caching、http-requests、lazy-loading、resource-hints、optimized、cdn一起列为绩效速赢Quick Wins项——这些优化投入小、收益大是开展深度 Core Web Vitals 排查之前的首选起点。二、为什么它在高优先级页面重量与加载时间的正相关规则文档用一组直观的数据说明了背景一个 1.5MB 的页面在 4G 移动网络下需要 3–5 秒才能加载完成每减少 100KB 都能显著改善用户体验尤其是在慢速网络上。原因在于页面重量与实际加载时间直接相关资源越大网络传输耗时越长而移动设备不仅网络带宽有限CPU 解析和执行 JavaScript 的能力也远弱于桌面设备。与之相邻的 js-file-size 规则进一步补充了这条因果链的细节JavaScript 与图片不同图片只需解码而 JavaScript 必须经历下载、解析、编译、执行四个阶段一个 1MB 的脚本在旗舰手机上解析可能只需 1 秒在低端设备上却可能要 10 秒。交互指标FID/INP又是 Google Core Web Vitals 的组成部分直接影响搜索排名。因此页面重量不只是体感问题它同时牵动用户体验、数据流量成本对按流量计费的用户尤其关键和 SEO。三、重量基准表按资源类型划分的目标线规则文档给出了完整的基准表格这是把页面重量从抽象概念变成可执行检查项的关键类别目标Target可接受Acceptable差Poor整页总计 500KB 1500KB 1500KBHTML 50KB 100KB 100KBCSS 50KB 100KB 100KBJavaScript 200KB 400KB 400KB图片 200KB 500KB 500KB字体 100KB 200KB 200KB需要特别说明这里的大小通常指**传输后压缩后**的大小。相邻规则 js-file-size.mdx 中明确标注了Keep individual JS bundles under 200KB (compressed)单个 JS 包压缩后低于 200KBcss-file-size.mdx 同样以 gzip 后 50KB 作为 CSS 的参考上限。在做预算或验收时应统一采用 Gzip/Brotli 压缩后的传输尺寸口径。四、典型的页面重量构成优化优先级从哪来规则文档给出的典型构成占比是制定优化顺序的依据资源类型平均占比优化优先级图片50–70%高JavaScript15–25%高CSS5–10%中字体5–10%中HTML2–5%低这组数据直接给出了行动顺序图片通常是最大的体重来源JavaScript 是第二大来源。性能速赢清单 performance-quick-wins.mdx 中也有呼应——Images and other heavy assets are often the largest contributors to page weight. Reduce transfer cost before chasing framework-level micro-optimizations图片和其他重型资源往往是页面重量最大的贡献者在追求框架级微优化之前先降低传输成本。五、先测量再优化如何准确称出页面重量规则文档提供了一个可直接运行的测量脚本利用浏览器 Performance API 按资源类型拆分整页重量// 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 } }脚本要点数据来源performance.getEntriesByType(navigation)[0].transferSize提供 HTML 文档的传输大小performance.getEntriesByType(resource)覆盖页面发起的全部子资源请求传输大小transferSize是网络层实际传输的字节数已含压缩效果比encodedBodySize更贴近用户真实消耗的流量分类规则依据initiatorType如css、script、img与 URL 扩展名双通道判定资源归属未命中的归入other输出以 KB 为单位汇总各分类与总量并返回{ total, breakdown }供后续集成。除了脚本规则文档还推荐了三种测量手段可按需选用浏览器 Network 面板按 Size 列排序快速找出最重的资源Lighthouse 性能审计给出整体性能得分与资源量诊断WebPageTest提供更细粒度的资源分解与瀑布图。SKILL.md 中强调的测量原则也值得记住在给出优化建议前先确认真正的瓶颈在 DevTools、Lighthouse 或现场数据中确实存在而不是凭直觉下手。六、图片优化削减页面重量的大头图片占整页重量的 50–70%是优化的第一优先级。规则文档给出的 Next.js 方案分为两层自动图片优化配置 组件层面的响应式图片。6.1 自动图片优化配置// next.config.js - automatic image optimization module.exports { images: { formats: [image/avif, image/webp], deviceSizes: [640, 750, 828, 1080, 1200, 1920], minimumCacheTTL: 60 * 60 * 24 * 365, // 1 year } }配置含义formats允许的图片格式列表avif与webp在同等视觉质量下体积远小于 JPEG/PNG浏览器会自动选择支持的最优格式deviceSizes响应式图片的候选断点宽度列表next/image会根据视口宽度从该列表中挑选最合适的尺寸生成图片避免移动端加载桌面级大图minimumCacheTTL图片缓存的最短时长这里设置为一年60 * 60 * 24 * 365秒让优化后的图片在浏览器/CDN 层长期复用。Front-End-Checklist 自己的 Web 应用就在实践中使用了这套配置apps/web/next.config.js 中声明了formats: [image/avif, image/webp]、deviceSizes: [640, 828, 1200, 1920]并补充了imageSizes: [32, 64, 128, 256]面向图标、缩略图等小图以及remotePatterns白名单仅允许从 GitHub 头像与 OpenCollective 图片域名加载远程图片进一步约束了不可控资源的引入。6.2 组件层面的响应式图片// Component with optimized images import Image from next/image function ProductCard({ image, name }: { image: string; name: string }) { return ( Image src{image} alt{name} width{300} height{200} loadinglazy sizes(max-width: 640px) 100vw, 300px / ) }要点width/height 必须显式指定为图片预留布局空间避免加载后发生布局偏移CLSloadinglazy视口外图片延迟加载减少首屏传输量sizes告诉浏览器在不同视口宽度下图片的展示宽度配合srcset由浏览器挑选最合适的尺寸避免小屏下载大图。这与仓库中同属performance/assets的 optimized、srcset 等图片规则在目录上是姊妹关系packages/content/rules/en/images/分类实践时通常一起检查。七、JavaScript 瘦身代码分割 懒加载JavaScript 是页面重量的第二大来源。规则文档给出两条路径构建期的手动分包Vite与运行期的动态导入React。7.1 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把体积大且变动少的第三方依赖拆成独立 chunk利用长效缓存让用户只下载一次将图表类库如 recharts、d3单独拆出只有用到图表的页面才需要加载chunkSizeWarningLimit: 200以 200KB 为阈值任何 chunk 超出即给出构建警告——这正是把第三节的JavaScript 200KB预算下沉到构建工具里的做法。7.2 React 动态导入// Dynamic imports for code splitting import { 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 ) }lazy()让组件代码在首次渲染时才加载Suspense提供加载占位。这样重组件只在需要时进入主包首屏 JavaScript 显著减少。对于 Next.js 项目js-file-size.mdx 给出了等价写法——next/dynamicimport dynamic from next/dynamic const HeavyComponent dynamic(() import(./HeavyComponent), { loading: () pLoading.../p, })7.3 配套手段Tree Shaking 与依赖审计同规则还强调了三项配套实践Tree Shaking确保 Webpack/Vite/Rollup 移除未使用的导出。只引入需要的函数import { format } from date-fns而不是整个库import _ from lodash依赖审计用bundle-analyzer类工具找出重量级依赖压缩始终用 Gzip 或 Brotli 提供 JS。Front-End-Checklist 自身也在配置层面实践了这些原则apps/web/next.config.js 通过experimental.optimizePackageImports对lucide-react、radix-ui/react-icons等图标库做按需打包优化并通过compiler.removeConsole在生产构建中移除console.log同时利用cacheComponents: true启用组件缓存、以transpilePackages控制 monorepo 内部包的转译粒度。八、CSS 优化消除渲染阻塞资源CSS 是渲染阻塞资源——浏览器必须先下载并解析完 CSS 才能开始绘制像素因此 CSS 文件越精简FCP首次内容绘制越快。规则文档给出的优化思路/* 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 清除未用样式框架类 CSSTailwind、Bootstrap通常包含大量实际用不到的类css-file-size.mdx 给出了具体的 postcss 配置示例通过content扫描源码文件来剔除未使用的规则CSS 自定义属性用--color-primary、--spacing-md这类变量统一维护设计令牌消除重复声明减小文件体积避免整体引入大框架若只用其中几个组件就不要整个引入 Bootstrap/Foundation 的 CDN 文件按路由拆分不要交付一个巨大的app.css只在需要的页面加载对应的样式表。该规则还提醒裁剪后务必用 PageSpeed Insights 或浏览器 Coverage 面板验证确认路由实际少发了渲染阻塞代码而不是仅仅重新组织了样式。构建侧则建议启用 CSSNano 等压缩器并避免预处理器中的深层嵌套会生成冗长选择器、增大体积。九、字体优化别让字体吃掉 100KB字体通常占整页重量的 5–10%优化空间主要在子集化与加载策略/* 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; }unicode-range 子集化只包含页面实际用到的字符集如拉丁字符U0000-007F, U0080-00FF浏览器按需下载对应子集中文字体更应做子集拆分font-display: swap字体加载期间先用回退字体渲染文本避免不可见文本闪烁FOIT阻塞首屏内容系统字体栈完全规避自定义字体下载代价是视觉一致性略降适合对品牌字体不敏感的站点优先 woff2WOFF2 是压缩率最高的现代字体格式Front-End-Checklist 仓库 apps/web/public 目录下的字体资源即采用.ttf之外的现代实践规则层面则明确建议woff2。十、CI/CD 性能预算让 1500KB 成为硬性门槛人工检查会随代码演进而退化规则文档因此强调在 CI 中设置性能预算让超重的构建直接失败。10.1 Lighthouse 预算配置// 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 }, ] } ] } }这份配置把第三节的基准表直接翻译成了机器可判定的预算resourceTypebudget对应基准表中的目标值total500KB整页 500KBscript200KBJavaScript 200KBimage200KB图片 200KBstylesheet50KBCSS 50KBfont100KB字体 100KB10.2 GitHub Actions 集成# GitHub Actions performance check - name: Run Lighthouse uses: treosh/lighthouse-ci-actionv10 with: budgetPath: ./lighthouse-budget.json uploadArtifacts: truebudgetPath指向预算文件uploadArtifacts: true会把审计报告作为构建产物上传便于团队追溯。规则文档的自动化检查清单还包括查看 Network 面板按 Size 排序、运行 Lighthouse 性能审计、用 WebPageTest 做详细分解以及在 CI 中配置性能预算。10.3 人工/持续监测RUMReal User Monitoring监控真实用户的页面重量与加载表现捕捉实验室环境测不到的弱网长尾相邻规则 page-load-time.mdx 同样建议在 CI/CD 中建立性能预算两条规则在仓库中互为补充后者更关注端到端加载时间。十一、验证闭环如何确认整改生效规则文档给出完整的验收清单自动化检查在 Lighthouse、PageSpeed Insights 或 DevTools 中测量受影响页面确认目标指标确实改善检查网络瀑布图或性能时间线确认预期的资源/执行变更真正生效在 CI 中运行性能预算让超重构建失败。人工检查在节流的移动网络配置throttled mobile profile下验证而不是只在本地桌面环境如果规则对应某个预算或 Web Vital确认页面持续处于阈值内用 RUM 持续监测捕捉真实用户的分布情况。这与 SKILL.md 的定位一致这条规则是high优先级、beginner难度、约 20 分钟即可完成一次完整整改的高杠杆项且 Front-End-Checklist 在性能速赢清单 performance-quick-wins.mdx 中把它列为先做这些的起点——先解决图片传输、代码压缩、缓存与加载顺序这些高收益低风险的项再进入框架级微优化。十二、延伸阅读仓库内的相关规则在 Front-End-Checklist 仓库中page-weight规则通过relatedRules与以下规则建立关联建议组合使用js-file-size单个 JS 包压缩后控制在 200KB 内涉及代码分割、Tree Shaking 与依赖审计css-file-sizeCSS 文件应精简且去除未用样式涉及 PurgeCSS、CSSNano 与按路由拆分http-requests请求数量与页面重量共同决定加载体验compressionGzip/Brotli 压缩是削减传输字节数的最快手段速赢清单 performance-quick-wins.mdx上述规则的组合执行入口Agent 技能封装 skills/page-weight/SKILL.md面向自动化审计的 check/fix/explain/codeReview 四段式操作指南。一句话总结以 500KB 为努力目标、1500KB 为容忍上限先称重量Performance API Network 面板、再砍大头图片 → JS → CSS → 字体最后用 CI 预算把结论固化下来——这就是 Front-End-Checklist 给页面瘦身留下的完整闭环。【免费下载链接】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），仅供参考 
长河君 · 2026/9/19 10:11:46 · 阅读 1.2k Front-End-Checklist 页面重量优化实战：把整页资源控制在 1500KB 以内
Front-End-Checklist 页面重量优化实战把整页资源控制在 1500KB 以内【免费下载链接】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是指渲染一个页面所需的全部资源的总大小它直接决定了用户在弱网环境下的加载体验。本文以 Front-End-Checklist 仓库中 performance 分类下的page-weight规则为核心系统讲解 500KB 目标值 / 1500KB 上限的基准划分、典型资源占比、JavaScript/CSS/字体三大优化手段以及如何在 CI/CD 中落地性能预算读完即可在你的项目里建立一套可度量的页面瘦身流程。一、规则解读这条规则到底在检查什么在 Front-End-Checklist 仓库中page-weight规则同时以两种形式存在一种是面向人类读者的规范文档 packages/content/rules/en/performance/page-weight.mdx另一种是面向 Agent 的技能封装 skills/page-weight/SKILL.md。两者核心判定一致包含全部资源在内的整页重量应低于 1500KB理想状态低于 500KB。SKILL.md 的元数据给出了这条规则的定位priority: high高优先级、difficulty: beginner入门难度、estimatedTime: 20约 20 分钟可完成整改。它被归类到performance分类下的assets资源子类对应的检查思路是Check检查分析整页所有资源的总大小确认是否低于 1500KB理想为 500KBFix修复通过图片优化、代码压缩、移除不必要的资源来降低总重量Explain解释说明页面重量如何影响加载时间尤其在移动网络上以及如何影响用户体验Code Review评审审查影响该指标的路由、资源与加载行为明确指出增加网络、CPU 或布局开销的具体文件、请求或渲染步骤并说明用于确认问题的测量方法。这条规则在仓库的检查清单体系中也占据核心位置packages/content/checklists/en/performance-quick-wins.mdx 将performance/page-weight与compression、browser-caching、http-requests、lazy-loading、resource-hints、optimized、cdn一起列为绩效速赢Quick Wins项——这些优化投入小、收益大是开展深度 Core Web Vitals 排查之前的首选起点。二、为什么它在高优先级页面重量与加载时间的正相关规则文档用一组直观的数据说明了背景一个 1.5MB 的页面在 4G 移动网络下需要 3–5 秒才能加载完成每减少 100KB 都能显著改善用户体验尤其是在慢速网络上。原因在于页面重量与实际加载时间直接相关资源越大网络传输耗时越长而移动设备不仅网络带宽有限CPU 解析和执行 JavaScript 的能力也远弱于桌面设备。与之相邻的 js-file-size 规则进一步补充了这条因果链的细节JavaScript 与图片不同图片只需解码而 JavaScript 必须经历下载、解析、编译、执行四个阶段一个 1MB 的脚本在旗舰手机上解析可能只需 1 秒在低端设备上却可能要 10 秒。交互指标FID/INP又是 Google Core Web Vitals 的组成部分直接影响搜索排名。因此页面重量不只是体感问题它同时牵动用户体验、数据流量成本对按流量计费的用户尤其关键和 SEO。三、重量基准表按资源类型划分的目标线规则文档给出了完整的基准表格这是把页面重量从抽象概念变成可执行检查项的关键类别目标Target可接受Acceptable差Poor整页总计 500KB 1500KB 1500KBHTML 50KB 100KB 100KBCSS 50KB 100KB 100KBJavaScript 200KB 400KB 400KB图片 200KB 500KB 500KB字体 100KB 200KB 200KB需要特别说明这里的大小通常指**传输后压缩后**的大小。相邻规则 js-file-size.mdx 中明确标注了Keep individual JS bundles under 200KB (compressed)单个 JS 包压缩后低于 200KBcss-file-size.mdx 同样以 gzip 后 50KB 作为 CSS 的参考上限。在做预算或验收时应统一采用 Gzip/Brotli 压缩后的传输尺寸口径。四、典型的页面重量构成优化优先级从哪来规则文档给出的典型构成占比是制定优化顺序的依据资源类型平均占比优化优先级图片50–70%高JavaScript15–25%高CSS5–10%中字体5–10%中HTML2–5%低这组数据直接给出了行动顺序图片通常是最大的体重来源JavaScript 是第二大来源。性能速赢清单 performance-quick-wins.mdx 中也有呼应——Images and other heavy assets are often the largest contributors to page weight. Reduce transfer cost before chasing framework-level micro-optimizations图片和其他重型资源往往是页面重量最大的贡献者在追求框架级微优化之前先降低传输成本。五、先测量再优化如何准确称出页面重量规则文档提供了一个可直接运行的测量脚本利用浏览器 Performance API 按资源类型拆分整页重量// 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 } }脚本要点数据来源performance.getEntriesByType(navigation)[0].transferSize提供 HTML 文档的传输大小performance.getEntriesByType(resource)覆盖页面发起的全部子资源请求传输大小transferSize是网络层实际传输的字节数已含压缩效果比encodedBodySize更贴近用户真实消耗的流量分类规则依据initiatorType如css、script、img与 URL 扩展名双通道判定资源归属未命中的归入other输出以 KB 为单位汇总各分类与总量并返回{ total, breakdown }供后续集成。除了脚本规则文档还推荐了三种测量手段可按需选用浏览器 Network 面板按 Size 列排序快速找出最重的资源Lighthouse 性能审计给出整体性能得分与资源量诊断WebPageTest提供更细粒度的资源分解与瀑布图。SKILL.md 中强调的测量原则也值得记住在给出优化建议前先确认真正的瓶颈在 DevTools、Lighthouse 或现场数据中确实存在而不是凭直觉下手。六、图片优化削减页面重量的大头图片占整页重量的 50–70%是优化的第一优先级。规则文档给出的 Next.js 方案分为两层自动图片优化配置 组件层面的响应式图片。6.1 自动图片优化配置// next.config.js - automatic image optimization module.exports { images: { formats: [image/avif, image/webp], deviceSizes: [640, 750, 828, 1080, 1200, 1920], minimumCacheTTL: 60 * 60 * 24 * 365, // 1 year } }配置含义formats允许的图片格式列表avif与webp在同等视觉质量下体积远小于 JPEG/PNG浏览器会自动选择支持的最优格式deviceSizes响应式图片的候选断点宽度列表next/image会根据视口宽度从该列表中挑选最合适的尺寸生成图片避免移动端加载桌面级大图minimumCacheTTL图片缓存的最短时长这里设置为一年60 * 60 * 24 * 365秒让优化后的图片在浏览器/CDN 层长期复用。Front-End-Checklist 自己的 Web 应用就在实践中使用了这套配置apps/web/next.config.js 中声明了formats: [image/avif, image/webp]、deviceSizes: [640, 828, 1200, 1920]并补充了imageSizes: [32, 64, 128, 256]面向图标、缩略图等小图以及remotePatterns白名单仅允许从 GitHub 头像与 OpenCollective 图片域名加载远程图片进一步约束了不可控资源的引入。6.2 组件层面的响应式图片// Component with optimized images import Image from next/image function ProductCard({ image, name }: { image: string; name: string }) { return ( Image src{image} alt{name} width{300} height{200} loadinglazy sizes(max-width: 640px) 100vw, 300px / ) }要点width/height 必须显式指定为图片预留布局空间避免加载后发生布局偏移CLSloadinglazy视口外图片延迟加载减少首屏传输量sizes告诉浏览器在不同视口宽度下图片的展示宽度配合srcset由浏览器挑选最合适的尺寸避免小屏下载大图。这与仓库中同属performance/assets的 optimized、srcset 等图片规则在目录上是姊妹关系packages/content/rules/en/images/分类实践时通常一起检查。七、JavaScript 瘦身代码分割 懒加载JavaScript 是页面重量的第二大来源。规则文档给出两条路径构建期的手动分包Vite与运行期的动态导入React。7.1 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把体积大且变动少的第三方依赖拆成独立 chunk利用长效缓存让用户只下载一次将图表类库如 recharts、d3单独拆出只有用到图表的页面才需要加载chunkSizeWarningLimit: 200以 200KB 为阈值任何 chunk 超出即给出构建警告——这正是把第三节的JavaScript 200KB预算下沉到构建工具里的做法。7.2 React 动态导入// Dynamic imports for code splitting import { 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 ) }lazy()让组件代码在首次渲染时才加载Suspense提供加载占位。这样重组件只在需要时进入主包首屏 JavaScript 显著减少。对于 Next.js 项目js-file-size.mdx 给出了等价写法——next/dynamicimport dynamic from next/dynamic const HeavyComponent dynamic(() import(./HeavyComponent), { loading: () pLoading.../p, })7.3 配套手段Tree Shaking 与依赖审计同规则还强调了三项配套实践Tree Shaking确保 Webpack/Vite/Rollup 移除未使用的导出。只引入需要的函数import { format } from date-fns而不是整个库import _ from lodash依赖审计用bundle-analyzer类工具找出重量级依赖压缩始终用 Gzip 或 Brotli 提供 JS。Front-End-Checklist 自身也在配置层面实践了这些原则apps/web/next.config.js 通过experimental.optimizePackageImports对lucide-react、radix-ui/react-icons等图标库做按需打包优化并通过compiler.removeConsole在生产构建中移除console.log同时利用cacheComponents: true启用组件缓存、以transpilePackages控制 monorepo 内部包的转译粒度。八、CSS 优化消除渲染阻塞资源CSS 是渲染阻塞资源——浏览器必须先下载并解析完 CSS 才能开始绘制像素因此 CSS 文件越精简FCP首次内容绘制越快。规则文档给出的优化思路/* 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 清除未用样式框架类 CSSTailwind、Bootstrap通常包含大量实际用不到的类css-file-size.mdx 给出了具体的 postcss 配置示例通过content扫描源码文件来剔除未使用的规则CSS 自定义属性用--color-primary、--spacing-md这类变量统一维护设计令牌消除重复声明减小文件体积避免整体引入大框架若只用其中几个组件就不要整个引入 Bootstrap/Foundation 的 CDN 文件按路由拆分不要交付一个巨大的app.css只在需要的页面加载对应的样式表。该规则还提醒裁剪后务必用 PageSpeed Insights 或浏览器 Coverage 面板验证确认路由实际少发了渲染阻塞代码而不是仅仅重新组织了样式。构建侧则建议启用 CSSNano 等压缩器并避免预处理器中的深层嵌套会生成冗长选择器、增大体积。九、字体优化别让字体吃掉 100KB字体通常占整页重量的 5–10%优化空间主要在子集化与加载策略/* 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; }unicode-range 子集化只包含页面实际用到的字符集如拉丁字符U0000-007F, U0080-00FF浏览器按需下载对应子集中文字体更应做子集拆分font-display: swap字体加载期间先用回退字体渲染文本避免不可见文本闪烁FOIT阻塞首屏内容系统字体栈完全规避自定义字体下载代价是视觉一致性略降适合对品牌字体不敏感的站点优先 woff2WOFF2 是压缩率最高的现代字体格式Front-End-Checklist 仓库 apps/web/public 目录下的字体资源即采用.ttf之外的现代实践规则层面则明确建议woff2。十、CI/CD 性能预算让 1500KB 成为硬性门槛人工检查会随代码演进而退化规则文档因此强调在 CI 中设置性能预算让超重的构建直接失败。10.1 Lighthouse 预算配置// 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 }, ] } ] } }这份配置把第三节的基准表直接翻译成了机器可判定的预算resourceTypebudget对应基准表中的目标值total500KB整页 500KBscript200KBJavaScript 200KBimage200KB图片 200KBstylesheet50KBCSS 50KBfont100KB字体 100KB10.2 GitHub Actions 集成# GitHub Actions performance check - name: Run Lighthouse uses: treosh/lighthouse-ci-actionv10 with: budgetPath: ./lighthouse-budget.json uploadArtifacts: truebudgetPath指向预算文件uploadArtifacts: true会把审计报告作为构建产物上传便于团队追溯。规则文档的自动化检查清单还包括查看 Network 面板按 Size 排序、运行 Lighthouse 性能审计、用 WebPageTest 做详细分解以及在 CI 中配置性能预算。10.3 人工/持续监测RUMReal User Monitoring监控真实用户的页面重量与加载表现捕捉实验室环境测不到的弱网长尾相邻规则 page-load-time.mdx 同样建议在 CI/CD 中建立性能预算两条规则在仓库中互为补充后者更关注端到端加载时间。十一、验证闭环如何确认整改生效规则文档给出完整的验收清单自动化检查在 Lighthouse、PageSpeed Insights 或 DevTools 中测量受影响页面确认目标指标确实改善检查网络瀑布图或性能时间线确认预期的资源/执行变更真正生效在 CI 中运行性能预算让超重构建失败。人工检查在节流的移动网络配置throttled mobile profile下验证而不是只在本地桌面环境如果规则对应某个预算或 Web Vital确认页面持续处于阈值内用 RUM 持续监测捕捉真实用户的分布情况。这与 SKILL.md 的定位一致这条规则是high优先级、beginner难度、约 20 分钟即可完成一次完整整改的高杠杆项且 Front-End-Checklist 在性能速赢清单 performance-quick-wins.mdx 中把它列为先做这些的起点——先解决图片传输、代码压缩、缓存与加载顺序这些高收益低风险的项再进入框架级微优化。十二、延伸阅读仓库内的相关规则在 Front-End-Checklist 仓库中page-weight规则通过relatedRules与以下规则建立关联建议组合使用js-file-size单个 JS 包压缩后控制在 200KB 内涉及代码分割、Tree Shaking 与依赖审计css-file-sizeCSS 文件应精简且去除未用样式涉及 PurgeCSS、CSSNano 与按路由拆分http-requests请求数量与页面重量共同决定加载体验compressionGzip/Brotli 压缩是削减传输字节数的最快手段速赢清单 performance-quick-wins.mdx上述规则的组合执行入口Agent 技能封装 skills/page-weight/SKILL.md面向自动化审计的 check/fix/explain/codeReview 四段式操作指南。一句话总结以 500KB 为努力目标、1500KB 为容忍上限先称重量Performance API Network 面板、再砍大头图片 → JS → CSS → 字体最后用 CI 预算把结论固化下来——这就是 Front-End-Checklist 给页面瘦身留下的完整闭环。【免费下载链接】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），仅供参考