预算绩效管理的建议_绩效预算指标

预算绩效管理的建议

Yesterday, Chris Coyier pondered aloud the best metric to use for a performance budget:

昨天，克里斯·科耶耶(Chris Coyier)大声思考了用于绩效预算的最佳指标 ：

Re: performance budgets. I wonder if measuring times is smart or not. So many variables, seems like requests/sizes/blockers easier to track.

回复：绩效预算。 我想知道测量时间是否明智。 如此多的变量似乎更容易跟踪请求/大小/阻止程序。

It’s an interesting question, and one that I touched on at the beginning of the year. I think it’s worth elaborating on a little.

这是一个有趣的问题，我在年初就谈到了这个问题 。 我认为值得详细说明。

The purpose of a performance budget is to make sure you focus on performance throughout a project. The reason you go through the trouble in the first place though is because you want to build a site that feels fast for your visitors.

绩效预算的目的是确保您专注于整个项目的绩效。 您首先遇到麻烦的原因是因为您想建立一个对访问者来说感觉很快的网站。

One of these goals (prioritizing performance) is an internal one impacting the people who are creating the site. The other goal (building a site that feels fast) is an external one impacting people who visit your site. It’s not surprising that I’ve found the most effective metrics to differ for each.

这些目标之一(优先考虑性能)是内部目标，它会影响创建网站的人员。 另一个目标(建立一个快速访问的网站)是一个外部目标，它会影响访问您网站的人。 我发现最有效的指标各不相同也就不足为奇了。

For the purposes of this post, I’m breaking those metrics down into four categories:

出于本文的目的，我将这些指标分为四类：

1. Milestone timings

   里程碑时间

2. SpeedIndex

   速度指数

3. Quantity based metrics

   基于数量的指标

4. Rule based metrics

   基于规则的指标

里程碑时间 (Milestone timings)

Examples: Load time; domContentLoaded; Time to render 示例：加载时间； domContentLoaded; 渲染时间

Most time-based metrics are “milestone timings” (totally stealing that term from the super smart Pat Meenan). Some (like visually complete or time to interact) are closer than others to telling you something about the experience of loading a given page, but they all suffer from the same limitation: they measure performance based on a single point in time.

大多数基于时间的指标都是“里程碑时间”(完全从超级聪明的Pat Meenan 窃取该术语 )。 有些(例如视觉上的完整或交互的时间)比其他的更接近于告诉您有关加载给定页面的体验 ，但是它们都受到相同的限制：它们基于单个时间点来衡量性能。

Web performance isn’t defined by a single moment. Like a book, it’s what happens in-between that matters.

Web性能不是一瞬间就能定义的。 就像一本书一样，重要的是它们之间发生的事情。

Page A may load for 3 seconds, but not display anything to visitors until the 2.5 second mark. Page B may load in 5 seconds, but display the majority of the content after a mere second. Despite taking 2 seconds longer in total, Page B may be the better experience.

A页可能会加载3秒钟，但直到2.5秒标记才会对访问者显示任何内容。 页面B可能会在5秒钟内加载，但是仅在一秒钟后就会显示大部分内容。 尽管总共花费了2秒以上的时间，但B页可能是更好的体验。

A single milestone timing won’t help you identify that. To get a semi-accurate representation of how it feels to load a page, you have to pair several milestone timings together. You can do that, but there’s a better way (hey there, SpeedIndex).

单个里程碑时间不会帮助您识别这一点。 要获得准确的页面加载感觉的半精确表示，您必须将几个里程碑时间配对在一起。 您可以这样做，但是有更好的方法(嘿，SpeedIndex)。

Still, milestone timings as budget metrics do have advantages. They’re easy to describe. Visually complete is a pretty easy to understand even without a working knowledge of performance.

尽管如此，里程碑式的时间预算确实具有优势。 它们很容易描述。 即使没有实际的性能知识，外观也很容易理解。

They’re also easy to track. You would be hard pressed to find any sort of performance monitoring solution that doesn’t allow give you these sort of metrics.

它们也很容易跟踪。 你将很难找到任何形式的性能监控解决方案， 不允许给你这些排序指标。

