为什么Google Cloud UI这么慢？

这是我在英国的千兆互联网连接上的高端2018 MacBook Pro上收集的一些指标。

下载大小是压缩大小，JavaScript大小是未压缩的。主要内容是指例如当“云功能”变为可见时，即“完全加载”是指无需对UI进行任何更改。

我们可以看到每个页面加载了超过15 MB的JavaScript代码。查看Chrome DevTools中的性能时间表可以确认，运行此代码是导致页面性能不佳的主要原因。

本文将详细介绍Google Cloud Functions页面的页面加载过程，并研究如何加快加载速度。

您可以使用这些策略来调查并改善正在使用的应用程序的性能。

最初的HTML请求非常快，只需要150毫秒。它包含一个嵌入式SVG微调器，该微调器显示JavaScript代码的第一块正在加载的时间。

这些文件的下载时间不会太长，但是运行代码会使UI冻结一段时间。此时，微调框SVG停滞不前，直到被Google Cloud Console页面的框架UI取代为止。

初始化-浏览器运行模块初始化代码，即在加载模块而不是调用其功能之一时运行的代码

对于整个Google Cloud页面，仅解析源代码就需要250毫秒，而编译又需要750毫秒（不包括在＆＃34; Compile Script＆＃34;上花费的113毫秒）。

呈现通用Google Cloud UI后，页面将开始加载18个其他JavaScript文件，总大小为1.5 MB。

但是，发出大量单独的请求实际上不是问题-它可以通过增加缓存命中率的可能性来提高性能，并且拆分捆绑包可以轻松地仅加载必需的代码。

加载第一个设置的捆绑包后，应用程序开始发出提取请求，并再加载3个捆绑包，总大小为6 MB。

当在我的普通网络上加载页面时，所有请求都模糊在一起，很难看到哪些请求是顺序的。因此，此屏幕截图显示了受限制的连接上的请求图表。

加载云功能列表的请求大约需要700毫秒。但它不会在捆绑包加载后立即开始，部分原因是有一个testIamPermissions请求需要首先完成。

结果是CPU最终闲置了半秒钟-如果请求提早开始，这次可以更好地使用。

最终，该应用重新渲染，我们得到了我们想要查看的云功能列表。

Chrome DevTools具有一个代码覆盖率工具，可跟踪哪些代码部分实际在当前页面上运行。这可以帮助识别不必加载的代码。

“云功能”页面运行其下载的JavaScript代码的53％。这实际上有点令人失望，因为这意味着即使仅加载必要的代码，它仍只会将页面的JavaScript总大小减少一半。

实际上，大量代码由配置对象组成。例如，此200 KB对象具有4997个密钥。

使用JSON.parse将其作为JSON字符串加载可能会更快，因为JSON比JavaScript对象更易于解析。这将很容易做到，但可能不会带来巨大的性能提升。

理想情况下，该应用无需在客户端上加载完整列表，但这将很难实现。

上面的200KB JSON对象实际上包含在两个JavaScript捆绑包中。分解并重新使用它可以节省下载和处理时间。

Google云端页面会加载大型的初始JavaScript包。加载和初始化此代码所花费的时间越长，加载特定于页面的代码并呈现用户想要查看的Cloud Functions列表所花费的时间就越长。

但是初始捆绑包还包含次要内容，例如复杂的导航侧栏。在加载主页内容之前，此菜单将起作用，但应仅在主要内容之后加载。

在某些情况下，Google Cloud已经做到了这一点。例如，页面最初呈现标题的简单版本，然后在以后加载更复杂的功能。

尽管静态页面的性能通常由阻止渲染的网络请求所控制，但单页面应用程序通常会被JavaScript执行或加载帐户数据阻止。

下载大量代码可能会影响慢速连接时的性能，但是由于压缩和缓存，CPU处理通常会产生更大的影响。

为什么Google Cloud UI这么慢？本文研究了大型JavaScript应用程序的性能，并探讨了如何使其更快地运行。 https://t.co/HSHhCXYQCi

-DebugBear（@DebugBear）2020年12月9日