保持网页性能优化的策略

Avatar of Chris Coyier
Chris Coyier 发布

DigitalOcean 为您旅程的每个阶段提供云产品。立即开始使用 $200 免费赠送额度!

第一步是关注网站的性能。第二步是采取措施使其变得更好。第三步是长期保持性能优势。

这意味着不要只在一年中抽出几次时间来尝试改进网站的性能,而应该将其融入到您的日常开发工作中,并努力防止性能退化。当然,网站的开发越活跃,这也会变得越难。

我在这方面算不上专家。我属于那种在短时间内集中精力研究性能,然后就忘记了的人。很容易认为你已经掌握了它,现在已经没问题了。如果网络从不改变,而你再也不触碰你的网站,这将是正确的。但当然,这两件事都不太可能发生。

以下是我一直在收集的一些想法。请记住,这些都是关于保持性能优势的策略,而不是具体的性能提升技巧。

设定性能预算

也许您听说过性能预算的概念?其理念是设定一些您必须遵守的**实际数字**。可能类似于以下内容:

总页面重量 600KB
20 个请求
1000 的速度指数
1 秒的开始渲染时间

Tim Kadlec 提供了更多有关您可以选择的指标信息。以下来自 Katie Kovalcin 关于该主题的演讲中的部分内容:

有了性能预算,性能工作不再是“也许我可以看看是否能改进一些东西,让它们更快”,而是“我正在努力实现这个目标,或者修复导致我们超出预算的东西”。后者促进了我们追求的长期性能监控精神。

使用性能监控服务

SpeedCurve 是一个非常棒的工具。SpeedCurve 允许您创建非常美观且实用的仪表盘,用于监控网站性能随时间的变化。它使用功能强大的 Webpagetest,我们都了解并喜欢它,但它相当丑陋,对跟踪性能随时间的变化帮助不大。

一些随着时间推移跟踪的性能指标。

与我们保持性能优势的主题最相关的是,SpeedCurve 提供性能预算监控。您可以设置要监控的特定指标,以及当您超出预算时如何收到警报。

SpeedCurve 还有许多其他很棒的功能值得探索。例如,将您的网站与竞争对手进行比较,在不同的屏幕宽度断点处测试您的网站,在部署时测试性能,以及更多功能。


Calibreapp 是另一个用于此目的的出色网站。

您可以为特定内容设置特定的 预算,并在超出预算时收到警报。


当然,收到警报很棒。更棒的是:修复它。

突出显示性能

Lara Hogan 撰写了 《性能设计》,并担任 Etsy 的高级性能工程经理。她与我分享了 Etsy 办公室走廊的这张照片,他们放置了一台大型显示器,用于显示一些性能指标。

但请注意,这不仅仅是图表和数据…

庆祝性能胜利

Etsy 不仅会突出显示性能,Lara 还说他们有一个(季度)**性能之星**。我非常喜欢这个想法,因为它是一种积极的激励方式。如果您的团队中有人为性能做出了重大贡献,也许可以…

  • 撰写博客文章。解释他们做了什么,如何做的,以及为什么重要。
  • 对那个人表示感谢。
  • 向公司中的每个人展示。告诉全世界。

这将激励下一个有能力做同样事情的人。

建立其他激励(或惩罚)机制

当然,积极的激励机制是一个好主意。您的公司是否已经发展到可以为性能之星提供实际奖励,例如金钱或休假时间?性能提升既可以为公司带来更多利润(转化率提升),又可以节省资金(带宽),因此分享财富似乎是一个好主意。

我建议不要对性能退化采取实际上的惩罚。除了显而易见的原因(负面情绪不好)之外,它还会阻碍人们尝试新事物,还会鼓励他们在调查问题发生原因时隐瞒真相。

但也许可以采取一些折中的办法,例如建立一种“你弄坏了,你就负责”的文化。这意味着,如果您在网站的某个区域引起了问题,从现在起您就要负责监控该区域。

自动化一切

如果存在一个与性能相关的任务,它是一个明显的最佳实践,并且可以自动完成(而不是需要人来完成),那就这样做。

例如,应该优化图像。这是我们大多数人都知道应该做的事情,但为什么要手动完成呢?您的 CMS 可以自动优化您上传的图像吗?(示例)。您的构建过程可以为您完成吗?您的 DevOps 团队可以构建一些精密的工具来提供帮助吗?例如,像 ReSRC 这样的服务?

我会将任何自动获得性能提升的服务归入此类别。我指的是像 CDN 这样的东西,像 CloudFlare 这样的东西,像精密的托管 DNS 这样的东西,像 W3 Total Cache 这样的工具(可以完成特定于 CMS 的操作以提高速度),像 SPDY 这样的东西等等。

安排日历提醒

与其只是含糊其辞地决定检查性能,不如将其明确地添加到日历中。将其设置为重复事件。

将其添加到会议议程中。创建 Slack 机器人来提醒您。做一些实际的事情。

阻止糟糕的部署

如果您拥有一个足够先进的构建和部署系统,也许您可以建立一个系统来防止导致性能下降的构建被部署。

在部署之前运行一组测试非常普遍,这通常涉及启动像 PhantomJS/无头浏览器这样的工具来检查内容。据推测,您也可以测试一些性能方面的内容。最简单的方法可能是检查请求数量和总页面重量。

影响高层领导

我试图找到一个好的来源,但没有找到。我的笔记中引用了类似这样的内容:

如果所有 CEO 都被迫在一个月内只使用手机浏览网页,网站的速度就会变得更快。

这意味着,有能力做出最大改变的人往往对这个问题一无所知。或者至少他们没有像应该的那样重视它。

我曾经听到 Lara Hogan 说:

每天向 VIP 发送一个重要的统计数据,持续两周。

不断向他们灌输一些重要的真相,可能比发送一封长篇大论的邮件效果更好,因为后者会比缓存的 HTTP 请求更快地被忽略(明白我的意思吗?)。

影响您的同事

带午餐来!与您的同事一起学习午餐。你不是孤军奋战,如果每个人都理解并站在同一战线,战斗会容易得多。

持续学习

为了助燃,继续学习更多关于网页性能的知识。你学得越多,知道的越多。我个人需要提高我的 HTTP/2 知识,因为它似乎是值得迁移的。

这里有一个值得观看的视频

另一个

好的,再来一个

Scott Jehl 还有一本关于所有这些内容的书:负责任的响应式设计