taste-web-performance

taste-web-performance

速度也是设计的一部分。首屏区域在 900ms 时才绘制出来，而且标题发生位移，那这个首屏区域就是失败的设计。

1. 性能预算（先写下来）

以移动设备上的 p75 为目标（用普通手机，而不是你的 Mac）：

• LCP < 2.5s — 首屏文字或首屏图片必须是最大内容绘制元素，并且要快速绘制。
• CLS < 0.1 — 元素首次绘制后不得发生位移。每种字体、图片和广告尺寸的盒子都有导致 CLS 的风险。
• INP < 200ms — 点击不能被长任务阻塞；交互发生时，不能让 JS 在主线程上执行繁重工作。
• 营销页面的总页面大小 ≤ 1.5MB；“简单”页面应控制在 500KB 以下。
• 在构建说明中写明预算——没有注明预算的页面，就没有计划。

2. 字体加载（Agent 最常见的失败原因）

• 字体系列不得超过两种，样式不得超过约 4 种（设计品味技能已设置上限——在代码中严格执行）。
• 所有 Web 字体都使用 font-display: swap，且字体加载后文字不得发生位移：预留空间，或将位移控制在 ≤ 3px。
• 对首屏字体文件（仅限 woff2）使用 preload；其余字体延迟加载，或使用正确的 unicode-range 子集。
• CSS 中不得使用 @import（会阻塞渲染），不得使用阻塞首次绘制的字体加载脚本，也不得加载当前路由中页面用不到的字体。
• 如果字体包中的展示字体具有装饰性，可考虑在首屏以下的所有内容中使用系统字体回退——标题才是这款字体发挥作用的地方。

3. 图片（每张都要做出选择）

• 每张图片都要明确指定 width/height（或 aspect-ratio）——这是零成本的 CLS 修复方法。
• 格式：运行时使用 AVIF/WebP，仅在确实需要透明背景时使用 PNG；营销页面绝不能使用 2MB 的 JPEG。
• 使用 srcset/sizes 实现响应式交付；折叠线以下的所有内容都使用 loading="lazy"，LCP 图片使用 fetchpriority="high"。
• 装饰性图像应使用 CSS（渐变、噪点、图案）——如果 Agent 用 400KB 的图片来“解决”背景问题，失败的是设计，而不只是预算。
• 在标记中按正确的宽高比裁切首屏图片，而不是用 CSS 挤压图片。

4. CSS 和 JS 交付

• CSS：使用一个文件，或按路由提供关键 CSS；两段式页面不需要框架样式表，也不要使用未精简的实用工具样式大杂烩。
• JS：所有非交互关键的脚本都使用 defer；静态页面不要使用框架（落地页没有理由加载 React）。
• 关键路径中不得包含同步第三方脚本（聊天组件、分析工具）；如果要加载分析工具，应在交互后加载。
• 动画只能使用 transform/opacity（参见 taste-motion）；在滚动时为 top/width/box-shadow 设置动画只会造成卡顿，不是功能。

5. 验证流程（每次都要执行）

1. 构建后，在限速配置文件下运行 Lighthouse（移动设备、Slow 4G）——不要在本地 Mac 上运行。
2. 报告三项核心指标和页面大小。任何预算超标项都必须修复，或给出书面理由。
3. 每次更改图片或字体后都要重新检查——这两类改动最容易在悄无声息中导致性能回退。
4. prefers-reduced-motion 和离线可用的字体不是可有可无的附加项；它们是约定的一部分。

6. 检查清单（出现以下情况就判定页面不合格……）

• 加载字体时未使用 swap 且未为文字预留尺寸，或字体系列超过两种。
• 图片未指定尺寸、未确定格式，或首屏图片使用了延迟加载。
• 重新加载时出现可见的布局位移（请实际测试；位移不会主动暴露问题）。
• 存在阻塞渲染的脚本或样式表、@import，或为静态页面加载了框架。
• 页面大小或核心指标超出预算，且未说明理由。
• 未记录该页面的 Lighthouse 运行结果。
• 页面看起来经过设计，表现却像 2015 年。