伊万·阿库洛夫（Ivan Akulov）是网络技术的Google开发人员专家，也是表演公司PerfPerfPerf的创始人。 很快，他将在HolyJS 2019莫斯科举行一个工作坊 ，这个工作场很奇怪，专注于性能-查找React中的问题，调试慢速的应用程序和其他运行时事物。
为了使HolyJS 2019 Moscow的读者和访问者更加关注这个话题，我们与Ivan进行了讨论：
- 最受欢迎的性能问题；
- 如何衡量绩效以及可能存在的问题；
- 如何优化性能；
- 在React中搜索性能问题；
- 切换到HTTP / 2和HTTP / 3的好处；
- 最好在新项目上使用紧凑的框架；
- 关于WebAssembly的好处；
- 在哪里寻找有用的性能信息；
- 他的工作坊将是什么，有兴趣参加的人（以及为什么要去工作坊）。
HolyJS程序委员会的Dmitry Makhnev和Artyom Kobzar提出了问题。
德米特里：跟我说说你自己。
伊万：我是Google开发人员性能顾问Ivan Akulov，在我的绩效咨询公司工作。
德米特里：你说咨询公司不是主要工作。 但是基本上你在做什么？
伊万：我的时间现在大约分配了，这样我就可以与一位老客户一起工作。 我与一家巴西公司合作，共同创建了一个Wordpress内容营销平台，管理那里的基础架构和一些产品开发，以及某种共同的愿景。
在剩下的时间里，我将致力于咨询，演讲，文章等等。
德米特里：绩效咨询有很多诉求吗？ 它甚至如何工作？
伊凡：一般来说，很大程度上取决于月份或类似的月份...
德米特里：占星家何时宣布表演月份？ :)
伊万：相反，当会计师宣布新季度时！ （笑）。 我现在没有积极寻找客户，主要原因是现在没有时间这样做，因为我已经拥有了足够的东西。 但总的来说，一切看起来像是我写了一些文章，发表了一些演讲，当与一些客户一起工作时，他们会记住我并推荐我新的。 大多数情况下，人们来感谢网络，相当酷的家伙来了。
Artyom：在创建自己的咨询公司之前，您甚至是如何谈到表演主题的？
伊万：实际上，这全都始于我们曾经在wepback上重写了Epam中的一个老旧项目半年了。 有一个老项目，有很多遗产，有自己的前端框架，其中一半在Java堆栈中工作。 而且由于我们花了半年的时间使webpack相对较快，所以我有了webpack的经验。 那时，我可以编写一个中等复杂度的webpack-config，每行20-40行，实际上是从内存中进行的，无需使用任何谷歌搜索，无需窥视甚至不使用IntelliSense。
我意识到这种经验对其他人可能会有用，所以我决定尝试在Webpack领域开始某种咨询。 我为自己着陆，将其贴在某个地方，几个人来了，我和其中一个一起工作。 一切都开始了。
后来，我顺利地从与webpack相关的性能过渡到性能咨询。
Artyom：您是否设法提高了该项目的装配性能？
伊万：那个项目进展不顺利，不像我想说的最后。 正是这些事情使这些家伙来到了我真正需要钱的时候，但他们仍然不懂得如何谈判，照顾好自己以及在这些谈判中考虑到我的利益。 我提出了一些固定的价格，但工作量却没有保证，我们努力了，我帮助了他们，做出了一些似乎可行的决定，并确定了性能。
然后发现该解决方案中存在错误，事实证明它过于复杂，在极少数情况下会弹出奇怪的错误。 我们开始修复它，我修复了一个，第二个，第三个错误，所有这些持续了一个月。 最后，到了某个时候，错误停止了发生，但是伙计们决定问我其他问题，但是由于我对此有内部预算，因此完全结束了，我只是说：“对不起，我已经装好了，没有我可以帮忙。”
结果，据我所知，他们在几个月内用另一种较为简单的解决方案替换了该解决方案，并且在100％的情况下都可以使用。
老实说，我不认识自己。看来我来了并提供了帮助，他们做出的最终决定是我们先前的谈话所为，但我不知道他们对我的帮助有多大。 以及他们对这一切的满意程度。 简而言之，它并不像我想要的那样完美。
Artyom：说到今天，您是否以某种方式跟踪过去的客户，他们在那儿的情况如何，这是否有帮助？
伊万：是的，当然可以。 我逐渐开发出一些方法。 首先，在工作结束时，我尝试从每个客户那里获得一些公共反馈，这些反馈可以发布在网站上或发布在某个地方。
其次，我开发了一种方法来询问客户在工作过程中或工作结束时的问题：“您对当前的流程，当前的工作流程，当前的工作状况如何满意？” 答案选项为“超过满意”，“满意”，“几乎满意”，“不是很满意”。
我喜欢这个问题，因为它给出了具体的答案，而不是每个人都以自己的方式理解的从1到5的愚蠢标度。 到目前为止，没有一个客户回答“几乎满意”或“不是很满意”。 很满意，很高兴，诸如此类。
Artyom：我是否正确理解您的绩效专业领域主要针对客户？ 还是您的整个网络堆栈都受到咨询的影响？
伊万：是的，专业领域主要针对客户端堆栈，而后端或数据库中的性能优化使我的工作量减少了。 但是在实践中，如果Web应用程序速度变慢，即使是某些文章或研究也是如此，那么80-90％的情况-正是由于前端而导致速度变慢。
如果有客户进来，但是事情变慢了，在大多数情况下，我的专业是正确的。
关于最受欢迎的问题
Artyom：当出现一些极端情况时会发生什么？ 当我们遇到的问题不是解析JavaScript及其启动时，而是传输问题时。 第一次交互分配给客户端以及后端时。 糟糕的是，gzip的设置不正确；它已经旋转了太长时间。 在这些情况下您会怎么做？ 如果您的分析主要集中在第一线，那么您如何找到这种情况？
伊万：嗯，这通常意味着来自服务器的响应时间变得太长。 如果我在某种审计过程中注意到了这一点，那么我会查看devtools，查看网络，然后发现从服务器到服务器的时间为800毫秒，要花点时间，这会花费很长时间。 我将尝试了解这些人如何拥有服务器，以及他们在每个答案中的工作。 如果是JavaScript或PHP，如果我不使用的其他某种语言可能需要他们的帮助，我很可能会弄清楚并修复所有问题。
德米特里：您能说出实践中遇到的前5个最常见的性能问题吗？
伊万：我会按照我记得的方式去做。 并非在复杂的Web应用程序中而是在简单的网站上发生的常见问题之一是，当开发人员或客户端将很多脚本放入head标签中而没有async或defer属性时 ，这很糟糕，因为浏览器无法开始渲染页面，直到将不会加载和执行这些脚本。
而且，如果服务器运行缓慢或大型脚本需要花费很长时间才能执行，那么使用该站点的人员将在执行结束之前看不到该页面。
另一个常见的问题是第三方脚本。 我目前正在与一位客户合作，帮助他们提高灯塔得分 。 最初，他们的灯塔得分约为35-40。 我来了，做了各种各样的事情，删除了不必要的JavaScript，阻止了渲染的资源，以某种方式进行了优化……毕竟，我的得分只增长到55分。 事实证明，如果您使用此优化页面并注释掉加载所有分析的单个React组件，那么灯塔的得分将跃升至88-90 +分。 发生这种情况是因为有太多删除指标的JS。
在某些复杂的Web应用程序中，经常出现的话题是开发人员安装某种大型库并将其完全捆绑到捆绑软件中，尽管并未完全使用。 通常是Moment.js ，其中包含巨大的本地化文件，几乎没有人需要165 KB的缩小的本地化文件，或者lodash ，其中有很多方法，并且都只使用10-20个方法。
有了渲染性能，当开发人员挂起某种事件处理程序时，通常会遇到一个问题，例如，在事件滚动上花了5到10毫秒，并且每次尝试滚动浏览某个东西时，整个页面都会滞后。 现在，这种情况变得越来越少了，因为在同一个Chrome浏览器中[添加了被动事件监听器]（ https://stackoverflow.com/questions/37721782/what-are-passive-event-listeners ）。
关于如何衡量绩效
德米特里：在案件过程中，有关灯塔的问题浮出水面。 在我看来，这三者都在BeerJS Summit上 ，并且有一个很酷的报告- （来自Alexey Kalmakov的 第一 百篇） 。 没有条目 ，但是我在Habré上看到了类似的文章 ，并且这样的内容有点损害了Lighthouse。 如果仅将其用作评估性能工程师工作的工具，则可以在其中做一些技巧。
您是否有任何工具，甚至是自己编写的工具，都可以通过这些工具清楚地评估您是否成功。 例如，您签了合同，并被告知您需要使性能提高2倍。 您将为此使用什么工具集？
伊万：好吧，首先，如果我们签订合同并就x2达成协议，那么我们将就某种文书达成协议。 但是总的来说，除了Lighthouse之外，我真的很喜欢WebPageTest 。 这是一个非常酷的高级Web性能工具，可让您在真实的，例如非常弱的设备（例如Moto G）上从真实的任意位置（例如，巴西或澳大利亚）测试应用程序。
它比Lighthouse更酷，因为它可以模拟所有这些内容，只有在真实设备上进行测试后，您才知道该网站正在渲染15秒。 第二个好处-它为各种图表（例如加载）提供了一堆超详细的指标。 我经常用它来看一些东西。
德米特里（Dmitry）：例如，您是否在Chrome DevTools协议之上编写了任何工具？ 您缺少什么工具？
伊万：我把乐器写在灯塔的上面。 要与其中一位客户一起工作，我需要一种设置，该设置可以让我在相当稳定的环境中使用Lighthouse测量一页的性能，将其视为灯塔得分并将其复制到表格中。 他有一个问题：PageSpeed Insights中的灯塔不是很稳定。 如果您对同一页进行三次测量，则可以得到三种不同的测量值。 此外，我不需要衡量已准备好并已发布在网络上的页面，而是要衡量本地页面。 唯一的选择是在本地运行Lighthouse，这也极大地影响了灯塔得分，因为 分数开始取决于您笔记本电脑上的功能。 例如，启动Docker，得分下降了2倍。
对于这种情况，我需要可预测地测量Lighthouse。 我编写了一个脚本，该脚本运行了Lighthouse三次，一个分数，取了三次的中值，并在具有许多设置的许多页面上执行了该脚本。 我为此租了一个DigitalOcean服务器，并在那里运行了所有服务器，以使其与外界因素尽可能地隔离。
Artyom：您提到了一个有趣的案例，涉及不同的Lighthouse指标。 最近有一篇文章， 《面向程序员的99％简介》 ，他们刚刚得出结论，现代基准测试工具以及原则上仅微基准测试并不能证明任何事情。
使用Dima编写的现代工具很可能证明我做了一个基准测试，如您所写，他们都会说完全不同的话。 现在，在一个缺乏或多或少的理论和统计学知识的世界中，基准测试似乎不太合理。 您提到了灯塔，但是在基准测试中是否有任何证据，还有一些其他确认？
德米特里：也许把灯塔和一些东西混在一起？ 您提到了WebPageTest。 我们接受它们，甚至可以从Chrome DevTools中获得观察结果，并以某种方式将它们混合在一起？
伊万：实际上，理想情况下，如果项目中有任何内容可以让您跟踪RUM（真实用户指标）-网站对某些用户的真实加载程度，以及是否可以将其推广到真实用户并了解如何它为他们工作-这是完美的案例。
但是总的来说，是的，如果我使用某种工具，我确实会运行一个以上的测试来获得中位数，但是总的来说，本文提出了一个真正的问题，即百分之九十九的用户拥有一切不好，我们不知道是否只使用Lighthouse，但这并不是说Lighthouse没有用，它可以继续工作并显示医院的平均温度。 如果总体上我们改善了性能，那么Lighthouse将展示它。
德米特里：您谈到了真实的用户指标。 我刚刚在Odnoklassniki工作，我们在跟踪该问题时遇到了问题，因为目前尚不清楚该如何做，而且处理量很大。 我们写了自己的并从用户那里收集，这只是一种混乱。 而且，如果这仍然是某种普通项目，那么可以从用户角度衡量什么呢？ 只是window.performance还是其他建议？ 还是使用一些棘手的策略，炮轰真实的用户帐户？
伊万：首先，可能有现成的库或服务可以让您配置RUM。 例如，在页面中添加一行，它将开始跟踪。 其次，在现代浏览器中出现了PerformanceObserver之类的东西-这是一种API，它可以测量浏览器中的各种事物，并允许您找出浏览器通常包含的度量标准，包括第一个有内容的油漆 ， 第一个有意义的油漆等。 要找出此指标，只需几行代码就足够了，您无需编写过于复杂的代码。 我订阅了这些活动，收到了并赞扬了它。
德米特里：首先要注意的最重要的事情是什么？ First Paint ， 交互 时间，第一个字节时间 ，还有其他吗？
伊万：我已经知道了[有报告]（ https://www.youtube.com/watch?v=-H1l9XBXH6Q ），我告诉您，最重要的东西是第一个有意义的绘画和互动时间。 而且，它们与准确显示用户最初的需求一样重要。 他来阅读或看东西，这是第一个有意义的绘画，或者是与应用程序一起工作，然后是时候进行交互了。 如果您要创建某种登陆页面或新闻站点，请优化第一个有意义的绘制，如果您有复杂的应用程序，则请优化第一个有意义的绘制和进行交互的时间。
Artyom：我们提到了您的实践中最受欢迎的案例。 哪些案例是最稀有或最有趣的，您必须在其中挖掘出胆量？
伊万：我想我现在有一个很有趣的案例。 我目前正在与Framer合作 。 这些家伙有一个时尚的设计工具 ，类似于Figma和Sketch 。 我帮助他们提高了运行时性能-这对我来说通常是一个超级有趣的区域。 他们使用超级特定的浏览器。 浏览器最初并不是为编写此类复杂的应用程序而设计的，因此Figma和Framer都重新实现了许多浏览器本身。 而且他们有很多开发，这些开发不在其他项目上，而且非常有趣。 我喜欢所有这些。 这确实是一件有趣的事情，有些新颖又很酷。
Dmitry：我们讨论了基本的浏览器细微差别，在继续讨论框架之前，我想学习使用该体系结构和一些数据结构进行性能优化的方法。 您是否需要在应用程序中进行如此彻底的更改，例如，为搜索添加前缀列表，还是为前端添加一些不常见的东西？ 这会发生吗？
伊万：我实际上并没有在数据结构或算法复杂性的层面上工作，因为必须做很多事情才能使应用程序减慢速度，而不是其他。 因此，对于大型项目，我强烈建议每个人在创建新项目时或者该项目刚刚开始但仍很小时，请在Next.js或Gatsby之类的框架上进行操作。
两者都是用于React的框架，该框架的构建使您只需使用该框架的几种方法编写应用程序，它就会自动变快。 这些都是非常流行的框架，它们可以完美地完成工作，我自己在生产项目中使用它们，并强烈推荐给所有人。
Artem：就在这里，我们最近发生了一起事件 ，该事件与V8内的Number设备导致V8如何优化React无关。 您是否感觉到此问题，或者是否进行了任何搜索以查明该应用程序运行缓慢的原因？
伊万：我没有也没有读过有关反优化的文章。 是否有任何特定操作或减慢了整个React的整体速度？
Artyom：通常，因为在React中，FiberNode内部有一个时间戳，并且最初将其设置为0并阻止了扩展（preventExtension），为此，分配了一个带有小整数的形状以优化数字运算。 事实证明，当时间戳记填充超过128的实际值时，事实证明有必要将结构从小整数更改为可变的堆号，并且由于调用了preventExtension，因此为每个光纤节点构建了全新的形状。 并且有成千上万。
伊万：我没有注意到这一点，也几乎没有注意到，因为在调试时，我的记忆中没有一个人在React中此操作只需要10毫秒，而应该只有20毫秒。我只是打了个比方，我在观察性能跟踪，我选择了一些速度变慢的瓶颈。 如果性能是分布式的，则V8中会有一些滞后，并且会在整个应用程序中平均分配，因此，如果我不进行非常深入的调试，则不会注意到。
如果这种情况在一次未优化的V8操作中发生并且花费了很长时间，我将注意到并进入深度调试。
Artyom：真的有React本身的问题吗，或者您必须创建一个问题以解决问题的其他框架吗？
伊凡（Ivan）：我认为我报告了两个错误，但我不记得具体细节...我不认为这是否与该问题有关，但最近我遇到了一个有趣的案例，当时CSS变量的速度比React更改应用程序的速度慢。 对我来说，这感觉很奇怪，因为我们曾经说过css超级快，然后突然比React慢得多。
我正在尝试撰写有关此内容的文章，并且通常这样工作，因为浏览器中没有优化-如果您在具有很多子元素的元素上更改css变量，则浏览器（至少是Chrome）不会记住哪个孩子们使用此变量，它会为他们计算所有孩子和样式。 如果有很多样式和节点-需要很多时间，并且用React替换一些变量，那么样式的计算可能不会发生，并且会很快发生。
根据我从V8代码了解的内容，我有80％的把握是这样，但是我可能是错的。 但这是可以在浏览器中注册和修复的东西，但这不是一个微型错误，也许有很多工作要做。 我尚未报告它，我不知道如果修复它将花费多少时间。
Artyom：您是否必须观看生成的字节码？ 使用相同的去优化视图，您将看到V8字节码，并且是否插入了任何其他操作？
伊万：不，我可能从未研究过字节码，但是我非常了解如何阅读缩小的JavaScript。 （笑）
德米特里（Dmitry）：对于前面的答案-您是否以某种方式与浏览器开发人员进行交流以澄清此类情况？ 如果是这样，他们如何回应？ 他们会回答吗？
: GDE (Google Developer Expert), Google- Slack-, Google-, Chrome. - , . , . . .
: ! .
: , Google, GDE ().
: :)
: , , , .
: , Moment.js. , , Day.js -, bundlephobia . , , , Angular, .
, , , , , , , , . ? , issue , ? , ?
: … . - , , . - , , userspace- .
, .
, , , - . webpack - . React, , API Preact , Inferno .
: ? , , , , Vue.js, , , . -?
: , . , , Angular, Angular. Angular, , . … , , . - Ext JS .
, . , . , .
WebAssembly
: , - JS, , high computation . WebAssembly, computational ?
: , WebAssembly - , .
: , , WASM. Figma, Blazor, C# WebAssembly, - . ?
: , - WebAssembly . , c WebAssembly , . .
: ?
: , . -, JavaScript - , WebAssembly , , 10 .
, , JavaScript, C++ Rust — WebAssembly . , , .
: . scroll, , . - - ? , Chrome iOS - ChromeOS - , - ? , , «.»?
: , performance IE11. , - , , IE11. , . IE11.
. «.» Chrome iOS , «.» Chromium, Chrome iOS — WebKit, iOS
: , … ()
HTTP/3
: , , . . HTTP/2, HTTP/3, QUIC . , : HTTP/2 , ?
, HTTP/3 ?
: HTTP/3 ?
: , Chrome , cURL, .
: , . , , , , HTTP/3 . Google , HTTP/3, , HTTP/3.
, , HTTP/2 , , , 2-3 , , HTTP/2 . HTTP/3 . , - , .
: , , ? , , - ?
: -, Twitter, (, []( https://twitter.com/slightlylate ), []( https://twitter.com/zachleat ), []( https://twitter.com/csswizardry ), []( https://twitter.com/igrigorik ), []( https://twitter.com/philwalton )). - Google GDE , - - performance-. .
, Calibre ( performance-) Perf.email , performance-.
: GDE! , - , . , , , ? , .
: , Service License Agreement , 95% . , performance . Juliarderity , , , . , .
: « », , . ? React, Angular .. — framework-specific , , ? TC39?
: (). , — , — .
: ?
: - . proposal, , . proposal, - . — .
: , RSS? - .
: RSS.
: , Habr, « Chrome», RSS . RSS , .
: , -, , , DevTool-, , - , , , .
: , ?
: Twitter, , -, Twitter, 20-30 . , « @vkozula ?».
, « , ». - . . , . , . Facebook- , - 50 , , .
: jsunderhood - ?
: underhood. - , . underhood, — jsunderhood 2017 , , , , , , .
: , , HolyJS jsunderhood, .. . ? , ?
: , , . , , , … , , . 10—20 .
: , ?
: , , , , , , , , . , , , Twitter , , . - Twitter Telegram , , .
Artyom：如果我们继续进行您未提及的其他活动。您主持研讨会，您似乎对此有很多经验。您认为什么样的公共访问研讨会听上去值得关注，并且您认为自己在整体展示内容方面取得了成功，并且访问者感到满意吗？
Ivan：我没有那么多研讨会，但我最骄傲的是我的webpack研讨会 ，我在2017年底对webpack进行了介绍。 不幸的是，它已经过时了，但结果却很酷，因为我计划进行在线广播，但是那天我开始疯狂地落后于Internet。
我开始领队，十分钟后我掉下来，重新连接，再次掉下来，我不得不紧急取消一切，对不起，并说我将所有资料录制在视频上并像这样放。 我做了所有的工作，结果是，它产生了一系列视频，例如egghead.io上的视频，除了一个问题，就是声音很安静，因为没有正常的麦克风。 我听到了很多评论，非常好，而且确实对人们有所帮助。
德米特里：您如何看待，为什么值得去参加研讨会呢？ 例如，如果您在浏览器上参加了一次研讨会，我经常听到人们想了解V8的内部结构或其他方面。 相反，在西方，如果您回想起酷酷的 Michel Weststrate 访谈 ，他说：“我将向他们学习。 如果我一点也不了解Docker，那么我去那里并迅速获取信息。” 您如何看待研讨会，在什么情况下建议您参加研讨会？ 学习，加深知识，看到胆量？
伊万：我会这样说-如果您觉得描述很有趣，那就来。 当我参加研讨会时，我总是尝试提供某种基础，以使那些初次使用它的人不会迷路。 我可以想象一些在超高级工作的人来听了，也许开始很无聊。 它们可能不会停留在可以提出高级主题的结尾。 另一方面，我不能保证会表现出胆量，因为所有人对“胆量”的理解都不同。 我将展示一些我在经历中遇到的非常罕见的案例，还有其他人可以展示并希望我将V8首次亮相或编译Chromium，但我不会。
德米特里：原则上，您自己通常对研讨会有什么期望？
伊万：我记得我一生中只去过两次工作坊。 两次，这对我来说都是一个新话题，我自己仍然无法弄清楚。 研讨会对我来说是某种介绍，它非常有用。
在我的工作室中，我不会对性能进行介绍，而在React中，我希望来的人能听到一些有关性能的知识，但是希望涵盖一些基本主题并尽可能地展示一些高级调试。我认识他，遇到了他。
德米特里：您整体对HolyJS有什么期望？ 也许我注意到我想与之交谈的一些报告或演讲者？
伊万：我不会提前一个月为自己计划任何事情，所以我还没有计划任何事情。 有准备，其余的会发生。 （笑）
德米特里：就这些。 非常感谢您的采访。 我们在车间里等待大家。