编程开发 编辑复核
Web 性能预算与瓶颈定位
从真实设备和页面任务出发制定 LCP、INP、CLS、JS、图片和接口预算，再安排低风险优化。
PROMPT WORKBENCH
复制后替换变量
保留结构，先填真实信息，再把结果交给模型运行。
你是一名Web 性能工程师。请基于真实测量数据分析瓶颈，不用实验室单次分数承诺所有用户都会获得同样提升。
先区分已知事实、合理假设和待核验信息；没有依据的内容写“待验证”，不要为了完整而猜测。
请按以下结构输出：
1. 定义设备、网络、页面和关键用户任务
2. 记录 LCP、INP、CLS、TTFB、JS、图片和接口基线
3. 按用户影响、确定性、风险和成本排序优化
4. 设计发布前后对比、分层监控和回滚门槛
输入变量：
- 页面与任务（{{page}}）：说明页面、入口和用户要完成的动作。
- 测量数据（{{measurements}}）：提供真实用户或实验室数据及采集日期。
- 资源清单（{{assets}}）：列出图片、字体、脚本和接口。
- 优化边界（{{constraints}}）：说明不能改变的视觉、功能和缓存策略。
约束：保留用户的真实语气和业务边界；把事实、推断与建议分开；涉及日期、价格、版本、法规或安全的内容写明来源和采集时间。HOW TO USE
使用说明
- 先保存基线和设备条件，再一次只改少量瓶颈。
- 用真实用户分位数和任务完成率复盘，避免只追求 Lighthouse 分数。
WHEN IT FITS
适用判断
适合这些情况
- 要给项目定性能上限，避免体积和耗时无节制增长。
- 有实测数据作为基线，知道现在处于什么水平。
- 需要把预算拆到具体资源上，能在 CI 里卡住。
换个做法更好
- 页面已经很慢，你要找原因：用《性能瓶颈定位计划》。
- 项目还没上线也没有真实用户：预算定了也没有参照。
- 你要优化的是后端接口耗时：这条针对前端资源。
FAILURE MODES
常见翻车与修正
- 预算数值是模型给的行业「标准」，和你的实际情况无关。
要求基于你提供的当前实测值来定，比如「不超过当前值」或「三个月内降到 X」，并说明依据。
- 预算只有总量，超标时不知道该砍哪块。
要求拆到资源类型（JS/CSS/图片/字体/第三方脚本），每类单独设上限。
- 定了预算但没说怎么监控。
补充要求：给出可以在 CI 或监控里落地的检查方式，以及超标时的处理流程。
ACCEPTANCE
怎么判断输出合格
- 预算数值基于你的实测基线，不是通用标准。
- 拆到了资源类型级别，超标时能定位。
- 给出了可自动化的检查方式。
- 写明了超标后的处理流程和例外审批条件。
SAFETY BOUNDARY
使用边界
- 预算数值要基于你的真实用户设备和网络分布，照搬通用指标会定出不切实际的目标。
- 模型给的优化收益是估计值，改动前先测出基线，否则无法判断优化是否真的有效。