如何为每位客户制定真正有效的性能预算

摘要

性能预算是一份书面协议，规定了网站需要达到的速度，由代理机构与其客户共同制定。它们防止了一种太常见的模式：在发布时优化页面，然后随着新脚本和功能的添加，页面逐渐变慢。本文中的框架为您提供了一个可重复的流程，用于在每个账户中创建、沟通和执行这些预算。您将学习如何选择真正反映访客体验的以用户为中心的指标，如何根据真实情况而不是通用清单设定阈值，以及如何将预算变成一份可见的合同。文章还涵盖了将预算嵌入交付流程、在不引发对抗性对话的情况下处理违规，以及每季度审查预算。最终结果是，页面速度不再是每月恐慌的来源，而成为您的代理机构刻意管理的一项功能。

您有多少次为客户交付了快速加载的页面，却看着它慢慢膨胀回一个缓慢、充满脚本的影子？如果您在代理机构工作，答案可能是“比我想象的要多”。模式总是一样的：您优化了首页，庆祝绿色分数，然后三个月后，客户的营销团队添加了一个新的聊天机器人脚本，增加了明显的延迟。突然间，您又回到电话上解释为什么网站感觉缓慢，尽管您已经修复了这个问题。

这不是技术失败，而是治理失败。性能被视为一次性的发布任务，而不是持续约定。解决方案是性能预算：一个书面、双方同意的限制，规定页面在被视为不合格之前允许有多重或缓慢。但预算本身只占价值的一半；真正的价值在于它迫使您和您的客户在添加新脚本、插件或功能之前，明确进行权衡。

在接下来的步骤中，我将带您了解如何为多个客户创建、沟通和执行性能预算，而无需每次都重新发明轮子。

步骤 1：选择反映用户体验的指标

性能预算只有在您限制的数字对应于客户用户感受到的内容时才有用。太多代理机构围绕单一的实验室指标（如首字节时间）设定预算，而这个指标与页面是否感觉快速没有直接关联。Google 自己的指南已经转向以用户为中心的指标，这就是为什么 Core Web Vitals 围绕诸如主要内容出现所需时间等内容构建。根据 Google 的 SEO 入门指南，页面速度是排名因素；根据 web.dev，Core Web Vitals 衡量用户体验。这些来源告诉您要选择反映用户旅程的指标，而不仅仅是服务器的响应时间。

对于大多数客户网站，从 Core Web Vitals 加上一个大致的页面权重预算开始。不要为每个页面跟踪所有指标。营销网站可能关注最大内容绘制（LCP），因为那是英雄图像出现的时候；Web 应用可能更关心交互到下一次绘制（INP），因为交互性是其全部业务。如果您需要了解这些指标，我们关于优化 Core Web Vitals 的分步指南详细介绍了相关要点。

步骤 2：根据实际情况而非基准设定预算

设想一个销售手工家具的客户。他们的受众大多在 40 岁以上，在农村连接下使用平板电脑购物。如果您从通用审计清单中复制“推荐”阈值，您设定的数字将无法反映现实。一个适用于使用 5G 的城市专业人士的目标，可能对使用 DSL 线路的人是不可能的。预算必须对实际使用网站的人有意义。

以客户最重要的最慢页面作为基线。在您的客户用户最可能使用的硬件和网络上进行测量。然后设定一个比当前状态明显更好，但又不至于激进到需要完全重建的目标。并按模板类型细分预算：结账流程的预算应比“关于”页面更严格，因为结账缓慢会直接造成收入损失。

步骤 3：让预算可见并获得批准

将您商定的预算转化为一页文档。在一面列出您设定的指标和阈值。在另一面，将这些阈值转化为平实的语言描述：绿色意味着页面加载速度足够快，访客不会离开；红色意味着需要重大改进。将其作为要求而非建议呈交给客户。获得决策者的批准，而不仅仅是联系人。

一个有用的框架是展示每个指标在用户注意力方面代价是什么。与其说“我们的 LCP 很糟糕”，不如说“主要内容加载时间太长，许多访客会放弃”。现在客户明白了利害关系。当后来有人想添加一个将页面推入红色区域的脚本时，您可以指出已签署的预算，并询问他们想削减什么。这不再是个人问题——而是你们共同达成的协议。

步骤 4：将预算嵌入交付流程

只存在于幻灯片中的预算不是预算。它必须嵌入到您构建、测试和审查页面的方式中。在 QA 流程中添加性能检查：在任何页面上线前，运行您的测量并将其与预算进行比较。如果超出预算，在有人做出权衡之前，页面不会上线。

在实践中，这意味着为每个页面分配固定的权重。图像和视频通常是最大的问题，因此制定一项政策：每个图像必须压缩，每个视频必须延迟加载，每个第三方脚本在添加前必须经过审核。客户的营销团队可能不想听到他们的新跟踪脚本必须等待，但如果它违反了预算，这就不再是一个是/否的问题；这是一个权衡。这就是预算成为您正常工作流程一部分的地方——如果您的代理机构有一个可重复的 SEO 性能工作流程，预算自然会融入其中。

步骤 5：处理违规而不指责

假设您客户方的 IT 团队添加了一个新的分析套件，给每个页面增加了大量权重。预算现在变红了。您最不应该做的就是发送一封指责性的电子邮件。相反，将预算视为中立的裁判。您不是在告诉他们“不”；您是在告诉他们“预算说不”。这将对话从个人偏好转变为客观测量。现在的任务是：我们削减什么才能回到预算内？也许新的分析套件可以配置为延迟加载，或者您可以移除一个冗余的旧脚本。

在实践中，您需要一个简单的预算违规分诊流程：确定发生了什么变化，评估影响，然后询问客户是要保留新功能还是满足预算。如果他们选择功能，他们就是正式决定退出预算。这是有价值的信息，因为它告诉您他们真正的优先事项在哪里。

步骤 6：每季度审查和修订

设置日历提醒，每季度审查每个客户的预算。网络在变化，您客户的业务在变化，您的测量数据也在变化。一年前不可能的预算现在可能很容易实现，反之亦然。使用来自分析和实验室测试的真实用户数据进行调整。在审查中，考虑下一步优先处理哪个页面；重要的慢页面不是首页。

但不要让审查成为每次有人想添加功能时放宽预算的借口。审查应基于用户体验的数据，而不是来自客户的阻力。人们很容易说“好吧，如果他们不在乎速度，我们为什么要在乎？”但研究是明确的：Google 已确认页面速度是排名因素，Core Web Vitals 是排名因素。作为代理机构，您的工作是让这一事实始终处于中心位置。

结论

性能预算不是规定性的；而是让权衡明确。当您设定预算时，您给了客户一种简单的方式来理解其数字决策的代价。当您执行预算时，您使自己免于无尽的“为什么又慢了”的电子邮件。当您审查预算时，您让网站与真实用户的需求保持一致。

从一位客户开始。应用这些步骤，总结行之有效的方法，然后将预算纳入您的标准入职套餐。几个月后，您将拥有一个可预测、可重复的流程，适用于每个账户——页面速度将不再是每月危机，而成为您的代理机构刻意管理的一项功能。