It’s worth singling out User Timing marks as a better option than the default milestone metrics reported by the browser. They do require a bit more planning and setup, but because they are custom to your site they can also give a much more accurate depiction of how your page is actually rendering.

值得一提的是，用户计时标记是比浏览器报告的默认里程碑指标更好的选择。 它们确实需要更多的计划和设置，但是由于它们是针对您的网站定制的，因此它们还可以对页面的实际呈现方式进行更准确的描述。

速度指数 (SpeedIndex)

我给SpeedIndex自己的小类别，因为它值得。 传统指标仅集中在一个时刻，而SpeedIndex则尝试衡量整体体验。 它不仅关注所有内容在页面上显示所花费的时间，还关注页面从头到尾的进度。 SpeedIndex分数就像高尔夫分数：越低越好。

In our example from above, Page B would likely have a lower SpeedIndex score. It got most of the content onto the page early, so the page appears faster to load.

在上面的示例中，页面B可能具有较低的SpeedIndex得分。 它尽早将大部分内容带到了页面上，因此页面显示的加载速度更快。

SpeedIndex gets a lot of love, and for good reason. It’s the closest we can get to putting a number to how it feels to load a page. But it’s not without its faults.

SpeedIndex获得了很多爱，这是有充分理由的。 这是我们最接近加载页面感觉的数字。 但这并非没有缺点。

SpeedIndex is not the easiest of metrics to explain to someone without a certain level of technical know-how. Heck, it can be hard to explain to people with a relatively high level of technical know-how. It didn’t really click for me until I re-read Pat’s original announcement a few times and played around with it in WebPageTest.

SpeedIndex不是最简单的指标，可以向没有一定技术知识水平的人解释。 哎呀，可能很难与较高水平的技术诀窍的向人们解释。 在我重新阅读了Pat的原始声明几次并在WebPageTest中对其进行处理之前，它并没有真正吸引我。

The other downside is that at the moment it’s not a metric that gets measured by anyone outside of WebPageTest. While I would be happy if everyone would track performance using a private instance of WebPageTest, I understand that’s not likely. Hopefully Pat’s work on RUM-SpeedIndex will result in better adoption of the metric in other monitoring tools.

另一个缺点是，目前，WebPageTest之外的任何人都无法衡量该指标。 如果我很高兴每个人都可以使用WebPageTest的私有实例跟踪性能，但我知道这不太可能。 希望Pat在RUM-SpeedIndex上的工作将导致该指标在其他监视工具中得到更好的采用。

基于数量的指标 (Quantity based metrics)

Examples: Total number of requests; Overall page weight; Total image weight 示例：请求总数； 总页面重量； 图像总重量

I’m going to lump request count, page weight and the like under this third category that I just made up for the sake of having something to call them.

我将在这个第三类中汇总请求计数，页面权重之类的内容，而这些只是为了给它们打电话而已。

Weight and request count tell you virtually nothing about the resulting user experience. Two pages with the same number of requests or identical weight will render differently depending on how those resources get requested.

权重和请求计数几乎不会告诉您所获得的用户体验。 具有相同数量的请求或相同权重的两个页面将根据请求这些资源的方式呈现不同的外观。

Yet even they can play a useful role in performance budgets. Their main advantage is that they are much easier to conceptualize during design and development. It’s a lot easier to understand the impact of one more script or another heavy image on a budget of 300kb than it is for a SpeedIndex based budget.

但是，即使它们也可以在绩效预算中发挥有用的作用。 它们的主要优点是在设计和开发过程中更容易概念化。 与基于SpeedIndex的预算相比，更容易理解一个脚本或另一个沉重图像对300kb预算的影响。

基于规则的指标 (Rule based metrics)

Examples: PageSpeed score; YSlow score 示例： PageSpeed得分； Y低分

I’ve seen some people use PageSpeed or YSlow scores as budgets. For anyone unfamilar, these are awesome tools that give your site a grade based on a list of performance rules it tests against.

