从旅程开始，而不是站点平均值
列出三到五个延迟会带来明显客户或运营成本的旅程：进入活动页面、查找商品、提交潜在客户表单、登录或完成支持请求。对于每个旅程，写明起点、有意义的成果、主要设备类型，以及必须正常工作的页面或交互。
为每个旅程单独建立预算行。仪表盘可能包含比公开文章更多的代码，但其筛选动作仍需响应性目标。以丰富媒体为主的产品页或许能接受更大的图片，但需要对主要可见图片设定限制。这样可防止关键路径在整体来源平均值中被掩盖。
明确访问者能看到或能做什么，例如阅读要约、看到搜索结果或收到表单确认。
缓存会显著改变资源成本，所以记录预算是否涵盖首次访问、重复访问或两者。
选择结果指标与可控输入
同时使用结果类指标和输入限制。Google 将 Largest Contentful Paint（LCP）描述为加载性能；Interaction to Next Paint（INP）描述交互响应性；Cumulative Layout Shift（CLS）描述视觉稳定性。其推荐的良好阈值是：LCP 在 2.5 秒或更低，INP 在 200 毫秒或更低，CLS 在 0.1 或更低，均按第75百分位分别衡量移动端和桌面端。
添加能及早暴露原因的限制：初始 JavaScript、主内容呈现前所需的图片、该路径的总传输量、第三方请求和已知的昂贵组件。持续以压缩后的传输大小为准进行跟踪。像 Time to First Byte 这样的诊断可以帮助调查慢加载，但它本身并不是客户感知的结果指标。
当旅程依赖于主内容可见时，使用 LCP 。
对搜索、筛选、菜单和结算使用字段 INP；在没有字段数据时再用实验室代理。
对初始路由和最大贡献者设上限，让责任方知道违规后必须改变什么。
以基线数据设定数值
为每个旅程采集基线。在 PageSpeed Insights 中，要区分 Chrome User Experience Report（CrUX）字段数据，它聚合了真实 Chrome 用户的体验，与 Lighthouse 实验室数据——后者是受控测试。字段数据核验到达用户的真实体验；实验室测试可在发布前让改动可重复。
至少按移动与桌面分割，并在可能的情况下按关键模板或 URL 细分。PageSpeed Insights 在 URL 数据缺失时可回退到来源（origin）数据，有些页面没有 CrUX 数据。把这种情况标注为实验室基线，并为重要旅程增加真实用户度量。为每个基线保存测试 URL、设备与网络配置、缓存状态、日期和工具版本。
选择一个在基线基础上有计划性改进的目标，然后在代表性环境中测试它。一个阻止正常发布的预算会被绕过；而高于当前体验的预算则无保护作用。
第75百分位是指 75% 的观测体验在该值或以下；它不是平均值。
把预算作为发布规则
把预算放在版本控制且可审阅的位置，放在代码或发布检查表旁。每一行需要写明旅程、指标、测试配置或受众、警告阈值、错误阈值、负责人、测量方法和例外途径。MDN 建议设定警告与错误级别：警告用于主动规划，错误是具有明显负面影响的上限。
实现自动化的可靠检查。打包器可以拒绝过大的资产或初始入口点；webpack 支持最大资产与入口点限制以及用于生产环境的错误提示。在拉取请求或候选发布中对受影响旅程运行可重复的实验室测试。将字段指标用于发布后验证与优先级判定，而不要把它们当作不可靠的构建门控。
当某个限制失败时，减少某个资产、推迟非必要代码、改变体验、拆分发布或批准例外。不要在暗中提高阈值以通过构建。
在发布前记录产品与技术负责人、客户影响、到期日和修复任务。
对受保护旅程在可复现的错误阈值上阻断发布；对警告阈值进行通知与调查。
发布后验证与修复
页面体量并不能完整预测最终体验。请求顺序、阻塞渲染的工作、设备能力、网络条件、缓存和第三方也同样重要。保留输入限制以捕捉增长，并用结果度量测试路径是否可用。W3C Resource Timing 接口公开资源的时序与传输、编码和解码后的大小，便于更深入诊断。跨域时序细节可能被 timing permissions 限制，因此不完整的水瀑流并不能证明没有第三方成本。
在重要模板、平台、营销标签或流量变化后审查字段结果。如果 LCP 变差，检查服务器响应、LCP 资源与阻塞渲染的工作。如果 INP 变差，检查实际交互；Lighthouse 无法测量 INP 因为缺乏用户输入，但 Total Blocking Time 可作为实验室代理。使用 SIU 的主动优化工作流对违规进行分诊、稳定关键路径，并在相同的测量上下文中验证修复。
过期的例外会快速揭示临时性能债务已变为永久负担。