为什么Google Cloud UI这么慢?

2020-12-09 22:03:22

这是我在英国的千兆互联网连接上的高端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毫秒(不包括在" Compile Script"上花费的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日