我见过有人将PageSpeed或YSlow得分用作预算。 对于任何不熟悉的人来说，这些都是很棒的工具，它们可以根据测试的性能规则列表为您的网站打分。

It’s really valuable as a checklist of optimizations you should probably be doing, but I think it’s less effective as a budget. While there’s a slightly stronger relation between these grades and the overall experience of loading a page than there is for quantity based metrics, it’s still a loose connection. A page with a higher PageSpeed or YSlow score doesn’t always mean the experience is better than a page with a slightly lower one.

作为您可能应该进行的优化检查清单，它确实很有价值，但我认为它作为预算的效果不佳。 尽管这些成绩与页面加载的整体体验之间的联系比基于数量的指标之间的联系要强一些，但它仍然是一个松散的联系。 具有较高PageSpeed或YSlow分数的页面并不总是意味着体验比具有较低页面体验的页面更好。

Monitoring your PageSpeed or YSlow score is a good idea, but not necessarily for your performance budget. Use these tools as a safety net for making sure you haven’t overlooked any simple optimizations.

监视您的PageSpeed或YSlow分数是个好主意，但不一定要针对您的性能预算。 使用这些工具作为安全网，以确保您没有忽略任何简单的优化。

我如何滚动 (How I roll)

My initial budget is always based on either SpeedIndex or some combination of milestone metrics. Which I use depends on the organization, what they will be using for monitoring, and how they will use the budget.

我的初始预算始终基于SpeedIndex或里程碑指标的某种组合。 我使用哪个取决于组织，他们将用于监视的对象以及他们将如何使用预算。

Regardless of the specific metric I choose, I always start here because these metrics relate in some way back to the user experience. They help keep tabs on the external goal: creating a site that feels fast for visitors. That’s what I’m most concerned with.

无论选择哪种具体指标，我总是从这里开始，因为这些指标在某种程度上与用户体验有关。 它们有助于控制外部目标：创建一个访问者感觉很快的网站。 这就是我最关心的。

These metrics get incorporated into the build process (using something like grunt-perfbudget as explained by Catherine Farman) and in the development environment (like Figure 1) to make sure they’re monitored.

这些度量被合并到构建过程中(使用Catherine Farman解释的grunt-perfbudget之类的东西)，并在开发环境中(如图1所示)以确保对其进行监视。

Figure 1: Enforcing a performance budget within Pattern Lab using some custom JavaScript.

图1：使用一些自定义JavaScript在Pattern Lab中实施性能预算。

After a few experiments to determine a rough equivalent, I pair those metrics with a quantity metric. Quantity metrics are helpful in achieving the internal goal: ensuring priority is given to performance throughout a project. They help guide design decisions. This is something Katie Kolvacin and Yesenia Perez-Cruz have each done an awesome job of discussing.

经过几次实验，确定了一个大致的等价物，然后将这些指标与数量指标配对。 数量指标有助于实现内部目标：确保在整个项目中优先考虑绩效。 它们有助于指导设计决策。 这是Katie Kolvacin和Yesenia Perez-Cruz各自进行的出色讨论。

Each of these types of metrics play different roles in guiding the creation of a site, and each is important. It doesn’t have to be an either/or proposition.

这些类型的度量标准中的每一种在指导网站创建中都扮演着不同的角色，并且每个都很重要。 它不一定是一个或非命题。

Use rule based metrics to make sure you haven’t overlooked simple optimizations.

使用基于规则的指标来确保您没有忽略简单的优化。

Use quantity based metrics as guides to help designers and developers make better decisions about what goes onto a page.

使用基于数量的指标作为指南，以帮助设计人员和开发人员对页面内容进行更好的决策。

But always back those up with a strictly enforced budget using a metric (like SpeedIndex) that is more directly related to the overall experience to ensure that the result feels fast. After all, that’s why you’ve decided to use a performance budget in the first place.

但是，请务必使用与整体体验更直接相关的指标(例如SpeedIndex)以严格执行的预算来支持那些预算，以确保快速获得结果。 毕竟，这就是为什么您决定首先使用性能预算的原因。

翻译自: https://timkadlec.com/2014/11/performance-budget-metrics/

预算绩效管理的建议