Coze自动化工作流与Agent智能体实战指南
2026/9/20 8:25:11
【免费下载链接】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 仓库中
page-load-time（页面加载时间）规则展开，该规则属于performance分类、web-vitals子类，优先级为 high、难度为 intermediate、预计耗时 30 分钟，其核心要求是：在标准网络连接下，页面完全加载时间需控制在 3 秒以内。读完本文，你将掌握 3 秒阈值的业务影响与量化基准、关键渲染路径与 JavaScript/图片/服务端的四大优化手段、React 渲染性能模式，以及基于 Performance API 的精确测量与 CI 验证方案。
规则完整定义位于 skills/page-load-time/references/rule.md，对应的仓库规则内容为 packages/content/rules/en/performance/page-load-time.mdx，Agent 使用时可通过 skills/page-load-time/SKILL.md 中的 Check → Fix → Explain → Code Review 四步流程落地审查。
一、规则核心：3 秒阈值与审查流程
1.1 规则的定位与判定标准
从 packages/content/rules/en/performance/page-load-time.mdx 的 frontmatter 可以看出，该规则的判定非常简单直白：
Check：在标准连接下测量页面加载时间，验证其是否在 3 秒以内。
整个规则围绕三个 prompt 展开：
| 环节 | 动作 |
|---|---|
| Check（检查） | 在标准连接下测量页面加载时间并验证是否低于 3 秒 |
| Fix（修复） | 通过懒加载、CDN、缓存策略与资源优化来降低加载时间 |
| Explain（解释） | 解释加载时间如何影响跳出率、SEO 排名与用户满意度 |
此外，SKILL.md 还额外提供了Code Review环节：审查路由、资源与加载行为中影响加载时间的因素，精确指出增加不必要网络、CPU 或布局开销的文件、请求或渲染步骤，并描述用于确认问题的测量方法。
1.2 为什么是 3 秒
规则在whyItMatters字段中给出了核心依据：
研究表明，53% 的移动端用户会放弃加载超过 3 秒的网站——缓慢的页面会直接损害转化率、用户参与度和 SEO 排名。
这一结论也被 SKILL.md 的 Quick Reference 收录，并补充了两条关键行动要点：
- 3 秒是跳出率急剧飙升的阈值；
- 聚焦 Core Web Vitals：LCP、FID/INP、CLS；
- 在节流 3G（throttled 3G）条件下测试，以模拟真实网络环境。
二、加载时间的影响量化：跳出率与转化率
规则给出了详细的加载时间与业务指标对照表，这是制定性能预算（performance budget）时最直接的参考依据：
| 加载时间 | 跳出率 | 转化率影响 |
|---|---|---|
| 1–2s | ~9% | 基线 |
| 2–3s | ~13% | -7% 转化 |
| 3–5s | ~25% | -16% 转化 |
| 5–10s | ~38% | -35% 转化 |
| 10s+ | ~50%+ | 严重影响 |
从表格可以直观看到，从 2–3 秒区间跨越到 3–5 秒区间时，跳出率从 ~13% 跃升到 ~25%，转化率下跌 16%——这正是 3 秒成为硬性阈值的业务逻辑所在。
三、需要衡量的关键指标与基准
"页面加载时间"并非单一指标，规则给出了完整的分段衡量维度。下表来自 rule.md 的 Key Metrics 部分，用 Good / Needs Work / Poor 三档给出了可直接落地的基准：
| 指标 | Good | Needs Work | Poor |
|---|---|---|---|
| Time to First Byte（TTFB） | < 200ms | < 500ms | > 500ms |
| First Contentful Paint（FCP） | < 1.8s | < 3s | > 3s |
| Largest Contentful Paint（LCP） | < 2.5s | < 4s | > 4s |
| Time to Interactive（TTI） | < 3.8s | < 7.3s | > 7.3s |
| Full Page Load（完整加载） | < 3s | < 5s | > 5s |
其中 LCP、CLS、INP 属于 Google 的 Core Web Vitals。仓库在 packages/content/checklists/en/core-web-vitals.mdx 中给出了这三项的目标值：
- LCP（最大内容绘制）：衡量加载性能，目标2.5 秒以内，通常由 hero 图片、标题或视频封面触发；
- CLS（累积布局偏移）：衡量视觉稳定性，目标0.1 以内，常由无尺寸图片、动态内容或晚加载字体引起；
- INP（交互到下一帧绘制）：衡量响应性，目标200ms 以内，自 2024 年 3 月起取代 FID。
Front-End-Checklist 的 Core Web Vitals 清单将page-load-time与 largest-contentful-paint、first-contentful-paint、interaction-to-next-paint、cumulative-layout-shift、lazy-loading 等规则编入同一检查清单，审计加载时间时通常需要与这些规则配合使用。
四、优化手段一：关键渲染路径（Critical Rendering Path）
规则给出的第一个优化方向是缩短从 HTML 到达浏览器到首屏可交互之间的关键渲染路径，核心代码示例位于 rule.md：
<!DOCTYPE html> <html> <head> <!-- Preconnect to critical origins --> <link rel="preconnect" href="https://fonts.googleapis.com"> <link rel="preconnect" href="https://cdn.example.com" crossorigin> <!-- Preload critical resources --> <link rel="preload" href="/critical.css" as="style"> <link rel="preload" href="/hero.webp" as="image"> <!-- Inline critical CSS --> <style>/* Critical above-fold styles */</style> <!-- Defer non-critical CSS --> <link rel="stylesheet" href="/main.css" media="print" onload="this.media='all'"> </head> </html>四个技巧的要点拆解：
preconnect：提前建立与关键第三方源（字体服务、CDN）的 TCP/TLS 连接，消除握手延迟；带crossorigin属性用于跨源请求（如字体）；preload：让浏览器尽早下载首屏关键资源（关键 CSS、LCP 图片），并使用as声明资源类型以便正确调度优先级；- 内联关键 CSS：将首屏（above-the-fold）样式直接写入
<style>，避免首屏渲染等待外部 CSS 请求； - 延迟非关键 CSS：通过
media="print"+onload技巧让非关键样式异步加载（media='all'切换后立即生效），避免阻塞渲染。
关于 preconnect/preload 的进一步细节，仓库在 resource-hints 与 preconnect 两条规则中有专门展开。
五、优化手段二：JavaScript 加载策略
JavaScript 是阻塞渲染的头号因素。规则给出了三种加载方式的选型对照：
<!-- Defer non-critical JavaScript --> <script src="/app.js" defer></script> <!-- Async for independent scripts --> <script src="/analytics.js" async></script> <!-- Module scripts are deferred by default --> <script type="module" src="/module.js"></script>defer：脚本在 HTML 解析完成后、DOMContentLoaded之前按顺序执行，适合与 DOM 有依赖关系的业务脚本；async：下载完成后立即执行，不保证顺序，适合完全独立、无需等待 DOM 的脚本（如埋点统计）；type="module"：ES Module 脚本默认具备 defer 语义，天然延迟执行，且支持import语法。
与渲染阻塞相关的完整治理策略，可参见仓库中的 render-blocking、duplicate-js 与 legacy-js 规则。
六、优化手段三：图片优化
图片通常是页面权重与 LCP 的最大贡献者。规则以 Next.js 的自动图片优化为例给出了标准写法（完整版见 page-load-time.mdx）：
// Next.js automatic image optimization import Image from 'next/image' function Hero() { return ( <Image src="/hero.jpg" width={1200} height={600} priority // Load immediately for LCP placeholder="blur" blurDataURL="data:image/jpeg;base64,/9j..." /> ) }关键参数说明：
priority：标记 LCP 图片立即加载（等效于自动附加preload与高 fetchpriority），首屏 hero 图必须使用；width/height：显式声明尺寸，预留布局空间，从根源上规避 CLS；placeholder="blur"+blurDataURL：用极小的 base64 模糊占位图提升首屏感知性能。
仓库实战佐证：Front-End-Checklist 的 Web 应用本体在 apps/web/next.config.js 中就配置了完整的图片优化管线：
images: { formats: ['image/avif', 'image/webp'], deviceSizes: [640, 828, 1200, 1920], imageSizes: [32, 64, 128, 256], remotePatterns: [ { protocol: 'https', hostname: 'avatars.githubusercontent.com', pathname: '/**' }, { protocol: 'https', hostname: 'images.opencollective.com', pathname: '/**' } ] }这份真实配置展示了三项值得照抄的实践：开启AVIF/WebP 自动协商（formats）、定义响应式断点尺寸（deviceSizes与imageSizes决定srcset生成）、通过remotePatterns白名单允许优化远程图片。同时该配置还通过compiler.removeConsole在生产环境移除console.log以减小 JS 体积。配套的图片维度规范可参见 packages/content/rules/en/images/dimensions.mdx（此处以 Core Web Vitals 清单引用的 rules 目录为准，实际路径为 packages/content/rules/en/performance/../images/dimensions.mdx）。
七、优化手段四：服务端优化（压缩与缓存头）
服务端是整条加载链路的起点——TTFB 不达标，前端再优化也无力回天。规则给出了 Express.js 下的两个经典动作：
// Enable compression // Express.js import compression from 'compression' app.use(compression()) // Set caching headers app.use('/static', express.static('public', { maxAge: '1y', immutable: true }))- 启用压缩：对文本类资源（HTML/CSS/JS/JSON）启用 gzip/brotli 压缩，显著降低传输字节数；
- 设置缓存头：静态资源使用
maxAge: '1y'+immutable: true，表示内容永不变化、无需重新验证，浏览器可直接使用本地缓存。
服务端优化的纵深知识可继续阅读仓库中的 compression、browser-caching 与 ttfb 三条规则。其中 ttfb.mdx 特别指出 TTFB 是"页面性能的地基"：它包含网络延迟与服务端处理时间，优化思路包括 CDN 边缘缓存、服务端逻辑/数据库查询优化、对不常变化的内容使用 SSG 静态生成；其验证标准是核心页面TTFB < 800ms，并需区分缓存命中与缓存未命中两种场景。
Front-End-Checklist 应用本体还在 next.config.js 中通过headers()为全站注入了安全响应头（Content-Security-Policy、X-Content-Type-Options: nosniff 等），这些头在优化过程中不应被牺牲，可作为服务端配置的附加参考。
八、React 性能模式：代码分割、记忆化与骨架屏
规则针对 React 应用给出了三个高性价比的渲染优化模式（完整代码见 page-load-time.mdx）：
import { lazy, Suspense, memo } from 'react' // Code splitting const HeavyComponent = lazy(() => import('./HeavyComponent')) // Memoize expensive components const ExpensiveList = memo(function ExpensiveList({ items }) { return items.map(item => <Item key={item.id} {...item} />) }) // Skeleton loading for perceived performance function Page() { return ( <Suspense fallback={<Skeleton />}> <HeavyComponent /> </Suspense> ) }- 代码分割（Code Splitting）：
React.lazy+ 动态import将重型组件拆成独立 chunk，仅在需要时加载，直接降低初始 JS 体积与解析成本； - 记忆化（memo）：
memo包裹昂贵列表组件，在 props 未变化时跳过重渲染，降低长列表与高频更新的 CPU 开销； - 骨架屏（Skeleton）：
Suspense的fallback在异步组件就绪前渲染占位 UI，用"感知性能"掩盖真实加载时间。
仓库在 code-splitting（此规则在 packages/content/rules 目录下）与 import-on-interaction、import-on-visibility 规则中进一步讨论了"交互时再导入"与"可见时再导入"两种按需加载策略。
九、如何精确测量加载时间
规则提供了基于Performance API的完整测量脚本（见 rule.md），可拆解加载链路的每个阶段：
// Performance API for precise measurements function measureLoadTime() { const timing = performance.getEntriesByType('navigation')[0] return { dns: timing.domainLookupEnd - timing.domainLookupStart, tcp: timing.connectEnd - timing.connectStart, ttfb: timing.responseStart - timing.requestStart, domContentLoaded: timing.domContentLoadedEventEnd - timing.fetchStart, fullLoad: timing.loadEventEnd - timing.fetchStart } } // Report to analytics window.addEventListener('load', () => { const metrics = measureLoadTime() if (metrics.fullLoad > 3000) { console.warn('Page load exceeded 3s target:', metrics) } })各阶段含义：
| 字段 | 计算方式 | 含义 |
|---|---|---|
dns | domainLookupEnd - domainLookupStart | DNS 解析耗时 |
tcp | connectEnd - connectStart | TCP 连接耗时 |
ttfb | responseStart - requestStart | 首字节到达时间 |
domContentLoaded | domContentLoadedEventEnd - fetchStart | DOM 就绪时间 |
fullLoad | loadEventEnd - fetchStart | 完整加载时间 |
脚本同时演示了监控接线方式：在load事件中比对fullLoad与 3000ms 阈值，超标即告警——这可以直接接入现有 RUM（Real User Monitoring）体系作为线上预警。
十、测试工具选型
规则给出了五款主流性能测试工具及其适用场景：
| 工具 | 适用场景 |
|---|---|
| Lighthouse | 整体性能审计 |
| WebPageTest | 详细的资源瀑布流（waterfall）分析 |
| Chrome DevTools | 实时调试 |
| PageSpeed Insights | 实验室数据 + 真实用户数据（CrUX） |
| GTmetrix | 历史趋势追踪 |
十一、验证与持续治理
自动化检查（Automated Checks）
- 使用节流 3G 模拟运行 Lighthouse（模拟真实弱网环境）；
- 从不同地理位置用 WebPageTest 测试（验证 CDN 边缘效果）；
- 通过 PageSpeed Insights 查看真实用户数据（与实验室数据相互印证）；
- 在CI/CD 中设置性能预算（performance budgets），加载时间超标即阻断发布。
手动检查（Manual Checks）
- 使用 **RUM（Real User Monitoring）**持续监控线上真实用户的加载表现。
十二、总结：把 3 秒规则接入你的性能体系
综合来看，page-load-time规则在 Front-End-Checklist 中是一个"结果指标"型规则：它的 3 秒阈值用于验收，而它的四类优化手段（关键渲染路径、JavaScript 加载、图片、服务端）加上 React 渲染模式则提供了实现路径。建议的落地顺序是：
- 先测量：用 Performance API 或 Lighthouse 拆分 TTFB/FCP/LCP/完整加载，定位最大瓶颈；
- 再优化：按"服务端 TTFB → 关键渲染路径 → 图片 → JavaScript → React 渲染"的顺序逐项治理；
- 后固化：将 3 秒阈值与 Core Web Vitals 指标写入 CI 性能预算，配合 RUM 持续监控，防止性能回归。
在审计或阅读代码时，可从 skills/page-load-time/SKILL.md 进入规则快速参考，从 packages/content/rules/en/performance/page-load-time.mdx 获取完整代码示例，再通过同目录下的 ttfb.mdx、largest-contentful-paint.mdx、lazy-loading.mdx、compression.mdx 等关联规则深入每一项子优化。
赞
【免费下载链接】Front-End-Checklist
🗂 The essential checklist for modern web development, for humans and AI agents
项目地址：https://gitcode.com/gh_mirrors/fr/Front-End-Checklist
相关推荐
页面加载时间优化实战：把网站加载控制在 3 秒内（Front-End-Checklist 性能规则全解）
页面加载时间优化实战：把网站加载控制在 3 秒内（Front End Checklist 性能规则全解） 本指南以 Front End Checklist 仓库
Front-End-Checklist 页面重量优化实战：把整页资源控制在 1500KB 以内
Front End Checklist 页面重量优化实战：把整页资源控制在 1500KB 以内 页面重量（Page Weight）是指渲染一个页面所需的全部资源
JavaScript 压缩（Minification）实战指南：基于 Front-End-Checklist 的前端性能优化规则
JavaScript 压缩（Minification）实战指南：基于 Front End Checklist 的前端性能优化规则 未压缩的 JavaScript
创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考