网站性能不只是要使网站页面加载速度更快。 还必须向开发人员和其他项目参与者传达有效的Web资源的重要性。 性能与其他功能是功能的一部分，因此不能在某一天推迟实现。
表演主题使我很感兴趣。 我记得所有这些都是从了解“贪婪”和“分而治之”算法开始的。 花费几分钟的时间来完成代码，重做代码并使其在几秒钟内完成任务，这是一件特别令人愉快的事情。
如果我们谈论网络，那么性能问题就不一样了：通常不是计算复杂性，而是在正确的时间以最佳方式执行必要的操作。 乍一看，这个任务看似基本，但实际上要复杂得多。
翻译成Alconost史蒂夫·苏德斯（Steve Suders）是第一个对分析浏览器如何请求Web资源并等待响应感兴趣的人之一：哪些资源阻塞工作，哪些资源可以推迟，响应头会发生什么？ 根据他的研究结果，他
列出了14条用于快速加载网站的规则 。 例如，以下是
适用于YSlow工具的性能
规则（您可能已经很熟悉） 。
14条史蒂夫·苏德斯的规则（ 来源 ）如今，有越来越多的用于控制生产率的新工具：有些工具需要单独启动，而另一些工具已内置到开发和部署管道中。 其中之一就是Google的
Lighthouse ：它在PWA指示器（渐进式Web应用程序），SEO等上显示数据。
在Google I / O 2018大会上显示的Lighthouse 3.0的屏幕截图（ 来源 ）这样的工具有助于确定在完成网站时要特别注意的方面，同时，它们已经实现了许多概念，其中不那么容易理解：PRPL，RAIL，Paint Timing API，TTI，HTTP / 2，速度指数，优先提示
等 ...
为什么表演在幕后
网站的响应性问题在许多公司中都是一个严重的问题。 我们拥有出色的工具和清晰的指南，但很少有人花时间来提高生产率。 也就是说，
重点不是我们不知道为什么网站加载这么长时间。因此，我并不是要解释为什么网站性能很重要。其他资源对此进行了更好的讨论，其中包含实际项目的实际数字。
我想谈谈发展文化及其对优先事项的定义 。 仅将生产力视为项目的另一个“功能”，我们才能学习如何关注它。
如果您读过这篇文章，那么您很可能是开发人员，您会与最新的Internet技术保持同步，并且对工作效率无动于衷。 如果您问您在哪里工作以及做什么，那可能是您来自某家公司的开发部门，您的任务之一就是确保生产率。 但是
最有可能的是，部门的其余员工以及整个公司的员工都无法说同样的话 -除非您当然是独立工作。 这是正常的：不可能一无所知。
解决日常任务时，您必须从事许多技术领域的工作：开发新功能，与其他部门进行交互（添加用于分析，广告，再营销，A / B测试的脚本），组织持续的集成和交付（CI / CD），确保安全，创建一个美观且易于使用的界面。 但是您仍然需要用测试遮盖后部！
通常几乎不可能去关注其他事情：时间有限，出色的工作量往往会增加。 因此，您必须确定优先级。
优先排序应该客观地基于可测量的假设。 例如：“我们相信，随着功能X的实施，用户保留率将提高Y％”，但是实际上这看起来要复杂得多。 看一下我们必须处理的任务，并注意谁来设置它们：
- 功能的实现 。 通常，新任务由所有者或产品经理根据其愿景和团队目标来确定。 对功能的请求可能来自依赖我们工作的人员（例如，添加用于跟踪或A / B测试的第三方脚本）。
- 组织CI / CD 。 开发人员可以创建自己的管道来进行组装和部署，但是他们很可能会使用其他人（例如，基础设施部门）准备的基础设施。
- 安全性 。 如果项目有一个专门负责安全性的部门（或至少一个人），这非常好，这有助于检查系统的结构，功能的实现，向我们发送安全报告并通知更正。
- 使用者介面 通常，项目具有负责外观，可用性和信息体系结构的设计人员和/或用户交互专家。
- 测试 。 我们在哪里没有测试，对吗？
如果某人负责一项任务，则很有可能在任务板上找到该任务。 大多数任务与工作流的某些角色相关联，但有些任务是默认分配给开发人员的，例如测试：开发部门作为整体负责，因此某些组件最终要比其他组件进行更好的测试。
也许没有人会认为自动测试很有用。 通常，开发部门自行决定测试涵盖的代码范围-团队中的所有开发人员都必须能够编写测试，这一点很重要。 类似的情况是性能问题：通常认为开发人员应该处理此问题。 我注意到，
为代码编写测试并同时了解将导致一个片段错误操作的后果，要比考虑所有可能降低Web资源速度的因素要容易得多 。
实现Web资源性能重要性的六个步骤
我们有分析性能的工具，但其使用取决于开发人员本身。 如何将应该被视为生产力的一种功能引入公司？
我已经编制了一份六点清单，可以在此问题上有所帮助。
1.开发环境≠用户环境
轻松工作 ，由Emil Perron拍摄对于网站开发，我使用MacBook Pro。 我有一部iPhone X手机，并且有一个单独的测试设备。 另外，我的互联网连接非常快，而且我坐在斯德哥尔摩和伦敦的数据中心附近。 下班后，我去了4G（无间断）的地铁。 一般而言
，4G最早是在斯德哥尔摩
出现-早在2009年 。
用户几乎不会有如此优雅的条件（极少数情况除外）。
如果我们自己没有性能问题-如何确定优化任务的优先级？ 这就像在不使用键盘控件，屏幕阅读器以及检查对比色的情况下尝试为残障人士实现界面一样，这是一件很糟糕的事情。
您不必在这里等待更改：西方网络开发人员喜欢从笔记本电脑和其他设备中选择最新版本。 几乎负责制定项目和公司目标的每个人都可以这样说。 此外，在某些情况下，我们专注于高端设备-因为那些更愿意为我们的产品付费的人使用它们。
布鲁斯·劳森（Bruce Lawson）在这个问题上说，我们应该建立“全球网络，而不是富裕西方的网络”。
想一想更好的方法：吸引更多的用户，即使他们的
溶剂更少或更少但溶剂更多？
有趣的是，由于没有考虑用户在真实设备上的工作，我们最终
做出了错误的假设 。 假设我们决定促进在统计上较少用户或较少使用（例如，每个会话的页面浏览量较少）的平台的开发和放弃。
支持几乎没有任何人使用过的旧浏览器是没有意义的 。 可以说这一决定是基于可靠数据的。
但是，我们不要着急。
但是，如果某个平台上的低性能是由于我们的产品不方便或无效而导致的，该怎么办？ 这个假设很难证明，因为开发人员会说对他们来说一切都很好-在他们的计算机上和特定的浏览器中（假设它将是Google Chrome）。 我们无意间对使用的浏览器给予了更多的关注，结果，我们经常为了更现代的工作环境而妥协。 哦，我从显示器的另一端听到一阵痛苦的叫声：“仍然使用此浏览器吗？ 让他们更新！”
我最近遇到了一个我非常喜欢的报价：
“当我在Google工作时，有人告诉我一个有关他们如何完成一些重大优化的故事，突然发现页面加载时间只是增加了。 对数据进行深入研究后，我们发现了一个原因：优化后，非洲的流量开始大量增加。 以前不可能在缓慢的Internet上使用该产品，并且经过优化后才有可能，并且出现了大量用户连接较弱的情况，这增加了平均下载时间。”
- 卢丹，“互联网膨胀”
我再说一遍：通过排除性能不佳和损坏统计的用户来模拟生产力的增长很容易。 但这不是优化，而是
带有数字的
游戏 。
自己动手，分发给从事该项目的同事，旧设备。 模拟不良的连接条件，降低处理器的速度-使产品适应此情况。 找出用户拥有的设备，并优先考虑实际访问您网站的设备，尤其要保持警惕。2.最好学习技术基础而不是特定的库
到目前为止，许多工作要求和工作面试问题都集中在图书馆上，而不是基础技术上。 尽管这样问更正确：“当浏览器尝试加载网站时会发生什么？ 出于什么原因，网站加载时间可能太长？ 您将如何组织一个规模不大的Web项目（客户端，服务器，数据库，缓存）的架构？”
知道这些问题答案的开发人员将明智地为项目选择npm库。 与设计师和客户讨论功能时，他将能够对开发进行特别展示。 这样的开发人员将考虑新旧浏览器的API，并尝试利用“不便”平台，而不是孤立它。
结果，该部门可能需要聘请一位了解React或Vue的专家，并立即将其纳入工作并继续进行该项目。 同时，对于新员工来说，留在公司的时间更长，对现有技术解决方案提出质疑并提供更好的选择将是一件好事。
无论我将开发技能应用于何处，都有两个不变的常数：
- 有必要质疑自己公司的决定，否则竞争者会做出决定-并且会挺身而出。 激发项目参与者的反馈，让他们有时间开发创新的原型和试验版本。
- 今天采用的技术解决方案不会持续很长时间。 精益于模块化，可以移除组件并快速交付。
如果您同意以上内容，那么您就会对那些不致力于特定技术并且可以证明各种技术解决方案的优缺点的人的想法持开放态度。
参加面试。 预留时间让员工学习一些东西（例如，您可以在午餐时间定期做一些小型演讲），并探索有益于项目的想法。
3.抽出时间进行实验和测试。
之前，我曾向同事发送过指向Google I / O之类的会议上的演讲的链接，以及有关各种新事物的文章。 在我看来，我和他们都知道最新的事件。
无心分享与您的有趣链接，您通常只会给您的同事更多的负担：他们不仅要做工作，而且还要阅读您发送的内容。 假定学习在实践中会更好，因此他们似乎需要尝试应用这种新的库，技术，构想等。
帮他们一个忙-自己在项目中应用新颖性。 “新的浏览器API看起来很棒” –错误的评估方法。 最好这样说：
“如果您这样使用X，我们的项目将会变得更好 。” 当然，第二个难度更大，但是在这种情况下，回报率更高-说服老板更容易。
网络上有许多有关性能优化如何改善关键指标的案例研究。 关于此的大量文章来源，例如
WPO Stats 。
在许多案例研究中，提高生产率导致改善了关键绩效指标。有时，要使公司更加关注Web项目的速度，仅凭某人的实践研究还不足以作为证据。
需要一个原型。 但是似乎没有时间，而且永远也不会创建它：一切都花在了修复错误和添加新功能上。
我认为每个功能都应经历三个阶段：
这个想法可能来自产品的所有者或经理，但也可能
来自开发人员 。 有必要对其进行测试并证明其有效-为此，我们需要一个原型。 只有在那之后才能实现该功能。 另外，这意味着在执行该想法之前必须以某种形式对其进行测试。
有必要证明提高站点性能可以提高性能-但其他功能也是如此。在搜索可以加速的内容时，请选择用户可以体验的内容。
为了使用户可以在可接受的时间内注意到差异， 站点的速度应至少增加20％ ，最好
增加30％ 。
4.培训同事
您是否曾经因为没有人理解它的工作原理而不得不删除或替换某些代码，这是否曾经发生过？ 也许这个碗没有经过任何人。 如果该代码仅由其作者理解和支持，那么如果此人休假，生病，离开公司，将会发生什么？
我们利用了约翰缺席的机会-我们摆脱了不必要的复杂性。我们大多数人都是团队合作，因此在选择解决方案时，您需要关注大多数同事会理解的解决方案。
在团队中定义“最小公倍数”，并不要因为过于有趣而仅使用过于复杂的解决方案 。 在性能优化中，有时会由于复杂性的过度增加而获得很小的收益。
几个月前，
我写了关于图像优化以及如何提高视在下载速度的文章 。 我从显而易见的事情开始：减少查询，选择正确的格式，优化图像。 但是，大多数人只记得使用占位符图像，这使您可以平滑过渡到所需图片。
上传图片之前可以显示的选项。这是最有趣和创新的部分！ 真的吗 现在，尝试告诉您的同事，您将创建一个后端服务，该服务将处理排队的图像并存储一个小的草图，该草图将在渲染时嵌入到页面中。 什么时候会开火？ 需要多长时间？ 在哪里存储草图？ 如何在不同服务器上扩展此服务？
避免图像传递并优化仍要传递的图像是最有效的-这是您应该努力的目标。
除了选择大多数同事可以理解的“足够好”的解决方案之外，您还
应该考虑提高部门的知识水平 。 您是否被视为特定区域的码头？ 向您的同事做演讲，并用新的想法激励他们。
毕竟，如果您仅提倡某个想法，那么它就不会持续很长时间。
5.分享成功案例（和失败案例）
要改变公司的思维方式，您首先必须使自己的同事相信新的方法。 但是，您需要在部门外部共享实验结果。
在整个公司范围内，
这将有助于激励其他员工，并为更雄心勃勃的事业开辟道路 。 如果多个部门认为有必要，则可以更轻松地获得对正确服务和基础结构的支持。
- ,
.
-, Etsy. :
« « », , : , , , ».
— , « »
., , , .
Etsy, , .
Vox Media — ,
The Verge . 2015 . Vox Media , .
« . — . ».
— Vox Media, « » ( )
SpeedCurve , The Verge Vox Media ( )Vox Media ( , ) , .
Vox Media .: ( ), . , , .
6.
— ́ , -.
, :
WebPagetest ,
Pagespeed Insights ,
Audits Chrome . .
WebPagetest — ., , , .
, , . — .
— . .
, ( , , . .).
RUM-, . , ,
, - , .
, , — Google Analytics , — : ,
Calibre ,
SpeedCurve SiteSpeed .
, .— . (, SiteSpeed) , . , .
- Caliber . « », - . :
- . , ( , ) .
- . , , , , . , , , , .
- . , , : « - », « Caliber», «», «» « ». , , — : .
? , .
- , .
- . — .
- — , , .
- , , , .
- 该工具能够可视化绩效指标并显示其变化，当我们决定与公司的其他Web开发人员分享经验时，该工具非常有用。这种工具必须对性能指标设置限制，超过该限制将要求拒绝更改代码（或者只是发出通知）。
- 提议的工具已包含在工作流程中，我们可以毫不费力地工作-无需从其他任务中获取资源。
结论
我试图提供一些有关如何创建响应速度更快的网站的提示-希望我能成功。 感谢您的关注！
关于翻译这篇文章由Alconost翻译。
Alconost以68种语言
本地化游戏 ，
应用程序和网站 。 母语翻译，语言测试，带有API的云平台，持续本地化，24/7项目经理，任何格式的字符串资源。
我们还制作
广告和培训视频 -适用于销售，图像，广告，培训，预告片，专家，Google Play和App Store的预告片的网站。
更多细节